Hlavní navigace

Nebezpečné prolomení ověřování identity a správy sezení

7. 9. 2011
Doba čtení: 5 minut

Sdílet

Slabiny autentizace a session managementu se týkají všech aspektů manipulace s ověřováním identity uživatelů a řízení aktivní relace. Autentizační mechanismy mohou mít závadnou správu oprávnění, funkci změny hesla, řešení zapomenutého hesla atp. Autentizace a session management bývají kritickými aspekty webů.

Návrh session managementu a autentizace je nutné správně vnést do architektury aplikace již v raných fázích vývoje (ve fázi návrhů, …). Není to jednoduché, session management se může stát, zvláště u rozsáhlých aplikací, velmi složitým tématem – pro vývojáře se vytvoření systému se silným a bezpečným session managementem a autentizací po celou dobu životního cyklu sezení uživatele často stává tématem nepolapitelným. Pokud se problematika správy sezení a autentizace podcení v návrhu, velice stěží se opravuje různými, mnohdy krkolomnými, záplatami v závěrečných fázích vývoje, ne-li po spuštění aplikace. Běžně užívané userid a heslo tak nemusí dostačovat u závažnějších aplikací, třeba v případě bankovních systémů. Mj. i proto se proces autentizace doplňuje silnějšími metodami autentizace – SW a HW kryptografickými tokeny, biometrickými prvky aj.

Obecné informace:

  

Základní informace u OWASP:

www.owasp.org/in­dex.php/Top10_2­010-A3

Potenciální útočníci: vnější anonymní útočníci, uživatelé s vlastními účty snažící se krást jiné účty, zasvěcení maskující své akce.

Vektor útoku: útočník využívá nedostatků a chyb ve funkcích souvisejících s uživatelským ověřováním anebo session managementem (účty, hesla, ID relace atp.). Jedná se o chybnou správu sezení a autentizace.

Slabina: Vývojáři se často snaží vytvářet vlastní systémy ověřování a správy sezení. Avšak stavba takového systému bývá mnohdy složitá. Tím vznikají nedostatky v odhlašování, správě hesel, timeoutech, „pamatování“ si uživatelského sezení, tajnou otázkou, aktualizací účtu atp. Taková slabá místa, vzhledem k jedinečnosti systému, mohou být obtížně objevitelná.

Tvůrce webové aplikace by si měl klást některé základní otázky:

  • Jsou ověřovací údaje při ukládání chráněny hešováním nebo šifrováním?

  • Nejsou ID relace vystaveny v URL?

  • Nejsou relace ID zranitelné vůči útokům typu session fixation anebo session hijacking?

  • Jsou ID relace změněny po úspěšném přihlášení?

  • Jsou hesla, kódy ID relace a další ověřovací údaje posílány pouze přes šifrované spojení?

  • Není nastaven příliš dlouhý timeout pro vypršení sezení?

  • Jsou požadavky přijímané serverem vázány na konkrétní instanci klienta (IP, user-agent atd.)?

  • Není možné ověřovací údaje uhodnout (např. predikovatelné přihlašovací údaje, relace ID, obnovovací heslo atp.)?

  • Je úložiště hodnot ID relací bezpečné?

  • Je vynucována změna hodnoty ID relace po dostatečně krátkém čase?

  • Jsou rozlišovány relace ID anonymních a neanonymních uživatelů?

  • Nejsou v aplikaci použity uživatelské údaje jako proměnné?

  • Není aplikace příliš závažná na to, aby umožňovala ukládání (zapamatování) si uživatelských ú­dajů?

Technické dopady: Uvedené chyby umožňují útočníkům prolomit některé nebo všechny účty. Po prolomení útočník může někdy provádět vše, co oběť. Jindy si může alespoň přečíst více či méně citlivé údaje. Často jsou útoky mířené na privilegované účty.

Obchodní dopady: Je zapotřebí zvážit obchodní hodnotu dotčených údajů či aplikační funkce. Též je vhodné zvážit obchodní dopad v důsledku zveřejnění zranitelnosti.

Příklady scénářů:

Scénář 1

Aplikace pro rezervaci letenek podporuje session ID v URL:

example.site/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

Přihlášený uživatel se chce se svou letenkou pochlubit přátelům. URL jim pošle e-mailem. Netuší však, že svým přátelům tak odhalí i své session ID. Znalí uživatelé se mohou prostřednictvím tohoto údaje dostat do sezení uživatele.

Scénář 2

Timeouty v aplikaci nejsou nastaveny správně. Uživatel pro přístup do aplikace používá veřejný počítač. Z aplikace se neodhlásí způsobem kliknutí na „Odhlásit“, ale pouze zavře kartu prohlížeče a od počítače odejde. Útočník použije stejný prohlížeč o hodinu později – má možnost vstoupit do neukončeného sezení oběti.

Scénář 3

Uživatel se přihlásí do aplikace. Útočník uživateli zcizí hodnotu session ID (např. fyzicky z počítače, XSS útokem, sociálním inženýrstvím atd.). Útočník si z jiného počítače (a třeba i ze sítě) načte webovou aplikaci, kterou používá uživatel. Útočník hodnotu session ID v cookie přepíše na hodnotu zcizenou oběti, požadavek s přepsanou hodnotou podstrčí a ocitne se v sezení oběti. Ukažme si to v aplikaci Web Goat:

Mějme dva uživatele webové aplikace: webgoat a aspect. Uživatel aspect je útočník a webgoat jeho oběť.

Web Goat: Uživatel webgoat vstoupí do aplikace. 

Web Goat → Session Management Flaws → Spoof an Authentication Cookie → User Name: webgoat a default k Password: webgoat

Útočník nějak zcizí hodnoty cookies – AuthCookie a JSESSIONID. Pro Mozillu Firefox existuje mnoho nástrojů, které hodnoty cookies pomohou zjistit. Např. z hlaviček pomocí LiveHTTPHeaders:

Dalším programy jsou např. Cookie Manager+, AnEC Cookie Editor aj.

Útočník vstoupí do aplikace pod svými uživatelskými údaji: User Name: aspect a default Password: aspect.

Útočník k útoku použije např. proxy Web Scarab. Nastaví Web Scarab → Proxy → Manual Edit → Intercept requests

Web Scarab: Tím se požadavky pozastavují pro další

Web Scarab → přepsání hodnot AuthCookie a JSESSIONID

Web Scarab: Web Goat → Accept Changes

Web Goat: útočník „přeskočil“ do sezení uživatele webgoat

Scénář 4

Útočník své oběti podstrčí odkaz na web s předem určenou hodnotou session ID (např. zadáním do URL). Oběť se přes podstrčený odkaz přihlásí do aplikace. Útočník pro vstup do sezení oběti využije podstrčenou hodnotu session ID.

Scénář 5

Uživatel se běžným způsobem odhlásí ze svého sezení v aplikaci. Neuzavře prohlížeč. Prohlížeč využije jiný uživatel (útočník), jenž v prohlížeči klikne na tlačítko „Zpět“ – ocitne se v sezení předchozího uživatele.

Scénář 6

Hodnota session ID je snadno predikovatelná. To zjistí útočník. Ručně anebo roboticky aplikaci podstrkuje možné hodnoty session ID – dokud se tímto způsobem nedostane do sezení některého přihlášeného uživatele.

Vývojáři, kteří vyvíjejí vlastní session ID, často zapomenou zahrnout složitost a nahodilost hodnoty, které jsou nutné pro bezpečnost. Pokud hodnota session ID není dostatečně složitá a náhodná, potom je aplikace náchylná na prolomení hrubou silou (např. lze automatem podstrkávat hodnoty session ID a vyčkávat, než dojde ke vniknutí do sezení jiného uživatele).

Jestli jsou hodnoty session ID dostatečně náhodné a složité, si vývojáři mohou otestovat např. s pomocí nástrojů Web Scarab a Burp Suite. Vyzkoušejme to opět na aplikaci Web Goat:

Web Goat

→ Start
→ Session Management Flaws → Hijack a Session

Web Scarab:

→ Proxy → Manual Edit → Intercept request

Web Goat

→ Login (bez vyplněných údajů)

Web Scarab

→ Accept Changes

→ SessionID Analysis → Collection → Previous Requests: POST

http://localhos­t:808/WebGoat/at­tack 200 OK

→ SessionID Analysis → Request → Raw → WEAKID= … smazat

→ SessionID Analysis → Response → Raw → Test

→ hláška Extracted Sessionids → OK

→ SessionID Analysis → ve spodní části zadat Samples třeba na 100 → Fetch → následně Analysis → vybrat URL

→ Export

Burp Suite

→ sequencer → manual load → load → open (vybrat)

root_podpora

→ analyse now

Závěr

Výskyt slabin typu Session Management a Broken Authentication je častý. Dopady případných útoků mohou být kritické. Zjistitelnost pro mnohé uživatele nebývá snadná (nicméně v některých případech může být náhodná), pro znalé útočníky bezproblémová. Typů těchto slabin je mnoho. Některé jsou snadno opravitelné, jiné opravy vyžadují kompletní přepracování celé architektury aplikace.

Byl pro vás článek přínosný?

Autor článku

Petr Dušek se věnuje kvalitě a testování SW, inicioval také vznik projektů CAPTCHA Help a Skener webu či překlad OWASP Top 10.