Хакери шукають різні шляхи злому ваших сайтів. У більшості випадків, якщо тільки сайт не представляє якоїсь комерційної цінності, це граються діти, намагаючись самоствердитися.
Днями сайти мого хостингу, м'яко кажучи, прилягали. Було видно, що DOS-ят якийсь із сайтів.
А видно це насамперед із статистики використання ресурсів сервера:
Я здивувався з тієї причини, що комерційних ресурсів на хостингу не лежить. Чого, питається, DOS-ть щось? З якою метою?
Що бачимо на діаграмі?
На першому малюнку ми спостерігаємо завантаження процесора. Вона вимірюється у 100% на одне ядро. Десь 15.00 за гринвічем атака почалася, а в районі 21.00 я попросив провайдера щось з цим зробити. Тих підтримка почала перенесення хостингу на інший майстер-сервер. Мабуть, щоб дати можливість використовувати більше системних ресурсів. Годині о 22:00 розпочався переїзд, перевірка цілісності файлів та інші процедури.
Не хотілося навіть возитися — і я просто ліг спати, бо, «ранок вечора мудріший».
Що видно у логах сервера?
Статистика на ранок вже не показувала якихось аномалій. Сайти однаково відкривалися через і далеко ще не відразу, тобто. атака тривала. Чи статистика писалася все ще зі старого сервера, чи це вже були дані майстер-сервера…
Тому я перейшов до вивчення ліг, щоб з'ясувати куди «стукають».
Коли я подивився в логі, стало ясно, що можна не турбуватися — стукає якась школота з однієї й тієї ж ip адреси в /xmlrpc.php одного з моїх сайтів на WordPress. Найімовірніше займається брут-форсом адмінського пароля.
Приємного, звичайно ж, мало, тому що «лежать» і всі інші сайти віртуального сервера. І найприкріше, що я не використовую ці XML сервіси на жодному зі своїх WP сайтів.
Блокуємо XML RPC.
Найпростіше, що ви можете зробити в цій ситуації, - видалити з кореневої папки сайту файл /xmlrpc.php. Сервер не знайшовши скрипу, не запускатиме PHP, витрачатиме ресурси пам'яті та час процесора. Рішення просте, але не гарне. По-перше, хтось може користуватися можливостями RPC. Наприклад, публікувати записи на сайт через один із багатьох Weblog клієнтів. По-друге, файл буде відновлено після чергового оновлення WP.
Якщо ваш сервер працює на Apache, можна блокувати доступ до xmlrpc.php, не видаляючи файл. Потрібно додати наступні інструкції на початок вашого .htaccessфайлу в кореневій директорії сайту WordPress. Це заблокує доступ до файлу з будь-яких адрес.
# XML-RPC DDoS PROTECTION
# XML-RPC DDoS PROTECTION < FilesMatch "^(xmlrpc\.php)" > Order Deny , Allow Deny from all < / FilesMatch > |
У моєму випадку можна було заблокувати лише IP-адресу джерела запитів, т.к. використовувався той самий адресу. Для блокування тільки IP-адреси «школодосера»:
< FilesMatch "^(xmlrpc\.php)" > Order Allow, Deny Deny from 85.93.93.157 Allow from All < / FilesMatch > |
Але якщо ви користуєтеся RPC, то можна скласти білий список адрес, які мають доступ до скрипту xmlrpc.php.
Використання XML-RPC у PHP для публікації матеріалів у LiveJournal.com (ЖЖ)
Для початку вам потрібно завантажити бібліотеку XML-RPC. Найбільш вдалою версією мені здається вільно розповсюджувана через sourceforge " ": Всі приклади нижче будуть наведені для цієї бібліотеки версії 2.2.
Що таке XML-RPC? RPC розшифровується як Remote Procedure Call, відповідно російською це можна перекласти як віддалений виклик процедур за допомогою XML. Сама методика віддаленого виклику процедури відома давно і використовується в таких технологіях як DCOM, SOAP, CORBA. RPC призначений для побудови розподілених клієнт-серверних програм. Це дає можливість будувати програми, які працюють у гетерогенних мережах, наприклад, на комп'ютерах різних систем, проводити віддалену обробку даних та керування віддаленими програмами. Зокрема, цим протоколом користується добре відомий в Росії сайт livejournal.com.
Розглянемо приклад, як можна розмістити кириличний запис (а саме із цим часто виникають проблеми) у ЖЖ. Нижче наведено працюючий код з коментарями:
new xmlrpcval($name, "string"), "password" => new xmlrpcval($password, "string"), "event" => new xmlrpcval($text, "string"), "subject" => new xmlrpcval ($subj, "string"), "lineendings" => new xmlrpcval("unix", "string"), "year" => new xmlrpcval($year, "int"), "mon" => new xmlrpcval( $mon, "int"), "day" => новий xmlrpcval($day, "int"), "hour" => новий xmlrpcval($hour, "int"), "min" => новий xmlrpcval($min , "int"), "ver" => new xmlrpcval(2, "int"));
/* на основі масиву створюємо структуру */ $post2 = array(new xmlrpcval($post, "struct"));
/* створюємо XML повідомлення для сервера */ $f = new xmlrpcmsg("LJ.XMLRPC.postevent", $post2);
/* описуємо сервер */ $c = new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80);
$c->request_charset_encoding = "UTF-8";
/* за бажанням дивимося на XML-код того, що відправиться на сервер */ echo nl2br(htmlentities($f->serialize()));
/* надсилаємо XML повідомлення на сервер */ $r = $c->send($f);
/* аналізуємо результат */ if(!$r->faultCode()) ( /* повідомлення прийнято успішно і повернувся XML-результат */ $v = php_xmlrpc_decode($r->value()); print_r($v); ) else ( /* сервер повернув помилку */ print "An error occurred: "; print "Code: ".htmlspecialchars($r->faultCode()); print "Reason: "".htmlspecialchars($r->faultString( )).""\n"; ) ?>
UPDATE, дякую, подробиці нижче в коментах - галочку «За проксі» включаємо тільки якщо не працює визначення при включеному «Пряме підключення»
2. Відключаємо XML-RPC - плагін Disable XML-RPC (його просто активувати і все).
3. Закриваємо wp-login.php - якщо звертатися до сайту через ip, то плагін не спрацьовує і підбирачі продовжують довбати сайт. Щоб цього уникнути, в.htaccess додаємо:
Файл wp-login копіюємо, перейменовуємо на будь-яке дивне ім'я, наприклад poletnormalny.php і всередині файлу автозаміною змінюємо всі написи wp-login.php на poletnormalny.php.
Все, тепер до адмінки можна звернутися тільки до вашого файлу.
Після цих трьох нескладних кроків сайти знову почали літати і прийшов спокій.
Ну і раптом цікаво
Один із варіантів як подивитися, що вас атакують. Це можна побачити в логах nginx (наприклад, шлях для Debian /var/log/nginx файл access.log).Введення в XML-RPC
У Мережі є багато різних ресурсів, які надають користувачам певну інформацію. Маються на увазі не типові статичні сторінки, а, наприклад, дані, що витягуються з бази даних чи архівів. Це може бути архів фінансових даних (курси валют, дані котирувань цінних паперів), дані про погоду, або більш об'ємна інформація - новини, статті, повідомлення з форумів. Така інформація може представлятися відвідувачеві сторінки, наприклад, через форму, як відповідь на запит, або щоразу генеруватися динамічно. Але труднощі в тому, що часто така інформація потрібна не так кінцевому користувачеві - людині, як іншим системам, програмам, які ці дані будуть використовувати для своїх розрахунків або інших потреб.
Реальний приклад: сторінка банківського сайту, де показуються котирування валют. Якщо ви заходите на сторінку як звичайний користувач через браузер, ви бачите все оформлення сторінки, банери, меню та іншу інформацію, яка "обрамляє" справжню мету пошуку - котирування валют. Якщо вам потрібно вносити ці котирування до свого інтернет-магазину, то нічого іншого не залишиться, як тільки вручну виділити потрібні дані та через буфер обміну перенести на свій сайт. І так доведеться робити щодня. Невже нема виходу?
Якщо вирішувати проблему "в лоб", то відразу напрошується рішення: програма (скрипт на сайті), якій треба дані, отримує сторінку від сервера як "звичайний користувач", розбирає (парсит) отриманий HTML-код і виділяє з нього потрібну інформацію. Це можна зробити або звичайним регулярним виразом, або за допомогою будь-якого html-парсера. Складність підходу – у його неефективності. По-перше, для отримання невеликої порції даних (дані про валюти - це буквально десяток-другий символів) треба отримувати всю сторінку, а це не менше кількох десятків кілобайт. По-друге, при будь-якій зміні коду сторінки, наприклад, дизайн змінився або ще щось, наш алгоритм аналізу доведеться переробляти. Та й ресурсів це відбиратиме порядно.
Тому розробники дійшли рішення - треба розробити якийсь універсальний механізм, який би дозволив прозоро (на рівні протоколу та середовища передачі) і легко обмінюватися даними між програмами, які можуть знаходитися будь-де, бути написаними будь-якою мовою і працювати під управлінням будь-якої операційної системи та на будь-якій апаратній платформі. Такий механізм називають зараз гучними термінами "Веб-сервіси" (web-service), "SOAP", "архітектура, орієнтована на сервіси" (service-oriented architecture). Для обміну даними використовуються відкриті і перевірені часом стандарти - передачі повідомлень протокол HTTP (хоча можна використовувати інші протоколи - SMTP наприклад). Самі дані (у нашому прикладі – курси валют) передаються упакованими у крос-платформний формат – у вигляді XML-документів. Для цього придумано спеціальний стандарт - SOAP.
Так, зараз веб-сервіси, SOAP і XML у всіх на слуху, їх починають активно впроваджувати і великі корпорації типу IBM і Microsoft випускають нові продукти, покликані допомогти тотальному впровадженню веб-сервісів.
Але! Для нашого прикладу з курсами валют, які повинні передаватися з сайту банку в двигун інтернет-магазину, таке рішення буде дуже складним. Адже тільки опис стандарту SOAP займає непристойні півтори тисячі сторінок, і це ще не все. Для практичного використання доведеться вивчити ще роботу зі сторонніми бібліотеками та розширеннями (тільки починаючи з PHP 5.0 до нього входить бібліотека для роботи з SOAP), написати сотні та тисячі рядків свого коду. І все це для отримання кількох літер і цифр - явно дуже важко й нераціонально.
Тому існує ще один, з натяжкою можна сказати альтернативний стандарт на обмін інформацією – XML-RPC. Він був розроблений за участю Microsoft компанією UserLand Software Inc і призначений для уніфікованої передачі даних між програмами через Інтернет. Він може замінити SOAP при побудові простих сервісів, де не потрібні всі "корпоративні" можливості справжніх веб-сервісів.
Що означає абревіатура XML-RPC? RPC розшифровується як Remote Procedure Call – віддалений виклик процедур. Це означає, що програма (неважливо, скрипт на сервері або звичайна програма на клієнтському комп'ютері) може прозоро використовувати метод, який фізично реалізований та виконується на іншому комп'ютері. XML тут застосовується для забезпечення універсального формату опису даних, що передаються. Як транспорт для передачі повідомлень застосовується протокол HTTP, що дозволяє безперешкодно обмінюватися даними через будь-які мережеві пристрої - маршрутизатори, фаєрволи, проксі-сервера.
І так, для використання треба мати: сервер XML-RPC, який надає один або кілька методів, клієнт XML-RPC, який може формувати коректний запит та обробляти відповідь сервера, а також знати необхідні для успішної роботи параметри сервера - адресу, назву методу та параметри, що передаються.
Вся робота з XML-RPC відбувається в режимі "запит-відповідь", в цьому є одна з відмінностей технології від стандарту SOAP, де є і поняття транзакцій, і можливість робити відкладені виклики (коли сервер зберігає запит і відповідає на нього в певний час в майбутньому). Ці додаткові можливості більше стануть у нагоді для потужних корпоративних сервісів, вони значно ускладнюють розробку та підтримку серверів, і ставлять додаткові вимоги до розробників клієнтських рішень.
Процедура роботи з XML-RPC починається з формування запиту. Типовий запит має такий вигляд:
POST/RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172
У перших рядках формується стандартний заголовок HTTP запиту POST. До обов'язкових параметрів належать host, тип даних (MIME-тип), який має бути text/xml, а також довжина повідомлення. Також у стандарті вказується, що поле User-Agent має бути заповнене, але може мати довільне значення.
Далі йде типовий заголовок XML-документа. Кореневий елемент запиту -
Рядок
Далі задаються параметри, що передаються. Для цього є секція
Після опису всіх параметрів слідують теги, що закривають. Запит та відповідь у XML-RPC – це звичайні документи XML, тому всі теги обов'язково повинні бути закриті. А ось одиночних тегів у XML-RPC немає, хоча у стандарті XML вони є.
Тепер розберемо відповідь сервера. Заголовок HTTP відповіді звичайний, якщо запит успішно оброблений, сервер повертає відповідь HTTP/1.1 200 OK. Також, як у запиті, слід коректно вказати MIME-тип, довжину повідомлення та дату формування відповіді.
Саме тіло відповіді таке:
Тепер замість кореневого тегу
Якщо під час обробки вашого запиту сталася помилка, то замість У відповіді буде елемент
А тепер розглянемо коротко типи даних у XML-RPC. Усього типів даних є 9 - сім простих типів та 2 складних. Кожен тип описується своїм тегом чи набором тегів (для складних типів).
Прості типи:
Цілі числа- тег
Логічний тип- тег
ASCII-рядок- описується тегом
Числа з плаваючою точкою- тег
дата та час- описується тегом
Останнім простим типом є рядок, закодований у base64, яка описується тегом
Складні типи представлені структурами та масивами. Структура визначається кореневим елементом
Масиви не мають назв і описуються тегом
Звичайно, хтось скаже, що такий перелік типів даних дуже бідний і не дозволяє розвернутися. Так, якщо треба передавати складні об'єкти або великі обсяги даних, то краще використовувати SOAP. А для невеликих, невибагливих додатків цілком підходить і XML-RPC, більш того, дуже часто навіть його можливостей виявляється дуже багато! Якщо врахувати легкість розгортання, дуже велика кількість бібліотек майже для будь-яких мов і платформ, широку підтримку в PHP, то XML-RPC часто просто не має конкурентів. Хоча відразу радити його як універсальне рішення не можна - у кожному конкретному випадку треба вирішувати за обставинами.
- Support for creating both xmlrpc clients and servers
- Fully automated or fully manual, fine-grained encoding and decoding from php values to xmlrpc
- Додаток для UTF8, Latin-1 і ASCII character encodings. З php mbstring extension enabled, even more character sets are supported.
- Support for http compression of requests and responses, cookies, proxies, basic auth and https, ntlm auth and keepalives with php cURL extension
- Optional validation of parameter types of incoming xmlrpc request
- Support for system.listMethods, system.methodHelp, system.multicall and system.getCapabilities methods
- Support for the
and - Можливості до реєстру існуючих php функцій або класу методів як веб-служби, виведення цін-відповідної інформації від phpdoc comments
- A web based visual debugger is included with the library
Requirements
- PHP 5.3.0 or later; 5.5 or later recommended
- php "curl" extension is needed if you wish to use SSL or HTTP 1.1 to communicate with remote servers
- php "mbstring" extension is needed to allow reception requests/responses in character sets other than ASCII, Latin-1, UTF-8
- php "xmlrpc" природний простір не вимагається, але якщо він налаштований, він буде не interference with operation of this library.
Download
News
- 1st of July, 2017
Released lib versions 4.2.0 та 3.1.0.
The release notes є доступні на Github - 20th of January, 2016
Released lib version 4.0.0.
Це перший час - перше - що в API повідомити про великі зміни, що ведеться з past і starts a transition to modern-day php.
Namespaces має бути введений, а потім більший параметр встановлюється в разі використання UTF-8; support for mbstring has been added, and much more.
Для повного набору змін, head on to on Github - 19th of April, 2015
Released lib version 3.0.1. - 15th of June, 2014
Released lib version 3.0.0. - 15th of December, 2013
Project moved to GitHubOnline xmlrpc debugger
A demo xmlrpc debugger application, побудований на стовпці цієї library, є активним на адресу http://gggeek.altervista.org/sw/xmlrpc/debugger/ . Ви можете використовувати debugger to e.g. Будьте SF demo server, або розмітка вашого свого індивідуального xmlrpc server, якщо це accessible на мережі.
Development
Description Status - updated 2009/07/26 Update documentation for all features added since version 2 Slowly progressing... Add the possibility to choose formatting of the xml messages Similar to what the php native xmlrpc extension does Fix warnings emitted when running with PHP 5 in STRICT mode Might have already been done in version 3.0, abandoning php 4 compat... Expand автоматична php функція до xmlrpc метод wrapper to таке advantage of exception handling and return xmlrpc error responses Expand автоматичний stub generator для автоматично перетворення php функцій на xmlrpc методи для PHP<= 5.0.2 look at AMFPHP code on how to do it.
Багато вдосконалень у версії 2.1
Новий те, що сервер може автоматично реєструвати php функцій є незважаючи на те, що він...Better support for mbstring when it"s enabled Should make e.g. charset encoding guessing faster Improve support for "version 1" cookies Add a possibility to use instead of the native error codes PEAR compatibility: add synonyms для функцій existing with different names in the PEAR version of the lib Add support for the xmlrpc extension Add to debugger capability to launch complete set of validator1 tests Досвідома можливість WSDL для опису exposed services and translation to/from system.methodSignature and system.describeMethods Деякі проблеми існують в системі XSD, що strictly define xmlrpc. Relax NG є певним чином альтернативним, але є малою підтримкою в інших інструментах для використання її в спільній роботі з WSDL файлом... Support http redirects (302) Add to sf.net для малого database, так що ми можемо реалізувати validator сторінку, що logs incoming users, such as is present on the xmlrpc.com site Add to benchmark suite capability to upload results to sf.net Write a php extension that will accelerate the most heavily використовує функції lib See how adodb did it for an example Test speed/memory gains using simplexml and relaxng instead of hand parsing of xml Security
The third security breach: квітень 2005
Це було довше і сприятливим відповіддю до 2-х років безпеки. All use of eval() has been removed since it still a potential exploit.
Якщо library був originally written, versions php available at time did не включає call_user_func(), et al. So it was written within those constraints to use eval() in two of the functions called by the xml parser. Для того, щоб скористатися цією функцією, Class Servers також використовує eval(), тому що вона використовується для parse xml, використовуючи ті ж самі функції.
Ці функції функцій, і array використовується для забезпечення вмісту оригіналу message, має бути rewritten до construction php values instead of building php code for evaluation. Це повинно скористатися будь-яким потенційним кодом execution.
The second security breach: липень 2005
Безпека vulnerability затверджена James Bercegay of GulfTech Security Research on the 27th of June, 2005, has caused quite a stir. Це буде зроблене ним на передній сторінці Salshdot, має бути mentioned на Netcraft, LWN і багато інших підприємств.
Докладні інструкції на побудову exploit code мають бути повідомлені на Інтернеті, і багато web hosting адміністраторів є більшою мірою, що є найкращий рівень плану, а який реальний ризик. Here are some answers.
Scope of the problem
- the bug affects the 2 libraries відомі як PEAR::XMLRPC and PHPXMLRMPC.
Це не дає ефекту xmlrpc implementation, який є розроблений в php і налаштований на тривалий час з "----xmlrpc" option (у Unix, на windows є звичайним шляхом налаштування/неможливість змінювати відповідну лінію в php. ) - bug (execution of php-code injected by remote hosts) resides exclusivamente in the file xmlrpc.inc in the phpxmlrpc distribution and RPC.php in the PEAR distribution
- both PEAR::XMLRPC and PHPXMLRMPC має released updated versions of library that fix the problem
- both libraries мають бути використані в багатьох номерах php applications (see the incomplete list above).
Відтоді всі lib належать basically of 2 very simple files, everybody tends to patch them according to its own tastes/needs and bundle them when distributing their app.
Більшість high-profile проектів мають бути надзвичайно швидким в повідомленні нових версій своїх специфічних apps, але це буде дуже довгий час для всього одного користувача до оновлення його системи.
It has to be said that many applications had been shipping until recently with extremely outdated versions of phpxmlrpc library included; a first injection bug had been fixed in 2001без будь-якого apparently taking notice (...)Це робить його незрівнянно багатим harder для sysadmins до того, щоб отримати достатню ціну для проблем: там є велике зміна, що на громадських hosting servers повідомлені файли будуть працювати в багатьох різних directories і в різних версіях.
How the vulnerability is triggered
- натиснути на bug attacker потреби в тому, щоб specially crafted xml evaluated in the creation process of xmlrpcval object. Xmlrpcval об'єкти створюються при сервері script decodes xmlrpc requests або коли деякі php scripts acts as xmlrpc client and decodes a response sent by a server.
Цей script-сервер є конкретним пристосуванням, і це використовується назвою сервера. .php is the equivalent of xmlrpcs.inc). - Тільки including xmlrpc.inc і xmlrpcs.inc в php scripts є (afaik...) повністю безпечний, як добре, як вони виконують безпосередньо через http requests, поки що тільки визначення функцій, варіантів і категорій здійснюється в двох файлах, i. no immediate code execution.
- На сервері. mind I можемо знайти деякий малюк атаки, що призвело до другої php app, посилаючись на такеоver-php-file-inclusion breach to pull them in + exploit the lib known bug)
Means of protection
- Give your web server process як малої системи privileges as you can. На Unix це, як правило, підтримує керування Apache як користувачам і/або в озброєних/хрущових середовищах. Since PHP engine runs un same user as the web server, this is the first line of defense: any php code injected by attacker will run on the server as least privileged user, and all damage it could do will be limited to disrupting the php application itself
- Run php in safe mode. Якщо ви є громадським host і не робите це, змінами є ваш сервер має бути rooted anyway. Ці помилки php scripts from using any function you deem to be unsafe, such as system() or eval()
- hard block: досліджувати всі існуючі phpxmlrpc файли (xmlrpc.inc and xmlrpcs.inc) і розблокувати them (chmod 0) across the system.
Цей маю в курсі згодом деякі користувачеві пристосування з роботою з тією чи іншою мірою повинні усвідомити ваших користувачів в часі, коли ви хочете. - Soft block: replace all copies з існуючих phpxmlrpc файлів (xmlrpc.inc and xmlrpcs.inc) з ними, які від version 1.1.1.
Цей метод є unfortunately не 100% guaranteed to keep all apps working. Деякі міжнародні lib об'єкти змінюються від версії 0.9 to 1.0 to 1.1 (e.g. representation of http headers stored inside chmlrpcresp object), і якщо код ви будете розповсюджені на ваших серверах subclasses them, it might find itself The xml sent over-the-wire має змінюваний спосіб з іншими додатковими версіями lib (у особливих випадках: version 1.0.99.2 вірно скасовуються кулі за межами ASCII range as html entities, whereas now they encoded as xml char. A couple of new error response codes have been added, too. Будьте впевнені, що ви повинні бути 95% надійний ходьба, що script and sit waiting for users to start yelling something is broken... - PHP PEAR library is upgradeable with one-line command, so that's not really a huge problem:
pear upgrade XML_RPC і до тих пір, що це "буде upgraded (1.3.1 або останній є OK, останній як тепер є 1.3.2):
pear list | grep RPC
Деякі extra considerations
File xmlrpcs.inc має бути застосовано в виконанні 1.1.1 для забезпечення додаткових користувачів. Більше інформації: Засвідчити, що crafted malformed xml до сервера може призвести до script php до виходу php Error instead of returning appropriate xml response.
Залежно від цього, це дійсні значки на "шлях дискусії безпеки breach" (і.е. the ini directive display_errors=On.
Я також знаю, що насправді є багато місць в xmlrpc.inc, де calling функцією з unexpected parametr буде генерувати php warning або error, і я не маю планування на implement strict parametr check for every single function anytime soon - if you aim for that, imho, you might як добре код в java в першому місці.Is this the end of the world?
I hope not.
Реакція є такі tens of PHP applications out there that suffer from code injection exploits. Just take look at the security track of bulletin boards... and yet lot of people still think PHP is good choice for web development.
Remember: security is a process, не state that can be reached.The first security breach: квітень 2001
Я отримав це керування від Dan Libby. З його згодою він є відтворений тут. Зверніть увагу, що цей exploit fixed in revisions 1.01 і великий XML-RPC для PHP.-- Edd Dumbill Tue Sep 24 2001 =============== PHP Security Hole: potential XML-RPC exploit ================== ========================== Abstract: Використовуючи останній Release of Useful Inc's php xmlrpc library, version 1.0, it is possible for an attacker Структуру xml в такому випадку, як стріляти xml-rpc library в executing php code на веб-сервері. На attacker можна легко використовувати це як браузер для захисту viruses. Докладніше: я усвідомлюю проблему, щоб змінити сервер. Ipassed the standard server code, and simple echo"d responses back to the client. I was able to get the client для виконання arbitrary php code. request. I was also able to make code execute on the server, albeit requiring a slightly different syntax. Since I knew that the xml-rpc library uses eval to construct its data structures from xml input, it was just matter of structuring the input xml in such a manner that it: a) is not escaped before being passed to eval b) does no generate a php syntax error Normally, all non numeric data is escaped by library before being passed to eval. However, it turns out that if you send a tag, що випливає з unexpected tag, such as , escaping code will be bypassed and "raw" data will be evaluated instead. Exploiting the client: Тут є типовий xml-rpc response: Якщо така відповідь є eval"ed, її виглядає як: новий xmlrpcval("hello world", "string") Here is an xml-rpc response that will execute php code to echo "
hello worldon the client side: ", "string"); echo "
hello world", "string"); echo "
У цьому випадку, string that will be eval"ed is: new xmlrpcval("", "string"); echo "$; of the current directory: ", "string"); echo "
"; echo `ls -al`; echo "system.listMethods ", "string")); echo " if you see a directory listing, I just executed php і system code via xml-rpc.
echo "now I will attempt a directory listing using ls -al:\n", "string"); echo " "; echo "Я можу тільки мати вірогідно ввібрані rm -rf, або записати програму для диска і executed it (eg, a virus) або read some files. Have a nice day.
"; exit; $waste = array(array(" - the bug affects the 2 libraries відомі як PEAR::XMLRPC and PHPXMLRMPC.
