Quick tip – Cisco VPN – i zmiana tablicy routingu

Ostatnio natrafiliśmy na ciekawy problem podczas używania klienta VPN Cisco AnyConnect. Mianowicie: po utworzeniu tunelu VPN-owego, klient ustawia swoje własne tablice routingu, w czym oczywiście nie ma nic dziwnego, jednak później stale je monitoruje, nie pozwalając na żadną zmianę.  Wyobraźmy sobie więc następującą sytuację:

• Tworzymy tunel VPN za pomocą klienta Cisco,
• Okazuje się, że VPN jest skonfigurowany w taki sposób, że cały ruch internetowy jest przepuszczany przez niego. My jednak chcemy, żeby przez VPN-a odbywał się ruch tylko do jednego konkretnego adresu IP,
• Próbujemy więc dostosować tablice routingu w systemie do swoich potrzeb…
• … nie możemy jednak tego zrobić, gdyż VPN automatycznie cofa każdą naszą zmianę!

Powyższy problem można łatwo potwierdzić, jeśli odpalimy w jednym terminalu polecenie route add -net 192.168.56.0/24 p7p1 a w drugim ip monitor route (polecenie do śledzenia zmian w tablicy routingu). (Rys. 1).

Rys 1. Automatyczne usunięcie dodanej tablicy routingu przez Cisco VPN

Zaczęliśmy się zastanawiać, w jaki sposób możemy rozwiązać ten problem. Jedną z pierwszych, choć niezbyt rozsądnych, propozycji były próby nieustannego ustawiania nowej reguły w pętli, licząc na to, że vpn nie będzie nadążał z usuwaniem. Rozwiązanie w pewnym stopniu działało, ale było niestabilne i powodowało duże zużycie procesora.

Okazało się, że problem jest znany i w internecie istnieją jego rozwiązania, np. polegające na nadpisaniu jednej z funkcji agenta VPN, tym samym sprawiając, że monitorowanie tablic routingu nie jest wykonywane. Okazuje się jednak, że i ten sposób prowadzi do 100% zużycia CPU.

W końcu wpadliśmy na inne rozwiązanie: skoro tunel VPN-owy jest już zestawiony i działa (utworzone są interfejsy itp.), to de facto daemon odpowiedzialny za utrzymywanie VPN-a nie potrzebuje już praw roota do działania, natomiast prawa roota są niezbędne by usunąć cokolwiek z tablicy routingu. Jeśli więc zmienimy uprawnienia działającego procesu VPN z roota na dowolnego innego użytkownika, podstawowa funkcjonalność powinna zostać zachowana, zaś pozbędziemy się niepożądanego zachowania. Sprawdźmy to!

Zaczynamy od ustalenia ID procesu vpnagentd i podpinamy pod niego gdb (Rys 2.).

Rys 2. Szukamy procesu vpnagentd i podpinamy gdb

W gdb wystarczy skorzystać z wywołania funkcji seteuid() , podając w argumencie dowolny uid innego użytkownika (Rys 3.)

Rys 3. Wywołujemy seteuid

Po wszystkim wychodzimy z gdb i potwierdzamy, że właściciel procesu rzeczywiście został zmieniony (Rys 4.).

Rys 4. Proces vpnagentd działa teraz z uprawnieniami innego użytkownika

Teraz wystarczy już tylko dodać nowy wpis do tablicy routingu i cieszyć się, że Cisco VPN go nie usunie ;) (Rys 5.).

Rys 5. Polecenie „route add” zakończone sukcesem

–Michał Bentkowski, realizuje testy penetracyjne w Securitum.