Úvod do XML-RPC
Na internetu existuje mnoho různých zdrojů, které uživatelům poskytují určité informace. Nemyslí se tím běžné statické stránky, ale například data získaná z databáze nebo archivů. Může se jednat o archiv finančních dat (směnné kurzy, kotace cenných papírů), údaje o počasí nebo rozsáhlejší informace – novinky, články, zprávy z fór. Takové informace mohou být návštěvníkovi stránky prezentovány například prostřednictvím formuláře, jako odpověď na požadavek, nebo mohou být pokaždé generovány dynamicky. Potíž je ale v tom, že často takové informace nepotřebuje ani tak koncový uživatel – člověk, ale jiné systémy a programy, které tato data využijí pro své výpočty nebo jiné potřeby.
Skutečný příklad: stránka bankovního webu, která zobrazuje kotace měn. Pokud na stránku přistupujete jako běžný uživatel prostřednictvím prohlížeče, vidíte veškerý design stránky, bannery, nabídky a další informace, které „rámují“ skutečný účel vyhledávání – kotace měn. Pokud potřebujete zadat tyto nabídky do svého internetového obchodu, nezbývá nic jiného, než ručně vybrat potřebná data a přenést je přes schránku na váš web. A budete to muset dělat každý den. Opravdu neexistuje žádná cesta ven?
Pokud problém vyřešíte přímo, pak se okamžitě objeví řešení: program (skript na webu), který potřebuje data, přijme stránku ze serveru jako „běžný uživatel“, analyzuje (analyzuje) výsledný html kód a extrahuje z něj potřebné informace. To lze provést buď regulárním regulárním výrazem, nebo pomocí libovolného html analyzátoru. Obtížnost přístupu spočívá v jeho neúčinnosti. Za prvé, pro příjem malé části dat (údaje o měnách jsou doslova tucet nebo dva znaky) je potřeba přijmout celou stránku, která má minimálně několik desítek kilobajtů. Za druhé, s jakoukoli změnou v kódu stránky, například se změnil design nebo něco jiného, bude muset být přepracován náš algoritmus analýzy. A to bude vyžadovat značné množství zdrojů.
Proto vývojáři dospěli k rozhodnutí - je nutné vyvinout nějaký univerzální mechanismus, který by umožnil transparentní (na úrovni protokolu a přenosového média) a snadnou výměnu dat mezi programy, které mohou být umístěny kdekoli, být napsány v jakémkoli jazyce a spustit pod jakýmkoli operačním systémem a na jakékoli hardwarové platformě. Takový mechanismus se nyní nazývá hlasitými termíny „webové služby“, „SOAP“, „architektura orientovaná na služby“. Pro výměnu dat se používají otevřené a časem prověřené standardy - pro přenos zpráv se používá protokol HTTP (lze však použít i jiné protokoly - např. SMTP). Samotná data (v našem příkladu směnné kurzy) jsou přenášena zabalená v multiplatformním formátu – ve formě XML dokumentů. Pro tento účel byl vynalezen speciální standard – SOAP.
Ano, nyní jsou webové služby, SOAP a XML na rtech, začínají se aktivně implementovat a velké korporace jako IBM a Microsoft uvolňují nové produkty navržené tak, aby napomohly celkové implementaci webových služeb.
Ale! Pro náš příklad se směnnými kurzy, které musí být přenášeny z webových stránek banky do motoru internetového obchodu, bude takové řešení velmi obtížné. Vždyť jen popis standardu SOAP zabírá obscénních jeden a půl tisíce stran, a to není vše. Pro praktické použití se také budete muset naučit pracovat s knihovnami a rozšířeními třetích stran (až od PHP 5.0 obsahuje knihovnu pro práci se SOAP) a napsat stovky a tisíce řádků vlastního kódu. A to vše získat pár písmen a číslic je zjevně velmi těžkopádné a iracionální.
Proto existuje další, dalo by se říci, alternativní standard pro výměnu informací – XML-RPC. Byl vyvinut za účasti společnosti Microsoft společností UserLand Software Inc a je určen pro jednotný přenos dat mezi aplikacemi přes internet. Může nahradit SOAP při budování jednoduchých služeb, kde nejsou potřeba všechny „podnikové“ schopnosti skutečných webových služeb.
Co znamená zkratka XML-RPC? RPC je zkratka pro Remote Procedure Call. To znamená, že aplikace (ať už skript na serveru nebo běžná aplikace na klientském počítači) může transparentně používat metodu, která je fyzicky implementována a spuštěna na jiném počítači. XML je zde použito k poskytnutí univerzálního formátu pro popis přenášených dat. Jako transport se k přenosu zpráv používá protokol HTTP, který umožňuje bezproblémovou výměnu dat prostřednictvím libovolných síťových zařízení – routerů, firewallů, proxy serverů.
K použití tedy potřebujete: XML-RPC server, který poskytuje jednu nebo více metod, XML-RPC klienta, který dokáže vygenerovat správný požadavek a zpracovat odpověď serveru a také znát parametry serveru nutné pro úspěšnou činnost - adresa, název metody a předané parametry.
Veškerá práce s XML-RPC probíhá v režimu „request-response“, což je jeden z rozdílů mezi technologií a standardem SOAP, kde existují jak koncepty transakcí, tak možnost provádět zpožděné hovory (když server uloží žádost a odpoví na ni v určitou dobu v budoucnu). Tyto doplňkové funkce jsou užitečnější pro výkonné podnikové služby, výrazně komplikují vývoj a podporu serverů a kladou další požadavky na vývojáře klientských řešení.
Postup práce s XML-RPC začíná vytvořením požadavku. Typický požadavek vypadá takto:
POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Hostitel: server.localnet.com
Content-Type: text/xml
Délka obsahu: 172
První řádky tvoří standardní hlavičku HTTP POST požadavku. Mezi požadované parametry patří hostitel, datový typ (typ MIME), který musí být text/xml, a délka zprávy. Norma také stanoví, že pole User-Agent musí být vyplněno, ale může obsahovat libovolnou hodnotu.
Následuje obvyklá hlavička XML dokumentu. Kořenový prvek požadavku je
Čára
Dále se nastavují přenášené parametry. K tomu slouží tato sekce.
Po popisu všech parametrů následují uzavírací značky. Požadavek a odpověď v XML-RPC jsou běžné dokumenty XML, takže všechny značky musí být uzavřeny. V XML-RPC však neexistují žádné jednotlivé značky, ačkoli jsou přítomny ve standardu XML.
Nyní se podívejme na odpověď serveru. Hlavička odpovědi HTTP je normální, pokud je požadavek úspěšně zpracován, server vrátí odpověď HTTP/1.1 200 OK. Stejně jako v požadavku musíte správně zadat typ MIME, délku zprávy a datum generování odpovědi.
Samotné tělo odpovědi je následující:
Nyní místo kořenové značky
Pokud při zpracování vašeho požadavku došlo k chybě, místo toho Odpověď bude obsahovat prvek
Nyní se krátce podíváme na datové typy v XML-RPC. Datových typů je celkem 9 – sedm jednoduchých typů a 2 komplexní. Každý typ je popsán vlastní značkou nebo sadou značek (u komplexních typů).
Jednoduché typy:
Celá čísla- tag
Booleovský typ- tag
ASCII řetězec- popsané tagem
Čísla s pohyblivou řádovou čárkou- tag
datum a čas- popsané tagem
Posledním jednoduchým typem je base64 kódovaný řetězec, který je popsán tagem
Komplexní typy jsou reprezentovány strukturami a poli. Struktura je určena kořenovým prvkem
Pole nemají žádná jména a jsou popsána tagem
Někdo samozřejmě řekne, že takový seznam datových typů je velmi špatný a „neumožňuje vám rozšíření“. Ano, pokud potřebujete přenášet složité objekty nebo velké množství dat, pak je lepší použít SOAP. A pro malé, nenáročné aplikace se XML-RPC docela hodí, navíc se často i jeho schopnosti ukáží jako přemrštěné! Vzhledem k jednoduchosti nasazení, velkému množství knihoven pro téměř jakýkoli jazyk a platformu a široké podpoře v PHP, pak XML-RPC často prostě nemá konkurenci. I když to nelze hned doporučit jako univerzální řešení – v každém konkrétním případě se musí rozhodnout podle okolností.
Počínaje sobotním polednem se můj server, kde je hostováno asi 25 webů Wordpress, začal silně zpomalovat. Vzhledem k tomu, že se mi podařilo bez povšimnutí přežít předchozí útoky ( , ), hned jsem nechápal, co se děje.
Když jsem na to přišel, ukázalo se, že hesla byla hrubě vynucená + mnoho požadavků na XMLRPC.
Ve výsledku se nám to všechno podařilo utnout, i když ne hned. Zde jsou tři jednoduché triky, jak se tomu vyhnout.
Tyto techniky pravděpodobně zná každý, ale šlápl jsem na pár chyb, které jsem v popisech nenašel - možná to někomu ušetří čas.
1. Zastavte vyhledávání, nainstalujte plugin Limit Login Attempts - nainstalujte jej, protože jiné ochrany značně zpomalují server, například při použití pluginu Login Security Solution server po půl hodině zemřel, plugin silně zatěžuje databázi .
V nastavení nezapomeňte zaškrtnout políčko „Pro proxy“ - jinak určí IP vašeho serveru pro všechny a automaticky všechny zablokuje.
AKTUALIZACE, děkuji, podrobnosti níže v komentářích - zaškrtněte políčko „Pro proxy“ pouze v případě, že detekce nefunguje, když je povoleno „Přímé připojení“
2. Zakázat XML-RPC – plugin Zakázat XML-RPC (je snadné jej aktivovat a je to).
3. Zavřete wp-login.php – pokud na stránky přistupujete přes IP, plugin nefunguje a výběry nadále padají stránky. Chcete-li se tomu vyhnout, přidejte do .htaccess:
Zkopírujeme soubor wp-login, přejmenujeme ho na jakýkoli divný název, například poletnormalny.php, a uvnitř souboru pomocí autocorrectu změníme všechny nápisy wp-login.php na poletnormalny.php.
To je vše, nyní máte přístup k panelu správce pouze pomocí svého souboru.
Po těchto 3 jednoduchých krocích začaly lokality opět létat a nastal klid.
No, najednou je to zajímavé
Jednou z možností je zjistit, zda na vás někdo neútočí. To lze vidět v protokolech nginx (například zde je cesta k souboru Debian /var/log/nginx access.log).Hackeři hledají různé způsoby, jak hacknout vaše webové stránky. Ve většině případů, pokud stránka nemá nějakou komerční hodnotu, jsou to děti dovádějící, snažící se prosadit.
Onehdy byly mé hostingové stránky, mírně řečeno, „položeny“. Bylo jasné, že některé weby byly DOSované.
To lze vidět především ze statistik využití zdrojů serveru:
Byl jsem překvapen z toho důvodu, že na hostingu nejsou žádné komerční zdroje. Proč, můžete se zeptat, DOS? Za jakým účelem?
Co ukazuje diagram?
Na prvním obrázku vidíme zatížení CPU. Měří se 100 % na jádro. Útok začal kolem 15:00 GMT a kolem 21:00 jsem požádal poskytovatele, aby s tím něco udělal. Technická podpora zahájila převod hostingu na jiný hlavní server. Zřejmě proto, abych měl možnost využívat více systémových prostředků. Přibližně ve 22:00 začal přesun, kontrola integrity souborů a dalších postupů.
Vlastně jsem se ani nechtěl obtěžovat - a prostě jsem šel spát, protože "ráno je moudřejší než večer."
Co je vidět v protokolech serveru?
Statistiky už ráno nevykazovaly žádné anomálie. Stránky se stejně otevíraly pokaždé jindy a ne hned, tzn. útok pokračoval. Buď byly statistiky stále zapsány ze starého serveru, nebo již byly daty z hlavního serveru...
Proto jsem přešel ke studiu protokolů, abych zjistil, kde „klepou“.
Když jsem se podíval na logy, bylo jasné, že není třeba se znepokojovat – nějaká shkolota klepala ze stejné IP adresy v /xmlrpc.php jednoho z mých WordPress webů. S největší pravděpodobností násilně vynucuje heslo správce.
To samozřejmě není příliš příjemné, protože všechny ostatní stránky virtuálního serveru také „lžou“. A nejnepříjemnější věc je, že tyto XML služby nepoužívám na žádné ze svých WP stránek.
Blokování XML RPC.
Nejjednodušší věc, kterou můžete v této situaci udělat, je odstranit soubor z kořenové složky webu /xmlrpc.php. Server, pokud nenajde pískání, nespustí PHP, což plýtvá paměťovými prostředky a časem procesoru. Řešení je jednoduché, ale ne hezké. Za prvé, někdo může používat možnosti RPC. Například publikujte příspěvky na webu prostřednictvím jednoho z mnoha klientů Weblog. A za druhé, soubor bude obnoven po další aktualizaci WP.
Pokud váš server běží na Apache, můžete zablokovat přístup xmlrpc.php bez smazání samotného souboru. Na začátek svého musíte přidat následující pokyny .htaccess soubor v kořenovém adresáři webu WordPress. To zablokuje přístup k souboru ze všech adres.
# OCHRANA DDoS XML-RPC
# OCHRANA DDoS XML-RPC < FilesMatch "^(xmlrpc\.php)" > Objednávka Odmítnout, Povolit Ode všech popřít < / FilesMatch > |
V mém případě bylo možné zablokovat pouze IP adresu zdroje požadavku, protože... byla použita stejná adresa. Chcete-li zablokovat pouze IP adresu „shkolodoser“:
< FilesMatch "^(xmlrpc\.php)" > Objednat Povolit, Zamítnout Zamítnout z 85.93.93.157 Povolit od všech < / FilesMatch > |
Pokud ale používáte RPC, můžete vytvořit bílý seznam adres, které mají přístup ke skriptu xmlrpc.php.
Počínaje sobotním polednem se můj server, kde je hostováno asi 25 webů Wordpress, začal silně zpomalovat. Vzhledem k tomu, že předchozí útoky (útok 1 - přesně před rokem, útok 2 - v březnu) jsem dokázal bez povšimnutí přežít, hned jsem nechápal, co se děje.
Když jsem na to přišel, ukázalo se, že hesla byla hrubě vynucená + mnoho požadavků na XMLRPC.
Ve výsledku se nám to všechno podařilo utnout, i když ne hned. Zde jsou tři jednoduché triky, jak se tomu vyhnout.
Tyto techniky pravděpodobně zná každý, ale šlápl jsem na pár chyb, které jsem v popisech nenašel - možná to někomu ušetří čas.
1. Zastavte vyhledávání, nainstalujte plugin Limit Login Attempts - nainstalujte jej, protože jiné ochrany značně zpomalují server, například při použití pluginu Login Security Solution server po půl hodině zemřel, plugin silně zatěžuje databázi .
V nastavení nezapomeňte zaškrtnout políčko „Pro proxy“ - jinak určí IP vašeho serveru pro všechny a automaticky všechny zablokuje.
AKTUALIZACE, díky DarkByte, podrobnosti níže v komentářích - zaškrtněte políčko „Pro proxy“ pouze v případě, že detekce nefunguje, když je povoleno „Přímé připojení“
2. Zakázat XML-RPC – plugin Zakázat XML-RPC (je snadné jej aktivovat a je to).
3. Zavřete wp-login.php – pokud na stránky přistupujete přes IP, plugin nefunguje a výběry nadále padají stránky. Chcete-li se tomu vyhnout, přidejte do .htaccess:
Zkopírujeme soubor wp-login, přejmenujeme ho na jakýkoli divný název, například poletnormalny.php, a uvnitř souboru pomocí autocorrectu změníme všechny nápisy wp-login.php na poletnormalny.php.
To je vše, nyní máte přístup k panelu správce pouze pomocí svého souboru.
Po těchto 3 jednoduchých krocích začaly lokality opět létat a nastal klid.
No, najednou je to zajímavé
Jednou z možností je zjistit, zda na vás někdo neútočí. To lze vidět v protokolech nginx (například zde je cesta k souboru Debian /var/log/nginx access.log).- Podpora pro vytváření xmlrpc klientů i serverů
- Plně automatizované nebo plně manuální, jemnozrnné kódování a dekódování z hodnot php do xmlrpc
- Podpora kódování znaků UTF8, Latin-1 a ASCII. S povoleným rozšířením php mbstring je podporováno ještě více znakových sad.
- Podpora http komprese požadavků i odpovědí, cookies, proxy, základní auth a https, ntlm auth a keepalives s rozšířením php cURL
- Volitelné ověření typů parametrů příchozího požadavku xmlrpc
- Podpora metod system.listMethods, system.methodHelp, system.multicall a system.getCapabilities
- Podpora pro
a - Možnost zaregistrovat existující funkce php nebo metody třídy jako webové služby, extrahování informací s přidanou hodnotou z komentářů phpdoc
- Součástí knihovny je webový vizuální debugger
Požadavky
- PHP 5.3.0 nebo novější; Doporučuje se 5.5 nebo novější
- rozšíření php "curl" je potřeba, pokud chcete pro komunikaci se vzdálenými servery používat SSL nebo HTTP 1.1
- rozšíření php "mbstring" je potřeba, aby bylo možné přijímat požadavky/odpovědi ve znakových sadách jiných než ASCII, Latin-1, UTF-8
- nativní rozšíření php "xmlrpc" není vyžadováno, ale pokud je nainstalováno, nebude docházet k žádným zásahům do provozu této knihovny.
Stažení
Zprávy
- 1. července 2017
Vydané verze knihovny 4.2.0 a 3.1.0.
Poznámky k vydání jsou k dispozici na Github - 20. ledna 2016
Vydána verze knihovny 4.0.0.
Je to vůbec poprvé, kdy API vidí velké změny, odstraňuje minulost a začíná přechod na moderní php.
Byly zavedeny jmenné prostory a výchozí znaková sada, která se používá, pokud je UTF-8; byla přidána podpora pro mbstring a mnoho dalšího.
Úplný seznam změn najdete na Github - 19. dubna 2015
Vydaná lib verze 3.0.1. - 15. června 2014
Vydaná lib verze 3.0.0. - 15. prosince 2013
Projekt se přesunul na GitHubOnline ladicí program xmlrpc
Na adrese http://gggeek.altervista.org/sw/xmlrpc/debugger/ je aktivní demo aplikace debuggeru xmlrpc, postavená na této knihovně. Debugger můžete použít např. dotaz na demo server SF nebo ladění vlastního osobního serveru xmlrpc, pokud je dostupný na internetu.
Rozvoj
Popis Stav – aktualizováno 26. 7. 2009 Aktualizujte dokumentaci pro všechny funkce přidané od verze 2 Pomalu postupuje... Přidejte možnost zvolit formátování xml zpráv Podobně jako to dělá php nativní rozšíření xmlrpc Opravte varování vydávaná při běhu s PHP 5 v STRICT režimu Možná již bylo provedeno ve verzi 3.0, opuštění php 4 compat... Rozšiřte automatickou funkci php na obálku metody xmlrpc, abyste využili výhody zpracování výjimek a vraceli chybové odpovědi xmlrpc Rozbalte automatický generátor útržků pro automatický převod funkcí php na metody xmlrpc pro PHP<= 5.0.2 podívejte se na kód AMFPHP, jak to udělat.
Mnoho vylepšení ve verzi 2.1
Nyní, když server může automaticky registrovat funkce php, je to méně potřeba...Lepší podpora pro mbstring, když je povolen Měl by udělat např. rychlejší hádání kódování znakové sady Vylepšete podporu pro soubory cookie „verze 1“. Přidejte možnost použít místo nativních chybových kódů Kompatibilita PEAR: přidejte synonyma pro funkce existující s různými názvy ve verzi PEAR knihovny Přidejte podporu pro rozšíření xmlrpc Přidejte do ladicího programu možnost spustit kompletní sadu testů validator1 Prozkoumejte použitelnost WSDL pro popis exponovaných služeb a překlad do/z system.methodSignature a system.describeMethods Některé problémy existují při použití XSD k striktní definici xmlrpc. Relax NG je rozhodně lepší alternativa, ale v jiných sadách nástrojů je malá podpora pro jeho použití ve spojení se souborem WSDL... Podpora přesměrování http (302) Přidejte do sf.net malou databázi, abychom mohli implementovat stránku validátoru, která zaznamenává příchozí uživatele, jako je například stránka xmlrpc.com Přidejte do sady benchmarků možnost nahrávat výsledky na sf.net Napište rozšíření php, které zrychlí nejpoužívanější funkce knihovny lib Podívejte se, jak to adodb udělal na příkladu Testujte rychlost/zvýšení paměti pomocí simplexml a relaxng místo ruční analýzy xml Bezpečnostní
Třetí narušení bezpečnosti: srpen 2005
Jednalo se o další a proaktivní reakci na druhé narušení bezpečnosti níže. Veškeré použití eval() bylo odstraněno, protože to bylo stále potenciální zneužití.
Když byla knihovna původně napsána, verze php dostupné v té době neobsahovaly call_user_func(), et al. Bylo tedy napsáno v rámci těchto omezení použít eval() ve dvou funkcích volaných analyzátorem xml. Kvůli tomuto použití třída server také používala eval(), protože musela analyzovat xml pomocí stejných funkcí.
Tyto obslužné funkce a pole používané k udržování obsahu původní zprávy byly přepsány tak, aby vytvořily hodnoty php namísto vytváření php kódu pro vyhodnocení. To by mělo odstranit jakýkoli potenciál pro spuštění kódu.
Druhé narušení bezpečnosti: červenec 2005
Bezpečnostní zranitelnost objevená Jamesem Bercegayem z GulfTech Security Research 27. června 2005 způsobila značný rozruch. Dostal se na titulní stránku Salshdotu, byl zmíněn na Netcraftu, LWN a mnoha dalších stránkách.
Na internetu byly zveřejněny podrobné pokyny pro vytváření exploit kódu a mnoho správců webhostingu se stále ptá, jaký je nejlepší plán obrany a jaká jsou skutečná rizika. Zde je několik odpovědí.
Rozsah problému
- chyba ovlivňuje dvě knihovny známé jako PEAR::XMLRPC a PHPXMLRMPC.
NEOVLIVŇUJE implementaci xmlrpc, která je vestavěná v php a je povolena v době kompilace pomocí volby "--with-xmlrpc" (v Unixu, na Windows se obecně povolí/zakáže změnou příslušného řádku v php.ini ) - chyba (spuštění php kódu vloženého vzdálenými hostiteli) se nachází výhradně v souboru xmlrpc.inc v distribuci phpxmlrpc a RPC.php v distribuci HRUŠKA
- jak PEAR::XMLRPC, tak PHPXMLRMPC vydaly aktualizované verze knihovny, které problém opravují
- obě knihovny byly použity ve velkém množství php aplikací (viz neúplný seznam výše).
Vzhledem k tomu, že celá knihovna sestává v podstatě ze 2 velmi jednoduchých souborů, každý má tendenci si je opravovat podle svého vkusu/potřeb a při distribuci své aplikace je sdružovat.
Většina významných projektů byla extrémně rychlá při vydávání nových verzí příslušných aplikací, ale každému uživateli bude trvat mnohem déle, než aktualizuje svůj systém.
Je třeba říci, že mnoho aplikací bylo donedávna dodáváno s extrémně zastaralými verzemi knihovny phpxmlrpc; první chyba vstřikování byla opravena v roce 2001 aniž by si toho někdo zjevně všiml (...)To bohužel velmi ztěžuje systémovým administrátorům najít snadný lék na tento problém: existuje velká šance, že na veřejných hostingových serverech budou výše uvedené soubory nalezeny v mnoha různých adresářích a v mnoha různých verzích.
Jak je zranitelnost spuštěna
- Aby mohl útočník spustit chybu, potřebuje mít vyhodnocený nějaký speciálně vytvořený xml v procesu vytváření objektu xmlrpcval. Objekty Xmlrpcval se vytvářejí, když skript serveru dekóduje požadavky xmlrpc nebo když některé skripty php fungují jako klient xmlrpc a dekódují odpověď odeslanou serverem.
Serverový skript je specifický pro aplikaci a často se jmenuje server.php (ale je možná jakákoli varianta zvolená projektem nebo uživatelem) a musí obsahovat soubory xmlrpc.inc i xmlrpcs.inc (u verze hruška server .php je ekvivalent xmlrpcs.inc). - Pouze zahrnutí xmlrpc.inc a xmlrpcs.inc do php skriptů je (afaik...) zcela bezpečné, stejně jako jejich přímé volání přes http požadavky, jelikož v těchto dvou souborech se provádí pouze definice funkcí, proměnných a tříd, tzn. žádné okamžité spuštění kódu.
- Soubory server.php a diskusní.php distribuované s plnou knihovnou phpxmlrpc ve skutečnosti implementují živý server xmlrpc, takže můžete zvážit zablokování přístupu k nim nebo ještě lepší jejich odstranění, pokud je najdete nasazené na produkčních serverech (mimo horní část mé mysl Dokážu vykouzlit nějaký druh útoku zahrnujícího druhou aplikaci php, která trpí porušením převzetí-php-file-inclusion, abych je vtáhla + využila známou chybu lib)
Prostředky ochrany
- Dejte procesu svého webového serveru co nejmenší systémová oprávnění. Na Unixu to obecně znamená spouštění Apache jako uživatel nikdo a/nebo v jailrooted/chrooted prostředí. Protože PHP engine běží pod stejným uživatelem jako webový server, jedná se o první obrannou linii: jakýkoli php kód vložený útočníkem poběží na serveru jako nejméně privilegovaný uživatel a veškeré škody, které by mohl způsobit, budou omezeny na narušení samotné php aplikace
- Spusťte php v nouzovém režimu. Pokud jste veřejný hostitel a neděláte to, je pravděpodobné, že váš server byl stejně rootnutý. To zabraňuje php skriptům používat jakoukoli funkci, kterou považujete za nebezpečnou, jako je system() nebo eval()
- Tvrdý blok: najděte všechny existující soubory phpxmlrpc (xmlrpc.inc a xmlrpcs.inc) a zakažte je (chmod 0) v celém systému.
To může samozřejmě bránit fungování některých uživatelských aplikací, takže byste měli své uživatele informovat v době, kdy to uděláte. - Měkký blok: nahraďte všechny kopie existujících souborů phpxmlrpc (xmlrpc.inc a xmlrpcs.inc) těmi, které pocházejí z verze 1.1.1.
Tato metoda bohužel není 100% zaručena, že všechny aplikace budou fungovat. Některé vnitřní části objektů lib se změnily z verze 0.9 na 1.0 na 1.1 (např. reprezentace hlaviček http uložených uvnitř objektu xmlrpcresp), a pokud je kód, který jste nasadili na své servery, podtřídí, může se dostat do potíží. XML zasílané po drátě se také změnilo s ohledem na některé starší verze lib (zejména: verze 1.0.99.2 nesprávně kódovala znaky mimo rozsah ASCII jako entity html, zatímco nyní jsou kódovány jako entity znakové sady xml). Bylo také přidáno několik nových kódů odezvy na chyby. Přesto byste měli být na 95 % v bezpečí při spuštění tohoto skriptu a sedět a čekat, až uživatelé začnou křičet, že je něco nefunkční... - knihovnu PHP PEAR lze upgradovat pomocí jednořádkového příkazu, takže to ve skutečnosti není velký problém:
hruška upgrade XML_RPC a zjistit, zda byl upgradován (1.3.1 nebo novější je v pořádku, nejnovější je nyní 1.3.2):
seznam hrušek | grep RPC
Některé úvahy navíc
Soubor xmlrpcs.inc byl také opraven ve verzi 1.1.1, aby poskytoval lepší uživatelský zážitek. Podrobněji: odeslání speciálně vytvořeného chybně formátovaného xml na server by způsobilo, že php skript vygeneruje chybu php místo toho, aby vrátil odpovídající xml odpověď.
Podle některých to ve skutečnosti znamená „narušení zabezpečení odhalení cesty“ (tj. zobrazená chybová zpráva php obvykle obsahuje citlivé informace o cestách souborového systému), ale pak každý jednotlivý skript PHP trpí stejným bezpečnostním problémem, pokud správce systému provozuje produkční servery s direktiva ini display_errors=On.
Vím také jistě, že na xmlrpc.inc je mnoho míst, kde volání funkce s neočekávaným parametrem vygeneruje php varování nebo chybu, a neplánuji v dohledné době implementovat přísnou kontrolu parametrů pro každou jednotlivou funkci - pokud zaměřte se na to, imho, můžete také kódovat v Javě.Je tohle konec světa?
Doufám, že ne.
Důvodem je, že existují desítky PHP aplikací, které trpí zneužitím vkládání kódu. Stačí se podívat na bezpečnostní stopu nástěnek... a přesto si spousta lidí stále myslí, že PHP je dobrá volba pro vývoj webu.
Pamatujte: zabezpečení je proces, nikoli stav, kterého lze dosáhnout.První narušení bezpečnosti: září 2001
Dostal jsem toto doporučení od Dana Libbyho. S jeho svolením je zde reprodukován. Všimněte si, že tento exploit je opraven v revizích 1.01 a vyšších XML-RPC pro PHP. -- Edd Dumbill Út 24. září 2001 ============= Bezpečnostní díra PHP: potenciální zneužití XML-RPC ===================== ======================== Abstrakt: Pomocí nejnovější verze knihovny php xmlrpc Useful Inc, verze 1.0, je možné, aby útočník strukturoval xml takovým způsobem, že přiměl knihovnu xml-rpc ke spuštění php kódu na webovém serveru. Podařilo se mi spustit libovolný php kód a s vypnutým bezpečným režimem php systémové příkazy. Útočník by to mohl snadno použít jako bránu pro spouštění virů. Podrobnosti: Problém jsem demonstroval úpravou ukázkového skriptu server.php, který je součástí distribuce xmlrpc, a jeho voláním pomocí skriptu client.php, který je také součástí distribuce. Obešel jsem standardní kód serveru a jednoduše jsem odeslal odpovědi zpět klientovi. Podařilo se mi přimět klienta, aby spustil libovolný php kód. Poté jsem obnovil ukázku server.php do původního stavu a pomocí telnetu odeslal upravený Podařilo se mi také provést spuštění kódu na serveru, i když to vyžadovalo trochu jinou syntaxi. Útok se soustředí na použití funkce eval() php. Protože jsem věděl, že knihovna xml-rpc používá eval ke konstrukci svých datových struktur ze vstupu xml, šlo jen o to strukturovat vstupní xml takovým způsobem, aby: a) nebylo před předáním do eval předáno negeneruje chybu syntaxe php Normálně jsou všechna nečíselná data knihovnou před předáním do eval escapována. Ukazuje se však, že pokud odešlete atag následovaný neočekávaným tagem, jako např , únikový kód bude vynechán a místo něj budou vyhodnocena „surová“ data. Využití klienta: Zde je typická odpověď xml-rpc: Ahoj světe Ahoj světe
"na straně klienta:", "řetězec"); echo " Ahoj světe
"; \$odpad = pole("Ahoj světe
"; $waste = array("", "string") Vše mezi "string"); a \$waste je možné nahradit libovolným kódem téměř libovolné délky. Nakonec je zde jeden, který vytiskne obsah aktuálního adresáře:", "řetězec"); echo " "; echo `ls -al`; echo "
"; exit; \$waste = array("system.listMetody ", "řetězec")); echo " pokud vidíte výpis adresáře, právě jsem provedl php a systémový kód přes xml-rpc.
"; echo "nyní se pokusím o výpis adresáře pomocí ls -al:\n"; echo `ls -al`; echo " "; echo "Mohl jsem jednoduše vyvolat rm -rf nebo napsat program na disk a spustit ho (např. virus) nebo přečíst nějaké soubory. Hezký den.
"; exit; $waste = array(array(" - chyba ovlivňuje dvě knihovny známé jako PEAR::XMLRPC a PHPXMLRMPC.