Kompromitácia doménových účtov zneužitím WiFi siete

Cieľ

Cieľom bude WPA2 Enterprise WiFi sieť, ktorá pre autentizáciu používa doménové prihlasovacie údaje a zariadenia nemajú dostatočne hardeningovanú konfiguráciu. Toto dovolí útočníkovi vystaviť tzv. Rogue AP (prístupový bod, ktorý sa tvári ako legitímny), ku ktorému sa reálny užívateľ pokúsi pripojiť.

Cieľ útoku: WPA2 - Enterprise
Autentizácia: doménové meno a heslo
Výsledok: Zoznam doménových mien a NetNTLM hashe hesiel

Attack Intro

Podstatou útoku je vytvorenie tzv. Rogue AP alebo Evil Twin, čo je access point (prístupový bod), ktorý bude mať nakonfigurované zabezpečenie a SSID rovnako, ako legitímna sieť na ktorú útočíme. K tejto sieti sa v ideálnom prípade pokúsi prihlásiť legitímny užívateľ, ktorý nám behom autentizačného procesu odovzdá svoje prihlasovacie meno a hash hesla pre prihlásenie do internej siete. Útočník má tiež možnosť deautentizovať pripojeného klienta z legitímnej siete, pričom klient sa pri pokuse o obnovenie pripojenia pokúsi autentizovať k nasadenému Rogue AP.

Behom tohto útoku získa útočník tzv. NetNTLMv1 hash užívateľovho hesla. Lámanie týchto hashov je podstatne rýchlejšie napríklad v porovnaní s lámaním zdieľaných hesiel pre WPA2-PSK. Pre porovnanie uvádzame benchmark z ktorého je vidieť rozdiel v rýchlosti. Pri benchmarku bol použitý notebook s pomerne staršou grafickou kartou nVidia Quadro K1100M.

• NetNTLMv1 – 395 700 000 hashov za sekundu
• WPA2 – 8410 hashov za sekundu

Benchmark NetNTLMv1 – nVidia Quadro K1100M:

Benchmark WPA2 - nVidia Quadro K1100M:

Pokiaľ má užívateľ nastavené slabšie heslo, ktoré sa nám podarí cracknúť, získame tým prístup do internej siete spoločnosti pod identitou napadnutého užívateľa.

Pre prevedenie útoku budeme potrebovať jeden externý WiFi adaptér podporujúci monitor mode a packet injection. O výbere vhodného adaptéru je možné nájsť množstvo zdrojov na internete, nám sa však osvedčili a pri teste sme používali adaptéry značky ALFA (AWUS051NH) a TP-LINK (TL-WN722N v1). Ďalej si pripravíme obľúbenú linuxovú distribúciu (v našom prípade Kali Linux) a môžeme začať.

Postup

Pre realizáciu tohto útoku je možné použiť niekoľko nástrojov, napr. eaphammer, hostapd-wpe, hostapd + freeradius ..
My budeme pre vytvorenie Rogue AP používať nástroj eaphammer, ktorý je možné nájsť na Githube

• https://github.com/s0lst1c3/eaphammer

Rozbehnutie tohoto nástroja je jednoduché a postup a prípadné pokročilé možnosti je možné nájsť v README alebo manuále nástroja. Najzákladnejší postup pre spustenie na Kali vyzerá takto:

$ git clone https://github.com/s0lst1c3/eaphammer
$ ./cd eaphammer
$ ./kali-setup
$ ./eaphammer --cert-wizard
$ ./eaphammer -i wlan0 --channel 4 --auth wpa-eap --essid Corp_SSID --creds

Podrobne je možné konfiguráciu Rogue AP modifikovať aj v config súbore v adresári:

• /hostapd-eaphammer/hostapd/hostapd.conf

Ak všetko beží, treba už len počkať na užívateľa, ktorý sa nám na sieť pripojí.

Pre crackovanie hashu je následne možné použiť napríklad nástroj hashcat, ktorý si poradí s väčšinou typických hashov vrátane NetNTLMv1

• https://hashcat.net/hashcat/

Hashcat od nás potom bude potrebovať pár informácií. Typ hashu, ktorý budeme crackovať sa zadáva parametrom -m a je možné ho nájsť priamo v helpe hashcatu:

Rovnako sa dá nájsť, spolu s príkladom ako má tento hash vyzerať, pomocou parametru --example-hashes:

Ďalej budeme potrebovať slovník, ktorý pre crackovanie použijeme. Ako proof of concept použijeme štandardný slovník rockyou.txt, ktorý sa dá stiahnuť z internetu prípadne je uložený defaultne v Kali v archíve /usr/share/wordlists/rockyou.txt.gz.

Posledná informácia, ktorú hashcatu dáme bude samotný hash, ktorý možeme skopírovať do textového súboru.

Výsledný príkaz bude vyzerať približne takto:

$ .\hashcat64.exe -m 5500 ..\hashes\corp_ssid.5500 ..\rockyou.txt

Pokiaľ sa hashcatu podarí nájsť heslo ktoré zodpovedá crackovanému hashu, zobrazí sa toto heslo vo výstupe:

Hashcat samozrejme podporuje hromadu pokročilých možností, ktorými sa dá zvýšiť pravdepodobnosť, že bude heslo uhádnuté ako sú napríklad masky a pravidlá. Informácie k týmto možnostiam je možné nájsť na stránkach hashcatu.

Crackovanie hesiel sa typicky neodporúča robiť vo virtuálnom systéme, pretože bude pravdepodobne bežať niekoľkokrát pomalšie ako na samotnom hostovi. Odporúčame teda spúšťať hashcat priamo na hostovi, ktorý má korektne nainštalované drivere na grafickú kartu aby ju pri crackovaní mohol použiť.

Testovanie a mitigácie

Pre užívateľa, ktorý je cieľom útoku nieje jednoduché odhaliť a zareagovať na tento útok. Rôzne operačné systémy reagujú rôznym spôsobom na zmenu pripojenia, resp. na pripojenie k neznámemu AP s rovnakým SSID.
Pri testovaní aký rozsah môže mať tento útok sme skúsili množstvo rôznych klientov, operačných systémov a ich konfigurácií aby sme zistili v akom prípade budú klienti na tento útok náchylný a v ktorých prípadoch korektne odmietnu komunikáciu s naším Rogue AP.

Najčastejším klientom s ktorým sa v korporátnej sieti stretneme sú užívateľské stanice s operačným systémom Windows. Konfigurácia zabezpečenia bezdrôtovej siete sa v systémoch Windows konfiguruje cez nastavenie adaptérov v „Network and Sharing Centre“. Pravým kliknutím na bezdrôtový adaptér a výberom možnosti „Status“ sa dostaneme na kartu stavu adaptéra. Následne sa výberom možnosti „Wireless Properties“ a karty „Security“ dostaneme na kartu konfigurácie zabezpečenia. Tu je po otvorení nastavení „Settings“ možné upravovať jednotlivé možnosti pri pripojení.

Testované konfigurácie klientov:

Windows 7

Rogue AP s untrusted certifikátom (podpísaný našou self-signed CA)

Pri použití kvalifikovaného certifikátu (Let's Encrypt) bol rozdiel v prvom scenári, kde Windows 7 užívateľovi zobrazil hlášku pre potvrdenie pripojenia rovnako ako v scenári 2.

Dialóg, ktorý je užívateľovi zobrazený obsahuje informácie o certifikáte, ktoré môže vyplniť útočník aby vyzerali legitímne. Potvrdzovací dialóg vyzerá nasledovne:

Windows 8.1

Windows 8.1 sa správal rovnako pri použití Rogue AP so self-signed aj kvalifikovaným certifikátom

Dialóg, ktorý je užívateľovi zobrazený obsahuje iba server thumbprint, na základe ktorého užívateľ nedokáže rozoznať či je AP legitímne alebo nie:

Windows 10

Windows 10 sa správal rovnako pri použití Rogue AP so self-signed aj kvalifikovaným certifikátom.

Dialóg, ktorý je užívateľovi zobrazený obsahuje iba server thumbprint, na základe ktorého užívateľ nedokáže rozoznať či je AP legitímne alebo nie:

Android 7.0 (Huawei Nova1) – Default network manager:

Android pri prvom pripojení umožňuje špecifikovať CA certifikát, reálne je ale otázka koľko užívateľov túto možnosť využije. Bez špecifikácie certifikátu sa Android 7.0 vždy automaticky pripojil k Rogue AP a odoslal prihlasovacie meno a hash hesla útočníkovi.

Android 8.0 (Samsung S9)

Pri použití defaultného network managera sa Android 8.0 správal rovnako ako Android 7.0 popísaný vyššie. Pri tomto teste sme použili aj aplikáciu tretej strany Wifi Manager stiahnutu z Play Storu, ale správanie bolo rovnaké ako pri použití defaultného managera. To znamená že Android 8.0 sa tiež vždy automaticky pripojil k Rogue AP a odoslal prihlasovacie meno a hash hesla útočníkovi.

iPhone 8 (iOS 12.1.2) / iPhone X (iOS 12.1.2)

Pri automatickom pripojení iOS overuje zhodu s predchádzajúcim potvrdeným certifikátom. Táto kontrola pri pokuse o pripojenie k Rogue AP zlyhá a zariadenie sa ďalej nepokúsi pripojiť. Znamená to, že sa prihlasovacie údaje útočníkovi neodošlú.

Užívateľ by musel manuálne kliknúť na útočníkom vytvorenú sieť, kde mu zariadenie zobrazí podrobnosti nového certifikátu. Až po potvrdení nového certifikátu bude zariadenie pokračovať v pokuse o pripojenie.

macOS Mojave 10.14.2

MacOS sa pri pokuse o pripojenie správa rovnako ako iOS. Overuje zhodu s predchádzajúcim certifikátom a po zlyhaní tejto kontroly nepokračuje s pokusom o pripojenie. Užívateľ musí manuálne zvoliť túto sieť a potvrdiť detaily nového certifikátu.

Záver

Ako je z testovania vidieť, pokiaľ je pripojenie klientov k internej sieti pomocou Wifi nakonfigurované aby bolo čo najviac "user-friendly", môže to so sebou niesť značné riziko. Útočník môže pomerne jednoducho získať prihlasovacie mená a heslá legitímnych užívateľov a použiť ich pre následný neautorizovaný prístup do internej siete spoločnosti.

Z testovania rôznych klientov je vidieť, že mobilné zariadenia s operačným systémom Android sú prednastavenej konfigurácií veľmi náchylné na tento útok. Opakom sú zariadenia s iOS a macOS, ktoré sú veľmi paranoidné a užívateľovi jednoducho nepovolia prístup k Rogue AP. Pri klientoch s operačným systémom Windows záleží na konfigurácií siete, prípadne na paranoji samotného užívateľa, ktorý má v mnohých prípadoch možnosť jednoducho pripojenie schváliť.

Ako obranu proti podobnému útoku je možné použiť autentizáciu klientskými certifikátmi, vynútenie validácie certifikátu AP pri prihlasovaní a ideálne zakázať pripájania vlastných zariadení do internej siete. Implementácia týchto opatrení nemusí byť možná v každom prípade a preto je treba ako vždy nájsť vhodnú strednú cestu medzi bezpečnosťou a použiteľnosťou nasadených technológii.

Poznámky z testovania

• Z hľadiska Enterprise WiFi Rogue AP útoku nie je rozdiel medzi Windows 7, 8.1 a 10
• Prínos mať trusted certifikát je pomerne malý a hodí sa na velmi špecifické situácie
• Android je veľmi náchylný na Enterprise WiFi Rogue AP Attack
• iPhone je odolný voči Enterprise WiFi Rogue AP Attack
• iOS sa chova rovnako ako macOS
• Ak originálny AP podporuje len TKIP nebo CCMP, je nutné toto na Rogue AP dodržať (kvôli Windows staniciam), univerzálna voľba je podpora oboch
• Klienti sa pripoja na 2.4 Ghz Rogue AP, aj keď legitímny AP je 5 GHz a naopak
• V prípade útoku mimo dosah Legit AP:
  - Legitímnemu klientovi je jedno či je Rogue AP na 2.4 nebo 5 GHz, z toho dôvodu je lepšie mať Rogue AP na 2.4 Ghz - väčší dosah, širšia podpora klientov
• V prípade útoku v dosahu Legit AP:
  - Ak je v dosahu Legit AP na 5 Ghz a Rogue AP na 2.4 GHz, klienti (Windows, Android) majú tendenciu pripojiť sa na 5 GHz
  - Z toho dôvodu, ak je legitímna sieť LEN 2.4 GHz, dáva zmysel mať Rogue AP na 5 GHz
• V prípade že Legit AP je na 5 GHz a u nej klient, ktorého deautentizujeme pripojí sa aj k našej 2.4 Rogue AP, ak ale v okolí nie je ďalší 5 GHz Legit AP
  - Z toho dôvodu je lepšie mať 5 GHz Rogue AP, ak sú v okolí akékoľvek Legit AP
• Na AP typu security WPA2-EAP-CCKM-CCMP sa dá použiť AP s typom security WPA2-EAP-CCMP
• libssl od verzie 1.1 podporuje ako minimum TLS 1.2, čo na linuxe znefunkčňuje hostapd a cely útok. Je potrebné upraviť MinProtocol v openssl.cnf:

vim /etc/ssl/openssl.cnf
MinProtocol = None