Sidejacking aneb nasloucháme v síti

V předchozím článku jsem zeširoka nakousl session hijacking jako úvod do dalších brzkých dílů. Ale jak už to tak při psaní blogísku bývá s volným časem, je ho čím dál méně, takže pokračování přichází až teď, po třech měsících. No nic, podívejme se na první možnost krádeže Session ID, kterou je Sidejacking čili odchycení SID z běžného sítového provozu.

Kdo poslouchá za rohem?

Nejjednodušší cestou je sniffování neboli odchytávání paketů na lokální síti. K tomu je zpravidla potřeba síťová karta přepnutá do tzv. promiskuitního módu, ve kterém poslouchá veškerou komunikaci probíhající v daném segmentu. Pro zpracování, třídění a prohlížení zachycených paketů pak existuje celá řada utilit a programů, jako je tcpdump, dsniff, Wireshark a mnoho dalších.

Sniffování se útočníkům komplikuje překlápěním lokálních sítí na přepínaný bezkolizní Ethernet. Lapidárně řečeno, místo hubu se použije switch ;). V takové síti pak i útočník v promiskuitním módu vidí pouze svou vlastní komunikaci, protože switch do jeho síťového segmentu nic jiného nepustí.

Naopak se v poslední době dramaticky zvyšuje počet nešifrovaných bezdrátových Wi-Fi připojení, která může odposlouchávat prakticky kdokoliv. Pro útočníka odpadá nutnost být nějakým drátem fyzicky připojen do sítě, nezabezpečená data létají volně vzduchem. Poměrně populární je šifrování Wi-Fi spojení pomocí protokolů WEP a WEP2, které ale byly již před mnoha lety prolomeny a jsou tak zcela nepoužitelné. Spolehlivým řešením je použití protokolů WPA, WPA2 či EAP.

Přihraj to ke mně

Pokročilejší variantou je ovládnutí některého síťového prvku po cestě. Útočník může například fyzicky připojit svůj počítač těsně před router. Nebo využít nějakou slabinu routeru, převzít nad ním kontrolu a naslouchat provozu přímo na něm. Nebo změnit jeho směrovací tabulky a prohánět veškerou komunikaci přes svůj počítač. Případně router úplně vynechat a komunikaci si nechat posílat přímo k sobě pomocí ARP poisoningu či DNS spoofingu.

Pří útoku nazvaném Man-in-the-middle vstoupí útočník některým z výše popsaných způsobů přímo do komunikace mezi serverem a klientem. Sám pak funguje jako transparentní proxy. Vůči oprávněnému uživateli se tváří jako server, přijímá od něj dotazy, ty coby klient přeposílá skutečnému serveru. A v opačném směru zase vrací odpověď. Vše samozřejmě zároveň zachytává.

Zvláštním případem jsou již existující proxy servery. Logování a cachování komunikace vykonávají už ze své podstaty. Útočník, který se jich zmocní, tak má přístup ke všem datům na nich uloženým, mimo jiné právě i k zachyceným SID.

Šifrováním k blahu lidstva

Je asi zjevné, že vy jako weboví vývojáři nemůžete těmto útokům zamezit přímo. Nemáte totiž pod kontrolou celou síťovou infrastrukturu na cestě od svého serveru až k uživateli. Všechno, co můžete změnit, je pouze a jen vaše aplikace a nastavení vašeho serveru.

Z tohoto pohledu je jedinou účinnou ochranou proti sidejackingu komunikace po šifrovaném kanále. V případě webových aplikací tedy zavedení SSL/TLS šifrované komunikace založené na důvěryhodném serverovém certifikátu. Mezi klientem a serverem je ustanoven šifrovaný HTTPS kanál, do kterého nikdo po cestě nevidí, nemůže v něm nic číst ani měnit.

Nepodceňujte svou aplikaci

Pokud se rozhlédnete po dnešním internetu, většina webových aplikací šifrování vůbec neřeší. Hlavní důvody pro takovou lehkovážnost jsou vesměs čtyři:

• Vývojáři se domnívají, že jejich aplikace něco takového vůbec nepotřebuje.
• Administrátoři neumí šifrování správně nainstalovat a nastavit.
• Je potřeba mít koupený důvěryhodný certifikát od nějaké všeobecně známé certifikační autority, což stojí nějaké peníze.
• Šifrování zvyšuje zátěž serveru.

Oprávněnost jednotlivých bodů nechť si u svého projektu zváží každý sám.

Šetříme na nesprávném místě

Často také můžete vidět aplikace, které šifrují pouze některé své části, jako je registrace, přihlašování či odesílání objednávky. Problém je ale v tom, že Session ID se mezi klientem a serverem obvykle posílá vždy, nejen v těchto vybraných sekcích. Útočník tak může snadno získat SID a s ním i přístup k celé uživatelově session právě při odchycení libovolného nešifrovaného dotazu.

Ale i když se snažíte šifrovat vše, na jedno místo můžete zapomenout.

Uživatelé na náš web často přicházejí prostým zadáním názvu domény, čili nešifrovaným HTTP kanálem. Pak bývá zvykem přesměrovat je pomocí HTTP 301 do zabezpečené komunikace. Častou chybou ale je, že jim hned při této první odpovědi nastartujeme sessions a pošleme v cookies přidělené Session ID či jiné citlivé informace. To je ale špatně, protože v tomto okamžiku jde odpověď ze serveru ještě po nešifrovaném kanále, naslouchající útočník tak přidělené SID bez problémů odchytí. A i když se poté oprávněný uživatel k serveru přihlásí již skrz zabezpečenou komunikaci, útočník už má k jeho přihlášené session volný přístup.

Muž uprostřed cesty

Ani zašifrovaná komunikace není samospásná. Pokud při ní útočník použije útok Man-in-the-middle, vypíše se uživatelům varování o chybném certifikátu. To ale většina z nich bez problémů odklikne, protože je na to z jiných webů zvyklá a stejně tomu vůbec nerozumí. Navíc vůči klientovi nemusí útočník vůbec komunikovat přes HTTPS, ale už od samého počátku může udržovat pouze nešifrované HTTP spojení. Oslím můstkem bychom se mohli dostat i ke klasickému phishingu a podobně.

Tady už se ale dostáváme na tenký led uživatelské neznalosti a neopatrnosti, kdy nám bohužel nepomůže ani šifrování, ani svěcená voda.

Seriál o bezpečnosti sessions

1. Nenechte si uhodnout Session ID
2. Session hijacking aneb ukradení SID
3. Sidejacking aneb nasloucháme v síti (právě čtete)
4. Session ID do URL nepatří
5. Předávání SID pomocí cookies
6. Bráníme se zneužití ukradeného SID
7. Session fixation aneb nenechte si podstrčit SID