Skákající WiFi aneb jak ohrozit bezdrátovou infrastrukturu

Příběh o hledání záškodníka

Únor: WiFi se nám začíná hádat

Náš síťový guru Dan si začal všímat podivného chování našich WiFi přístupových bodů (AP) na 5 GHz. Všechna AP v budově se začala přelaďovat na kanály nedefinované pro DFS. AP toto obvykle dělají, když v kanálu, na kterém právě operují, zaznamenají meteoradar (tedy radar na počasí, který operuje ve stejných frekvencích).

Červen: nečekané zjištění

Problém je stále nevyřešen, ale výrobce našich AP to (nepříliš úspěšně) řeší. Sledujeme fóra, plnící se podobnými problémy jiných uživatelů. Dan již vyloučil aktivitu pravého meteoradaru a z pozorování anomálie zjistil, že se musí jednat o přístroj někoho ve firmě.

Červen: do příběhu nechtěně vstupuji já

Tím záškodníkem je můj mobilní telefon! Po ověření MAC adresy začíná vše hezky do sebe zapadat. Problém se začal projevovat, jak již bylo napsáno, v únoru. V únoru jsem do Etnetery nastoupil. Korelace s logy navíc ukazuje, že AP, která meteoradar detekují, jsou ta, kolem kterých se pravidelně pohybuji (tedy trasa: židle – kávovar – záchod).

Červen: fáze nedůvěry

Dan mi nevěří, že se nejedná o úmysl. Dokazuji, že telefon není rootnutý, nemá na sobě nic moc navíc a celkově je nemodifikovaný. Testujeme dále a opravdu AP utíká z kanálu jak před meteoradarem. Mé nadšení stoupá a začínám být lehce hyperaktivní z nově objevené moci. Menším vyděšením je nalezení dalšího kolegy se stejným modelem telefonu, který se však chová správně. Může to být ještě lepší?

Epilog

Lepší to být může. Testujeme mobil s dalšími Enterprise AP řešeními, u kterých telefon dokonce způsobuje DoS na 4–10 minut.

Jak to tak vypadá, shodou okolností jsem se dostal k telefonu, který se cítí být meteoradarem, jako (snad) jeden z miliónu.

A teď technicky

DFS, tedy dynamický výběr frekvence, je v principu technologie, která umožňuje jednotlivým AP při startu vybrat prázdnější vysílací kanál, případně se při zaplnění kanálu přepnout na volnější.

V rámci implementace DFS, musí WiFi AP operující na 5 GHz (dle ETSI EN 301 893 pro země EU) v případě detekce meteoradaru operujícího na stejném kanálu změnit svůj vysílací kanál. Toto opatření je zde právě z důvodu nerušení meteoradarů.

‍

Implementace se liší podle výrobce, ale běžně by mělo AP při detekci kolize s meteoradarem přestat v kanálu vysílat a přeladit se. Na nově vybraném kanálu následně probíhá detekce meteoradaru, která může trvat až 10 minut (opět záleží na implementaci). Delší doba je nutná, jelikož meteoradary se točí relativně pomalu a sledují různé azimuty.

‍

DFS kanály se liší dle státu. Toto v kombinaci s TPC, tedy maximální vysílací silou, (také kvůli rušení meteoradarů) je důvod, proč musíte u WiFi AP nastavovat zemi. V případě nastavení jiné země na AP, nebo přímo pokusu o vyřazení DFS, se jedná o porušení všeobecných ustanovení pro užívání rádiových frekvencí v daném státu.

‍

V našem případě tedy AP reagují validně jako při detekci meteoradaru. Problém je, že nejde o meteoradar, ale jen mobilní telefon.

Provedli jsme pár testů jako PoC (Proof of Concept) s následujícími předpoklady:

• nastavení země v rámci EU,
• detekce meteoradaru je zapnuta na AP (což je, myslím, samozřejmé),
• telefon se nemusí na WiFi připojit, stačí pokus.

Testy jsme provedli na následujících modelech:

• Aruba IAP-115-RW,
• Mikrotik hAP AC,
• Ubiquiti UAP AC PRO.

Z našich omezených testů vyplývá, že implementace uhnutí před vysíláním meteoradaru se výrazně liší:

• Aruba AP: uhne z kanálu, ale v závislosti na nově vybraném kanálu trvá detekce před vysíláním 1-10 minut.
• Mikrotik AP: uhne a v konzoli ukazuje “running AP”. Klienti toto AP ale do zásahu administrátora nevidí a nemohou se připojit.
• Ubiquiti AP: přeladí se na jiný kanál, detekce DFS trvá jen cca 1 minutu. Do restartu AP se ale nepřeladí jinam, což znamená zvýšení kolizí v kanálu.

Náš závěr z provedeného PoC je, že při správném určení AP lze poměrně efektivně způsobit DOS útok bez potřeby větších zdrojů.

‍

Jestli se jedná o špatný firmware v telefonu, špatný chipset pro WiFi nebo je naopak špatně detekční algoritmus (napříč výrobci), nejsme schopni posoudit. Možné je vše (nebo třeba něco úplně jiného...).

‍

Nechceme dělat ukvapené závěry. Nepodařilo se nám odhalit, jestli se jedná o validní vysílání meteoradaru z telefonu, nebo jen špatnou detekci ze strany AP. Nejsme ani plně vybavení na hlubší analýzu, a proto jsme v kontaktu s jedním výrobcem ohledně vyřešení tohoto problému.

A jak z toho udělat něco praktického?

(jak pro útočníka, tak pro penetračního testera)

Jak využít detekce meteoradaru pro DoS útok jsme si již ukázali. Jak se ale říká, DoS je jen nepovedený exploit (zneužití funkcionality, nebo díry pro vykonání autorem nezamýšlené operace). Navíc, při penetračním testování vás za DoS útok nikdo moc nepochválí. Tak jsme se částečně nechal inspirovat prezentací od Gabriela Ryana “The Black Art of Wireless Post-Exploitation” z DEF CONu a útok přes zlé dvojče AP jsme lehce ztišili.

‍

Pokud znáte princip útoků přes zlé dvojče AP a zajímá vás jen výsledné ztišení přes detekci meteoradaru, doporučuji přeskočit sem.

Útok přes zlé dvojče AP:

1. Najdeme cílené AP. Metodika a principy lepšího cílení jsou popsány v této prezentaci.
2. Nasadíme naše zlé AP se stejným ssid, jako cílené AP a se silnějším vysílacím signálem.
3. Přes replay útok zaplavíme médium deauth pakety jednotlivých klientů, které vidíme.
4. Klienti se od původního AP odpojí.
5. Pokusí se hned připojit zpět, standardně se ale klienti připojují k AP s nejsilnějším signálem. Což může být právě naše zlé AP.

Koncepčně se jedná o poměrně jednoduchý útok, který vyžaduje málo zdrojů. Koncepty ale většinou problematiku zjednodušují za praktické použití a i v tomto případě to není až tak triviální problém.

‍

Zaměřme se na WPA2-PEAP. Proběhlo prvních 5 bodů útoku a klient se snaží připojit na zlé AP. Dostaneme sice hashe, ale zlý RADIUS server (který bychom museli za zlé AP nasadit) nedokáže dokončit autentizaci a klient se nepřipojí. Co s tím? Útočník má teď dvě možnosti. Může zkusit obdržený hash prolomit online přes výkonný stroj (což pro slabá hesla už je triviální problém). Nebo v tento moment operaci preruší, hash prolomí offline v rámci dnů. Následně nasadí zlé AP znovu, už se znalostí hesla, se kterou dokáže již proces dokončit a klient se již následně na zlé AP připojí.

‍

Následně přes modifikaci provozu klienta může útočník dostat na cílený stroj například reverzní shell, který se po časové prodlevě (dostatečné pro to, aby se klient přepojil do původní uzavřené sítě) pustí a zavolá útočníkův stroj.

Hlučnost útoku:

Tento útok lze ale poměrně dobře detekovat.

1. Většina enterprise řešení WiFi AP už poskytuje detekci rogue AP (tedy AP, která nejsou naše, ale snaží se tak vypadat), čímž můžou upozornit místní IT na probíhající útok.
2. V případě offline prolamování hesel dostávají obránci čas detekovat v záznamech provozu anomálie spojené se záplavou deauth paketů.

Bod 1 může útočník obejít tím, že nasadí zlé AP například v blízké kavárně, kam chodí zaměstnanci s notebookem rádi pracovat. Pokud bude mít trochu štěstí, nevšimnou si, že se namísto na veřejné AP kavárny snaží připojit na zlé AP, které se tváří jako jejich firemní WiFi.

Bod 2 ale tak jako tak v rámci tohoto útoku neobejde.

A sem zapadá funkce detekce meteoradaru:

1. Útočník nasadí zlé AP na stejný DFS kanál jako jsou cílená AP,
2. Jeho AP ale nastaví tak, že nebude reagovat na meteoradar (protože je zlý),
3. Provede DoS cílených AP přes detekci meteoradaru,
4. Profit. Neposílá deauth pakety a záznam provozu jen obsahuje naprosto běžnou operaci a to tedy uhnutí před meteoradarem, které mělo za následek dočasné odpojení klientů.

Samozřejmě tento útok funguje jen v případě, že jsou cílená AP na DFS kanálech, ale i tak to otevírá poměrně zajímavou alternativu pro běžný útok přes zlé dvojče AP.

‍

P.S.: Rozhodně bychom se chtěli vyvarovat diskuzí ohledně vysílacích frekvencí meteoradarů a polemice o tom, proč jsou vůbec WiFi a meteoradary ve stejném pásmu.