Błąd w protokole SMB umożliwiający kradzież hasła do Windowsa po raz pierwszy odkryto w 1997 roku. Dziura nie została wtedy w pełni załatana. Dzięki temu, po 18 latach dalej za jej pomocą można zaatakować nie tylko wszystkie wersje Windowsa (nawet Windows 10 preview), ale także produkty 31 innych producentów, m.in. Adobe, Apple i Symanteca…
Luka w SMB znana od 18 lat…
SMB jest kluczowym komponentem sieciowym włączonym domyślnie w każdej wersji Windowsa. W 1997 roku odkryto błąd odkryto błąd w Internet Explorerze, który wykorzystując słabość w protokole SMB pozwalał na kradzież danych loginu i hasła do Windowsa (wtedy 95).
Atak, w uproszczeniu, polegał na zaproszeniu użytkownika na stronę internetową, która wymuszała logowanie po SMB (file://x.x.x.x lub \\x.x.x.x) wykorzystując fakt, że Windows stara się logować do zdalnych zasobów SMB automatycznie i “po cichu”. To prowadziło do ujawnienia danych logowania podstawionemu serwerowi (dane są zahashowane, ale należy wziąć pod uwagę, że obecnie wszystkie kombinacje 8 znakowych haseł mogą być “złamane” przy użyciu oclHashcata w ok. 10 godzin).
Microsoft udostępnił wtedy poprawkę poprzez ciężką do zaimplementowania politykę GPO, ale nigdy nie usunął faktycznej przyczyny problemu (głównie z tego powodu, że jest to problem projektowy, tzw. “design flaw”). Dzięki temu, po 18 latach, błąd powrócił w nowym wcieleniu i pod nazwą “Redirect to SMB“. Problem “na nowo” odkryli pracownicy firmy SPARE, a swoim znaleziskiem podzielili się w raporcie.
Redirect to SMB – na czym polega atak?
Nowa odsłona ataku wprowadza po prostu nowy wektor ataku, do którego wykorzystuje webserwer odpowiadający ma żądania HTTP kodem błędu 301 lub 302 i przekierowujący użytkownika na zasób SMB (file://x.x.x.x). Celem atakującego jest więc wymusić przekierowanie do SMB w programie, który korzysta z dziurawej biblioteki urlmon.dll i któregoś następujących wywołań API:
URLDownloadA
URLDownloadW
URLDownloadToCacheFileA
URLDownloadToCacheFileW
URLDownloadToFileA
URLDownloadToFileW
URLOpenStream
URLOpenBlockingStream
W przypadku Internet Explorera jest to bajecznie proste. IE “rozumie” i obsługuje SMB, wystarczy więc odpowiednio spreparowana strona internetowa. Ale nawet jeśli ofiara nie korzysta z Internet Explorera, można ją z sukcesem zaatakować, np. tak:
- Stwórz HTML z linkiem do obrazka wskazującym na kontrolowany przez siebie zasób SMB
- Zapisz HTML jako .doc
- Prześlij .doc do pracownika.
Otworzenie pliku .doc przez Worda spowoduje, że edytor rozpozna iż jest to tak naprawdę nie dokument a strona HTML, więc zrenderuje go korzystając z — zgadliście — …Internet Explorera!
Sposobów jest oczywiście zdecydowanie więcej:
- Ataki Man in the Middle to jeden z przykładów. W każdą odpowiedź HTTP można wstrzyknąć zasób SMB. Ataki te można realizować np. poprzez ARP Cache Poisoning.
- XXE (XML External Entites), funkcja wspierana przez parsery XML może być nadużyta do przekierowań na SMB
- Kontrolki odpowiedzialne za np. “podgląd obraków” w znanych programach typu chat/IM
Wśród podatnych na “przekierowanie do SMB” aplikacji, SPARE wymienia Adobe Readera, Apple QuickTime, GitHub dla Windows, oraz Apple Software Update (iTunes) a nawet Microsoft Baseline Security Analyser czy antywirusy Symanteca (Norton) AVG, BitDefender i Comodo a także narzędzia związane z bezpieczeństwem (.NET Reflector i Maltego CE).
Poniżej demonstracja ataku na AVG:
Mam Windowsa — co robić, jak żyć?
No jakby Wam to powiedzieć… 😉 Sami za wiele nie zrobicie — przede wszystkim twórcy oprogramowania muszą przepisać swoje programy tak, aby nie korzystały z groźnych funkcji, które pozwalają na przekierowywanie żądań do SMB. To chwilę zajmie, dlatego do tego czasu najlepiej zablokować obsługę żądań SMB poza lokalną (zaufaną) podsieć, wydając na firewallu polecenie blokujące dostęp do portów TCP 139 i 445 w kierunku wychodzącym.
Warto też zapoznać się z wytycznymi Microsoftu z 2009 roku dot. tzw. Extended Protection for Authentication.
Dodatkowo warto wdrożyć zestaw dobrych praktyk od Rapid7.