W roku 2010 Microsoft nieskutecznie załatał błąd w obsłudze plików LNK umożliwiający zainfekowanie komputera przez samo włożenie do niego odpowiednio spreparowanego dysku USB. Łatę MS można było łatwo ominąć.
Podstawową bronią Stuxnetu był błąd w przetwarzaniu plików LNK (СVE-2010-2568), który pozwalał infekować każdy komputer, do którego został podłączony zarażony napęd USB. Komputery irańskich naukowców, które stanowiły ostateczny cel ataku, nie były podłączone do internetu, zatem możliwość ich zainfekowania przez napędy USB była główną nadzieją twórców wirusa. Błąd ten został pierwszy raz użyty w listopadzie 2008 przez konia trojańskiego Zlob. Z bliżej niesprecyzowanych powodów nikt – oprócz najwyraźniej twórców Stuxnetu – nie zwrócił wtedy uwagi na fakt używania przez Zloba błędu typu 0day i został on załatany dopiero kilka tygodni po odkryciu Stuxnetu. Łata była jednak nie do końca skuteczna.
Wczytywanie ikonek z plików wykonywalnych? Świetny pomysł!
Nie wiemy, jaka idea przyświecała twórcom mechanizmu wyświetlania ikon plików LNK w systemie Windows, gdy wpadli na pomysł, by można je było wczytywać z bibliotek DLL. Pliki LNK, zawierające skróty do innych plików lub folderów, mogą w Windowsie ładować swoje ikony z plików CPL. Z kolei pliki CPL to w istocie pliki DLL. Oryginalny eksploit polegał zatem na wskazaniu jako źródło ikony pliku LNK złośliwej biblioteki DLL. Wystarczyło samo podłączenie do komputera napędu USB je zawierającego i otwarcie dowolnego folderu (lub posiadanie włączonej funkcji AutoPlay) by doszło do infekcji.
Załatane, ale dalej podatne
Gdy błąd został nagłośniony Microsoft wypuścił łatę MS10-046, która wprowadziła listę dozwolonych plików CPL, z których można wczytywać ikony. W styczniu tego roku niejaki Michael Heerklotz odkrył jednak sposób na ominięcie tych ograniczeń. Wykorzystał on logikę mechanizmów zabezpieczeń by przemycić taką ścieżkę do złośliwego pliku, która na skutek wewnętrznej obróbki w systemie przejdzie wszystkie weryfikacje poprawności a jednocześnie wskaże na plik wybrany przez atakującego spoza białej listy.
Fragment kodu umożliwiającego atak
Opisany atak ma tym poważniejsze konsekwencje, że działa stabilnie i skutecznie we wszystkich wersjach Windowsa, ponieważ wykorzystuje wbudowane mechanizmy systemu i nie musi przejmować się zabezpieczeniami typu ASLR. Microsoft zainwestował w ostatnich latach wiele wysiłku w utrudnienie przeprowadzenia licznych klas ataków, jednak tego rodzaju błędy są praktycznie niemożliwe do wyeliminowania przez stosowanie ogólnych mechanizmów zabezpieczeń na poziomie systemu operacyjnego.
Aktualizujcie Windowsy albo przynajmniej modyfikujcie rejestr
Aby zabezpieczyć swój system trzeba zainstalować najnowsze aktualizacje. Aby tymczasowo uchronić swój system przed atakiem wystarczy z kluczy rejestru
HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler HKEY_CLASSES_ROOT\piffile\shellex\IconHandler
usunąć wartość pola (Default) i zostawić je puste. Spowoduje to, że ikony plików LNK będą białe – ale przynajmniej nikt nie wykona w ten sposób swojego kodu na Waszym komputerze.
Komentarze
A w jaki sposób próba wczytania ikonki z DLL-ki powoduje wykonanie kodu? Dlaczego nie można poprawić mechanizmu ładowania ikonek? Pliki EXE i DLL w Windowsie to w sumie takie same pliki tylko mają inne rozszerzenie. Oba pliki implementują ten sam format PE który pozwala na przechowywanie różnych zasobów i w tym m.n. ikonek. Czemu nie wystarczyło po prostu poprawić kodu parsującego pliki PE w poszukiwaniu ikonek?
>A w jaki sposób próba wczytania ikonki z DLL-ki powoduje wykonanie kodu
Okazuje się, że szukając ikony w danym pliku ten plik jest ładowany przez shell32.dll w explorer.exe wywołaniem LoadLibrary z domyślnymi parametrami. Domyślne parametry powodują oczywiście uruchomienie DllMain.
Co ciekawe, Windows umożliwia wczytywanie plików PE taki sposób, żeby traktować je wyłącznie jako zasób danych. Żaden kod z takiej DLL-ki nie jest uruchamiany, a całość trafia do pamięci z włączonym NX. Dlaczego to nie zostało użyte – dobre pytanie ;)
„Dlaczego to nie zostało użyte – dobre pytanie ;)”
Czyżby lobby producentów oprogramowania antywirusowego? ;>
Windows po załadowaniu Biblioteki DLL funkcją LoadLiblary wykonuje automatycznie funkcję DllMain. Problem polega(ł) na tym, że aby odczytać ikonę z biblioteki DLL, była ona ładowana za pomocą wspomnianej funkcji. Nie wiem dlaczego programiści M$ nie użyli funkcji LoadLiblaryEx z flagą LOAD_LIBRARY_AS_DATAFILE, dzięki czemu żaden kod nie może zostać wykonany z takiej biblioteki i możliwe jest jedynie odczytanie zasobów w niej zawartych (w tym ikon).
„Nie wiem dlaczego programiści M$ nie użyli funkcji LoadLiblaryEx z flagą LOAD_LIBRARY_AS_DATAFILE” – te oraz inne logiczne pytania są chyba niemożliwe do zrozumienia dla ichnich programistów.
„Wszyscy” od dawna już (chyba) wiedzą że najważniejszą rzeczą przy pisaniu programu/systemu/webaplikacji jest filtrowanie danych wejściowych i zapisywanych. Ale oni nie wiedzą.
To jest amelinium, tego nie pomalujesz.
Bo jak szybciej jedzie to bardziej rozpierdala
niech mi ktoś powie co było w tych rejestrach bo ikonki z menu start i wielu innych miejsc mi wcięło. Nie ostrzegliście że to nie dotyczy tylko ikonek z napędów ale całego windowsa.
Hehehe bracie chwała ci za poświęcenie w imię nauki
{85cfccaf-2d14-42b6-80b6-f40f65d016e7}
to tam mam ja :) Win 8.1
Zrobiłeś to na produkcyjnym systemie? Nawet się do tego nie przyznawaj. Takich rzeczy robi się na testowym Windows, np. na wirtualnej maszynie
Armatą na kreta. Przecież można zrobić backup gałęzi rejestru którą modyfikujemy.
Też poproszę o domyślne dla Win 7 Pro, bo się sypnęły wszystkie ikony po tym, niefajnie że dajecie niesprawdzone porady.
Jeśli ikony się sypnęły, to porada jest jak najbardziej sprawdzona… ;>
Ależ była sprawdzona… Domyślna wartość to {00021401-0000-0000-C000-000000000046}
Default GUID dla HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler
znajdziecie w HKEY_CLASSES_ROOT\.lnk\shellex\*
jakikolwiek podklucz bedzie mial ten guid jako default, dla piffile jest ten sam.
„Błąd Windows użyty w Stuxnecie nie był prawidłowo załatany od 5 lat.”
Ależ był prawidłowo załatany, Michael Heerklotz odkrył teraz kolejny (nowy) sposób na jego wykorzystanie, czyli nic nowego – stare błędy nowymi…celami do wykorzystania w inny sposób.