- Databáze XML zranitelnosti (3) -
Poslední aktualizace v 28.06.2014 16:26:34
Další možností, kterou externí entity útočníkům nabízí, je zasílání požadavků ze strany serveru na další zařízení Server Side Request Forgery (SSRF). Jako zdroj externí entity totiž můžete bez problému použít také HTTP(S) protokol, nebo i různé další síťové protokoly, viz. odstavec wrappers.
K čemu to může být útočníkovy dobré?
Řekněme, že by útočník našel na nějakém internetovém serveru zranitelnost typu SQL injection, která umožňuje smazat celou databázi odesláním následujícího požadavku:
http://www.aplikace.cz/action?q='; drop database();--
Útočník v tomto případě může jako zdroj externí entity uvést právě zmíněnou adresu a světe div se, databazáze bude vymazána a v logu zůstane jako strůjce útoku uveden webový server, jehož parser zpracovával upravený XML dokument.
<!ENTITY entita SYSTEM "http://www.aplikace.cz/action?q='; drop database();--">
Název | Popis |
Mnohem zajímavějším pro útočníka ale může být skutečnost, že pro komunikaci ve vnitřní síti mají jednotlivá zařízení často nastavena mnohem benevolentnější pravidla. Pokud je pak webový server umístěn právě na rozhraní nějaké vnitřní sítě nebo je provoz na tento server routován přímo do LAN, může útočník skrz externí entity mířit své požadavky právě tam. To je věc, jež by mu jinak zůstávala odepřena. Tímto způsobem se může například pokusit přistoupit s defaultním heslem na hraniční routery, nebo může provést detailní průzkum vnitřní sítě. Princip SSRF do vnitřní sítě 1) Útočník odešle na webový server XML s externí entitou žádající obsah z některého stroje ve vnitřní síti. <!ENTITY entita SYSTEM "http://192.168.1.1"> Podle reakcí parseru se pak útočník snadno dozví, zda má k danému zdroji přístup, nebo zda daný zdroj není živý. No route to host: Když stroj neodpovídá Poznámka: Podle prezentace z Defconu by mělo být za určité konstalace hvězd možné použít v PHP na Windows také zástupné znaky ve jméně souboru, což se mi ovšem nepodařilo potvrdit. <!ENTITY test SYSTEM "C:/intet_pub/ad<<"> | |
Stejným způsobem, který byl uveden v předchozím odstavci, může útočník nejen zjistit, zda je určitá IP adresa v interní síti živá, ale v případě strojů běžících na platformě Windows, dokáže zjistit dokonce i to, zda je možné k některému z počítačů ve vnitřní síti přistoupit s administrátorskými právy. Tato skutečnost by se dala testovat pomocí pokusů o přístup do administrátorských sdílených složek C$. <!ENTITY entita SYSTEM "//192.168.1.1/C$/install.ini"> Poznámka: Ve svém výpisu uvádím běžná lomítka, která mi bez problémů fungují ve WAMPu, kde své ukázky testuji. V různých dokumentech se ovšem uvádí zápis se zpětnými lomítky, které jsou pro Windows typičtější. Případně funguje také zápis s uvedeným wrapperem file://, viz následující výpis. <!ENTITY entita SYSTEM "//192.168.1.1/C$/install.ini"> | |
Ani u skenování portů, jímž je možné na konkrétním stroji ve vnitřní síti otestovat otevřené porty, nebude nutný dlouhý popis. I tentokrát je totiž princip totožný s předchozími případy. Stačí, když budeme testované porty postupně uvádět za adresou cíle oddělené dvojtečkou. <!ENTITY entita SYSTEM "file:///192.168.1.1:21"> Pokud je port uzavřen, dočkáme se podobné odpovědi jako „Connection refused“ v závislosti na systému. V opačném případě se pravděpodobně dočkáme chyby při parserování obsahu, případně výpisu vráceného textu, nebo timeoutu. | |
O zneužití protokolů http:// nebo file:// u externích entit jsme se již zmínili. Tyto protokoly ovšem nejsou jedinými prostředky, kterými externí entity mohou přistupovat k datům. V případě PHP jsou podporovány všechny následující wrappery, viz. PHP manuál. file:// Pro útočníka z nich budou mít zřejmě nejzásadnější význam wrappery php:// a expect://. |