Windows potrafi chronić przed wirusami HTA, ale nikt tego nie zauważył

Przypomnijmy, do znudzenia, którędy dostają się do (w pełni zaktualizowanego) Windowsa wirusy, jeżeli uruchomimy jakąś zainfekowaną treść. Tak - trzeba ją uruchomić. Wirusy nie pojawiają się w komputerze same, a podatności niewymagające otwierania są rzadkie. Jest to wciąż ten sam zestaw elementów, a wśród nich pozycje niezmienne od niemal ćwierćwiecza:

• Visual Basic Script
• Makra Microsoft Office
• PowerShell
• UAC
• HTA

Gigantycznej liczby infekcji ransomware dałoby się uniknąć, gdyby Windows zmienił kilka domyślnych ustawień. Microsoft jednak uparcie odmawia wprowadzania zmian. Powody nie są jasne. Nikomu w Redmond, wbrew dziwnym teoriom, nie zależy na tym, by Windows był łatwy do zarażenia. Obniża to opinię o produkcie i skłania do szukania konkurencyjnych rozwiązań. Wytłumaczeniem może być chęć zachowania zgodności lub korporacyjna inercja, przekładająca się na niezdolność do podejmowania decyzji.

Makra Office da się wyłączyć. Jeżeli ktoś ich naprawdę bardzo potrzebuje, można zastosować reguły ASR, które pozwolą im działać, ale odbiorą prawo do uruchamiania zewnętrznych poleceń. Podobnie UAC jest możliwy do naprawy poprzez podniesienie suwaka na samą górę (jakiekolwiek inne ustawienie jest pozbawione sensu: albo UAC ustawiamy na samą górę, albo można je w ogóle wyłączyć). Potem robi się trudniej.

Visual Basic Script jest wykonywany przez podsystem WSH (Windows Scripting Host). Istnieją zasady grupy (GPO) pozwalające na jego wyłączenie, ale wciąż możliwe jest wołanie interpretera poleceń "przez pośrednika". Zastosowanie zasad grupy wyłączających WSH oraz zmiana domyślnego skojarzenia plików VBS z WSH na Notatnik rozwiązuje całkiem sporo problemów, ale nie wszystkie.

PowerShell z kolei w ogóle domyślnie nie ma żadnych zasad grupy pozwalających na jego wyłączenie. Nie oznacza to, że wyłączenie PowerShella przez GPO jest niemożliwe. Każdy program da się zablokować albo wyciąć na zaporze przez GPO. Różnica polega na tym, że jeżeli jakiś program ma swoją własną, dedykowaną zasadę, to taki scenariusz jest obsługiwany. Jeżeli jej nie ma i robimy ją sami, takie rozwiązanie staje się od razu "brzydkim, nieudokumentowanym hackiem", za konsekwencje którego Microsoft nie odpowiada.

Podobny problem był dotychczas z HTA. Pliki HTA, czyli "Aplikacje HTML", domyślnie uruchamiają się strefie zabezpieczeń "Lokalna" , a nie "Internet". Wszak mają udawać aplikację, prawda? W rezultacie, pliki HTA mają prawo do wykonywania skryptów operujących na lokalnych plikach. To coś, czego nie wolno skryptom na stronach internetowych.

Jakiś czas temu ktoś odkrył, że parser aplikacji HTML, program MSHTA.EXE, jako argument przyjmuje nie tylko ścieżkę do pliku. Możemy podać także zdalny URL, a wtedy MSHTA.EXE sobie taki plik pobierze i wykona. Także stosując strefę lokalną, bez zabezpieczeń. Jest to konsekwencja nieodpowiedzialnej decyzji podjętej przez zespół IE w 1999 roku, z którą Microsoft nic nie robił przez 23 lata.

Aż do październikowych aktualizacji. Gdy przeczytamy o Łatkowym Wtorku nie w spisie załatanych dziur, a w notach wydawniczych, odkryjemy mało nagłośnioną decyzję o wprowadzeniu nowej zasady grupy, nazwanej "Wyłącz aplikację HTML". Domyślnie, rzecz jasna, zasada jest nieaktywna - ale bardzo wskazane jest ją włączyć. Jest dziś naprawdę mało programów wykorzystujących technologię HTA, więc potencjalne problemy ze zgodnością są rzadkie.

Zasada znajduje się w szablonie administracyjnym "Składniki systemu Windows\Internet Explorer". Jej włączenie sprawi, że w Rejestrze pojawi się klucz REG_DWORD "DisableHTMLApplication" o wartości 1, w ścieżce "SOFTWARE\Policies\Microsoft\Internet Explorer\Hta" (w HKCU lub HKLM). Bez wątpienia wpłynie to pozytywnie na bezpieczeństwo.