Názory k článku Chyba ve FreeRADIUS umožňuje připojení k Wi-Fi bez hesla

FreeRADIUS 2.2.5 balicek v Debbianu Jessie https://packages.debian.org/jessie/freeradius
je stale neopraveny http://metadata.ftp-master.debian.org/changelogs/main/f/freeradius/freeradius_2.2.5+dfsg-0.2_changelog :-(

Již jsem si začal myslet, že je článek bez chyb. Nepovedlo se.
Volba je enable = no, to d navíc se tam připletlo mojí chybou.

Opravil jsem, díky.

Well done!

Pokud to dobře chápu, tohle je jiný princip – že se při obnově spojení účet vůbec neověřuje. Útočník by se tedy mohl „přihlásit“ bez znalosti jakéhokoli hesla.

Navíc zneplatnění všech session při změně je sporná praktika, při samotné změně hesla k tomu není důvod. Důvod k tomu je, pokud předpokládám, že někdo získal neoprávněný přístup k účtu – jenže ne každá změna hesla musí být vyvolána podezřením na kompromitaci hesla.

Je to exaktne stejnej princip, pri pouziti web session se taky nezjistuje zadny heslo, a proste se bere za to, ze autorizace prosla.
Ne, při použití session se předpokládá, že v dané session už byl konkrétní uživatel autentizován.

Stejný princip jako u té chyby FreeRADIUS by byl, kdyby si útočník vymyslel sessionID, odeslal požadavek (bez jména a hesla) na server, před získáním odpovědi spojení přerušil, pak se přesunul na jiný počítač a tam zadal stejné sessionID, a komunikace by prošla. Což u toho webu moc nedává smysl, protože tam se session vytvářejí proto, abyste věděl, který to je uživatel, takže mít autentizovanou session bez uživatele bude obvykle nemožné.

protoze user si to heslo (jako v tomhle pripade) meni prevazne proto, ze ma podezreni ze se na nej prihlasuje nekdo/nebo neco, co nema
To je pouze vaše domněnka.

S platnou session se muze vesele prihlasovat dal a protoze se session prevazne pri prihlaseni sama obnovuje ... tak libovolne dlouho a navzdy.
Session by samozřejmě mělo být možné zneplatnit, ale nemusí se to dělat automaticky se změnou hesla. Spíš by na to měl být mechanismus, který bude vyžadovat ještě něco, než jen znalost aktuálního hesla.

Trochu zapomínáte na to, jakou popisujete situaci. Pokud útočník uživateli změní heslo a tím ho zároveň odhlásí ze všech session, má uživatel smůlu a nadobro přišel o účet. Pokud útočník změní heslo, ale nezruší tím všechny session, původní uživatel je nejspíš někde ještě přihlášen a může přes tohle původní přihlášení svůj účet znova ovládnout, změnit heslo a zrušit útočníkovu session.

V tomhle konkretnim pripade je to jen okoreneno tim, ze se platna session vytvori jeste driv, nez dojde k autorizaci, a presto, ze k ni nedoslo, zustava platna.
Ne, to není „okořenění“, to je podstata chyby.

Defakto neni v clanku popsano, jestli oprava resi jen to preruseni spojeni, nebo jestli resi i tu zmenu hesla.
Změny hesla se to vůbec netýká. Autentizace v tomhle případě ani nemusí být jménem a heslem, jako autentizační protokol je možné zvolit třeba klientské certifikáty nebo jednorázová hesla.

Při obnovení přerušeného spojení FreeRADIUS 3.0.x v defaultní konfiguraci důvěřuje autorizaci z doby vytvoření spojení. Dokonce ani neukládá dodatečně přiřazované parametry jako VLAN a při obnově je tudíž neposílá.

FreeRADIUS umožňuje obnovení parametrů i provedení dodatečných kontrol při obnovení spojení, ale správce to musí nakonfigurovat.

Při vytvoření spojení FreeRADIUS ukládá atributy User-Name, Stripped-User-Name a Cached-Session-Policy. Obsah posledního atributu si musí nastavit správce při úspěšném vytvoření spojení. Při obnově spojení může jeho obsah použít pro nastavení parametrů jako je VLAN. Pokud se do atributu uloží i čas vytvoření spojení, tak by mělo jít zkontrolovat, zda se mezitím nezměnilo heslo uživatele. Nezkoušel jsem to, v diskusním listu pro FreeRADIUS lze nalézt několik ukázek použití atributu Cached-Session-Policy.

Ne, předchozí úspěšné přihlášení totiž nemá žádnou spojitost s možností chybu zneužít. Jediná spojitost je ta, že to úspěšné přihlášení je potřeba na to abyste tu chybu omylem využili na současných telefonech.

Tedy teď si nejsem jistý na co vlastně reagujete.

U toho FreeRadiusu je potřeba pouze pokus o přihlášení, vhodně přerušený před ověřením hesla. Tedy "založení platné session" ještě před ověřením hesla a vhodným přerušením a následným navázáním spojení se znalostí té session se tomu ověřování úplně vyhnout.

U těch webů s tou session to tak je. Problém je, když se ta session dá prodlužovat (do nekonečna), například přístupem. Větším problémem je pak, když se předává v url kvůli tomu, že se má sdílet mezi doménami. To se pak snadno dostane i do googlu (protože uživatel někam pastne url) a taková session pak nevyprší (o to se postarají třeba roboti.)

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í.

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.
Tohle je trochu matoucí – i kdyby bylo ošetřeno předčasné ukončení komunikace, pořád zůstává prostor pro útok tím, že využiju čas mezi vložením neautentizovaného záznamu do cache a jeho vymazáním při neúspěšné autentizaci (nebo ukončení spojení). Sice by to útočníka omezilo na relativně krátký čas (nejspíš do timeoutu spojení), ale i za tu chvíli může napáchat relativně dost škod v síti, do které neměl mít přístup.

Předpokládám, že chyba byla opravena tím, že se neautentizované spojení do cache vůbec nevkládá, nebo je označené jako neautentizované a není na něm možné provést rychlou obnovu spojení.