Alternate Data Streams (ADS)

16 kwietnia 2013, 11:28 | Teksty | komentarze 3
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Wstęp

W artykule wyjaśnimy stosunkowo mało znany i dość słabo udokumentowany mechanizm Alternate Data Stream (ADS), będący właściwością systemu plików NTFS. Poza oficjalnymi zastosowaniami ADS jest jednym z mechanizmów wykorzystywanych przez oprogramowanie malware do ukrywania danych w NTFS.

 

ADS w praktyce

Na wstępie zobaczmy, jak wygląda działanie ADS w praktyce:

Zauważmy, że w powyższym przykładzie dodaliśmy do pliku test.txt dodatkowe dane i mamy do nich dostęp. Nie zmieniając przy tym nawet sumy kontrolnej pliku!
Można się domyślać (słusznie), że również rozmiar takiego pliku (wyświetlony za pomocą polecania DIR) nie ulegnie zmianie.

W przykładzie utworzyliśmy Alternate Data Stream o nazwie „dodatkowa.txt” – dla pliku test.txt (w odróżnieniu od Normal Data Stream, będącego klasycznie znaną zawartością – pliku test.txt).

Podobne utworzenie ADS-u można wykonać na katalogu:

Co więcej, można w ten sposób ukryty kod wykonać:

 

Listowanie ADS-ów

W tym momencie może powstać pytanie o to, czy istnienie prosty sposób wyświetlenia ADS-ów dla danego pliku albo wręcz wylistowania wszystkich ADS-ów w systemie?

Odpowiedź dla systemów wcześniejszych od Vista/Windows 2008 brzmi: Windows nie posiada standardowych narzędzi umożliwiających uzyskanie tych informacji (można jednak doinstalować odpowiednie aplikacje, służące nam pomocą w tym zakresie, np. lns czy lads). W przypadku systemów Vista/Windows 2008 (oraz późniejszych) polecenie dir posiada przełącznik /r umożliwiający listowanie ADS-ów. Przykład z Windows 7:

 

 

Oficjalne zastosowanie ADS-ów

Zauważmy, że powyżej wyświetlony został również inny Alternate Data Stream – Zone.Identifier. Tutaj możemy wskazać jedno z nielicznych ‚legalnych’ zastosowań ADS-ów. Otóż przeglądarka internetowa (najczęściej Internet Explorer, ale i windowsowy Firefox 3) jest w stanie oznaczyć plik ściągany z Internetu odpowiednią wartością Zone.Identifier. Dzięki temu przy próbie uruchomienia takiego pliku z poziomu Windows Explorera, generowany jest dodatkowy komunikat ostrzegawczy (o uruchomieniu potencjalnie niebezpiecznego pliku) – jak poniżej:

windows_warning

Aby komunikat nie był generowany wystarczy zmienić Zone Identifier na niższy – np. w następujący sposób:

Więcej o mechanizmie Security Zones (oraz Zone Identifier) można poczytać na stronach Microsoftu:
http://msdn.microsoft.com/en-us/library/ms537021%28v=VS.85%29.aspx

Znane są też inne oficjalne zastosowania ADS-ów jak: przechowywania tagów przypisanych do plików (np. autor), czy przechowywania miniaturek dla obrazów (za: http://en.wikipedia.org/wiki/Alternate_data_stream oraz http://rootkitanalytics.com/userland/Exploring-Alternate-Data-Streams.php#well-known-Alternate-Data-Streams).

Istnieje również jeszcze inne ‚legalne’ zastosowanie ADS-u, które prowadzi nas do początków wprowadzenia tego mechanizmu w Windows, sięgającego aż Windows NT.

 

Historia ADS

ADS został oryginalnie wprowadzony w celu zapewnienia kompatybilności z systemem plików MacOS, noszącym nazwę HFS (informacja za: http://www.irongeek.com/i.php?page=security/altds oraz http://www.alex-ionescu.com/NTFS%20Alternate%20Data%20Streams.pdf). W HFS, metadane o pliku (między innymi typ pliku – np. plik graficzny, tekstowy, wykonywalny, itd) przechowywane są w tzw. resource fork, a same dane pliku – w data fork. Przed wprowadzeniem ADS, system plików Windows obsługiwał jedynie data fork (w nomenklaturze Apple), a po wprowadzeniu ADS-ów zaczął również „wspierać” resource fork. Dzięki temu, można było zaimplementować w prosty sposób kopiowanie czy przenoszenie plików pomiędzy dwoma systemami plików (tj. HFS i NTFS).

Może powstać pytanie – co dzieje się w gdy przenosimy plik zawierający ADS-y na system plików nie wspierający tego mechanizmu (np. FAT)? ADS-y w takim przypadku zostają usunięte. Podobnie sytuacja ma miejsce np. podczas przesyłania pliku e-mailem (gdzie transferowany jest tylko Normal Data Stream – tj. zawartość pliku, której normalnie się spodziewamy).

Powyższy fakt jest również pewną odpowiedzią na zachowanie sha1sum.exe z przykładu na początku artykułu (rozdział: ADS w praktyce) – otóż funkcje biblioteczne Windows przy prośbie o podanie zawartości pliku – odwołują się domyślnie do Normal Data Stream. Dlatego w obu przypadkach obliczenia sumy SHA-1 wynik był taki sam – za każdym razem liczona jest suma dla Normal Data Stream.

 

Wrogie zastosowanie ADS

Naturalnie narzucającym się wrogim zastosowaniem ADS – jest ukrywanie za jego pomocą danych. Jak widzieliśmy wyżej, w wielu systemach Windows, standardowe narzędzia nie wykrywają informacji zawartych w ADS. Czytelnik może wykonać prosty test – spróbować ukryć wirusa zapisanego w ADS (metodami opisanymi powyżej) oraz sprawdzić czy oprogramowanie antywirusowe wykryje taki malware. W tym celu proponujemy wykorzystać plik EICAR, umożliwiający przetestowanie poprawności działania oprogramowaina antywirusowego, przy jednoczesnej nieszkodliwości samego 68-bajtowego pliku tekstowego EICAR. Testy takie Czytelnik może wykonać na własne ryzyko – zgodnie z instrukcją na stronie EICAR. Test taki pokaże czy nasz antywirus sprawdza również dane zawarte w ADS.

 

Gdzie fizycznie znajdują się dane przechowywane w ADS?

Poniżej przedstawiamy garść informacji technicznych ułatwiających zrozumienie na ogólnym poziomie fizyczne miejsce składowania danych zawartych w ADS. Takie informacje mogą być przydatne np. podczas analizy powłamaniowej. Aby nie powielać zbyt dużej ilości informacji, zaprezentujemy wybrane informacje ze źródeł traktujących o temacie.

Informacje te wskazują, że miejsce przechowywania informacji o fizycznej lokalizacji ADS znajdują się w tzw. MFT (Master File Table)

ntfsmft

W pierwszym przybliżeniu ułożenie informacji w NTFS wygląda jak powyżej. Nas obecnie interesuje sam MFT, który na który składa się lista rekordów:

  • Za: http://msdn.microsoft.com/en-us/library/bb470206%28VS.85%29.aspxEach file record segment starts with a file record segment header. For more information, see FILE_RECORD_SEGMENT_HEADER. Each file record segment is followed by one or more attributes. Each attribute starts with an attribute record header. For more information, see ATTRIBUTE_RECORD_HEADER. The attribute record includes the attribute type (such as $DATA or $BITMAP), an optional name, and the attribute value. The user data stream is an attribute, as are all streams.

Podsumowując – wpis (rekord) w MFT dla każdego pliku składa się nagłówka oraz listy atrybutów. Jednym z atrybutów jest nazwa pliku, innym atrybutem jest zawartość pliku. Atrybutem są też strumienie – „normalny” oraz „alternatywne”.

Graficznie można przestawić to w sposób następujący (za: http://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx):

 

mftstructure1

 

Aby zlokalizować miejsce umieszczenia ADS-a na dysku pozostaje nam jeszcze sprawdzić gdzie fizycznie przechowywane są atrybuty. Tutaj sytuacja jest bardziej skomplikowana – nie ma na to pytanie prostej odpowiedzi. W określonych przypadkach dane mogą znaleźć się w samym MFT (tzw. atrybut rezydentny) – warunkiem jest nie przekroczenie rozmiaru ~1kB przez atrybut:

mftstructureattribute0

Za: http://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx

Jednak możliwe są również inne scenariusze, począwszy od w relatywnie prostego:

mftstructureattribute1

Za: http://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx

Aż po dość skomplikowany:

mftstructureattribute2

Za: http://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx

Podsumowanie

W artykule opisaliśmy mechanizm Alternate Data Stream w systemie plików NTFS. W następnej kolejności wskazaliśmy oficjalne oraz wrogie zastosowania ADS-ów. Na koniec przedstawiliśmy informację, w którym miejscu należy fizycznie poszukiwać danych zawartych w ADS. W nowych systemach Windows, omawiany mechanizm cały czas jest domyślnie dostępny – warto więc śledzić ewentualnie zmiany, które są w nim wprowadzone w kolejnych odsłonach Windows. Może to bowiem  wpłynąć na bezpieczeństwo naszego systemu operacyjnego.

Michał Sajdak (michal.sajdak<at>securitum.pl)

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



Komentarze

  1. Amadeusz

    Dobrze zrozumiałem: wysłanie mailem pliku pozbawia go powiązanych danych?

    Nie można całkiem wyłączyć tej „funkcjonalności”?

    Odpowiedz
    • Mailem – tak pozbędziemy się ADS-ów.
      Wyłączyć tego raczej się nie da – to jakby element standardu NTFS. Więc prawdopodobnie dopóki będziemy używać NTFS, będziemy też mieć tam ADS.

      Odpowiedz
  2. phaxe
    Odpowiedz

Odpowiedz