TCP, mamy problem

Dostępność pasma i dużej mocy obliczeniowej pozwala realizować ataki na protokół TCP, które wcześniej wydawały się niewykonalne.

Dostępność pasma i dużej mocy obliczeniowej pozwala realizować ataki na protokół TCP, które wcześniej wydawały się niewykonalne.

Gdy w 1996 r. haker o pseudonimie daemon9 opublikował w kultowym magazynie Phrack artykuł poświęcony fałszowaniu pakietów IP, mało kto zdawał sobie wtedy sprawę, że właśnie nastała nowa era. Artykuł ten zapoczątkował trwający do dziś intelektualny wyścig, którego stawką jest bezpieczeństwo transmisji danych. Wyścig, w którym udział biorą twórcy protokołów, starający się nie popełniać błędów, oraz naukowcy i hakerzy, którzy je odkrywają i publikują.

Specyfikacja protokołu TCP (Transmission Control Protocol) została opublikowana ponad 20 lat temu (dokument RFC 793 z 1981 r.). Na przestrzeni tego czasu wszystkie poważniejsze błędy i słabości TCP zostały zidentyfikowane i znaleziono dla nich metody zaradcze lub obejścia. Nikt nie spodziewał się, że po tak długim czasie w tej masowo wykorzystywanej technologii zostaną jeszcze odkryte jakieś poważniejsze luki. Zaufanie do TCP jest obecnie tak duże, że protokół ten zaczyna być w całości obsługiwany sprzętowo w procesorach ogólnego stosowania.

Zagrożenia jednak istnieją.

TCP został zaprojektowany jako zorientowany połączeniowo, dwukierunkowy, niezawodny protokół przesyłania danych. W ciągu 20 lat pojęcie niezawodności jednak się zmieniło. Zagrożeniem transmisji nie jest dziś słaba jakość łączy, lecz złośliwcy starający się podsłuchać lub przejąć połączenie. Ponadto, ataki, o których wiedziano już niegdyś, lecz uważano za niemożliwe do przeprowadzenia w praktyce, dzięki mocy obliczeniowej zwykłych komputerów i dostępności pasma sieciowego stały się obecnie realne. Ogłoszona niedawno "poważna dziura w TCP" należy właśnie do tej ostatniej kategorii.

Wydajność ma koszty

Działanie TCP opiera się na dodawaniu do pakietów IP nagłówków zawierających wiele flag (etykiet), za pomocą których druga strona jest informowana o stanie połączenia i które wspomagają obsługę sytuacji błędnych, np. retransmisje. Każdy wysyłany w ramach sesji TCP pakiet IP ma również tzw. numer sekwencyjny (ISN - Initial Sequence Number). To 32-bitowa liczba wybierana losowo na początku połączenia, a potem zwiększana o liczbę bajtów danych (bez nagłówków) wysyłanych z każdym kolejnym pakietem.

Odbiorca przyjmie dane po TCP tylko wtedy, gdy numer sekwencyjny otrzymanego pakietu będzie zgodny ze spodziewanym. W przybliżeniu będzie to wartość ISN ustanowiona na początku sesji zwiększona o liczbę bajtów danych już otrzymanych. Odbiorca potwierdza przyjęcie pakietów, wysyłając nadawcy pakiet z flagą ACK (od acknowledgement - potwierdzenie).

Powyższy opis to duże przybliżenie, diabeł tkwi zaś w szczegółach.

U zarania TCP sądzono, że sfałszowanie pakietu TCP będzie relatywnie trudne, będzie bowiem wymagać odgadnięcia następujących parametrów:

  • adresu IP nadawcy i odbiorcy;

  • portu źródłowego nadawcy;

  • portu docelowego odbiorcy;

  • spodziewanego numeru sekwencyjnego.
Spójrzmy jednak realistycznie. Zdobycie adresów IP komunikujących się stron jest obecnie dość łatwe - współczesne aplikacje nasłuchujące mają nawet interfejs graficzny i działają w sieciach gigabitowych! Co do portów źródłowych, jest ich co prawda aż 65535, ale większość systemów wybiera port źródłowy w sposób przewidywalny, zwykle zaczynając od 1024 i dodając 1 z każdym kolejnym wykonanym połączeniem. Porty docelowe są jeszcze łatwiejsze do ustalenia - porty usług HTTP, SMTP, FTP i innych są stałe i powszechnie znane.

Najwięcej problemów przysparza atakującemu numer sekwencyjny. Odgadnięcie liczby o długości 32 bitów wymaga wypróbowania prawie 4,3 mld kombinacji. I tak byłoby w istocie, gdyby nie tzw. okno TCP. Jeśli protokół TCP po stronie nadawcy czekałby na potwierdzenie ACK dla każdego wysłanego pakietu IP, transmisja danych byłaby bardzo niewydajna. Dlatego właśnie do TCP wprowadzono możliwość, aby nadawca mógł wysłać za jednym razem porcję danych.

Po wysłaniu danych w ramach pewnej liczby pakietów nadawca czeka na potwierdzenie pierwszego z nich i wówczas może wysłać następny nowy pakiet. Po przyjściu kolejnego potwierdzenia, nadawca wysyła kolejny nowy pakiet itd. W ten sposób w trasie znajduje się zawsze kilka pakietów, a ich liczbę określa (pośrednio - przez limit bajtów/pakiet) właśnie parametr okna TCP.

Niedomknięte okno

Owo "okno" niewątpliwie radykalnie poprawia wydajność TCP, stanowi jednak furtkę, którą można wykorzystać do modyfikacji transmisji. Zgodnie z podstawowym założeniem niezawodności TCP dane nie muszą wcale przychodzić do odbiorcy w takiej samej kolejności, w jakiej zostały wysłane. A zatem odbiorca musi być gotowy przyjąć każdy z pakietów znajdujących się w danym momencie w drodze. Dopiero później będzie układać je we właściwej kolejności.

Inaczej rzecz ujmując, z punktu widzenia odbiorcy poprawny jest nie jeden, ale bardzo duża liczba numerów sekwencyjnych. Jeżeli np. odbiorca potwierdzi pakietem ACK otrzymanie pakietu o numerze ISN równym 2000, a okno TCP wynosi 4 KB (4096 bajtów), odbiorca będzie przyjmować wszystkie pakiety o numerach ISN od 2001 do 6096. Ten właśnie szczegół leży u podstaw ataków na okno TCP.

Liczba numerów sekwencyjnych akceptowanych przez odbiorcę jest definiowana prostym wzorem:

2<sup>32</sup>/2 x win, gdzie win to długość okna wyrażona w bajtach.

To znaczy, że im większe okno, tym łatwiej jest atakującemu "wstrzelić" się we właściwy numer sekwencyjny ze względu na większe prawdopodobieństwo wystąpienia konkretnego numeru ISN w puli, której oczekuje odbiorca. W latach 80. największe stosowane okna TCP miały rozmiar ok. 4 KB, co zmuszało potencjalnego atakującego do przetestowania średnio ok. 500 tys. numerów sekwencyjnych. Przy ówczesnych przepustowościach łączy rzecz była nierealna i z tego powodu nikt nie traktował tego okna TCP jako furtki do ataku.

Współczesne systemy operacyjne powszechnie używają okien o rozmiarze 32 KB, nawet 64 KB, co radykalnie ogranicza liczbę numerów do przetestowania - przy oknie 32 KB atakujący musi przetestować 64 tys. numerów, a przy 64 KB - połowę mniej. Przy łączach DSL atak polegający na wysłaniu wielu pakietów można wykonać w czasie od ok. dwóch do kilkunastu minut.

Nie dla złośliwców

Protokół TCP nie był projektowany z myślą o bezpieczeństwie danych, lecz niezawodności transmisji. W TCP liczy się to, by wszystkie dane dotarły do adresata postaci niezmienionej pomimo zakłóceń i zmieniających się warunków, np. zmieniające się topologie i ścieżki routingu, straty pakietów, zmieniona kolejność przychodzących fragmentów itd.

Dzięki stosowanym dziś stosunkowo dużym oknom TCP atakujący może wysyłać do sieci spreparowane pakiety IP zawierające np. kod wirusa lub flagę RST oznaczającą zerwanie połączenia. Właściwy (w danym momencie) numer sekwencyjny można uzyskać na dwa sposoby: albo bezpośrednio podsłuchując połączenie TCP, co ogranicza zasięg ataku do lokalnego segmentu sieci przez który przechodzi połączenie, albo zgadując go, wysyłając do sieci pakiety z wieloma różnymi numerami ISN. W przypadku długotrwałej (trwającej co najmniej kilkanaście minut) sesji TCP istnieje duża szansa, że pakiety wysyłane przez intruza zostaną przyjęte przez odbiorcę i przeniesione do wyższych warstw jako prawidłowe dane.

Wbudowane w TCP zabezpieczenia przed przypadkowym przekłamaniem danych nie chronią go przed celowymi atakami. Do tego celu należy wykorzystać dedykowane protokoły bezpieczeństwa, takie jak IPsec.


TOP 200