Miesiąc temu, kontynuując temat pliku hosts, zaproponowałem żeby odebrać prawa do zapisu do pliku hosts wszystkim userom (warto rzucić okiem w komentarze). Oczywiście, malware działający z prawami admina może sobie te prawa przywrócić, ale obecnie żaden malware tego nie robi - więc wyprzedzilibyśmy twórców malware'u o drobny krok, i mieli krótką chwilę spokoju od kilku rodzin bankerów. Oczywiście kolejnym krokiem ze strony malware-writerów byłoby przywracanie zapisu do pliku, wtedy sysadmini może zaczęli by "audytować" ten plik (chodzi mi oczywiście o logowanie dostępu do pliku, i np. uruchamianie odpowiednich alertów/procedur gdyby taki dostęp został wykryty), a twórcy malware'u by to audytowanie wyłączali, i tak dalej i tak dalej.
W przypadku tej serii bitew tak na prawdę sprawa rozbija się o plik c:\windows\system32\drivers\etc\hosts. A gdyby tak zadać inne pytanie: co ten plik odczytuje?
Idąc tą drogą docieramy do modułu DNSAPI.DLL (szukając po stringach), oraz serwisu Dnscache (śledząc dostęp do pliku).
Powstaje kolejne pytanie: a co się stanie gdy w pliku DNSAPI.DLL podmienimy ciąg \drivers\etc\hosts na coś innego?
Odpowiedź brzmi: DNSAPI.DLL zacznie czytać z innego pliku. Plik \drivers\etc\hosts przestanie być używany, a lista sajtów phishingowych będzie mogła być dopisana do zupełnie innego pliku.
Co z tego wynika? To że nikt obecnie nie monitoruje tego "innego" pliku. Ba, on może nawet nie istnieje jeszcze (malware go sobie utworzy).
"Hah! Ale można monitorować dostęp do pliku DNSAPI.DLL"
Tak jest, i to jest kolejny naturalny krok który zostałby wykonany. Jaki będzie kolejny krok strony przeciwnej? Oczywiście zostawienie pliku DNSAPI.DLL w spokoju, i podmiana stringu ze ścieżką w pamięci serwisu Dnscache. Ilu sysadminów sprawdza ten string w pamięci serwisu? Ano właśnie...
Oczywiście naturalnym odruchem jest odebranie praw do dostępu do serwisu Dnscache wszystkim oprócz właściciela (czyli również adminowi te prawa są odebrane), ale jak się okazuje, tak już jest "by default" na systemach Windows XP (i wyższych jak mniemam).
Natomiast jeżeli malware będzie odpalony z admina, to to i tak nic nie da, ponieważ będzie mógł sobie przywrócić prawa dostępu do procesu wywołując kilka prostych API.
Które rodziny malware'u obecnie korzystają z tej metody? Na szczęście żadne mi znane. Mamy więc trochę czasu aby ustawić 'Audytowanie' dostępu do Dnscache na systemach które obsługujemy, lub dorzucić taką funkcjonalność w produktach podnoszących bezpieczeństwo które udostępniamy.
Czy jest jakieś dobre rozwiązanie tego problemu? O dziwo TAK - NIGDY NIE UŻYWAJ KONTA ADMINA DO NORMALNEJ PRACY! Konto użytkownika wystarcza. Malware uruchomiony z konta użytkownika ani nie ma dostępu do pliku hosts, ani do serwisu Dnscache. Ufam że wszyscy rozsądni użytkownicy tak właśnie robią, a na nierozsądnych i tak wystarczy dopisanie IPeków do drivers\etc\hosts.
Na koniec mała demonstracja:
By the way...
There are more blog posts you might like on my company's blog: https://hexarcana.ch/b/
Oraz kod Proof of Concept (tak tak, publikuje... to jest zlepek prostych funkcji WinAPI, żadnej magii tu nie ma, więc jeżeli ktoś myśli że niepublikowanie tego powstrzyma kogoś od wdrożenia powyższego pomysłu w życie, to jest niestety w błędzie, a wypadałoby żeby sysadmini (którzy nie zawsze są programistami) mieli okazję przetestować wypracowane rozwiązania):
hack_a_hosts.cpp (8KB, CPP, source, testowany na XP)
Uwaga: powyższy PoC ustawia prawa dostępu do Dnscache na full access dla user'a z którego jest uruchamiany, i nie cofa praw do oryginalnych (po resecie powinno się "samo" przywrócić).
Komentarze mile widziane ;>
Comments:
Yep, masz rację, trzeba po restarcie ponownie podmienić string. Natomiast przeżywalność restartu to zupełnie inna sprawa, i jest masa metod żeby to zrobić, nie wszystkie monitorowane ;>
@Jurgi
Hah, wg mnie to świetna sprawa. Co prawda nie sądzę by po za środowiskiem laboratoryjnym udało się to z wysoką skutecznością zrobić. Niemniej jednak pomysł mi się ultra podoba ;>
I jeszcze mam luźne skojarzenie z http://blog.didierstevens.com/2009/07/06/patching-pdf-readers-to-support-hidden-embedded-files/ :)
Podążając za kolejnymi skojarzeniami, mi z kolei to z "czytaczami" PDFów skojarzyło się z odblokowywaniem pewnych "serverowych" feature'ów w Windows XP: http://www.vttoth.com/mirror.htm ;>
@neonek
Do CPC wrócę jak tylko uda mi się uruchomić jakiś układ z AVR ;>
Co do uw-team.org, to są drobne problemy z serwerem w serwerowni (hardware). Powinno być za kilka dni online. Dla ciekawskich: rzućcie okiem na blip'a unknowa ;>
Co do AVR to też mam zamiar sobie coś sklecić, ale mam jeden problem. Nie wiem jaki układ wybrać (znaczy się wiem chcę 1280) tylko nie wiem jaki moduł uruchomieniowy (DIP) jak zwał, tak zwał wybrać. Może jakaś propozycja ?
To w sumie powinienem napisać pod postem o RAND_MAX, ale tam już chyba nikt nie zagląda ;)
Add a comment: