Zło czai się w tunelu

Temat tunelowania informacji nie jest nowy. Przeważnie jednak myślimy o nim w kontekście zapewnienia bezpiecznego dostępu do zasobów sieci dla użytkowników mobilnych, oddziałów czy też partnerów biznesowych. Niestety tunelowanie może też służyć do ukrywania strumienia nieautoryzowanych danych wewnątrz innego, dozwolonego.

Temat tunelowania informacji nie jest nowy. Przeważnie jednak myślimy o nim w kontekście zapewnienia bezpiecznego dostępu do zasobów sieci dla użytkowników mobilnych, oddziałów czy też partnerów biznesowych. Niestety tunelowanie może też służyć do ukrywania strumienia nieautoryzowanych danych wewnątrz innego, dozwolonego.

Gdy chcemy tunelowanie wykorzystać do zabezpieczenia naszych danych, szukamy sprzętowych i programowych rozwiązań, które - mówiąc w dużym uproszczeniu - pozwolą na transmisję informacji w postaci zaszyfrowanej po łączach, które nie mogą być uznane za bezpieczne, np. internetowych. Chodzi o stosowanie tuneli w klasycznym rozumieniu tego słowa, a więc o rozwiązania VPN wykorzystujące chociażby takie protokoły, jak IPSec czy GRE. Jako administratorzy to my kontrolujemy budowę takich tuneli, autoryzujemy użytkowników, którzy powinni mieć do nich dostęp oraz określamy, jakiego rodzaju dane oraz gdzie mogą nimi płynąć.

Policjanci i złodzieje

Zło czai się w tunelu

Ukryty tunel

Niestety od dłuższego czasu na scenie bezpieczeństwa funkcjonują techniki i rozwiązania, które powodują, że cały czas zastanawiamy się nad tym, czy wszystkie aspekty ruchu są pod kontrolą. Bo możliwe jest przesyłanie (ukrywanie) strumienia nieautoryzowanych danych wewnątrz innego, dozwolonego - czyli tworzenie tzw. ukrytych tuneli (covert channels).

Większość z nas wie, albo przynajmniej słyszała co nieco o steganografii. Informacje ukrywamy bardzo często i wszędzie tam, gdzie jest to możliwe: szyfrujemy i ukrywamy woluminy, chowamy dokumenty wewnątrz plików muzycznych czy zdjęć itp. Jednak znacznie ciekawsza zabawa zaczyna się, jeżeli ktoś próbuje coś ukryć przed wścibskim okiem administratora lub zwyczajnie szuka sposobów na uzyskanie dostępu do zasobów, których strzeże brama dostępowa. Zabawa ta ma charakter dwustronny - z jednej strony cwany superużytkownik szuka sposobów przeniknięcia zapory, zaś z drugiej czuwa waleczny administrator, który musi wykryć i zniweczyć niecne zamiary tego pierwszego. Prawie jak zabawa w policjantów i złodziei. I na ten właśnie aspekt tunelowania postaramy się rzucić nieco światła, wcielając się w rolę napastnika.

Niezły kanał

Ukryte tunele i ukrywanie wewnątrz nich danych funkcjonują już od dłuższego czasu. Pierwsze wzmianki o nich pojawiły się już w latach siedemdziesiątych ubiegłego stulecia. Ukrywanie danych w komunikacji sieciowej nabrało rozpędu w połowie lat 90. Wówczas po raz pierwszy dokładnie opisano i zaprezentowano sposoby funkcjonowania ukrytych tuneli, głównie w oparciu o grupę protokołów TCP/IP v4. Potem pojawiły się (i dalej powstają) inne przykłady tworzenia ukrytych kanałów, coraz bardziej przemyślne techniki wykorzystujące całą gamę protokołów. Wraz z wprowadzeniem IPv6 odkryto nowe możliwości - choć obecnie w zasadzie tylko w Japonii jest to zaimplementowany na szeroką skalę standard.

Tak jak w standardowej, pozasieciowej steganografii i w tym przypadku cele mogą być trzy: albo ukrycie tego co jest transmitowane, albo ukrycie samego faktu transmisji, albo i jedno, i drugie. W szarej rzeczywistości najczęściej wystarczy ukrycie samego faktu transmisji. Możemy w zasadzie mieć pewność, że zajęci administratorzy nie będą nas niepokoić, dopóki nie dostaną maila typu Critical/High z systemu korelacji zdarzeń albo naszą działalnością nie "zjemy" 50% łącza. Co można ukrywać? Wszystko. Dzięki tunelom uzyskamy dostęp do domowej poczty, konsoli serwera P2P, uruchomimy upragnione Gadu-Gadu.

Skoro najpopularniejszym obecnie stosem protokołów jest TCP/IP v4, skupmy się na tym, jakie daje on możliwości ukrywania i tunelowania danych. Jak dowodzi teoria poparta praktyką, tunelowanie jest możliwe niemalże w każdej z warstw modelu OSI - począwszy od 2 wzwyż. Postarajmy się więc odpowiedzieć na pytanie - jak?

Za niskie progi

Zło czai się w tunelu

Nagłówek IP

Rzućmy okiem na warstwy modelu OSI. Z punktu widzenia ukrywania danych najbardziej interesujące są warstwy: łącza danych, sieci, transportowa oraz aplikacyjna. Ukrywanie danych w warstwie drugiej jest tematem niewdzięcznym i omijanym. Dzieje się tak dlatego, ponieważ istnieje wiele problemów, które należałoby wcześniej rozwiązać. Problemów, które wynikają z samej koncepcji funkcjonowania warstwy drugiej.

Jak wiadomo, warstwa ta odpowiada za dostarczanie ramek pomiędzy kolejnymi urządzeniami w sieci lokalnej, a komunikacja na tym poziomie jest ściśle związana ze sprzętem i nigdy nie przekracza granicy LAN/Internet. To sprawia, że jej użyteczność do zabawy w chowanego jest co najmniej wątpliwa, zwłaszcza w sieciach gdzie jako medium wykorzystywany jest kabel. Anonimowość takiej komunikacji też pozostawia wiele do życzenia.

Nie jest jednak aż tak nudno i bezbarwnie. Prowadzone są bardzo interesujące prace nad mechanizmami ukrywania danych w warstwie łącza danych w sieciach bezprzewodowych (np. system HICCUPS autorstwa Krzysztofa Szczypiorskiego, wykorzystujący system detekcji kolizji CSMA/CD). Są to jednak w większości tylko koncepcje i dlatego też darujemy sobie tę warstwę i przejdziemy oczko wyżej.

W warstwie trzeciej - sieci - pojawia się nieco więcej możliwości. Tutaj m.in. rezyduje protokół IP odpowiedzialny za adresację i ruting. Począwszy więc od warstwy sieci jesteśmy w stanie wyjść poza granice sieci lokalnej.

Do ukrywania danych w protokole IP mogą posłużyć różne pola w jego nagłówku. Dobrym przykładem jest dwubajtowe pole ID. Dzięki niemu możliwa jest fragmentacja pakietów i później prawidłowe ich złożenie. Jeżeli jednak przesyłane pakiety nie są poddawane fragmentacji, nic nie stoi na przeszkodzie, aby pole ID wykorzystać jako schowek. Podobnie sprawa ma się z polami Flags czy Options. Korzystanie z nich nie jest obowiązkowe, a więc pozostaje miejsce na ukrywanie danych. Niestety, obydwa pola są tak rzadko używane, że wykrycie modyfikacji jest dość proste.

Również w warstwie trzeciej działa inny protokół, który na pierwszy rzut oka nie przedstawia większej wartości dla osoby chcącej przemycić transmisję. Jest to jednak całkiem użyteczny transporter. ICMP, bo o nim mowa, odpowiada za generowanie informacji związanych z komunikacją IP. Najlepiej do celów ukrywania i tunelowania informacji nadają się dwa typy ICMP - 8 (echo request) oraz ICMP - 0 (echo reply). Jednym z pierwszych rozwiązań wykorzystującym ICMP do ukrywania innej komunikacji był Loki, potem jego sukcesor Loki 2. Znakomitym przykładem wykorzystania ICMP do tunelowania ruchu TCP jest niewielka aplikacja Ping Tunnel (ptunnel -http://www.cs.uit.no/~daniels/PingTunnel/ ).

Zło czai się w tunelu

Ping Tunnel w działaniu - widok na komputerze Klient

Ciekawe, że aby rozwiązanie to zadziałało, wystarczy, by firewall przepuszczał pakiety ICMP na zewnątrz, a to zdarza się dosyć często. Aby skorzystać z aplikacji ptunnel, potrzebujemy praw administratora na naszym komputerze oraz uruchomionej aplikacji ptunnel w trybie nasłuchiwania na komputerze, który wykorzystamy w charakterze proxy. Aplikacja jest dostępna zarówno w wersji dla systemu Windows, jak i Linux. Autor na własnej skórze przekonał się, że wersja dla Linuxa działa jednak znacznie stabilniej.

Ptunnel oferuje jeszcze dodatkową funkcjonalność polegającą na zabezpieczeniu dostępu do nasłuchującego proxy hasłem. Jednak żeby z niej skorzystać, musimy posługiwać się systemem spod znaku pingwina (konfiguracja - zob. Ekran: Ping Tunnel w działaniu - widok na komputerze Klient). Nieco nowszą aplikacją wykorzystującą tzw. IP-over-ICMP jest ICMPTX (warto spojrzeć na stronęhttp://thomer.com/howtos/nstx.html , ponieważ jego konfiguracja potrafi być męcząca). Widać więc, że blokowanie popularnych "pingów" nie jest pozbawione sensu, a celem jest nie tylko utrudnienie wykrycia maszyny, ale także uniemożliwienie wykorzystania tego prostego protokołu jako medium.

Potrzebuję transportu

Warstwa czwarta jest nie mniej interesująca - transport danych to idealne miejsce do chowania informacji i podszywania się. Najpopularniejszymi protokołami działającymi w tej warstwie są: TCP, UDP i DNS. TCP i UDP odpowiadają za doręczanie pakietów z miejsca A do miejsca B z tą różnicą, że TCP daje gwarancję. Badacze analizujący ruch w Internecie stwierdzili, że za dostarczenie ponad 80% danych odpowiada właśnie TCP.

Podobnie jak w przypadku IP dzięki modyfikacjom w nagłówkach protokołu TCP otrzymujemy spore możliwości ukrywania. W przypadku TCP najczęściej "grzebie" się w ISN (Initial Sequence Number). ISN jest to czterobajtowe pole, które pozwala jednej stacji na wynegocjowanie połączenia Three Way Handshake - SYN - SYN/ACK - ACK. Znakomicie nadaje się do tunelowania z przynajmniej dwóch powodów. Po pierwsze, 32 bity to pokaźna ilość miejsca na dane. Po drugie, numer ISN powinien być generowany losowo, a więc trudny do odgadnięcia i co za tym idzie trudniejsze jest rozpoznanie modyfikacji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200