Únos relace (také známý jako cookie hijacking nebo cookie sidejacking) označuje kybernetický útok, při kterém útočníci převezmou relaci legitimního uživatele a získají její ID, díky které se za tohoto uživatele mohou vydávat v libovolném počtu síťových služeb. Tento typ útoku je nebezpečný zejména pro aplikace, protože útočníkům umožňuje získat neoprávněný přístup k chráněným účtům a v nich uloženým datům.
Pokaždé, když uživatel přistupuje k webové stránce nebo aplikaci prostřednictvím připojení HTTP, dojde před otevřením komunikační linky a poskytnutím přístupu k ověření uživatele (například pomocí uživatelského jména a hesla). Samotná připojení HTTP jsou však “bezstavová”, což znamená, že každá akce, kterou uživatel provede, je posuzována nezávisle na sobě. V důsledku toho – pokud bychom se spoléhali pouze na protokol HTTP – by se uživatelé při každé provedené akci nebo zobrazené stránce museli znovu ověřovat, tedy znovu zadávat své přihlašovací údaje. Relace tento problém řeší.
Relace se vytvoří na serveru hostujícím webovou stránku nebo aplikaci, jakmile se uživatel přihlásí, a následně slouží jako reference pro počáteční ověření. Uživatelé mohou v podstatě zůstat ověřeni – a tedy přihlášeni – tak dlouho, dokud je na serveru relace otevřena. Uživatelé mohou relaci ukončit odhlášením ze služby a některé služby ukončí relaci po předem definované době nečinnosti.
Většina služeb vytváří tyto relace pomocí ID, jež představuje řetězec čísel a písmen uložený v dočasných souborech cookie relace, adresách URL nebo skrytých polích na webových stránkách. V některých případech se tato ID relací šifrují, ale není tomu tak vždy. V mnoha případech jsou tyto identifikátory relace založeny na předvídatelných informacích, jako je IP adresa uživatele.
K únosu relace dochází, když útočníci získají neoprávněný přístup k ID relace uživatele, což jim umožní převzít jeho online identitu. Útočníci se tak mohou vydávat za legitimní uživatele, získávat informace a provádět akce pod jejich identitou.
Jak únos relace funguje?
Únos relace začíná, když útočník získá neoprávněný přístup k ID relaci uživatele. Útočníci tento přístup obvykle získají buď krádeží souboru cookie relace uživatele, nebo uživatele přesvědčí, aby kliknul na škodlivý odkaz, jenž obsahuje předem známé či předvídatelné ID relace (více o tom níže).
Jakmile útočník získá ID relace a uživatel se přihlásí k dané službě, může útočník tuto relaci převzít. Udělá to tak, že použije ID relaci legitimního uživatele v jeho prohlížeči. Takto se pak útočník může vydávat za legitimního uživatele a získat přístup k jakýmkoliv informacím nebo provést jakoukoliv akci, ke které má uživatel oprávnění. V případech, kdy mají uživatelé jednotné přihlášení, tzv. SSO (Single Sign-On), může útočník pomocí tohoto přístupu získat neoprávněný přístup k libovolnému počtu aplikací, čímž vážně naruší zabezpečení všech aplikací.
Jaké existují typy únosu relace?
1) Cross-Site Scripting (XSS)
Cross-site scripting (XSS) je jedním z nejoblíbenějších přístupů k únosům relací a zároveň jedním z největších rizik. K XSS dochází, když útočník najde zranitelnost na cílovém serveru nebo v aplikaci a zneužije ji tím, že do webové stránky vloží skripty na straně klienta. Stránka se pak načte s tímto škodlivým kódem, ale na straně uživatele vše vypadá legitimně, protože stále pochází z důvěryhodného serveru. Po načtení škodlivého kódu získá útočník přístup ke krádeži ID relace uživatele.
Útočník může při útoku XSS odeslat odkaz na důvěryhodnou webovou stránku, ale s upravenými parametry dotazu HTTP. Jakmile uživatel na tento odkaz klikne, útočník může získat přístup k jeho ID relace, nebo v některých případech může odkaz dokonce tyto informace odeslat přímo útočníkovi. V podobných případech útočníci obvykle používají zkracovač URL, aby skryli pravou adresu, a tedy i cokoliv podezřelého v odkazu.
2) Session Sidejacking aka Session Sniffing
Session sidejacking, známý také jako session sniffing, je aktivnější typ únosu relace. V tomto případě útočníci používají k monitorování síťového provozu a krádeži souborů cookie relace po ověření sniffing paketů, jako je Wireshark nebo Kismet. Uživatelé jsou vůči tomuto typu útoku nejzranitelnější, pokud server zašifruje pouze ověřovací stránku, a nikoliv i další stránky v rámci relace. V důsledku toho mohou útočníci získat ID relace po ověření na nešifrovaných stránkách v průběhu relace.
Důležité je, že útočníci potřebují k provedení tohoto typu útoku přístup do sítě uživatele, což znamená, že k vedlejšímu útoku na relaci obvykle dochází prostřednictvím nezabezpečených nebo veřejných sítí Wi-Fi.
3) Fixace relace
K fixaci relace dochází, když útočníci mohou nastavit ID relace uživatele. Tento typ útoku vyžaduje zranitelnost cílové webové stránky, která umožňuje nastavit ID relace prostřednictvím adres URL nebo formulářů. V tomto případě může útočník nastavit ID relace jménem uživatele a následně jej přimět k příslušnému přihlášení buď zasláním podvodné adresy URL, která obsahuje ID relace, nebo nastavením tohoto ID v rámci falešného přihlašovacího formuláře.
V obou případech se legitimní uživatel přihlásí na webovou stránku a ověří se pomocí ID relace, které stanovil útočník. Jakmile se uživatel přihlásí, může útočník převzít i ID relace.
4) Předvídatelné identifikátory relací a hrubá síla (brute force)
Mnoho webových stránek se řídí určitým vzorem pro vydávání ID relace a v některých případech může být tak jednoduchý, jako je IP adresa uživatele. V těchto případech mohou útočníci sledovat vydávaná ID relací a určit tak jejich vzor. Pokud se jim to podaří, mohou snadno předpovědět, jak by mohl vypadat platný identifikátor relace pro konkrétní uživatele, a vygenerovat si takový identifikátor relace, který pak sami použijí.
Podobně může dojít k útoku hrubou silou, pokud útočníci získají přístup k seznamu ID relací a zkoušejí je pořád dokola, dokud jedno z nich nefunguje. Takový seznam budou mít obvykle k dispozici, pokud je vzor pro generování ID předvídatelný. Rozdíl v tomto případě spočívá v tom, že nemusí být schopni předvídat ID pro konkrétního uživatele, takže budou muset zkoušet různá ID ze seznamu, dokud nenajdou shodu.
5) Adversary in the Browser (také známé jako Adversary in the Middle nebo Man in the Middle)
Útok adversary in the browser vyžaduje, aby útočníci nejprve infikovali počítač malwarem. Jakmile se malware nainstaluje a uživatel se přihlásí na webovou stránku, útočník může vystupovat jako adversary in the middle a zachytávat informace, měnit akce, které uživatel na webu provádí, nebo provádět další akce vydávající se za tohoto uživatele – to vše bez jeho vědomí. Vzhledem k tomu, že tento typ útoku pochází ze skutečného zařízení legitimního uživatele, může být velmi obtížné odhalit jakékoliv porušení zabezpečení aplikace.
S tímto typem přístupu k zařízení uživatele mohou útočníci také přejít přímo do složky dočasného místního úložiště v prohlížeči (tzv. cookie jar) a poté získat ID relace pro libovolné soubory cookie.
Jaká jsou rizika a důsledky únosu relace?
Úspěšný únos relace dává útočníkovi možnost dělat cokoliv, co může dělat cílový uživatel. To s sebou nese značné riziko pro zabezpečení aplikací v různých směrech, zejména pokud jde o zahájení peněžních transakcí, přístup k chráněným datům nebo získání neoprávněného přístupu k jiným systémům prostřednictvím SSO.
Mezi nejvýznamnější rizika únosu relace patří:
- Krádež finančních prostředků: Útočníci získají možnost provádět jménem uživatele finanční transakce. Může jít o převod peněz z bankovního účtu nebo nákupy s uloženými platebními údaji.
- Krádež identity: Útočníci získají neoprávněný přístup k citlivým osobním údajům uloženým v účtech, které mohou použít ke krádeži identity oběti mimo napadené webové stránky/aplikace.
- Krádež dat: Útočníci mohou ukrást jakýkoliv druh citlivých osobních nebo organizačních údajů uložených v aplikaci a použít tyto informace k poškození oběti nebo organizace (např. v případě vydírání) nebo k realizaci svých záměrů (např. v případě prodeje chráněných informací nebo duševního vlastnictví).
- Přístup k dalším systémům prostřednictvím SSO: Pokud je SSO povolené, útočníci mohou získat neoprávněný přístup i k dalším systémům, což dále rozšiřuje potenciální riziko útoku typu session hijacking.
Jaká existuje ochrana proti únosu relace?
1) Používejte protokol HTTPS
Ujistěte se, že webové stránky a aplikace, které váš tým používá (zejména ty, které jsou součástí SSO univerza), vyžadují používání protokolu HTTPS všude – i mimo úvodní přihlašovací stránky – abyste zajistili plně bezpečné relace v každé její fázi. Měli byste také dodržovat standard používání šifrování SSL/TLS pro všechno, včetně sdílení klíčů relací. Tato úroveň šifrování je první linií obrany při ochraně viditelnosti klíčů relací. Nakonec byste měli nastavit standard pro uzamčení přístupu k souborům cookie ze skriptů na straně klienta, abyste se ochránili před útoky XSS.
2) Spoléhejte se na webové rámce (web framework) pro správu souborů cookie relace
Čím delší a náhodnější soubory cookie relace se generují, tím lépe, protože je pak obtížnější je předvídat nebo odhadnout, což nabízí ochranu proti útokům hrubou silou. Nejlepším způsobem, jak dosáhnout této skutečné náhodnosti, je použít webový framework pro generování a správu souborů cookie relace, nikoliv vytvářet systém sám.
3) Změňte klíče relace po ověření
Nejlepším způsobem ochrany proti útokům fixace relace je změna klíče relace ihned po ověření při přihlášení. Změna klíče po přihlášení způsobí, že i když útočník zná původní klíč, nebude znát klíč, který bude uživatele sledovat po zbytek relace. Tento přístup znamená, že i když útočník pošle uživatelům podvodný odkaz a uživatelé tento odkaz použijí k přihlášení, útočník nebude moci s vygenerovaným klíčem nic dělat.
4) Zaveďte další oblasti pro ověřování totožnosti
Přidání nových oblastí pro ověření identity nad rámec počátečního přihlášení a výsledného souboru cookie relace může poskytnout další vrstvu ochrany. Můžete se například podívat na IP adresu uživatele a zjistit, zda se shoduje s místem předchozích přihlášení, nebo sledovat celkové chování každého uživatele, abyste lépe identifikovali případné anomálie. Tento přístup však není dokonalý: může přehlédnout například případy, kdy se útočník přihlásí ze stejné IP adresy, z jaké se obvykle přihlašuje uživatel.
5) Zaveďte IDS a IPS
Intrusion Detection System (IDS) a Intrusion Prevention System (IPS) porovnávají provoz na webu s databází známých signatur útoků. Pokud tyto systémy najdou shodu, zablokují tento provoz a upozorní vlastníky systému. Jejich instalace může být obtížná a nákladná, ale představují silnou obranou vrstvu proti únosům relací.
6) Časové relace uživatelů a/nebo požadavek na automatické odhlášení
Nakonec zvažte zavedení zásad, které řídí způsob, jakým uživatelé ukončují relace. Mezi dva oblíbené přístupy patří časové vyřazení uživatelských relací, zejména po určité době nečinnosti, a požadavek na automatické odhlášení při každém zavření okna. Oba tyto přístupy pomáhají minimalizovat dobu, po kterou zůstává určitý soubor cookie relace aktivní. Stejně tak byste měli zajistit, aby se po odhlášení uživatele soubor cookie relace automaticky odstranil z jeho zařízení, aby nedošlo k dalšímu vystavení se riziku.
Zdroj: keyfactor.com