// codeart.ru / Статьи / DDOS с помощью Pingback-ов на блогах WordPress

DDOS с помощью Pingback-ов на блогах WordPress

Автор: Evgeny Sergeev

Эта статья - моя попытка рассказать в интересной форме о проблеме DDOS атак, которые могут быть организованы на блоги под управлением известного движка - WordPress. На сколько мне это удалось судить, безусловно, вам.

После того как хостер, у которого я обслуживался ранее, ненавязчиво дал понять, что мой блог кушает слишком много ресурсов, я занялся исследованием исходников WordPress-а (WP). Уж очень хотелось разобраться, куда пропадают бесценные процессорные такты.

Долгое время ничего дельного найти не удавалось. Нет. Конечно, были места, которые вызывали большие сомнения относительно их целесообразности. Например, очень не понравился механизм, отвечающий за локализацию WordPress-а. Но об этом я расскажу как-нибудь в другой раз. В целом же при низкой посещаемости блога ( а именно такая наблюдается большую часть суток на моем сайте ) никаких проблем быть не должно. Да и логи говорили о том, что проблемы были связаны именно с количеством одновременных обращений, а не с качеством исходного кода.

Вероятно, на этом месте можно было бы остановиться и не тратить бесценное свободное время на поиски слабых мест. Но почему-то я решил продолжить. И мое упрямство было вознаграждено. Глянув, на код, отвечающий за обработку удаленных процедур (RPC), в частности на реализацию механизма Pingback-ов - я сразу понял, что код далеко не так надежен, как мне того хотелось бы.

Проведя несколько поверхностных тестов и несколько раз, положив свою машину в глубокий даун - я понял: обратные пинги могут изрядно подпортить жизнь мне и моему сайту. Если в ближайшее время в этом отношении ничего не поменяется, то любой школьник сможет организовать DDOS атаку на мой блог, не прилагая для этого особых усилий.

Правда, у меня есть слабая надежда, что мои познания в области DDOS атак не так глубоки и те тесты, которые я легко провожу локально на своей машине и которые нарушают нормальную работу моего блога, не будут работать в глобальной сети, в виду технических ограничений, накладываемых маршрутизаторами и другим сетевым оборудованием. Поэтому давайте попытаемся разобраться в этом вопросе совместно (комментарии - оружие и верный помощник для вас).

Итак, Pingback - это один из трех Linkback методов, призванный упростить процесс обмена ссылками между двумя блогами. Согласитесь, справедливо рассчитывать на благодарность в виде обратной ссылки, если ставишь ссылку сам?

Но здесь есть один скользкий момент - на сколько я знаю, самая последняя спецификация на pingback датируется 2002 годом и имеет версию 1.0. Получается, с тех пор ничего нового в этом направлении не делалось, и сам факт такой низкой активности может свидетельствовать о ненужности, а, следовательно, и слабой проработке данного механизма.

В той же спецификации дается пять основных определений, которые просто необходимо знать, для того, чтобы далее мы с вами разговаривали на одном языке (прошу прощение за английский вариант, надеюсь, у вас не возникнет проблем с переводом):

source URI
The address of the entry on the site containing the link.
pingback client
The software that establishes the connection to inform the server about the link from the source to the target. Typically, the source will be the client.
pingback-enabled resource
A document, image or other resource that advertises a pingback server using a pingback HTTP header or a pingback link element.
pingback server
The software that accepts XML-RPC connections. Typically, the target URI will be associated with the server (e.g. on the same host).
pingback user agent
A single system, which is both a pingback client and a pingback server.
target URI
The target of the link on the source site. This SHOULD be a pingback-enabled page.

При рассылке pingback-ов WordPress выступает в качестве pingback клиента , а когда принимает запросы от других сайтов в интернете -pingback сервера. За каждую из двух ролей отвечает различный код и порядок действий, естественно, немного разный. Ранее я говорил о уязвимостях именно в реализации сервера.

Чтобы разобраться, как WP работает в режиме pingback сервера, давайте посмотрим файл: xmlrpc.php, в котором и реализована вся логика. На самом деле, данный файл служит не только для обработки Pingback запросов, но и для обслуживания других удаленных процедур. Из всех функций нас интересует только одна - pingback_ping. Вот упрощенный алгоритм ее работы:

1. Получаем параметры запроса (source URI, target URI );
2. Проверяем source URI указывает на наш блог или нет (здесь и далее в случае неверного ответа работа алгоритма прерывается и выдается ошибка);
3. Находим пост по source URI и проверяем на равенство source URI и target URI (очевидно, что pingback не должен идти сам на себя);
4. Проверяем, не зарегистрирован ли пинг с Target URI на Source URI (если ранее такой pingback уже был, то дальнейшие проверки не проводятся);
5. Загружаем страницу по Target URI (если не можем загрузить, то выдаем ошибку);
6. Ищем, тег <title> (или выдаем ошибку о его отсутствии );
7. Проверяем, есть на странице расположенной по адресу source URI ссылка на Target URI;
8. Создаем комментарий и сохраняем его в БД.

В случае, если мы попробуем сделать два pingback-а на одну и ту же страницу - ничего страшного не произойдет. В системе будет учтен только первый из них, а последующие будут отбиваться на 4-ом шаге алгоритма.

А, что будет происходить, если вместо корректного target URI будет получен URL произвольной страницы? Тогда алгоритм дойдет до 7-го шага и потом выдаст ошибку об отсутствии ссылки на наш блог. Но(!) информация о том, что этот адрес фиктивный нигде не будет учтена, а это значит, что при повторном обращении алгоритм будет так же работать до 7-го шага. А при нескольких параллельных запросах? А если страница, на которую указывает Target URI будет с медленного хостинга? На мой взгляд, при таком раскладе будут создаваться все новые и новые соединения, до тех пор, пока не израсходуются все ресурсы сервера (на локально машине у меня именно так и происходит).

С другой стороны, можно ли избежать подобной ситуации? По большому счету 100% защиты нет. Мне на ум приходят следующие варианты:
1. черный список доменов, на которые сделано больше N неудачных попыток;
2. черный список IP адресов pingback клиентов, с которых сделано больше N числа некорректных запросов;
3. ограничение на количество обрабатываемых pingback запросов.

Использование даже одного из трех методов поможет снизить нагрузку на сервер за счет отбраковывания заведомо ложных запросов. Это лучше чем дать возможность бесконтрольно сжирать ресурсы!

Есть и другая уязвимость в описанном алгоритме. Все дело в том, что даже если мы ограничим использование ресурсов нашего блога, то все равно останется возможность отправить огромное количество pingback запросов на тысячи WordPress блогов указав в качестве Target URI - адрес жертвы. В результате такого действия, все блоги одновременно попытаются запросить страницу, чтобы определить проставлена ли на них ссылка и тем самым организуют классическую DDOS атаку.

При такой атаке, даже если ресурс-жертва заблокирует часть IP адресов, с которых идет большое количество GET запросов (в том числе и публичные прокси) всегда можно будет направить новые порции запросов с ресурсов которые себя никак не скомпрометировали. Не мне вам говорить, на сколько велико количество установленных WordPress блогов.

При такой атаке так же может помочь первый пункт из списка выше. Блоги просто не будут посылать более N запросов на один и тот же домен. А значит, количество блогов для реализации полномасштабной DDOS атаки должно будет увеличиться многократно.

Конечно есть и другие слабые места, которые любой человек с нечистой совестью может использовать в своих грязных целях. Но две уязвимости указанные выше, на мой взгляд, наиболее опасны. Поэтому, на этой веселой ноте я хочу закончить свое повествование и узнать, что думаете Вы.

P.S. Если интересно, могу так же рассказать, как можно использовать Pingback-и для автоматической раскрутки блога.

    Лучшие комментарии

  1. Да уж, и правда, код-убийца. Видимо прийдется взять слова насчет твоего старого хостинга обратно. Похоже положить этим способом блог можно легко.

    Выглядит так как-будто туда не заглядывыли пару лет.

    // FIXME: does url_to_postid() cover all these cases already?

    Еще ведь можно в качестве source_url передать ссылку на какой-нибудь огроменный файл.

    Проблема похоже будет решена в 2.5. Вроде как там можно ставить хук на эту функцию в начале
    (http://trac.wordpress.org/browser/trunk/xmlrpc.php?rev=6815#L2167)
    и в конце (что есть и сейчас, только при атаке этот хук никогда не обработается). Т.е. если айпишник чаще входит в функцию чем выходит - убивать сразу.

  2. Еще небольшой баг нашел. Мелочь.

    url_to_postid() без mod_rewrite не проверяет домен. Так что если не ошибаюсь - с блога не используеющего mod_rewrite невозможно поставить пингбэк на запись с таким же id на другом блоге.

  1. “P.S. Если интересно, могу так же рассказать, как можно использовать Pingback-и для автоматической раскрутки блога.”

    Пишите пожалуйста. Отличный блог, читаю уже с месяц.
    По поводу статьи: я не сильно разбираюсь в WP и ддосе, но думал что последнее - это посылка огромного кол-ва пакетов (флуд) на машину. Таким образом вся машину уходит в даун, а не блог.
    Я в этом деле новичок, так что буду рад если поправите.

  2. Да, и обидно что не работает кнопка pdf, раньше пахала. Может это после Ваших эксперементов с ддосом?) (http://www.codeart.ru/wp-content/plugins/post2pdf/generate.php?post=430)

  3. Да уж, и правда, код-убийца. Видимо прийдется взять слова насчет твоего старого хостинга обратно. Похоже положить этим способом блог можно легко.

    Выглядит так как-будто туда не заглядывыли пару лет.

    // FIXME: does url_to_postid() cover all these cases already?

    Еще ведь можно в качестве source_url передать ссылку на какой-нибудь огроменный файл.

    Проблема похоже будет решена в 2.5. Вроде как там можно ставить хук на эту функцию в начале
    (http://trac.wordpress.org/browser/trunk/xmlrpc.php?rev=6815#L2167)
    и в конце (что есть и сейчас, только при атаке этот хук никогда не обработается). Т.е. если айпишник чаще входит в функцию чем выходит - убивать сразу.

  4. Еще небольшой баг нашел. Мелочь.

    url_to_postid() без mod_rewrite не проверяет домен. Так что если не ошибаюсь - с блога не используеющего mod_rewrite невозможно поставить пингбэк на запись с таким же id на другом блоге.

  5. Если интересно, могу так же рассказать, как можно использовать Pingback-и для автоматической раскрутки блога

    Конечно интересно.

    Кстати, о проблеме поедания ресурсов намекает не один хостинг. Уже слышал от многих и на себе испытал.

    Решение проблемы (оптимальное), как я понимаю, только в одном — отключить пигни и трэкбеки. Однако это не лучшее решиние (так как функций этих хочется).

    Из решений предложенных вами оптимальным я считаю ограничение на количество обрабатываемых pingback запросов.

    Кстати, вы разработчикам Wordpress об этой не писали?

  6. Delchyve, разработчикам Wordpress я не писал. Думаете нужно?

  7. А почему бы нет.
    Конечно не исключено, что о проблеме они знают (ведь многие баги качуют от версии к версии), но почему бы им не напомнить, что WordPress делается для людей :)

  8. P.S. Если интересно, могу так же рассказать, как можно использовать Pingback-и для автоматической раскрутки блога.

    Ну собсно говносеошники и пытаются с тебя поиметь обратные ссылки.
    Имеет смысл тупо отключить этот механизм и не морочиться.
    :)

  9. Спасибо за статью!..

    Второй абзац: “я занялся исследованием исподников”

    P.S. Если интересно, могу так же рассказать, как можно использовать Pingback-и для автоматической раскрутки блога.

    Обязательно расскажите! Уже подписался на RSS ;)

  10. Жень, 5+ за исследование!

  11. ага, вот оно то и есть!
    я то сидел думал, где они дырку в блоге нашли…))
    комментарии думал, а тут вот пинги)

  12. Кажется, вы всем ШКОЛЬНИКАМ рассказали сейчас как убивать сайты на WP.
    За что вам большое “СПАСИБО”

  13. Серега, а кто мешает сделать соответствующие фиксы?

  14. “Кажется, вы всем ШКОЛЬНИКАМ рассказали сейчас как убивать сайты на WP.
    За что вам большое “СПАСИБО” ”

    блин, вы дейтвительно думаете, что школьники читают этот блог??))

    а хакер.ру - зачем?! там было полно материала по вордпрессу, очень разной ;)

  15. Нда… надеюсь какие нить “программеры” с высоким самомнением ничо не напишут для реалиции таких атак.. а то скоро не надо будет компы вырусами заражать.. а только списки блогов в разных странах собирать… класический ddos получаеться… весело бы было если бы не все так грустно…

  16. >> Если в ближайшее время в этом отношении ничего не поменяется, то любой школьник сможет организовать DDOS атаку на мой блог, не прилагая для этого особых усилий.

    Не уверен. Да, алгоритм работы не оптимален, но с другой стороны создаваемая нагрузка сравнима с нагрузкой при публикации комментария, такчто у pingback здесь нет особого недостатка. У одного школьника интернета нехватит чтобы создать такую нагрузку.

    Собираюсь реализовать pingback/trackback в phpblosxom, есть над чем задуматься.

  17. Захотят нагадить - нагадят тем или иным способом, а где уж найдут информацию и подручные средства для этого - это уже на так важно.

  18. Интересная статья - не подумал бы, что с ВП могут возникнуть такие заморочки…

Leave a Reply

« Sony PSP - моя новая игрушка Знания, опыт, деньги. »

 

недорогой хостинг - AvaHost.Ru | свадебные цветы свадьба http://svadba-msk.ru | ваз купить официальный дилер Центральный округ