Kolejną popularną odmianą steganografii jest steganografia sieciowa, poświęcona technikom tworzenia ukrytych kanałów w protokołach sieciowych. Użycie ukry- tego kanału pozwala na przekazanie sekretnej wiadomości poprzez sieć, która może być narażona na podsłuch lub manipulację. Przesyłane pakiety danych pozwalają jednak na ukrycie względnie krótkich informacji. Przestrzeń do wykorzystania często wynosi tylko kilka bitów. Samo utworzenie dodatkowego kanału komunikacji polega na podważeniu bezpieczeństwa protokołu sieciowego [1] i znalezieniu takich obszarów, których modyfikacja nie zakłóci poprawnej transmisji danych. Do wprowadzenia zmian idealnie nadają się fragmenty obecnie nieużywane – pola wchodzące w skład specyfikacji nagłówka danego protokołu, jednak niemające znaczenia. Jako główny przykład wykorzystania fragmentów nagłówków pakietów w tym rozdziale posłuży stos TCP/IP.

Budowa protokołów TCP i IP

TCP/IP (ang. Transmission Control Protocol / InternetProtocol) to rodzina protokołów sieciowych służących do wymiany danych pomiędzy urządzeniami w sieci.

Model TCP/IP implementuje najważniejsze funkcjonalności standardowego modelu OSI1 , jednak składa się z mniejszej ilości warstw.

Każda wiadomość wysłana przez aplikację przechodzi przez wszystkie warstwy TCP/IP, od warstwy aplikacji do najniższej – dostępu do sieci. Kolejne warstwy dodają kontrolną informację jako nagłówek (ang. header). Proces ten nazywa się kapsułkowaniem. Następnie wiadomość jest transmitowana przez sieć do drugiego komputera. Przy odbiorze przechodzi przez wszystkie warstwy i nagłówki w przeciwnym kierunku (również pola poszczególnych nagłówków są odczytywane w kolejności odwrotnej – od prawej strony do lewej – 5.1), aż do warstwy aplikacji i docelowego procesu. Tajne informacje mogą być ukryte i przesyłane właśnie w nagłówkach, zawierających losowe liczby. Wielkość oraz zawartość poszczególnych nagłówków zależą od użytych protokołów.

Wysyłanie i odbieranie wiadomości

Wysyłanie i odbieranie wiadomości

TCP (ang. Transmission Control Protocol) – jest to strumieniowy protokół połączeniowy, który jest częścią protokołu TCP/IP. Protokół TCP umożliwia detekcję i korekcję przesyłanych pakietów. Składa je w całość i steruje ich ruchem. TCP jest protokołem niezawodnym, co oznacza, że każda wysłana wiadomość wymaga potwierdzenia przez odbiorcę jej dostarczenia, w przeciwnym razie następuje retransmisja pakietu danych.

Nagłówek protokołu TCP

Grafika prezentuje zawartość nagłówka TCP. Pola, które mogą być potencjalne użyte do celów steganograficznych, pozostały w kolorze białym.

Struktura nagłówka TCP

Struktura nagłówka TCP

Początkowy numer sekwencyjny
Numer porządkowy (ang. Initial Sequence Number, w skrócie ISN) to numer bajtu w strumieniu przesyłanych danych, który identyfikuje pierwszy bajt danych w kolejnych segmentach TCP. ISN jest liczbą losową, mieszczącą się na 32 bitach. Pole to nie musi być unikatowe, ponieważ jest używane tylko raz, podczas nawiązywania połączenia. Powoduje to, że przesyłanie ukrytych danych w dalszej transmisji nie jest możliwe. Do efektywnego przesłania ukrytych informacji w ten sposób należy jednocześnie przesyłać je w wielu połączeniach, na przykład przez stronę WWW bogatą w dane multimedialne i wykorzystującą protokół HTTP 1.0. Każdy zasób strony (strona HTML, arkusz CSS, obrazek, dźwięk itp.) powoduje otwarcie nowego połączenia TCP. Wykrycie powyższej metody jest trudne,
ponieważ konieczne jest monitorowanie wszystkich nawiązywanych połączeń TCP i analiza każdego numeru sekwencyjnego. Zapobieganie ukrytej transmisji polega na zastosowaniu technik proxy dla wszystkich połączeń podejrzanych o przenoszenie ukrytych informacji. Nie jest to łatwe zadanie i może się zdarzyć, że maszyna realizująca to zadanie potrzebuje znacznych zasobów przy intensywnej transmisji danych.

Pole zarezerwowane
Aktualnie sześciobitowe pole zarezerwowane nie jest wykorzystywane. Według dokumentu RFC2 definiujacego protokół TCP, pole to musi mieć zawsze wartość zero. Sieć jednak zazwyczaj ignoruje to pole i przepuszcza również inne wartości. Sytuacja wygląda podobnie jak w przypadku niewykorzystanych bitów pola TOS oraz flagi RF. Wykrycie i ograniczenie dodatkowej transmisji jest łatwe — wystarczy wyzerować pole zarezerwowane.

Wskaźnik ważności
Pole Urgent Pointer składa się z 16 bitów i jest bardzo rzadko stosowane. Według definicji protokołu pole to ma zastosowanie, tylko gdy jednocześnie zostanie
ustawiona flaga URG w nagłówku segmentu TCP. Przy próbie wysłania ukrytych danych przez pole wskaźnika ważności flagę URG należy zostawić wyzerowaną.
Wówczas wskaźnik ważności nie będzie interpretowany. Taki pakiet zostanie przesłany, mimo braku zgodności z dokumentem RFC.

Ukryty kanał w takiej formie warto ograniczyć i nie wykorzystywać całych 16 bitów pojemności pola. Pole wskaźnika ważności jest przesunięciem, wskazuje na ostatni „ważny” bajt w segmencie i jest dodawane do numeru sekwencyjnego w nagłówku segmentu TCP. Wielkość Maximum Transmission Unit (MTU) ogranicza rozmiar datagramu IP i dla sieci TCP/IP, ma na ogół wartość 1500 oktetów. Po pomniejszeniu tej wartości o minimalne rozmiary nagłówków IP i TCP uzyskamy 1460. Chcąc, aby nasza wiadomość była prawdopodobna i wiarygodna musi być krótsza od 1460 bajtów. Inna wartość pola wskaźnika ważności niż 0 przykuwa uwagę i jest podejrzana; jeśli do tego flaga URG jest ustawiona na 0, to łatwo jest dostrzec stworzony ukryty kanał.

Pole opcji
Występuje zarówno w nagłówku IP jak i TCP. Opcje protokołu TCP mają jednak zastosowanie w przeciwieństwie do nagłówka IP. Możliwe jest również tworzenie własnych opcji, nieuwzględnionych w protokole. Ograniczeniem wielkości jest jedynie maksymalna pojemność segmentu TCP. Użycie niecodziennych opcji wzbudzi jednak zainteresowanie, przez co fakt przesyłu dodatkowych informacji stanie się łatwy do wykrycia.

Protokół IP
IP służy do przesyłania pakietów danych przez sieć. Obecnie używane są dwie wersje tego protokołu: IPv4 (IP version 4) i IPv6 (IP version 6). IP w przeciwieństwie do TCP nie zapewnia żadnego systemu potwierdzania dostarczenia wiadomości. Pakiety danych otrzymywane z warstwy transportowej są dzielone na mniejsze datagramy. Każdy datagram zawiera nagłówek IP oraz bajty otrzymane z warstwy transportowej.

Struktura nagłówka IP

Struktura nagłówka IP

W nagłówku protokołu IP można wskazać kilka elementów, które mogą stanowić budulec ukrytego kanału. Na rysunku pozostały one w kolorze białym.

Typ obsługi
Pierwszym wyróżnionym polem nagłówka jest „Typ obsługi” (ang. Type of Service, w skrócie TOS). Jest to pole o pojemności 8-bitów i nie ma jednoznacznie określonej budowy, co oznacza, że może zostać wykorzystane w protokole, ale nie musi. Zależy to od używanego sprzętu lub oprogramowania.

  • użyć wszystkich 8 bitów do przesyłania danych;
  • wykorzystać jeden, nieużywany (najmłodszy) bit, by nie wpływać na wartości już wpisane do pola i nie zaburzać sposobu transmisji;
  • wykorzystać jeden bit, który normalnie jest stosowany, na przykład bit określający małe opóźnienie (bit 4.);
  • użyć trzech skrajnie lewych (najstarszych) bitów pola TOS, określających pierwszeństwo, a w praktyce ignorowanych w większości sieci;
  • wykorzystać dwa najmłodsze, nieużywane bity pola DSCP (ang. Differentiated Services Code Point) w sieciach wykorzystujących techniki przypisania różnych poziomów usług.

Powyższe metody różnią się pojemnością utworzonego ukrytego kanału oraz stopniem wykrywalności. Kanał utworzony w polu TOS jest podatny na zamazanie lub usunięcie. Jeśli w danej sieci pole to nie jest obsługiwane, routery mogą je ignorować lub zerować, czyli zamazywać. Natomiast jeśli pole jest używane, możliwe jest automatyczne ustawianie go w routerze zgodnie z wcześniejszą konfiguracją.

Pole identyfikacji
Kolejne pole to 16-bitowe pole identyfikacji, które musi być unikalne w ramach jednej transmisji (nadawca-odbiorca). Nie istnieje narzucona zależność pomiędzy kolejnymi numerami identyfikacyjnymi pakietów, więc można dowolnie zmieniać wartości tego pola. Jeżeli numery identyfikacji będą niepowtarzalne, a wartości pól identyfikacji będą niezależne od siebie i analiza statystyczna niemożliwa do wykonania, to tak utworzony kanał będzie stosunkowo bezpieczny. Jeśli jednak modyfikacja pola identyfikacji zostałaby wykryta, atak na taki kanał jest znacznie trudniejszy niż dla pola Type of Service.

Pole flag fragmentacji
W protokole IP występują trzy flagi, określające pożądane traktowanie data-
gramu w przypadku wystąpienia konieczności przeprowadzenia jego fragmentacji.
Kolejno od lewej (od najstarszego bitu) są to:

  • RF – (Reserved Flag) to najstarszy, nieużywany bit, posiada zawsze wartość 0. Ustawienie tego bitu nie wpływa na sposób traktowania diagramów przez routery, więc jest możliwe wykorzystanie nieużywanej flagi fragmentacji do transmisji danych.
  • DF – (Don’t Fragment) – ustawienie tej flagi oznacza brak zgody na przeprowadzanie fragmentacji tego datagramu (jeśli datagram musi być poddany fragmentacji, a flaga DF jest ustawiona, to datagram zostanie odrzucony);
  • MF – (More Fragments), ustawiona oznacza, że dla datagramu nastąpiła fragmentacja i występują po nim kolejne pakiety. Ostatni fragment datagramu ma tę flagę wyzerowaną.

Kanały oferowane przez flagi mają bardzo małą pojemność i są łatwo wykrywalne.

Pole opcji
W większości przypadków pozostaje nieużywane i posiada zmienną długość. Za pomocą tego pola możliwe jest definiowanie własnych opcji, które są numerowane
i dzielone według własnego upodobania. Umożliwia to wykorzystanie numerów dotąd nieużywanych do przesyłania danych. Pojemność jest wtedy ograniczona jedynie przez rozmiar danych niesionych przez datagram oraz maksymalną wielkość jednostki transportowej. W przypadku wykorzystania opcji zdefiniowanych na podstawie dokumentacji RFC, która opisuje protokół IP, wielkość ukrytego kanału waha się od jednego bitu na opcję do kilku bądź kilkunastu bajtów dla opcji z parametrami. Korzystanie z opcji definiowanych w RFC niesie jednak ryzyko, że dane mogą zostać usunięte przez poprawnie skonfigurowane routery. W przypadku definiowania własnych opcji dane zostaną przepuszczone przez router, jednak mogą wydać się podejrzane ze względu na brak zgodności z dokumentem RFC.

Metoda RSTEG

Jednak steganografia sieciowa to nie tylko modyfikacja nagłówków. Do przesłania steganogramu można użyć również mechanizmu retransmisji utraconych pakietów. Metoda RSTEG (ang. Retransmission STEGanography) opiera się na protokole TCP i wykorzystuje fakt, że brak potwierdzenia odebrania pakietu oznacza, że pakiet nie dotarł do odbiorcy. Obie strony tajnej komunikacji muszą być wtajemniczone w plan i działać świadomie. Jeśli w pewnym momencie host pełniący funkcję odbiorcy, mimo otrzymania pakietu nie wyśle potwierdzenia, dla nadawcy jest to sygnał, że musi przeprowadzić retransmisję danych. W tym momencie zamiast właściwego pakietu wysyłany jest pakiet ze steganogramem. Odbiorca wie, że kolejny pakiet będzie zawierał tajne informacje, więc bez problemu go odbiera. Procedurę można powtórzyć dowolną ilość razy a z uwagi na to, że retransmisje w sieciach komputerowych są powszechnym zjawiskiem, rozpoznanie tak przeprowadzonej wymiany danych jako anomalii jest dość trudne.

Protokół VoIP

VoIP (ang. Voice over Internet Protocol) to protokół do przesyłania informacji głosowych w formie pakietów IP. Komunikacja VoIP składa się z trzech faz. Najpierw nawiązywane jest połączenie między nadawcą a odbiorcą, później następuje faza z wymianą właściwych informacji. Trzecią fazę stanowi rozłączanie. Rozwiąznie VoIP bazuje również na innych protokołach, w których możliwa jest steganografia.

Najpopularniejsze są dwa sposoby steganografii z wykorzystaniem VoIP i protokołów pomocniczych w nim używanych.

  • Ukrywanie informacji w protokole SIP (ang. Session Initialization Protocol), będącym standardem inicjalizacji sesji wymiany danych pomiędzy węzłami chcącymi się ze sobą komunikować. Nagłówek pakietu zaproszenia, wysyłany podczas nawiązywania połączenia, zawiera pola nieużywane.
  • Metoda LACK (ang. Lost Audio PaCKets Stenography), opierająca się na protokołach transportowych, służących do przesyłu konwersacji RTP (ang. Realtime Transport Protocol) oraz wchodzący w jego skład UDP. Protokół UDP nie korzysta z mechanizmów potwierdzenia i retransmisji pakietów da-
    nych. Po przekroczeniu określonego czasu są uznawane za zaginione i nawet jeśli w końcu dotrą, to są ignorowane. Podczas rozmowy VoIP utrata części
    pakietów jest normalna i zazwyczaj użytkownik tego nie zauważa. Wykorzystując tę zależność można celowo tak manipulować pakietami danych
    ze steganogramem, aby były klasyfikowane jako opóźnione. Węzły sieciowe nieświadome tego działania będą je ignorować, natomiast odbiorca wtajemniczony w plan ukrytej komunikacji może taki pakiet przetworzyć i odebrać wiadomość.

1Model odniesienia łączenia systemów otwartych (ang. ISO Open Systems Interconnection Reference Model), standard zdefiniowany przez ISO oraz ITU-T opisujący strukturę komunikacji sieciowej, stawiany często za wzór dla protokołów sieciowych.
2RFC to zbiór technicznych dokumentów związanych z sieciami komputerowymi, niektóre z nich przekształciły się poźniej w oficjalne standardy. Za ich publikację odpowiada Internet Engineering Task Force. Każdy nowy dokument otrzymuje indywidoalny numer. Protokół TCP definiuje RFC 793