Rozbrajamy trojana. Część V: jak uniknąć infekcji

Badany w czteroczęściowej serii trojan o niezwykle skomplikowanej ścieżce infekcji był połączeniem geniuszu i głupoty. Niezwykle zaawansowane rozwiązanie inżynieryjne zostało nabyte przez kogoś, kto za słuszną inwestycję uznał wklejanie do Schowka adresu portfela BitCoin. Podobnie osobliwym zestawieniem jest metodyka ochrony przed zagrożeniem, jakie stanowi. Wykrywanie tak złożonych szkodników przez silniki antywirusowe jest prawie niewykonalne z racji liczby warstw. Ale ochrona sprowadza się od kilku prostych kroków.

Jak się ochronić przed takimi zagrożeniami? Choć opisywany, wieloetapowy trojan jest dziesiątki razy bardziej złożony od poprzedników, pierwszy etap korzysta z tej samej technologii, co wszystkie dotychczasowe szkodniki. Powodem są makra pakietu Office. Dlatego metoda ochrony jest taka sama, jak zwykle...

Wyłączyć makra w pakiecie Office, ale w ogóle bez wyświetlania ostrzeżeń o tym, że są wyłączone. Office może bowiem zadawać podstępne pytania, na które możemy z rozpędu odpowiedzieć twierdząco. Całkowite zablokowanie VBA dziś coraz rzadziej wiąże się z utrudnieniami w pracy, więc jeżeli nie pracujemy z dokumentami zawierającymi makra, warto wyłączyć podsystem ich obsługi. W tym celu, w oknie Opcje dowolnego z głównych programów Office, należy przejść do działu Centrum Zaufania, a w nim – do działu Ustawienia Makr. Obsługa makr zniknie wskutek wybrania pozycji "Wyłącz makra języka VBA bez powiadomienia" oraz wyczyszczenia opcji "Włącz makra programu Excel 4.0".

Zmienić skojarzenie rozszerzeń plików HTA i VBS z dedykowanych parserów na Notatnik. To pozwoli uniknąć uruchomienia złośliwego kodu wskutek nieprzemyślanego/przypadkowego kliknięcia. Żywe pliki HTA/VBS są jednak rzadkim zagrożeniem, ponieważ większość dostawców poczty uniemożliwia ich rozsyłanie. Zmianę wprowadzimy wyświetlając Właściwości dowolnego pliku HTA (może być nawet sztuczny, stworzony wskutek zmiany rozszerzenia) i klikając "Zmień" w sekcji "Otwierany za pomocą...".

Aktualizować!Aktualizować pakiet biurowy, by kod wykonywalny nie mógł zostać uruchomiony wskutek dziur w innych funkcjach niż makro, np. edytor równań lub niestandardowe pola RTF (były takie przypadki). Na szczęście, Office aktualizuje się sam. Wersja 365 robi to w tle, a wydania pudełkowe wykorzystują w tym celu Windows Update. Łatki otrzymuje nawet Office 2010, którego wsparcie miało skończyć się w listopadzie. Nie warto przeszkadzać Office'owi w aktualizacji. Zresztą, nieaktualny odmówi współpracy, bo nie otrzyma upoważnienia w ramach abonamentu.

To ważne: zawsze należy przestawić suwak Kontroli Konta Użytkownika (UAC) na samą górę. Ustawia to system tak, by podniesienie uprawnień zawsze wymagało interaktywnego potwierdzenia i nigdy nie odbywało się przez domniemanie. Pozwoli to uniemożliwić zdobywanie rozszerzonych uprawnień, gdy kod jednak jakoś się wykona. Domyślnie UAC pyta o uprawnienia tylko wtedy, gdy aplikacja jest "niezaufana". Dlatego więc te "niezaufane" aplikacje wołają pod spodem zaufane pliki EXE należące do samego Windowsa i każą im robić niezaufane rzeczy. O to UAC już nie pyta. Microsoft broni się, że ten brak ochrony powinien być mitygowany przez antywirusa. W praktyce to pozostałość po walce ze złą prasą, jaką otrzymała Vista, pytająca użytkownika o pozwolenie zbyt często.

Ewentualnie można też pracować na koncie ograniczonym zamiast administratora. Generalnie, praca na wysokich uprawnieniach, albo wręcz wyłączanie UAC to nieokrzesana, naiwna nieodpowiedzialność, o nonszalancji w stylu „szlachta nie pracuje”. Prawa administracyjne nie są nikomu potrzebne do codziennego szczęścia, a wyciągany z podziemi argument, że ktoś akurat potrzebuje ich do działania aplikacji kontrolującej tokarkę z 1997 nie czyni owego stwierdzenia ani trochę mniej prawdziwym.

Zablokować ruch wychodzący w wykonaniu programu MSHTA.EXE we wszystkich profilach. To nieco paranoidalne rozwiązanie, nieco nadmiarowe w przypadku stosowania się do tych powyżej, ale powinno zapobiec akurat tej metodzie infekcji. HTA jest bowiem niezniszczalne. Internet Explorer (IE 11) nie obsługuje skryptów VBS już od dwóch lat, ale w trybie HTA wciąż to potrafi. Możemy usunąć przeglądarkę IE z systemu, ale parser HTA dalej będzie działać, mimo że pod spodem używa właśnie IE. Oto magia bibliotek! Nie ma też Zasad Grupy bezpośrednio wyłączających ten podsystem. Na szczęście jest jednak PowerShell i poleceniem:

[code=powershell]New-NetFirewallRule -Program C:\Windows\System32\mshta.exe -Name "NoHTA" -DisplayName "Zablokuj HTA" -Enabled True -Profile Any ` -Direction Outbound -Action Block[/code]

...zabronimy parserowi HTA wyglądać na świat.

Najważniejsze to, jak zwykle, nie brać cukierków od obcych: nie otwierać niespodziewanych dokumentów wątpliwego pochodzenia. Jednakże wbrew opinii niektórych odrealnionych ekspertów spod znaku „sam był sobie winny”, niektórzy muszą otwierać wszystkie dokumenty jakie dostają. Alternatywą jest ignorowanie klientów, których nie należy pouczać. Zresztą, gdyby było „oczywiste” że dokument jest złośliwy, to dlaczego administrator nie wyciął go na serwerze pocztowym, co?

Kolejny raz otrzymujemy dowód na to, że nawet te najbardziej złożone wirusy wcale nie propagują się wskutek wykorzystania super-zaawansowanych, nieznanych i niezałatanych dziur w Windowsach. Zamiast tego korzystają z makr, nieuwagi i arogancji użytkowników. Zupełnie jak w roku 1999, stosując łatwe do zablokowania ścieżki.

Wyłączcie makra.