Hlavní navigace

Chyba ve FreeRADIUS umožňuje připojení k Wi-Fi bez hesla

Luboš Pavlíček

V dubnu se nám podařilo objevit zranitelnost v autentizačním serveru FreeRADIUS, která umožňuje připojovat se do sítě bez znalosti hesla. Některá zařízení zranitelnost nejspíše neúmyslně využívají pro své připojení do sítě.

Autentizace uživatelů v podnikových bezdrátových sítích

Nalezená zranitelnost se týká podnikových bezdrátových sítí, které pro ověřování používají metodu Protected Extensible Authentication Protocol (PEAP) či EAP-TTLS. Obě metody rozšiřují autentizační framework EAP, v obou se vytváří zašifrovaný TLS tunel. Údaje potřebné pro autentizaci uživatele se posílají uvnitř tohoto tunelu, většinou se kontroluje znalost hesla s využitím protokolu MS-CHAPv2. Studenti a učitelé z Vysoké školy ekonomické v Praze se takto ověřují v síti eduroam.

Ve frameworku EAP se používají následující pojmy:

  • supplicant (žadatel) – zařízení či příslušná část softwaru na zařízení, které se chce připojit do sítě,
  • authenticator (autentizátor) – přístupový bod (Access Point) či přepínač, ke kterému se zařízení připojuje,
  • authentication server (autentizační server) – aplikace, která povoluje či zamítá přístup do sítě. Při komunikaci mezi autentizátorem a serverem se obvykle používá protokol RADIUS, do kterého se zapouzdřují EAP zprávy.

Při autentizaci se zařízení (např. mobil) nejdříve připojí k nejbližšímu přístupovému bodu. Následuje zahájení EAP autentizace, kdy supplicant odešle vnější jméno a domluví se EAP protokol mezi zařízením a autentizačním serverem. Tato část komunikace není zašifrována a proto se jako vnější jméno někdy nastavuje anonymní identita.

Protokol PEAP definuje dvě fáze autentizace. V první se vytvoří šifrovaný tunel dle standardu TLS. Součástí je autentizace serveru, tj. kontrola jména a certifikátu serveru. Ve druhé fázi se ověřuje supplicant/zařízení. Posílá se reálné uživatelské jméno, pro ověření správného hesla se obvykle používá protokol MS-CHAPv2. Komunikace probíhá uvnitř vytvořeného TLS tunelu.

Po úspěšné autentizaci RADIUS server pošle autentizátoru zprávu Access-Accept, která obsahuje podklady k domluvení klíčů na zašifrování komunikace mezi zařízením a přístupovým bodem. Následuje tzv. 4-way handshake, který je popsán např. v článku „Odposlouchávání a prolamování Wi-Fi sítí zabezpečených pomocí WPA2“.

Ve schématu není vyjádřena EAP fragmentace – certifikáty serveru se nevejdou do jedné EAP zprávy a proto nutně dochází k rozdělení do více EAP zpráv a každá z nich se potvrzuje. Při úspěšné autentizaci si zařízení s našim RADIUS serverem vymění obvykle 11 zpráv.

Již od SSLv3 je součástí TLS podpora obnovení spojení (session resumption, viz RFC5246 sec 7.4.1.2). Nejdříve proběhne úplná TLS výměna a na jejím konci si obě strany uloží vygenerované session ID a bezpečnostní parametry včetně hlavního tajemství (master secret). Při vytváření následného spojení klient pošle session ID a pokud je platné, tak si obě strany obnoví uložený stav. Obnovení spojení výrazně zkracuje úvodní TLS výměnu, neboť není potřeba posílat certifikáty či se domlouvat na bezpečnostních parametrech.

V protokolu PEAP je definováno rychlé obnovení spojení (Fast Reconnect), které zahrnuje obnovení TLS spojení a též přeskočení autentizace a autorizace klienta ve druhé fázi. Při rychlém obnovení spojení obvykle postačuje vyměnit 4 zprávy s RADIUS serverem. Snižuje se i zatížení serveru, neboť nemusí ověřovat heslo vůči databázi či LDAP serveru.

Připojení protokolem EAP-TTLS má velmi podobný průběh. Pro rychlé obnovení spojení používá označení session resumption.

FreeRADIUS rychlé obnovení spojení podporuje od verze 2.1.x. Ve verzi 3.0.x je již povoleno ve výchozí konfiguraci. Údaje o sezení si ukládá do paměti či na disk, údaje jsou platné 24 hodin.

Odhalení zranitelnosti

Přibližně v polovině dubna jsme dokončili aplikaci, která uživatelům zobrazí logy z RADIUS serverů včetně přibližné lokalizace. Správci bezdrátové sítě si mohou zobrazit údaje pro jednotlivé účty či MAC adresy zařízení. Náš vedoucí začal aplikaci testovat a mimo jiné zadal vyhledání údajů za kolegu, který ten den nebyl v Praze. K našemu překvapení se vypsalo, že se ráno přibližně v 8:15 přihlásil do eduroam v budově na Žižkově. A poté znovu v době oběda.

Zavolali jsme mu a shodli se na tom, že někomu pomáhal nastavovat připojení do eduroam na mobilu. A protože dotyčný neznal své heslo, tak kolega použil své přístupové údaje. Po telefonátu si kolega změnil své heslo do eduroam a tím jsme problém považovali za vyřízený.

Druhý den kolega dorazil do práce a v průběhu dne jsme tak mezi řečí odbočili i k této záležitosti. Podívali jsme se do logů – a i tento den se stejné zařízení přihlásilo do eduroam pod účtem kolegy. Donutili jsme kolegu změnit si znovu heslo. Po změně hesla se notebook kolegy do WiFi nepřihlásil, dokud si na něm nenastavil nové heslo.

Po víkendu jsme se vrátili do práce – neznámé zařízení se opět přihlásilo pod účtem kolegy. To již začalo být podezřelé. První nás napadla chyba v konfiguraci RADIUS serveru. Prošel jsem všechny konfigurační soubory, spustil několik testovacích skriptů, ale nic jsem nenašel. V detailních logách požadavků a odpovědí vypadal průběh komunikace takto:

Time                |Direction, Type       | UserName  |Calling-station-id
---------------------------------------------------------------------------
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:05 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"

Apr 12 09:57:25 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| <-- Acesss-Challenge |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| --> Acesss-Request   |user@vse.cz|"7C-11-BE-5B-xx-xx"
Apr 12 09:57:25 2017| <-- Acesss-Accept    |user@vse.cz|"7C-11-BE-5B-xx-xx"

Tj. na začátku přišlo 8 Access-Request požadavků, které nejsou ukončeny povolením (Access-Accept) či zamítnutím (Access-Reject) přístupu. Po 20 vteřinách začne nové ověřování, kde k úspěšné autentizaci stačí poslat čtyři požadavky Access-Request.

Při debugování jsme zjistili, že první komunikace skončí na začátku druhé fáze PEAP autentizace, kdy supplicant neodpoví na MS CHAPv2 Challenge. Zařízení následně zruší asociaci s přístupovým bodem, připojí se k jinému přístupovému bodu bezdrátové sítě a poté zkusí rychlé obnovení spojení (Fast Reconnect). To je úspěšné, čímž se úplně obejde autentizaci i autorizaci.

Z analýzy zdrojových kódů vyplynulo, že FreeRADIUSu ukládá údaje o spojení ihned po vytvoření TLS tunelu s předpokladem budoucí úspěšné autentizace. Pokud autentizace a autorizace ve druhé fázi není úspěšná (EAP Failure), tak se údaje spojení z cache vymažou. Autoři FreeRADIUSu neošetřili předčasné ukončení komunikace ve druhé fázi autentizace.

O ověření zranitelnosti jsem požádal Pavla Kaňkovského z MFF UK, kterému velmi děkuji, že se začal problému intenzivně věnovat. Analyzoval zdrojové kódy a následně upravil testovací aplikaci eapol_test na otestování zranitelnosti. Též nahlásil zranitelnost autorovi FreeRADIUSu a spolupracoval s ním na jejím odstranění. 26. května vyšel FreeRADIUS verze 3.0.14, který chybu opravuje. Zranitelnost má přiděleno označení CVE-2017–9148. Zajímavostí je, že zranitelnost byla nahlášena již dříve. První pokus o opravu z února 2017 se příliš nezdařil, verze 3.0.13 je stále děravá.

Na řešení se velkou měrou podílel i správce národní eduroam federace Jan Tomášek z CESNETu, který o zranitelnosti informoval správce z připojených institucí i správce z jiných zemí. Do monitorovacího systému české federace eduroam doplnil pravidelné testování zranitelnosti u jednotlivých členů.

Zneužívá se zranitelnost v praxi?

Zařízení, na kterém jsme si všimli nestandardní autentizace do eduroam, byl iPhone od firmy Apple. Používá ho výše postavený pracovník školy a sledování jeho komunikace by pro některé kruhy mohlo mít větší finanční smysl. Na mobilu nebyl jailbreak, ani nebyly nainstalovány nějaké neobvyklé aplikace. Začali jsme monitorovat jeho síťový provoz, po měsíci vyhodnocování si nemyslíme, že by někdo cizí mobil ovládal.

V logách z FreeRADIUSu jsme našli 22 zařízení, která se do eduroam přihlásila s využitím uvedené zranitelnosti. Celkem 16 zařízení je od firmy Apple, v některých případech se takto přihlašují do eduroam již přes čtyři měsíce. Některá z nich se takto připojují téměř každý den.

Někteří vlastníci těchto mobilů si stěžovali, že s připojením do eduroam mají problémy – občas se jim mobil nepřipojí. V logách jsem našel případ jednoho zařízení, které se v průběhu dne snažilo připojit v 11:18, 11:53, 12:20, 12:40, 13:27,13:52 a 14:07. Teprve při posledním pokusu použilo fintu se zneužitím popisované zranitelnosti.

Na zapůjčeném iPhone 4S jsme byli schopni nasimulovat autentizaci bez ověření hesla. Obvykle stačí se jednou úspěšně přihlásit. Po změně hesla se zařízení dále „přihlašuje“ bez nutnosti zadat na něm nové heslo. Na iPhone se neobjeví dotaz na nové heslo. Na iPhone 6 s novější verzí IOS se nám zneužití zranitelnosti nasimulovat nepodařilo.

Celkem 6 zařízení má nainstalováno některou verzi systému Android, nejstarší je 4.1.2, nejnovější 6.0.1. Zařízení jsou od čtyř různých výrobců: Samsung, Lenovo, Motorola, Huawei. Využití zranitelnosti není spojeno se změnou hesla. Zařízení se úspěšné autentizuje pomocí hesla, poté se několik dní nepřipojí, největší nalezená přestávka je 15 dní. A poté se připojí s využitím uvedené zranitelnosti, tj. první pokus se v průběhu druhé fáze PEAP autentizace přeruší a poté následuje autentizace s obnovením spojení. V následující dny se připojují s ověřením hesla. Vzhledem k počtu výskytů jsem schopen uvěřit tomu, že přerušení při prvním pokusu o autentizaci je způsobené výpadky na síti.

Řešení je snadné

Popisovaná zranitelnost FreeRADIUSu je spojena s ověřováním zařízení (supplicant) pomocí protokolu PEAP či EAP-TTLS. Týká se i ověřování v drátových sítích pomocí 802.1X.

Nenarazili jsme na upravený software na zařízeních, který by tuto zranitelnost aktivně využíval. Starší zařízení firmy Apple nejspíše neúmyslně využívají chybu k obcházení bezpečnostní politiky. Pokud nastavím nové heslo, tak očekávám, že se zařízení s uloženým starým heslem již znovu nepřihlásí. Náhodně mohou chybu použít i další zařízení k připojení do sítě.

Řešení je poměrně jednoduché:

  • vypnout ve FreeRADIUSu cachování TLS session. Ve verzi 3.0.x to znamená nastavit „enable = no“ v sekci cache  souboru raddb/mods-enabled-eap.
  • upgradovat na FreeRADIUS 3.0.14.

Literatura

Našli jste v článku chybu?
12. 6. 2017 10:16
Honza Jaroš (neregistrovaný)

Podle distribučního konfiguráku z CentOS 7 pro FreeRadius 3.0.4 se to cachování vypíná volbou "enable = no", nikoli "enabled = no". Když jsem zkusil použít "enabled", ve výpisu konfigurace při startu "radiusd -X" se objevila defaultní hodnota.

12. 6. 2017 13:28

Dle logů si kolega heslo změnil asi tři dny po jeho nastavení na uvedeném mobilu. Když jsme narazili na problém, tak bylo jednodušší mu zavolat a požádat ho o změnu hesla, než procházet logy.

Samozřejmě neměl použít své přístupové údaje. Ale podpora uživatelů, kteří mohou ovlivnit náš plat, je specifická a někdy je použití vlastních přístupových údajů nejjednodušší krátkodobé řešení.