Null byte injection v preg_replace a nebezpečný nginx

10.5.2014 17:00 | Přečteno: 3760× | Web | | poslední úprava: 10.5.2014 17:43

Nedávno som bol nútený kvôli hacknutu niekoľkých PHP webov robiť bezpečnostný audit. Narazil som pri tom na niekoľko zaujímavých spôsobov útoku na web. V dnešnom blogu sa pozrieme na 2, ktoré ma zaujali asi najviac.

 Null byte injection v preg_replace

Volanie funkcií preg_replace vyzerá v zdrojových kódoch pomerne nenápadne a neškodne. Veď čo sa môže stať keď je v projekte nalsledujúci kód?

preg_replace('/'.$_GET['replace'].'/i', $_GET['with'], $str);

Toto nevynne vyzerajúce volanie preg_replace umožňuje útočníkovi vykonať ľubovoľný PHP kód a to vďaka niekoľkým nebezpečným vlastnostiam PHP.

Prvým problémom je, že PHP väčšinou obaľuje C funkcie. C-čkári určite vedia, čo znamená null terminated string. Vložením znaku '\0' do regulárneho výrazu je možné ho kdekoľvek ukončiť.

Druhým problémom je to, že flagy regulárneho výrazu sa zapisujú priamo do zdrojového kódu.

Poslednou chybou milých indov je flag e, ktorý umožňuje spustiť výsledok regulárneho výrazu ako PHP kód (hmm, že by sa niekomu nechcelo písať eval?). Nasledovným requestom je možné zobraziť phpinfo.

http://www.example.com/subor.php?replace=||/e%00&with=phpinfo();

Takže aby sme sa v budúcnosti vyhli takýmto bezpečnostným problémom je potrebné obaliť užívateľom zadávané parametre preg_replace do preg_quote. Viacej info napr. tu. Krásny príklad použitia si môžte pozrieť na tomto odkaze.

Zraniteľnosť cgi v spolupráci s nginx

location ~* \.php$ {
  fastcgi_pass php_cgi;
  ...
}

Toto je krásna ukážka diery, pomocou ktorej môže útočník na serveri spustiť ľubovoľný PHP kód. Postačí na server prepašovať súbor obsahujúci PHP kód (napr. avatar obsahujúci <?php ... ?>). Potom stačí do prehliadača zadať nasledujúcu adresu a jpg súbor sa vykoná ako PHP skript.

http://www.example.com/avatars/123.jpg/file.php

Ako je to teda možné? Zapísané pravidlo v nginx nám hovorí, že všetky požiadavky končiace sa na .php nasmeruje na PHP CGI. To funguje správne. Problém je zase v PHP.

V defaultnej konfigurácii však PHP skúsi nájsť súbor avatars/123.jpg/file.php. Ak neexistuje pokúsi sa nájsť súbor s podobnou cestou (v tomto prípade avatars/123.jpg) a vykoná ho ako PHP skript.

Ako riešenie sa zvyčajne odporúča rôzny tuning nginx, alebo nastavenie cgi.fix_pathinfo=0 v php.ini.

Zopár informácií o probléme tu, alebo priamo vo wiki k nginx.

Ešte jeden vtip z dielne PHP. Viete ako sa kontroluje pretečenie int?

int size;
size = ...;
if (size > INT_MAX) return NULL;

Veľmi výživný text vrátane riešení s floatmi na use.perl.org

Vtip 2: žiadne heslo - dobré heslo ;)

       

Komentáře

[Petr Tomášek]

preg_replace('/'.$_GET['replace'].'/i', $_GET['with'], $str)

Tak nevím, ale takový kód snad nemůže napsat ani největší zíma...

[mirec]

Tiež som si hovoril. Radšej pomlčím o tom, v koľkých pluginoch wordpressu som takýto kód našiel ...

[R]

Idealny pocet volani preg_replace() v kode je nula. Niektori ludia sa vsak vyzivaju v regularnych vyrazoch a nasekaju tam potom kopu tazko riesitelnych bugov.

[pavlix]

Regexy jsou nástroj jako každý jiný, dají se používat dobře i špatně.

[Sten]

Ideální počet volání interpretru PHP je nula. Někteří lidé se ale vyžívají v masochismu a natahají tak na server kopu těžko řešitelných bezpečnostních děr

[ja]

A co na to mod_security?

[mirec]

Mám tak pocit, že by si poradil s null v preg_replace, ale pravdu povediac nikdy som mod_security nekonfiguroval (nie som správca, len programátor). Samozrejme druhý problém s hádaním cesty nemá šancu ovplyvniť, ale tento typ útoku sa v našom prípade nemohol stať, v každom prípade správanie php cgi ma celkom zaujalo.

[psio]

PHP je tak bad by design ze prechod na Python/Django bylo jak vysvobozeni. Tim netvrdim ze tu nejsou problemy s bezpecnosti, ale je to uplne jiny level. Chovani typu provedu cokoliv i to co nebylo explicitne volano, hlavne aby to vratilo nejaky vysledek misto vyjimky, me privadely k silenstvi. Uplne me desi ty weby ktery pustilo vedeni na internet a kde je to takovyma pastma prospikovany. Pripominky smetli do kose, hlavne ze to dostal zakaznik v terminu. Az se najde nekdo kdo to bude chtit zneuzit tak tu mame docela pekny botnet :(

[mirec]

Ja momentálne pracujem prevažne na projektoch v djangu. Je to fakt obrovský rozdiel oproti PHP. Hlavne debugovanie (werkzeug) je neskutočne pohodlné. Dnes som narazil na wdb, budem musieť vyskúšať.

[Šangala]

A to řešení kontrola na INT_MAX přes float je správné nebo bezpečné?

[mirec]

Ani správne ani bezpečné, akurát to demonštruje schopnosti programátorov PHP.

[Šangala]

Oki, já jenom že píšeš „riešení s floatmi“ a ono to problém neřeší…, tak jsem nevěděl…

[Jendа]

Asi ne, protože float bude mít (na většině architektur) 24 bitů, ale int 32. Takže dokážeš vyrobit float, který se zaokrouhlí dolu a přeteče ti pár znaků.

[Šangala]

Ne-ne, float v podání PHP je double a int záleží na architektuře, tedy bude obvykle 64bit a to je, mimo jné, schopné testem projít a být to větší něž INT_MAX (INT64_MAX).
Pokud máš 64bit systém, tak si zkus:
php files.php

<?php

echo (int)PHP_INT_MAX,"<br />\n";
echo number_format((double)PHP_INT_MAX,0,'.',''),"<br />\n";
echo "--------------------------<br />\n";
$var = 9223372036854775808.0;//an expresion
if ($var > PHP_INT_MAX){
  echo "Error expresion is bigger then INT_MAX";
}else{
  $myint = (int) $var;
  echo $myint," ¡WOW!<br />\n";
}

Pokud s eto chce dělat takto je třeba respektovat double a tedy testovat max na 9007199254740991 (nebo zjednodušeně na 15 míst 999999999999999).

[mirec]

To bol float v zdrojákoch PHP a to je napísané v C, takže float je tam skutočne float.

[Šangala]

A já proč se mi to nezdálo a jaktože je tam INT_MAX (místo PHP_INT_MAX) tak to si kluci dělají srandu - doufám. Nicméně na druhou stranu, variantu s INT64 a double je v C/C++ k vidění v různých variantách rozhodně častěji, než by mělo být…

[Matlák]

Ta narážka na float to calculate length of a string mi připoměla slavný článek PHP is a fractal of bad design. Každý člověk co alespoň trochu zavadil o PHP by si jej měl přečíst

[Matlák]

oprava linku

[Jirka]

Ani jedno

[trekker.dk]

Nerozbíjí náhodou cgi.fix_pathinfo=0 weby, které závisí na PATH_INFO? Mám za to, že v takových případech je stejně nějaký ten "tuning" nginx potřeba.

[mirec]

Áno, rozbíja. Kontrolovať existenciu súboru je možné aj na strane nginx, ale je potrebné aj tak vziať do úvahy možné race condition keď medzi kontrolou a vykonaním cgi bol súbor vymazaný. Najlepšie riešenie je zakázať vykonávanie .php v adresároch, ku ktorým má používateľ právo zapisovať.

[Petr Tomášek]

Chyba. Nejlepší řešení je zakázat uživateli zapisovat do jakýchkoliv adresářů, které potom HTTP servíruje. Všechno je nutné ukládat někam mimo a pak mít skript, soubory pojmenovat nejlíp číslem, číslo mít v databázi a pak mít skript, který tyto soubory servíruje.

[mirec]

Servírovať súbory skriptom je často v praxi nerealizovateľné. So surovým servírovaním súborov cez nginx dosiahnem rádovo 100x vyššiu priepustnosť než so skriptom. Za najlepšie považujem skôr odpútať sa od konceptu spúšťania nejakých skriptov podľa URL adresy a buď používať jazyk kde webová aplikácia routuje URL automaticky, alebo povoliť len hlavný PHP skript a routovať si URL adresy v ňom. Zvyšné súbory môžu byť v takom prípade bezpečne obsluhované priamo webovým serverom.

[Václav HFechs Švirga]

U velkých souborů ti také vyprší max execution time. Ale jinak soubory přejmenovat na nějaký hash určitě dobrý nápad je.

[Sten]

Ne, nejlepší řešení je používat routing, takže webová aplikace nenačítá kód ze souborů rozházených po adresářích za běhu. Ale to PHP neumí.