Alternate Data Streams (ADS)

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:

C:\ads>echo tresc pliku > test.txt

C:\ads>sha1sum.exe test.txt
09cb212652585a2de1be31f483441f8f9d110af2  test.txt

C:\ads>echo dodatkowa tresc > test.txt:dodatkowa.txt

C:\ads>sha1sum.exe test.txt
09cb212652585a2de1be31f483441f8f9d110af2 test.txt

C:\ads>dir
 Wolumin w stacji C nie ma etykiety.
 Numer seryjny woluminu: 1111-2222

 Katalog: C:\ads

2010-04-23  16:50    <DIR>          .
2010-04-23  16:50    <DIR>          ..
2010-04-22  10:35            19968 sha1sum.exe
2010-04-23  16:34                14 test.txt
               2 plik(ów)             19&nbsp;982 bajtów
               2 katalog(ów)  102280 bajtów wolnych

c:\ads>more < test.txt
tresc pliku

c:\ads>more < test.txt:dodatkowa.txt
dodatkowa tresc

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:

C:\ads>echo ukryta > c:\ads:ukryta.txt

C:\ads>notepad c:\ads:ukryta.txt

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

Windows7 - uruchamianie ukrytego kodu vbs:

C:\ads>echo Wscript.Echo "uruchomiony" > test.txt:script.txt

C:\ads>cscript //E:vbs test.txt:script.txt
Host skryptów systemu Windows firmy Microsoft (R) wersja 5.8
Copyright (C) Microsoft Corporation 1996-2001. Wszelkie prawa 
zastrzeżone.

uruchomiony

Windows XP - uruchamianie ukrytego pliku exe:

C:\ads>copy c:\Windows\notepad.exe .
Liczba skopiowanych plików:         1.

C:\ads>type c:\Windows\system32\calc.exe > notepad.exe:calc.exe

C:\ads>start c:\ads\notepad.exe:calc.exe

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:

c:\ads>dir /r
 Wolumin w stacji C nie ma etykiety.
 Numer seryjny woluminu: AAAA-1111

 Katalog: c:\ads

2010-04-23  16:50    <DIR>          .
                                  9 .:ukryta.txt:$DATA
2010-04-23  16:50    <DIR>          ..
2010-04-22  10:35            19 968 sha1sum.exe
                                 46 sha1sum.exe:Zone.Identifier:$DATA
2010-04-23  16:34                14 test.txt
                                 18 test.txt:dodatkowa.txt:$DATA
               2 plik(ów)             19 982 bajtów
               2 katalog(ów)  102 073 958 400 bajtów wolnych

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:

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

C:\ads>notepad md5sum_zone3.exe:Zone.Identifier

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.

• Za: http://www.alex-ionescu.com/NTFS%20Alternate%20Data%20Streams.pdf The Master File Table of the partition will contain a list of all the data streams that a file contains, and where their physical location on the disk is.

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

• Za: http://ixbtlabs.com/articles/ntfs/
  

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):

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:

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:

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

Aż po dość skomplikowany:

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)