19-letnia luka w Windowsie pozwala wykraść dane logowania do Konta Microsoftu i VPN-ów

Na łamach serwisu habrahabr.ru użytkownik ValdikSS przedstawiahistorię buga, który pamięta jeszcze czasy jednordzeniowychpecetów z 256 MB RAM i dotyczy mechanizmu pojedynczego logowania(Single Sign-On). Użytkownik loguje się po uruchomieniu komputera,a potem system operacyjny wykorzystuje te dane do uzyskania dostępudo wszelkich zasobów lokalnej sieci, po protokole NTLM. Przesyłanesą w ten sposób nazwa domeny, nazwa konta i kryptograficzny skróthasła. Jeśli dane są poprawne, dostęp zostaje przyznany. Jeślinie, system wyświetla okno dialogowe z prośbą o nowe danedostępowe.

I w zasadzie nie byłoby tu problemu, gdyby nie dostęp do zasobówspoza sieci lokalnej. Wystarczy spróbować otworzyć zasób SMB wInternet Explorerze, Edge lub jakiejkolwiek innej aplikacjikorzystającej z Windows API – podczas zapytania zostaną wysłaneaktualne dane konta, jeszcze przed wyświetleniem okna dialogowego zpytaniem o dane dostępowe. Przeprowadzenie ataku jest trywialne –wystarczy np. osadzić na stronie internetowej klikalny obrazek zlinkiem do zasobu SMB, lub e-maila z takim obrazkiem wysłaćużytkownikowi Outlooka. Jedno kliknięcie ofiary w obrazek i jużdane logowania do sieci lokalnej są w rękach napastnika.

Uważano dotąd, że to nic strasznego, co z tego, że ktoś poznadane logowania w lokalnej sieci, i to bez hasła. Gorzej jednak, jakzaatakowany komputer wykorzystywany jest w firmowej domenie – jakzauważa ValdikSS, z nazwy domeny nietrudno zrozumieć, o jakąorganizację chodzi, a później wykorzystać te dane douwierzytelniania się do korporacyjnych zasobów dostępnych zInternetu. Czasem nawet nie potrzeba tu hasła. Odpowiedniozestawiając przy ataku na uwierzytelnienie NTLM serwer proxy, możnanawet uwierzytelnić się bez hasła – taki atak na ActiveDirectory (LDAP) z wykorzystaniem sniffera Intercepter-NGzaprezentowano już dwalata temu.

Sytuacja pogorszyła się wraz z nastaniem Windowsa 8, w którymMicrosoft zaczął zachęcać użytkowników do logowania się dosystemu nie poprzez lokalne konto, lecz poprzez konto Microsoftu.Oczywiście wciąż można było korzystać z systemu z kontemlokalnym, lecz wiele systemowych usług, na czele z Windows Store czyOneDrive było wówczas niedostępnych. Wspomniany wyżej atak,przeprowadzony przeciwko użytkownikom Windowsa 8, 8.1 czy 10, którzykorzystają z konta Microsoftu, da napastnikowi więc niebezużyteczne w zasadzie dane lokalnego konta, lecz znacznieatrakcyjniejsze dane konta Microsoftu. To już jednak też byłowiadome od jakiegoś czasu.

Wkładem ValdikaSS w tę metodę ataku jest odkrycie ciekawegozachowania Windowsa 10. Otóż jeśli nazwy NetBIOS i stacji roboczejsą takie same, podczas próby dostępu do zasobu Windows używadanych aktualnego konta (czy to lokalnego, czy Konta Microsoftu).Jeśli nazwy się nie zgadzają, a użytkownik korzysta z VPN-uwykorzystującego standardowy protokół uwierzytelniania MSCHAPv2,to system operacyjny przesyła nazwę użytkownika i skrótkryptograficzny hasła do VPN-u. Co z tym można zrobić? ValdikSSpokazuje to na poniższym wideo, z atakiem przeciwko użytkownikomInternet Explorera, ale zauważa, że atak można spreparować tak,by zadziałał też na ofiary korzystające z Chrome (wykorzystującścieżkę dostępu file://).

Podstawowym zastosowaniem jest oczywiście wykradanie dostępu doVPN-ów, jak autor odkrycia podkreśla, wielu dostawców stosuje tesame loginy i hasła do kont co do uwierzytelnienia VPN. Wystarczyzlokalizować usługę po adresie IP. A w wypadku przejęcia hashahasła do konta Microsoftu, to zawsze można spróbować sił ztęczowymi tablicami. W razie odtworzenia hasła, napastnik zyskujepełen dostęp do wszystkiego, co ofiara umieściła w microsoftowychusługach.

Samo wyrzucenie Internet Explorera nie rozwiązuje problemu. Wieleinnych aplikacji próbuje uzyskać dostęp do zasobów SMB poprzezAPI Windowsa. Najrozsądniej jest więc skorzystać z zaporysieciowej. ValdikSS radzi by domyślnie zablokować dostęp do portu445 dla wszystkich klas adresów poza:

192.168.0.0/16 169.254.0.0/16 172.16.0.0/12 10.0.0.0/8 fd00 :: / 8 fe80 :: / 10

Z kolei inni użytkownicy wskazali, że mechanizm wyciekania danych można zablokowaćteż w Rejestrze, wpisem:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0] "RestrictReceivingNTLMTraffic"=dword:00000002 "RestrictSendingNTLMTraffic"=dword:00000002

Jeśli chcecie sprawdzić, czy Wasze systemy są na atak podatne,wypróbujcie usługę Witch,która taki właśnie atak na protokół NTLM przeprowadza.