Zpět na seznam článků     Číst komentáře (7)     Verze pro tisk

Local Session Poisoning - Shared sessions

Autor: .cCuMiNn.   
25.10.2016

Na Internetu jsou miliony webových stránek hostovány na sdílených serverech (webhostingu). Čím dál častěji se ale objevují také nejrůznější cloudové služby, které nabízejí standardizované webové aplikace běžící na serverech poskytovatelů. Na každém z těchto sdílených serverů se pak nachází klidně i tisíce webových aplikací, přičemž existuje množství různých typů útoků, které umožňují získat neoprávněný přístup z jedné hostované aplikace do jiné. Tento text si klade za cíl popsat jeden takový typ útoku pojmenovaný Local Session Poisoning, jenž útočníkům na těchto serverech umožňuje provádět authorization bypass.


Background

Protokol HTTP je protokolem bezstavovým. To znamená, že každý request, který směřuje ze strany uživatele na webový server, je naprosto samostatný a soběstačný. Webový server si nijak nepamatuje předchozí stavy. Server vždy pouze vyřídí aktuální požadavek uživatele a po odeslání odpovědi tuto komunikaci okamžitě zapomene. Pokud uživatel potřebuje být při komunikaci přihlášen, musí se oproti serveru autentizovat s každým novým requestem. Bez externích mechanismů by to v praxi znamenalo, že by uživatel musel s každým svým požadavkem odesílat na server také své uživatelské jméno a heslo. Jak jistě chápete, neslo by toto s sebou rizika spojená s možným odposlechem a jinými útoky, které by se pokoušely takto přenášené přihlašovací údaje odcizit. Programovací jazyky proto zavádí sessions (relace), díky nimž se uživatel přihlásí pouze jedenkrát. Server po přihlášení vygeneruje náhodný session identifikátor (dále pouze SID), který si jednak zapamatuje, a jednak jej předá uživateli, aby se ten tímto identifikátorem nadále autentizoval. V případě PHP si server uloží vygenerovaný SID do úložiště sessions na filesystém jako soubor, který bude v defaultním nastavení PHP pojmenován prefixem sess_ a vygenerovým SID.

Ukázka výpisu sdíleného adresáře pro ukládání session souborů

Společně s odpovědí pak server odešle uživateli HTTP hlavičku Set-Cookie, která při defaultním nastavení serveru ponese hodnotu PHPSESSID=vygenerované_SID.

Výpis response serveru s HTTP hlavičkou Set-Cookie

Jakmile webový prohlížeč uživatele obdrží tuto odpověď, uloží si na základě HTTP hlavičky Set-Cookie předané hodnoty do úložiště cookies a přiřadí si je ke konkrétní doméně, která mu tuto hlavičku zaslala.

Add-on pro Firefox:  Cookies Manager+

Soubor, který si aplikace na straně serveru uložila do úložiště sessions, bude následně používán pro ukládání session proměnných. Ty mohou být ze strany aplikace ukládány takto:

$_SESSION["name"]="My Name";

Pokud tedy uživatel odešle na server své přihlašovací údaje, a server uživatele autentizuje, pak se vytvoří relace a server si do session proměnných uloží například id uživatele, jeho jméno a případně i jeho uživatelská práva.

Když následně uživatel odešle na stranu serveru další request, bude společně s ním předána serveru webovým prohlížečem automaticky také HTTP hlavička cookie, která bude obsahovat hodnoty všech cookies, které má webový prohlížeč pro danou doménu uloženy.

Výpis requestu s HTTP hlavičkou Cookie

Pokud webová stránka na straně serveru obsahuje volání funkce session_start(), načte server z úložiště relací session soubor, který obsahuje název se stejným identifikátorem, jako přišel v hodnotě cookie PHPSESSID. Obsahem tohoto souboru si prohlížeč naplní superglobální pole $_SESSION[] uloženými session proměnnými.

Následně se aplikace již může podle obsahu session proměnných rozhodovat, zda se uživatel již v minulosti autentizoval, o koho se jedná a jaká má tento uživatel privilegia.

Předpoklady pro úspěšný útok

  • Webový server hostuje více aplikací. Cílem útoku je provést autorizační bypass a ovlivnit jednu webovou aplikaci z aplikace jiné. Je zřejmé, že tohoto nebude možné dosáhnout na serveru, který hostuje pouze jednu jedinou webovou aplikaci.
  • Webový server používá pro ukládání session souborů všech hostovaných aplikací jedno sdílené úložiště. Mnoho webových serverů s podporou PHP je nakonfigurováno tak, aby session soubory všech hostovaných aplikací ukládalo do jednoho společného úložiště (adresáře). Defaulně je tímto adresářem temp. Pokud jste schopni na serveru spustit svůj vlastní kód, můžete zjistit spuštěním PHP funkce phpinfo(), kam session soubory ukládá Váš webový server. Úložiště pro session soubory najdete ve výpisu z phpinfo() pod položkou session.save_path. Ze svého scriptu lze pak úložiště vypsat také voláním PHP funkce session_save_path().
  • Hostované aplikace běží pod stejným uživatelským účtem. Session soubory se ukládají s přístupovými právy -rwx------ a jejich vlastnictíkem je uživatel, pod kterým běží interpret PHP. Předpokladem pro sdílení session souboru mezi různými aplikacemi tedy je, že budou tyto aplikace spuštěny pod stejným uživatelským účtem (např. www-data). To znamená, že interpret PHP musí na serveru běžet jako modul Apache. V případě spouštění interpretu jako CGI nebo Fast CGI, bude s největší pravděpodobností u jednotlivých aplikací odlišný vlastník, a ten tak díky právům na filesystému nebude mít možnost číst obsah cizích session souborů. V PHP lze uživatele, pod kterým aplikace běží zjistit voláním funkce get_current_user().
  • V některých případech je nutlé, aby byl útočník schopen spustit na serveru svůj vlastní PHP skript. Během některých útoků bude potřeba zjistit, resp. změnit obsah session proměnných. K tomu je potřeba, aby byl webový server hostingem, na který jsme schopni uložit a spustit své vlastní PHP skripty. V případě, že server legitimní upload a spuštění PHP skriptů neumožňuje, musí útočník vyhledat v libovolné z hostovaných aplikací takovou zranitelnost, která mu umožní vzdálené spuštění kódu (remote code execution, LFI, RFI, apd.).

Vektory útoku

Útoky proti cizím webovým aplikacím

Pro tento typ útoku je potřeba splnit požadavek na možnost spouštění vlastních PHP skriptů útočníkem na straně webového serveru. Tento typ útoku bude proto útočníky využíván převážně na sdílených serverech webhostingu.

Samotný útok je pak možné rozdělit do několika fází:

  • Útočník si na webhostingu založí vlastní webovou php stránku (mypage.hosting.xx) s následujícím obsahem:

    <?php
      session_start();
      print_r($_SESSION);
    ?>

  • Útočník navštíví svou stránku uvedenou v bodě 1, čímž dojde k vytvoření relace a útočníkovi se v prohlížeči uloží cookie (např. PHPSESSID).

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_1fd1jtmnbudtb1t9k31rlontq7       obsah: prázdný
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      mypage.hosting.xx                     PHPSESSID       1fd1jtmnbudtb1t9k31rlontq7

  • Následně si uživatel vyhlédne cíl (např. eshop.hosting.xx) hostovaný na stejném serveru, zaregistruje se do něj a po registraci se rovnou přihlásí.

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_1fd1jtmnbudtb1t9k31rlontq7       obsah: prázdný
      sess_hvmuld3jacojvl6lplar7b4fl1         obsah: customer_id=123
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      mypage.hosting.xx                     PHPSESSID       1fd1jtmnbudtb1t9k31rlontq7
      eshop.hosting.xx                      PHPSESSID       hvmuld3jacojvl6lplar7b4fl1

  • Útočník následně v úložišti cookies zkopíruje SID napadené stránky a přepíše jím SID své vlastní aplikace

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_1fd1jtmnbudtb1t9k31rlontq7       obsah: prázdný
      sess_hvmuld3jacojvl6lplar7b4fl1         obsah: customer_id=123
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      mypage.hosting.xx                     PHPSESSID       hvmuld3jacojvl6lplar7b4fl1
      eshop.hosting.xx                      PHPSESSID       hvmuld3jacojvl6lplar7b4fl1

  • Útočník navštíví svou webovou stránku, čímž předá v cookies změněnou hodnotu identifikátoru session. Vzhledem k tomu, že server využívá pro ukládání session sdílené úložiště, sáhne server po stejnojmenném souboru a naplní jím obsah pole $_SESSION. Kód print_r($_SESSION); na stránce útočníka poté způsobí, že skript vypíše seznam a hodnoty session proměnných, které si do relace uložil e-shop.

    Array
    (
        [customer_id] => 227
    )

  • Útočník vytvoří nový php skript, který pozmění hodnoty session proměnných:

    <?php
      session_start();
      $_SESSION["customer_id"]=98;
    ?>

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_1fd1jtmnbudtb1t9k31rlontq7       obsah: prázdný
      sess_hvmuld3jacojvl6lplar7b4fl1         obsah: customer_id=98
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      mypage.hosting.xx                     PHPSESSID       hvmuld3jacojvl6lplar7b4fl1
      eshop.hosting.xx                      PHPSESSID       hvmuld3jacojvl6lplar7b4fl1

  • Následně útočník navštíví webové stránky e-shopu. Aplikace načte hodnoty session proměnných ze sdíleného session souboru, kde nyní bude uvedeno customer_id jiného zákazníka.
  • Útočník se ocitl na cizím účtu, který může mít například i administrátorská práva.

Authentication bypass v cloudových aplikacích

V případě útoků na cloudové aplikace, kdy všechny webové aplikace na serveru mají stejnou programovou strukturu – liší se pouze svým vzhledem (skinem), není potřeba, aby měl útočník k dispozici možnost spouštění vlastních PHP skriptů. Průběh útoku na cloudovou službu poskytující zákazníkům například e-shopy, by mohl vypadat následovně:

  • Útočník se zaregistruje do jednoho z e-shopů (eshop1.cloud.xx) a přihlásí se do něj.

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_ kbg196j2d3rrvuk7ihlqlbbfp1      obsah: customer_id=93
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      eshop1.cloud.xx                         PHPSESSID     kbg196j2d3rrvuk7ihlqlbbfp1

  • Útočník zkopíruje session cookie v úložišti cookies ve svém webovém prohlížeči, aby toto cookie platilo i pro jiný e-shop, který je hostován na stejném serveru (eshop2.cloud.xx).

    Takto bude vypadat úložiště session souborů na straně serveru:
      sess_ kbg196j2d3rrvuk7ihlqlbbfp1      obsah: customer_id=93
    Takto bude vypadat úložiště cookies v prohlížeči útočníka:
      eshop1.cloud.xx                         PHPSESSID     kbg196j2d3rrvuk7ihlqlbbfp1
      eshop2.cloud.xx                         PHPSESSID     kbg196j2d3rrvuk7ihlqlbbfp1

  • Útočník přejde na webové stránky druhého e-shopu (eshop2.cloud.xx) a předá tím na server hodnotu SID, která náleží prvnímu z eshopů. Aplikace načte hodnoty session proměnných, ve kterých bude uvedeno customer_id, a uživatele bude tímto id autentizován. Aniž by se uživatel na tomto druhém e-shopu autentizoval, bude i v tomto e-shopu přihlášen a to pod jiným zákazníkem se stejným id. Jedná se tedy o krásný příklad authentication bypassu.
  • Útočník může v prohlížeči nastavit také platnost cookie pro všechny subdomény. V takovém případě bude uživatel naráz přihlášen do všech e-shopů běžících na stejném webovém serveru. Stačí v úložišti cookies odmazat z domény, které cookie náleží, subdoménu před první tečkou. Prohlížeč bude následně předávat toto cookie všem navštíveným subdoménám.

    .cloud.xx       PHPSESSID       kbg196j2d3rrvuk7ihlqlbbfp1

Authentication admin bypass v claudových aplikacích

Tento typ útoku je víceméně shodný s předchozím. Jediný rozdíl bude v tom, že si útočník zaregistruje na stejném cloudovém serveru svůj vlastní e-shop. Díky vlastnictví e-shopu bude mít tento uživatel administrátorská práva, a aplikace si tak například uloží tuto informaci do session proměnné isAdmin.

Po zkopírování cookie pro jiný e-shop a po následné návštěvě tohoto jiného e-shopu, bude mít útočník administrátorská práva i na tomto jiném e-shopu.

Authentication bapass na serveru s více aplikacemi téhož autora

Každý programátor má své zažité postupy při použití session proměnných. Pokud například jeden autor vytvoří web s autentizací a použije pro držení informace o přihlášení uživatele session proměnnou isLogged pak s největší pravděpodobností bude i jiná jeho aplikace držet tuto informaci ve stejně pojmenované session proměnné. Pokud pak takovýto vývojář provozuje své webové aplikace na jednom serveru (například na vlastním VPS) pod stejným uživatelským účtem a se sdíleným úložištěm session, bude pravděpodobně možné provádět authentication bypass stejným způsobem i mezi těmito zcela odlišnými aplikacemi.

Nemusí jít pouze o PHP

Ačkoliv jsme si výše uváděli příklady funkční pouze na PHP, hrozí stejné typy útoku i na jiných platformách (např. Java, .Net, apd.), kde se session na straně serveru ukládají do paměti. Střetl jsem se s cloudovými službami, kde se útočník mohl stát uvedeným postupem administrátorem všech hostovanch e-shopů, přestože byla aplikace vytvořena v Javě. Jak je to možné? Cloudová aplikace může v některých případech běžet pouze jedna jediná pro všechny hostované služby. Podle subdomény se mění pouze vzhled této aplikace, který je uložen ve formě dat například v databázi. Tato aplikace a tím pádem i všechny hostované služby pak opět sdílí jedno úložiště pro sessions, a to i v případě, kdy je toto úložiště umístěno v paměti, kde každá aplikace (v tomto případě je jen jedna) využívá svůj vlastní paměťový prostor.

Obrana

Administrátoři webových serverů mají k dispozici následující způsoby obrany.

  • Ukládat session soubory na straně serveru odděleně pro každou webovou aplikaci.
  • Spouštět interpret PHP jako CGI, resp. Fast CGI a každou webovou aplikaci provozovat pod jiným uživatelským účtem. Vzhledem k přístupovým právům, pod kterými jsou session soubory ukládány (-rwx------) nebude možné číst, resp. zapisovat do session souborů náležejících jiné webové aplikaci.
  • Do session proměnných ukládat a následně při přístupu uživatele kontrolovat také doménu, které session náleží. Tím se zabrání sdílení session například v cloudových službách, kdy je společné úložiště sessions a běh pod jedním uživatelem nejsnažším a nejvýhodnějším řešením pro jejich provozovatele.

Závěrem

Na Kafemlejnek.tv jsme si na téma této zranitelnosti povídali s Honzou Novotným a Petrem Ferschmannem. V závěrečné fázi videa jsou zachyceny také ukázky všech zde popisovaných typů útoků.



V případě zájmu o vyzkoušení si neoprávněného přístupu do administrace cizích e-shopů můžete navštívit Proof of Concept dostupný na adrese www.sharedsessions.cz.


Líbil se Vám článek?
Budeme potěšeni, pokud vás zaujme také reklamní nabídka

Social Bookmarking

     





Hodnocení/Hlasovalo: 1.47/30

1  2  3  4  5    
(známkování jako ve škole)