Díl 16. – Local Session Poisoning

Je až s podivem, že tato zranitelnost i několik let po svém objevení není běžně známá a že jí stále trpí všechny PHP aplikace, které se spolehnou na výchozí nastavení PHP. Principielně se zranitelnost týká i dalších platforem, ale tam není riziko tak vysoké jako právě v PHP.

Local session poisoning objevil Roman Kümmel na konci roku 2015 a snažil se informovat postižené majitele webů, které byly touto technikou zranitelné. Jak dopadl si sami můžete přečíst v článku Bezpečnostní tragikomedie. Zranitelnost byla pravděpodobně poprvé zdokumentována na webu Haxxor Security v září 2011, nicméně nijak světem neotřásla a dosud na internetu najdete jen několik dalších článků o této zranitelnosti.

To však neznamená, že se nejedná o závažný problém nebo o problém, který by byl od té doby již vyřešen. Zranitelnost je tu stále s námi a jak si Roman empiricky ověřil, je poměrně rozšířená.

S využitím této zranitelnosti máte poměrně velkou šanci dostat se neoprávněně do administrací ostatních webů, které běží na stejném webovém serveru, jako ten Váš. Riziko platí pro všechny defaultní PHP instalace na serverech, které hostují několik webů. U Java platformy by toto riziko připadalo v úvahu pouze tehdy, pokud by jedna aplikace (WAR) hostovala více různých klientských webů a neošetřila si spojení session s konkrétním webem.

Detaily o této zranitelnosti si ale radši poslechněte rovnou od Romana. A nezapomeňte na demo v druhé polovině dílu.

Video

Pouze audio

Zdroje

Jak šel čas v přednáškách:

Obsah

  1. představení zranitelnosti 1:14
  2. zamyšlení nad tím, které aplikace jsou zranitelné 12:10
  3. zrychlení hackingu nad všemi subdoménami 16:20
  4. zranitelnost WordPressu 20:11
  5. jak reagovali majitelé hostingů a majitelů webů při oznámení zranitelnosti 22:09
  6. přiznání autorství 29:19
  7. co udělat pro opravu? 31:23
  8. demo s ukázkou zranitelnosti v praxi 34:06

5 thoughts on “Díl 16. – Local Session Poisoning”

  1. V autorizačním systému který používáme, je v session uložený hash, ve kterém je zakódovaný id aplikace. Tento hash se v každé aplikaci ověřuje, tzn. že session z jiné aplikace není validní.

    Jestli tomu správně rozumím, tak v takovém případě tento útok není použitelný.

      1. Jestli to chápu správně, tak nikoliv. Ovšem pouze za předpokladu, že neumožňujete uživatelům uploadovat skripty s přístupem do serverové session na Váš server. Pak by si samozřejmě tento hash mohli jednoduše změnit.

        Tj. pokud by spolu s Vaší aplikací hosting poskytoval možnost hostovat dalším uživatelům WordPressy, tak je tato ochrana nedostatečná.

Leave a Reply

Your email address will not be published. Required fields are marked *