Nebezpečné webhostingy III

V předchozím díle jsme se seznámili s rozličnými způsoby, jakými útočníci získávají potřebné informace a jak při svých útocích postupují. Na konkrétní rady týkající se bezpečnostních direktiv tak nezbylo příliš místa, tento díl se vám to proto pokusí plně vynahradit.

Integritu sdílených dat na mass virtual hostingu zajišťují na úrovni PHP především tři základní direktivy, a sice safe_mode, open_basedir a disable_functi­ons. Systematicky projdeme každou z nich a ukážeme si, jak jejich chybná konfigurace narušuje pomyslnou bariéru mezi jednotlivými uživateli, což může v krajních případech vyústit až v praktickou nefunkčnost celé bezpečnostní politiky.

Direktiva safe_mode je jedna z nejkontrover­znějších, mnozí si bez ní neumí mass virtual hosting představit, jiní ji bez milosti zavrhují. Běžnou praxí ovšem zůstává, že se direktiva safe_mode na sílených serverech zapíná, i když v šesté verzi PHP byste ji hledali již marně. Jejími hlavními úkoly je především zakázat některé nebezpečné funkce, které by mohly zapříčinit narušení bezpečnosti celého serveru a v případě vykonávání dynamických skriptů kontrolovat identifikátory majitele jak zdrojového skriptu, tak cílového souboru/složky. Pokud se tyto identifikátory liší, pak je to jasné varování před tím, že se někdo pokouší narušit diskový prostor jiného uživatele a je mu přístup odepřen. Mezi zakázané funkce patří například shell_exec() pro práci s příkazovou řádkou operačního systému umožňující spuštění jiných aplikací nebo vykonání systémových příkazů. Přestože některé funkce aktivní safe_mode zakáže automaticky, není na škodu je uvádět i v direktivě disable_functions (viz níže) a řídit se tak bezpečnostní politikou Defense in Depth.

V souvislosti s aktivním safe_mode je dobré zmínit rovněž direktivy safe_mode_gid, safe_mode_inclu­de_dir a safe_mode_exec_dir. Zapnutí první jmenované omezí kontrolu identifikátorů pouze na skupinu, ve které se uživatel nachází, nikoliv jednotlivce a měla by být tudíž na sdíleném serveru deaktivována. Druhá jmenovaná direktiva ukazuje na adresář, ve kterém v případě spuštění dynamického skriptu nedojde ke kontrole žádného z identifikátorů. Na mass virtual hostingu by tedy měl být obsah této direktivy prázdný (no value) a poslední jmenovaná direktiva safe_mode_exec_dir obsahuje absolutní cestu k adresáři, v němž je možné pomocí jedné z funkcí system(), passthru(), popen() nebo exec() vykonávat systémové příkazy na úrovni příkazové řádky, případně spouštět libovolné aplikace. I obsah této direktivy by měl být tedy na sdílených serverech prázdný.

Pravděpodobně nejdůležitější bezpečnostním prvkem sdíleného serveru na úrovni PHP je direktiva open_basedir, rovnou tedy můžeme říci, že pokud je prázdná, v žádném případě nelze dotyčný webhosting považovat za bezpečný. Obsahem této direktivy je seznam absolutních cest k adresářům oddělených dvojtečkou, ke kterým máme přístup. Pokud není uvedena žádná z cest, máme naopak přístup kamkoliv, což samozřejmě představuje obrovské bezpečnostní riziko. Přístup se automaticky dědí na všechny podadresáře, uvést nadřazený adresář obsahující data všech uživatelů tudíž svým účinkem kopíruje prázdnou hodnotu. Obsah této direktivy by měl být pro každého zákazníka unikátní. Všechny uvedené cesty by měly být navíc ukončeny lomítkem, v opačném případě má totiž útočník přístup nejen do uvedených adresářů, ale i do složek, které začínají stejnými písmeny. V žádném případě by tato direktiva neměla obsahovat tečku, tedy odkaz na aktuální pracovní adresář. Pomocí funkce chdir() je totiž možné si jej změnit a útočník by tak splnil podmínku pokaždé, ať by byl v jakémkoliv adresáři. Navíc před touto skutečností varuje i samotný manuál.

V pořadí třetí, ale neméně důležitou bezpečnostní direktivou, je disable_functions, která by sama o sobě vydala na samostatný díl. Tato direktiva obsahuje zakázané funkce, které, ač jimi PHP disponuje, nejsou uživateli přístupné. Opět by se nemělo stát, že je tato direktiva prázdná, neboť se jedná o obrovské bezpečnostní riziko srovnatelné s odemčeným autem na parkovišti. Výčet zakázaných funkcí závisí především na používané verzi PHP, takže je komplikované říci, které byste zde měli najít a které tam být nemusí. Pro zběžnou analýzu postačí vědět, že v žádném případě, ať už je použita jakákoliv verze, by toto pole nemělo být prázdné.

Často se mě lidé ptají, proč správce zakázal i funkci copy(), co je na ní tak nebezpečného. Nebezpečného na ní není zhola nic a její zablokování problémům nepředejde. Důvodem je ale jeden neduh, kterým PHP trpí už dlouho. Vytvoříme-li totiž nějaký skript, který následně uploadujeme na server pomocí FTP, pak jsme jeho regulérními majiteli a soubor nese náš identifikátor. Vytvoříme-li však nějaký soubor, tedy i skript pomocí některé z PHP funkcí, nese takto vytvořený soubor identifikátor webového serveru, nikoliv náš. To samé platí pro případ, kdy soubor kopírujeme, kopie totiž rovněž nese jiný identifikátor, a sice opět serveru Apache. Z pohledu bezpečnosti to s sebou přináší jisté riziko, neboť pak lze některé PHP funkce donutit k tomu, aby pracovaly v prostoru jiného uživatele, a to i přesto, že je zapnutý safe_mode a direktiva open_basedir to výslovně zakazuje. Jak jsem se však již jednou zmínil, zablokování funkce copy() není řešením. Přirovnal bych to k naivitě zemědělce, který z bramborového pole sebral největší mandelinku a tiše doufal, že je za vodou, mezitím by mu však pole pustošila hejna těch menších.

Naší pozornosti by neměly uniknout ani direktivy upload_tmp_dir a session.save_path směřující na prostor sloužící k ukládání dočasných souborů. V žádném případě by tyto adresáře neměly být společné pro všechny zákazníky webhostingu, tedy něco ve smyslu /tmp. V praxi se to však stalo díky pohodlnosti správců serverů takřka pravidlem. Takové nastavení s sebou ale přináší řadu rizik v podobě lokálních útoků na webové aplikace cizích uživatelů, případně eskalace práv úpravou souboru asociovaného k přidělenému sezení. Tento nešvar je natolik rozšířen, že najít v současnosti webhosting s vlastními temporary adresáři není nic snadného a v drtivé většině případů bude při výběru serveru potřeba přimhouřit obě oči.

Nyní malinko odbočíme od konfigurace dynamického jazyka a zabrousíme do přístupových práv adresářů. Pokud totiž root webu nebo jakýkoliv později vytvořený adresář povoluje zápis někomu jinému, než je sám majitel oné složky, pak to sice není chyba, o bezpečnostní riziko se však zcela určitě jedná. Přinejmenším kořen webu, tedy místo, kde se nachází index, by těmito právy být opatřeno nemělo. Pokud tomu tak přece jen je, zamezte ostatním uživatelům v zápisu do vašeho rootu nastavením striktnějších přístupových práv a nespoléhejte se pouze na direktivu safe_mode.

Práci útočníků navíc usnadňují zautomatizované postupy v podobě webových aplikací, tzv. php shelly. Mezi ty nejznámější patří určitě nástroje c99 a r57, a to především díky své unikátní propracovanosti a množství detekovaných zranitelností. Tyto nástroje nabízejí přehledné a intuitivní ovládání, přičemž nevyžadují naprosto žádné znalosti útočníka, co se počítačové bezpečnosti týče.

Ne vždy je však v případě bezpečnostních incidentů na vinně špatná konfigurace nebo lidský faktor, tedy ten uživatelův. Krásnou ukázkou takového případu je například funkce tempnam() pro tvorbu dočasných souborů. Vývojový tým PHP si byl vědom toho, že by mohlo docházet k jejímu zneužívání, a proto ji opatřil poněkud nezvyklým bezpečnostním prvkem. Uživatel si sice může zvolit název souboru, za něj je však procesorem pokaždé přidán šestimístný náhodně vygenerovaný suffix. V případě, že by tedy útočník vytvářel skript hacked.php, výsledný soubor by se přesto jmenoval např. hacked.phpDc3qug, a to se zdá být na první pohled nepoužitelné. Vývojový tým Apache se však rozhodl pro poněkud odlišnou strategii. Pokud Apache nebude příponu souboru znát, podívá se na tu předchozí a tak bude pokračovat do té doby, dokud nenarazí na sobě známý suffix. Jako neznámý označí soubor teprve ve chvíli, kdy mu lidově řečeno dojdou přípony. Těchto rozdílných strategií mezi jednotlivými vývojovými týmy lze samozřejmě snadno zneužít, neboť útočník požádá o vytvoření souboru s názvem hacked.php., čímž dosáhne následující podoby jména souboru – hacked.php.Dc3qug. Apache příponu .Dc3qug znát zajisté nebude, podívá se tedy na předchozí .php a skript beze všeho vykoná. Snaha PHP developerů tak přišla vniveč. Jiným příkladem mohou být například obrázkové galerie, kde PHP považuje za obrázek i soubor s příponou .jfif. Apache tento suffix ale nezná a pokud útočník nahraje na server obrázek se jménem img.php.jfif, přes PHP kontrolu snadno projde, každopádně v případě načtení bude tento soubor zpracován jako dynamický skript, nikoliv obrázek. Rozdílů mezi oběma vývojovými týmy by se našlo zajisté mnohem více, což však bohužel nahrává do karet útočníkům a ti těchto nesrovnalostí nemilosrdně zneužívají.

Postupně jsme se seznámili s nejdůležitějšími konfiguračními direktivami, které by vám měly při výběru webhostingu napovědět něco více o bezpečnosti daného serveru. Jako jednoznačnou výhodu lze navíc brát přítomnost patche Suhosin, který bezpečnostní politiku posouvá ještě mnohem dál, dostupnost kompilace zdrojových kódů, případně firewall pro webové aplikace v podobě modulu mod_security. I o těchto rozšířeních naleznete v případě jejich přítomnosti ve výstupu funkce phpinfo() zmínku a rozhodně se vyplatí tyto faktory při výběru zohlednit.

       

Bezpečnost mass virtual hostingů není radno brát na lehkou váhu, a to ani v případech, kdy by z případných škod teoreticky neplynuly žádné finanční ztráty. Sdílené prostory vždy byly vynikajícím zdrojem utajovaných informací a místem k provádění ilegální činnosti pod rouškou anonymity.

Tento seriál neměl v žádném případě za cíl stát se příručkou při provádění jakýchkoliv útoků, nebo jiným způsobem poškodit majitele webhostingových společností. Jeho účelem je pouze poradit případným zájemcům o mass virtual hosting ve výběru vhodného partnera, alespoň co se počítačové bezpečnosti týče.