Robak Nimda kończy 25 lat. Jakie szkody wyrządził?

We wrześniu 2001 na świecie pojawił się zaawansowany robak Nimda, pamiętany dziś jako jeden z wirusów wykorzystujących IIS. Jego metod propagacji było jednak więcej i nie wszystkie dało się załatać. Dziś Nimda nie miałby szans na swój sukces.

Nimda: 20 lat robakaNimda: 20 lat robaka
Źródło zdjęć: © dobreprogramy | Kamil Dudek
Kamil J. Dudek

Nimda istotnie rozpowszechniał się za pomocą IIS, ale poza tym stosował też zasoby Udostępniania Plików Windows (SMB/NetBIOS). Atakował więc nie tylko serwery (w większości niezałatane – dziurę, którą stosował, poprawiono rok wcześniej), ale także stacje robocze z Windows 95/98. Jednak aby rozpowszechniać się na nich, coś musi je automatycznie uruchamiać. W ich przypadku winny był Internet Explorer.

 Zabezpieczenia: obecne, ale bez sensu

Problem z Internet Explorerem wynikał z wad jego największej siły: bycia platformą programistyczną, umiejącą uruchamiać zewnętrzny kod w wielu postaciach i możliwą do osadzania w dokumentach i aplikacjach. IE rysował strony internetowe, ale także widoki folderów i edytory wiadomości e-mail. W zależności od zastosowania, wykonywany kod miał różne uprawnienia. Jeżeli był z internetu, był traktowany jako niebezpieczny. Jeżeli był lokalny, otrzymywał pełne prawa. Koncepcja ta nosi nazwę Stref Zabezpieczeń i jej echa znajdują się w Windows do tej pory.

Wbrew złośliwym opiniom, IE nie został zaopatrzony w Strefy późno, po aferach. To dość wczesna funkcja, która niestety działała dość kiepsko. Co prawda chroniła w internecie, ale miała wiele "ślepych punktów". Czasem wystarczyło się podać za kogoś bezpiecznego, by IE mu uwierzyło. Większy problem był jednak ze strefą lokalną. Do niej należały skrypty WSH, aplikacje HTA, adaptacje folderów HTT oraz… poczta! Cóż, ponieważ pocztę pobrano ze skrzynki do domu, to znaczy, że jest już lokalna, prawda? To założenie sprawiało, że IE przypisywał strefę lokalną skryptom wewnątrz wiadomości e-mail. Co prawda miały one służyć do animacji na papeterii, ale stosując pełny silnik IE, mogły nawet ładować skompilowany kod ActiveX.


WIDEO
Sprawdziłem aparat vivo X500 Pro Max. Jest dobrze

 Gdzie się kończy strefa lokalna?

Wystarczyło więc dostać maila z Nimdą i raz na niego kliknąć celem wyświetlenia podglądu – i komputer zaczynał rozsyłać Nimdę dalej. Wirus dodawał się też do wielu miejsc w systemie umożliwiających ładowanie go po restarcie. A gdy natrafiał na dyski twarde udostępnione bez kontroli hasłem – robił to samo na zdalnych maszynach. Gdy użytkownik nie dostał Nimdy mailem, nic nie szkodzi. Zainfekowany IIS serwował wraz z dokumentem HTML plik EML (czyli e-mail trybu offline), ten zostawał otwierany przez Outlooka, który z kolei uznawał go za lokalny i… działo się to samo. Wystarczyło wejść na zainfekowaną stronę Internet Explorerem.

Czy Microsoft poprawił dziurawe Strefy Zabezpieczeń i IIS? Nie musiał. IIS był już dawno załatany, a Internet Explorer 5.5 dostał Service Pack latem 2001. Aktualizacje dawno zlikwidowały problem, ale… na wielu komputerach nie były automatyczne. Pozwoliły wirusowi się rozpowszechniać mimo łatek. A jaką szkodę wywołał Nimda? Poza generowaniem wielkiego ruchu sieciowego i rozwalaniem ustawień systemu celem wspomagania propagacji – niewiele. To oczywiście samo w sobie jest poważnym problemem: co prawda pliki nie są uszkadzane ani szyfrowane, ale sam fakt "siania" wirusem po świecie mocno obniża zaufanie. W dodatku niektóre warianty Nimda doklejały się do plików EXE. Staroświecko, jak dawne wirusy.

 Czy przyszłość jest bezpieczniejsza?

Pozostaje pytanie, czy obecny design Windows jest już wolny od takich błędów. Oczywiście, w przypadku cieknących Stref Zabezpieczeń, w większości tak. Ale dużo pomaga w tym przejście z IE na Edge i śmierć "prawdziwych" programów pocztowych. Nośniki problemu, jak wbudowany MSHTML, są nieużywane; WSH i HTA są wyłączone/niedostępne i mają zostać usunięte, adaptacji folderów HTT nie ma już od lat, ale…

Został PowerShell. Jego w zasadzie nie da się wyłączyć (w przeciwieństwie do WSH). Da się zakazać uruchamiania niepodpisanych skryptów, ale da się uruchomić PowerShell.exe z parametrem "Unrestricted", a następnie wkleić cały skrypt w cudzysłów i wykonać inline. Co prawda nic już nie wykonuje takich rzeczy samo (nawet makra Office są już wyłączone), ale pojawia się plaga fałszywych stron "przeklej ten kod i wklej w okienko Uruchom, aby potwierdzić, że jesteś człowiekiem". Microsoft nie chce dodać przełączników łatwo blokujących PowerShell, upierając się, że ten działa jak należy. Czeka nas jeszcze dobrych kilka lat obecności tego problemu.

Wybrane dla Ciebie
NIE WYCHODŹ JESZCZE! MAMY COŚ SPECJALNIE DLA CIEBIE