Zło czai się w tunelu
9 marca 2007 14:07
NetWorld
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
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 (ukrywaniu) 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.
Ukryty tunel
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
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.
Patryk Królikowski
***
Pełna treść artykułu została zamieszczona w marcowym numerze miesięcznika NetWorld.
AudioBot - odsłuchaj materiał
wydrukuj
wyślij do znajomego
