Rozbrajamy trojana. Część II: środowisko HTA

W tej części naszego cyklu omówimy środowisko HTA oraz jego cechy czyniące je doskonałym nośnikiem wirusów. A wszystko po to, by zrozumieć jedną linijkę w naszym makrowirusie! Próbuje on bowiem uruchomić aplikację HTA pobieraną z sieci. 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). PWA ubiegłego stulecia. Będąc aplikacją, działa lokalnie, a więc pracuje w strefie zabezpieczeń „Komputer” a nie „Internet”. Mają dzięki temu prawa, które dają bardzo rozbudowane możliwości w połączeniu z pewną inną cechą, mianowicie...

Tag „script” w języku HTML. Posiada on właściwości, które w języku HTML5 są uznawane za przestarzałe i w większości przypadków są już niestosowane. Jedną z nich jest pole „language”. Dziś wartością domyślną tego pola jest oczywiście JavaScript, dzisiejsze przeglądarki internetowe nie zawierają parserów żadnego innego języka skryptowego. Z jednym wyjątkiem: Internet Explorer. Przeglądarka IE w wersji 5.0 miała stać się platformą do uruchamiania aplikacji prosto z internetu. Zasługą tego podejścia jest XMLHTTPRequest, podstawa technologii AJAX i de facto fundament Web 2.0 i dzisiejszego świata aplikacji. Niestety, są też wady. Jedną z nich jest Visual Basic Script.

IE obsługuje Visual Basic Script (VBS) jako język dla skryptów na stronie internetowej na równi z JavaScriptem. Może się wydawać, że to tylko nieszkodliwa różnorodność, ale VBS ma coś, czego nie ma JavaScript: da się z jego poziomu sięgać do modelu COM, WMI, powłoki Windows, Rejestru i wiersza poleceń. Technicznie, wariant „JScript” czyli rozumiany przez Host Skryptów Windows dialekt JavaScriptu też umie takie cuda, ale jest to znacznie trudniejsze i nie przechodzi walidacji W3C. Z kolei tag

[code=js][/code]

w ogóle nawet nie podlega walidacji, uchodzi za dziwactwo i artefakt, dzięki czemu nic nie zgłasza sprzeciwu.

Host Skryptów Windows jest niedostępny gdy IE pracuje w strefie internetowej. Dopiero dodanie strony do zaufanych lub umieszczenie jej w lokalnej sieci może sprawić, że Internet Explorer zmieni strefę na łagodniejszą i zezwoli na ładowanie skryptów sięgających do modelu programowania systemowego. I tutaj następuje zderzenie inżynierów z marketingowcami, rocznik 1999. Internet Explorer miał być bardzo bezpieczny (wbrew pozorom), więc stosuje strefy zabezpieczeń. Miał być też platformą do wszystkiego, więc wymyślono „Aplikacje HTML”: środowisko do robienia aplikacji z UI strony WWW, ale możliwościami Windows API. Bezpieczeństwo miało nie kłócić się z platformą, więc aplikacje HTA mają prawa do skryptów, ale strony internetowe nie.

Super. I z wierzchu wszystko wydaje się być OK: jeżeli ktoś klika na plik z aplikacją HTA, to znaczy że ma ją na dysku. Pobrał, odblokował i świadomie trzyma na lokalnie. Tak uruchomiona aplikacja będzie miała prawa do skryptów, ale gdy ktoś wejdzie przez IE na stronę, którą otwiera – to tak otwarta praw do skryptów mieć nie będzie.

Z tym, że dwuklik na aplikację HTA to tak naprawdę uruchomienie programu MSHTA.EXE z parametrem, którym jest ścieżka do nazwy klikanego pliku. MSHTA okazuje się umieć przyjmować jako parametr nie tylko nazwy plików, ale i… internetowe adresy URL. A w jakiej strefie zabezpieczeń będą pracować treści z tak otwartych adresów URL? Ano oczywiście w strefie lokalnej! Jak aplikacja, to aplikacja. Uruchamianie HTA prosto z internetu, bez instalacji, to okropny pomysł i popełniony 22 lata temu gigantyczny błąd, którego implikacji nikt najwyraźniej nie był świadom.

Ale Microsoft tamtych lat rozumował dokładnie w takim stylu. Wychodzono z założenia, że jeżeli czegoś nie widać, to to nie istnieje. Użytkownik na co dzień nie widzi „MSHTA.EXE”: jeżeli uruchamia aplikację HTA, to ręcznie, a to oznacza że sam ją pobrał i świadomie uruchamia. Perspektywa wykorzystania MSHTA.EXE przez złośliwe oprogramowanie nie była brana pod uwagę, a żaden z programistów nie chciał zapewne nic zrobić z tym, że aplikacje HTA dawało się wołać prosto z sieci. Gdyby zasugerował obsługę stref zabezpieczeń, opóźniłby wydanie produktu i podważył dojrzałość technologii, a chcąc usunąć obsługę URL, zapewne dowiedziałby się od strategów firmy, że każde usuwanie „internetowości” to grzech.

W ten sposób w Windows znajduje się narzędzie pozwalające bez pytania uruchamiać skrypty wprost z internetu, na prawach użytkownika, z możliwością korzystania z WSH i modelu COM. Co więcej, nie da się tego wyłączyć! Nie istnieje żadna zasada grupy wyłączająca obsługę HTA. Istnieje za to coś na kształt implementacji gestu środkowego palca, wymierzonego w kierunku administratorów: da się zmienić skojarzenie rozszerzenia *.HTA z MSHTA.EXE na inny program. Rozwiązuje to dokładnie zero problemów, bo plik nie jest uruchamiany przez powłokę, a wołany bezpośrednio poleceniem.

Na domiar złego, obsługa HTA nie znika, gdy zdecydujemy się odinstalować Internet Explorera. Usunięcie przeglądarki nie usuwa bowiem silnika MSHTML.DLL, BROWSEUI.DLL ani właśnie MSHTA.EXE, dzięki czemu apliki HTA wciąż działają perfekcyjnie. Nawet usunięcie MSHTA.EXE z systemu nie będzie trwałe, ponieważ SFC zgłosi brakujące pliki i podczas następnego okna konserwacji, system uruchomi DISM Restore Health, które przywróci usunięty plik z rezerwy CBS lub wprost z Windows Update.

Złośliwe makro z maila uruchamia więc aplikację HTA z internetu. Wydawałoby się, że tu właśnie powinien wkroczyć do akcji antywirus, wszak próbujemy uruchomić złośliwy kod z internetu, prawda? Otóż niekoniecznie. Pobierana strona to… niewinny blog. Dosłownie. Adres URL prowadzi do skracacza linków Bitly, ale link ten po rozwinięciu prowadzi na bloga w domenie BlogSpot, a jest to portal znajdujący się pod opieką Google. Połączenie z domeną BlogSpot nie jest uznawane przez antywirusy i zapory za akt złośliwy, a sama strona otwarta w przeglądarce nie robi nic złego.

Zastosowano tu dwie sztuczki. Po pierwsze, fakt połączenia ze stroną o wątpliwej reputacji, w postaci narzędzia do skracania linków, jest przykrywany zastosowaniem małpy w adresie. Taka składnia umożliwia logowanie HTTP i jest ignorowana, gdy odbiorca połączenia nie wymaga logowania, często można ją więc dodać do adresu URL bez konsekwencji. Z perspektywy analizatora ruchów wygląda to tak: „fakt, strona trochę dziwna, no ale użytkownik się tam loguje, a nie ściąga byle co, więc pewnie ma hasło i to nie jest jakiś pierwszy lepszy zasób”.

Numer z BlogSpotem polega nie tylko na tym, że strona ta, będąca pod opieką Google’a, zazwyczaj bardzo szybko pozbywa się złośliwych i szkodliwych treści lub wręcz uniemożliwia ich dodanie. Pobierany „blog” z BlogSpota, uruchamiany jako aplikacja HTA, zawiera złośliwe elementy… ale jako skrypty VBS! A co przeglądarki robią z wtyczkami VBS? Nic. Ignorują je, jak komentarze. Dlatego można je zawrzeć bezkarnie, a Google nie zauważy. Blog nie zawiera treści (poza wulgaryzmami). Ale w jego wnętrzu znajdują się cztery tagi „script”, zapisane w całości w notacji HTML („z procentami”). Przetłumaczone, okazują się być skryptami Visual Basic Script.

Skrypty te są dopiero początkiem wieloetapowego, złożonego ataku, stosując szereg sztuczek dotychczas powszechnie nieobecnych w makrowirusach. Najpopularniejsze kampanie nawet bardzo groźnych szkodników były w większości przypadków mniej wyrafinowane w kwestii swoich modułów ładujących i zdecydowanie składały się z mniejszej liczby kroków pośrednich. Tutaj jest ich wręcz kilkanaście, co czyni sukces operacji zależnym od szczęścia i powtórzeń. Dlatego jak się wkrótce okaże, skrypty dbają o to, by pracować w wielu kopiach.

Interpreter HTA potrafi bezpośrednio ściągać i uruchamiać aplikacje z internetu Aplikacja HTA mogą stosować skrypty z VBS z dostępem do modelu programowania WSH Uruchomiony z wiersza poleceń, interpreter HTA nie informuje interaktywnie użytkownika o swoim działaniu Interpreter HTA nie daje się łatwo wyłączyć Przestępcy ukrywają złośliwy kod na "bezpiecznych" stronach, jak Google BlogSpot