Michal Čihař - Jak nedělat autentizační token

Jak nedělat autentizační token

Do phpMyAdmina chtějí protlačit podporu pro jeden autentizační token. Jak tato věc funguje na hardwarové úrovni nevím (má tam být nějaký autentizační kalkulátor, který na výzvu vygeneruje nějakou unikátní odpověď), ale docela mě pobavil přístup k bezpečnosti softwarového řešení okolo. Celá popisovaná věc se jmenuje Swekey a stojí za ním firma Musbe, založená jen kvůli tomuto zařízení ( to develop and market an innovative authentication technology ).

Token se strká do USB (v dnešní době to asi ani jinak nejde) a celou věc obsluhuje v Linuxu jakási binárka komunikující s tokenem přes libusb. No aspoň, že to bude hnít v userspace a ne v kernelu. Bohužel pokud to chcete použít na něčem jiném než i386, máte smůlu. Protože nám se jedná o autentizaci webové aplikace, máme ještě k dispozici další binárku a to plugin do prohlížeče Firefox (pro Windows případně ještě ActiveX pro MSIE).

Když už se uživateli poštěstí toto rozběhat (a nebude řešit takové nepodstatné otázky, jako třeba: proč binárka obsluhující ten token musí používat curl?), může vyzkoušet úžasné možnosti, které nám tato autentizace skýtá. A hlavně se podívat na kód, který se o autentizaci stará, protože ten již k dispozici máme. Kromě phpMyAdmina, kde je jakási meziverze už v SVN, ještě existuje plugin pro SquirrelMail a prý i patch pro RoundCube, modul pro PAM atd.

Jak vlastně celá věc funguje?

  1. Načte se ID z USB tokenu
  2. Ze serveru se stáhne náhodný token (platný dvě minuty)
  3. Náhodný token se nacpe do USB tokenu a ten vygeneruje OTP (jednorázové heslo)
  4. ID tokenu, náhodný token a OTP se pošle na server a ten je ověří

No vypadá to celkem jednoduše, tož pojďme se podívat jak to soudruzi naimplementovali. Podotýkám, že v patchi pro phpMyAdmin, už pomaly níže popsané problémy mizí, ale za cenu víceméně kompletního přepsání kódu, jak se (ne)budou vyvíjet patche/pluginy pro ostatní programy netuším, nicméně autoři pořád někde preferují původní řešení.

Komunikace

První věc, která kohokoliv musela praštit do očí bylo použití nešifrovaného HTTP spojení při komunikaci se serverem. Což ve spojení s jednoduchým až triviální protokolem, znamená, že kdokoliv, kdo je schopný na jakýkoliv HTTP požadavek odeslat odpověď "HTTP/1.0 200 OK\n\nOK" se může stát autentizačním serverem, který autentizuje cokoliv komukoliv. Soudruzi sice v patchi pro phpMyAdmina přešli na HTTPS s ověřováním certifikátu, ale z výkonnostních důvodů jinde zůstane nadále HTTP. Vskutku inovativní řešení.

Umístění souborů

Mapování tokenů na uživatele mělo být umístěno v kořenovém adresáři phpMyAdmina a tedy přístupné přes web. Což ve spojení s předhozí zranitelností znamená, že jediná informace, kterou by případný útočník potřeboval - ID klíče, který mu dovolí přístu, může bez problémů získat napsáním správného URL.

Dočasné soubory

Protože náhodný token je platný dvě minuty, rozhodli se autoři ušetřit námahu jejich serveru s generováním a tento token cachovat. Bohužel ukládat pevně pojmenovaný soubor do adresáře /tmp není zrovna nejlepší nápad a už vůbec není dobrý nápad tento soubor vytvářet s právy 777 . Co by se asi stalo, kdyby náhodný uživatel na serveru do tohoto souboru uložil třeba nějaký film a ten se následně začal odesílat na jejich server jako náhodný token při autentizaci?

No nechtějte to

Většina zde zmíněných problémů existuje ve všech implementacích tohoto tokenu, do kterých jsem se koukal. Kromě toho každá implementace přidává spoustu unikátních programátorských chyb. Zájemcům o pobavení se doporučuji modul pro PAM, který je vlastně jen spouštěč skriptu v bashi, který volá curl a komunikuje se serverem.

Update

Při psaní tohoto článečku mě napadl ještě jeden problém, kterým to asi bude trpět, ale nechtěl jsem to psát dokud to neověřím, což se právě stalo. Přístup k tokenu z prohlížeče není pluginem nijak omezován, takže jakákoliv stránka může zjistit ID vašeho tokenu a vygenerovat si OTP heslo. No lepší podmínky pro krádež identity si už lze představit jen těžko :-).