Quick tip – Cisco VPN – i zmiana tablicy routingu

10 lipca 2015, 16:33 | Teksty | komentarzy 15
Tagi: , ,
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

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

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

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

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

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

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

–Michał Bentkowski, realizuje testy penetracyjne w Securitum.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Można też po prostu zamienić oryginalnego klienta Cisco na darmowy vpnc, który wszystkie operacje związane z tablicą routingu przekierowuje z głównej binarki do osobnego skryptu shell (dzięki temu binarka ma mniej zależności od konkretnych bibliotek, a w shellu łatwiej ogarnąć rozbieżności pomiędzy systemami operacyjnymi).

    Tak więc w vpnc możemy swobodnie grzebać w skrypcie shellowym i nie tylko zabronić klientowi usuwania wpisów z tablicy routingu, ale wręcz je automatycznie tworzyć po nawiązaniu połączenia w taki sposób, jak jest wygodnie nam, a nie adminowi tego VPN-a.

    Odpowiedz
    • yzo

      Albo ShrewVPN, też pozwala manipulować tablicami.
      Swoją drogą ciekawe, czy takich manipulacji, jak opisana w artykule, nie zabrania umowa licencyjna tego klienta… nie zdziwiłbym się.

      Odpowiedz
      • Żeby tylko się nie okazało ze użycie ShrewVPN też jest niezgodne z licencją ;)

        Odpowiedz
  2. kramer

    przydatny trick. dzieki.

    Odpowiedz
  3. manto

    swietne… +1

    Juz wiem, czemu jeden z serwerow anyConnecta z ktorego korzystam, nie wpuszcza klientow linuksowych (ani vpnc ani oryginalnego ciscowego) :-). Choc slyszalem tez, ze trzeba wykupic oddzielna licencje na obsluge klientow linuksowych – ale nie chce mi sie w to wierzyc.

    A udalo sie komus oszukac taka konfiguracje – tzn. blokujaca dostep linuksowego klienta? Nie musialbym sie meczyc z winda.

    Odpowiedz
    • Postaw sobie router VPN na jakiejś wirtualce – po prostu niech sobie działa Windows z klientem VPN, a na innych komputerach dodaj wpis do tablicy routingu, kierujący ruch do wnętrza VPN na tą wirtualkę.

      Odpowiedz
      • manto

        Niestety konfiguracja VPNa odcina LAN. I poki nie ma podobnego tricka jak powyzszy na widnows, to takie rozwiazanie nie zadziala.

        Odpowiedz
  4. Adam

    Z tymi klientami alternatywnymi nie jest tak prosto jak mogłoby się wydawać. Firewall ASA sprawdza wersję klienta AnyConnect który się połączył i jeżeli wersja się nie zgadza, następuje jego aktualizacja do wersji podawanej z firewalla.

    Odpowiedz
    • Mówisz o tej samej wersji, którą w vpnc można ustawić poleceniem –application-version? :)

      Odpowiedz
  5. ssl

    Zapominacie o jednej bardzo ważnej rzeczy, wszystkie alternatywne klienty podane wyżej nie wspierają SSLa więc jak wymusi się że VPN ma być po SSL to teraz tylko AnyConnect.

    Odpowiedz
  6. tomek

    ale przekombinowane ;]

    vpnc przyjmuje dodatkowa opcje w configu ustawiajace tylko te routy ktore chcesz ( przydatne, gdy na jednym serwerze odpalonych jest kilka vpnc tuneli). to samo z anyconnectem.
    w sumie jest to obrzezany kawalek vpnc-script:

    Script ifconfig $TUNDEV inet $INTERNAL_IP4_ADDRESS pointopoint $INTERNAL_IP4_ADDRESS netmask 255.255.255.255 mtu 1412 up 2> /dev/null ; ip ro add X.X.X.X./X dev $TUNDEV

    Odpowiedz
    • No tak, tylko rzecz w tym, że administrator VPN może wyłączyć split-horizon, czyli wymusić, że cały ruch (również do Internetu) ma iść przez VPN.

      Cały artykuł i komentarze dotyczą właśnie *omijania* tego wymysłu.

      Odpowiedz
  7. q

    Sztuczki z ldpreload nie działają?

    Odpowiedz
  8. Zbyszek

    Poproszę jakiś tip dla klienta cisco anyconnect na windowsa… :)

    Odpowiedz
  9. gbajson

    vpnc jest calkiem calkiem, ale niestety:
    a) wywala sie,
    b) nie wspiera wszystkich opcji (man […] Note: cisco-tcp encapsulation is not yet supported)

    c) ale jak sie da uzyc, to tez polecam!!!

    Odpowiedz

Odpowiedz