Rozbrajamy trojana. Część I: makrowirus
Makrowirusy, czyli szkodniki ukryte w skryptach automatyzujących dokumentów Office, uparcie nie ustępują. W ciągu ostatnich kilku lat stały się popularniejsze niż w epoce swojej „chwały”, ale w praktyce stanowią niezmienne zagrożenie już od niemal ćwierćwiecza. Ich popularność jest konsekwencją utrzymywania w pakiecie Office tego, co sprawia że produkt ten zarabia pieniądze: zgodności z poprzednimi wersjami. I choć już od dawna uruchamianie makr jest domyślnie wyłączone, przestępcy stają się coraz bardziej przebiegli.
Kilka dni temu na redakcyjną skrzynkę pocztową przyszedł e-mail „z Uniwersytetu Warszawskiego”. Zawierał w załączniku prezentację w formacie PPT, wewnątrz której znajdowały się makra. Oczywiście, wirusa w niej nie wykrywały ani antywirus na pocztowym serwerze Grupy WP, ani systemowy Windows Defender. Mail nie wylądował nawet w spamie, co było tym dziwniejsze. Nie był rażąco podejrzany, ale dość prędko powinno się okazać oczywiste, że to oszustwo: Uniwersytet Warszawski nie wysyła maili z Brazylii, korzystając z top-domeny .mx (Meksyk).
Kłamstwo popłaca
Ale w tym szaleństwie jest metoda: sfałszowanie nagłówka tak, by pokazywał UW, a nie Meksyk, po czym wysłanie maila z meksykańskiego serwera sprawiłoby, że filtr antyspamowy poleciałby z punktami reputacji za taką sztuczkę. Zamiast tego zdecydowano się nie stosować podstawionego nadawcy, użyć postrzelonej domeny za dolara, ale sformatować imię, temat i samą treść maila tak, żeby wyglądały przekonująco. I poza życzeniami noworocznymi w marcu, prawie się udało.
Jak się wkrótce przekonaliśmy, pliku nie rozpoznawał żaden z popularnych programów antywirusowych, nie tylko nasze. Plik który otrzymaliśmy był bowiem o rząd wielkości bardziej złożony niż zwyczajowe makrowirusy. Naturalnie, z samej niewykrywalności nie należy wnioskować, że zagrożenie jest czymś nowatorskim. Programy antywirusowe regularnie mają problemy z szacowaniem zagrożeń. Ale postanowiliśmy zajrzeć do środka...
Automatyczne makra w uszkodzonym pliku
Już Office 2000 (Service Pack 3) ostrzegał, że uruchamianie makr może być niebezpieczne. Przestrzegał w ten sposób przed uruchomieniem głównej procedury (Sub Main) kodu Visual Basic for Applications: makra są bowiem ograniczoną formą programów VB6. VB6 i VBA różnią się od siebie jednak pewnymi szczegółami, a jednym z nich są procedury automatyczne, czyli funkcje wywoływane wskutek załadowania dokumentu, a nie załadowania makra. Są nimi funkcje Auto_Open i Auto_Close, które wykonują się zawsze i które można samodzielnie przeładować.
Nowsze wersje pakietu Office domyślnie blokują każdy kod znajdujący się sekcji makr dokumentu. Dotyczy to także procedur automatycznych. Otwarcie lewej dokumentu z internetu kończy się zatem wyświetleniem go w trybie odczytu, a gdy zechcemy włączyć edytowanie, makra i tak będą dalej wyłączone. Dopiero wyrażenie jawnej zgody na uruchomienie kodu może nam uczynić jakąkolwiek krzywdę (teoretycznie, w praktyce nie należy tego zakładać). Dlatego twórcy złośliwych dokumentów musieli zadbać o kreatywność.
Podsyłany dokument PowerPointa jest uszkodzony. Jest zarazem na tyle poprawny, że Eksplorator plików oraz Sekcja podglądu w Outlooku potrafią wyświetlić jego miniaturę. Plik sprawia zatem wrażenie normalnego dokumentu, ale okazuje się nie zawierać treści. Żadnej. PowerPoint otwiera go i nie zgłasza problemów, ale nie wyświetla też nic poza obramowaniem okna. Ale już po chwili wyświetla się komunikat czy chcemy odblokować makra...
OLE
Jaki jest sens takiego zachowania? Otóż jako, że dokument jest zapisany w formacie PPT a nie PPTX, jest on plikiem binarnym. Z tego powodu nie podlega on, tak jak nowe formaty Office, walidacji XML, w przypadku której zdeformowany dokument jest po prostu odrzucany jako niepoprawny. Wewnątrz binarnego dokumentu Office znajdują się, częściowo nieudokumentowane, strumienie OLE. Technologia OLE 2 to sposób zapisu (ale nie serializacji!) obiektów COM umożliwiający im komunikowanie się ze sobą, czyli model programowania. Każdy obiekt OLE ma swoje cechy, własności i metody z którymi można wdawać się w interakcję z poziomu języków programowania.
Obiekty OLE nie podlegają nowoczesnym formom walidacji. Wystarczy, że istnieją w postaci umożliwiającej załadowanie ich do pamięci lub zmapowanie struktury. Nie muszą być przetwarzane w całości, pochodzą wszak z czasów, w których 16 megabajtów pamięci operacyjnej uchodziło za luksus i nie wszystko pakowano w całości w RAM (nie to, co dziś). Toteż strumień OLE dla treści w dokumencie jest „urwany”: nie zawiera żadnej treści, ale jest poprawny w nagłówku określającym format. Plik ma 64 kilobajty, nie ma w nim wręcz miejsca na treść. Ale pusty dokument powinien być odrobinkę mniejszy.
Istotnie. W pliku znajduje się też drugi strumień, zawierający malutkie makro. Jego obecność nie wywołuje wyświetlenia paska informacyjnego z informacją o makrach, a zamiast niego Office serwuje okno dialogowe Tak/Nie z pytaniem, czy uruchomić zawartość aktywną. O ile użytkownik może zignorować kliknięcie na pasek na działającym dokumencie, szansa na to, że naciśnie „Tak” w jakikolwiek okienku próbując wyświetlić dokument który nie działa jest o wiele wyższa.
Trik ten był już stosowany wcześniej, ale dotyczył samego makra: kod z makrami to tak naprawdę zintegrowany z dokumentem projekt środowiska Visual Studio 98 (tak, nawet dziś!). Użycie w nim znaków niedrukowalnych uniemożliwiało wyświetlanie kodu. Tę samą sztuczkę zastosowano tym razem w odniesieniu do całego dokumentu. Poprzednio, chodziło o ukrycie kodu. Tym razem, powody są bardziej psychologiczne.
Python na ratunek
No dobrze, co wobec tego jest w tym makrze? Początkowo trudno powiedzieć. Dokument się nie ładuje. Odmowa załadowania makr wyłącza środowisko programowania, więc nie można przejrzeć kodu bez uruchomienia go, a tego byśmy nie chcieli. Plik jest plikiem PPT, a nie PPTX przez co nie da się łatwo zajrzeć do środka (pliki DOCX/XLSX/PPTX to tak naprawdę archiwa ZIP pełne XML-i). Z pomocą przychodzi narzędzie oletools środowiska Python. Dzięki niemu możliwe jest wyizolowanie strumienia zawierającego kod makra. Narzędzia oletools i olevba mają tę przewagę, że operują na bajtach, a nie na obiektach COM. Wiele cudownych ekstraktorów tak naprawdę ładuje i uruchamia makro celem wydobycia go. Olevba pozwala tego uniknąć.
Co widzimy? Pojedynczy plik źródłowy zawierający jedną funkcję: Auto_Close(). Kod jest zaciemniony: zachodzi odkodowanie treści zapisanej szyfrem i uruchomienie jej jako parametru wiersza poleceń. Oczyszczony kod to tylko osiem krótkich linijek, w którym następują poniższe czynności:
Wyświetlenie komunikatu „Error!” Pobranie strony internetowej programem MSHTA Uruchomienie Worda (pusty, nowy dokument) Wyświetlenie komunikatu „Loading!” Ping w kierunku komputera localhost
Oczywiście, główna „magia” następuje w punkcie drugim, a pozostałe wydają się być nonsensowne. Jednakże wcale tak nie jest. Operacja pingowania lokalnego adresu 127.0.0.1 ma na celu zmylenie analizatorów opartych na wirtualnych maszynach. Utworzenie zestawu czynności „no faktycznie coś dziwnego pobrał, ale potem jeszcze coś robił i łączył się z bezpiecznymi adresami” pozwala zdobyć trochę punktów reputacji w takim skanie. Podobnie jest z uruchomieniem Worda: „istotnie, forkuje jakieś procesy, ale jednym z nich jest podpisany przez Microsoft MSHTA, a drugi to w ogóle jest Word, więc spoko”. To nędzne wymówki, ale na potrzeby skanerów – wystarczające.
Zanim zajmiemy się tym, co zostało pobrane przez MSHTA, warto wspomnieć parę słów o tym, czym ono w ogóle jest. To potrzebne z perspektywy ochrony stacji roboczych. Otóż HTA to coś w stylu połączenia Metro i PWA, czyli aplikacje HTML. Pomysł środowiska opartego w pełni na kontrolkach webowych zrodził się w Microsofcie już w 1999 a pierwszym systemem, który miał rysować interfejs z jego użyciem nie miał być Windows 8, a konsumencka wersja Windows 2000, której nigdy nie wydano.
Aplikacja HTA to strona internetowa rysowana przez silnik Internet Explorera, wyświetlana w dedykowanym oknie, a nie w przeglądarce (celem ukrycia pasków menu, stanu i adresu). Będąc aplikacją, działa lokalnie, a więc pracuje w strefie zabezpieczeń „Komputer” a nie „Internet”. Mają dzięki temu prawa dostępu do wielu mechanizmów, które stanowią poważne zagrożenie i które istnieją dziś tylko z powodu uwarunkowań historycznych. O jakich mowa? O tym w następnej części.
Podsumowanie części pierwszej
Fałszowanie nagłówka wiadomości zmniejsza szanse na dostarczenie, bardziej opłaca się żywcem kłamać Uszkodzone dokumenty dalej mogą zawierać działające makra Stare formaty (DOC/PPT/XLS) łatwiej uszkodzić niż nowe (DOCX/PPTX/XLSX) Antywirusy dalej nie działają Do formatów, na które trzeba uważać powinniśmy dopisać, poza VBS i MHT, także HTA