Массовый взлом WordPress. Вопросы и ответы

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

Что тут можно сказать? Истерика она и в Африке истерика. Мы попытались собрать наиболее важные вопросы в связи с ситуацией и спокойно ответить на них.

Вордпрессеры, пожалуйста, поделитесь ссылкой на этот пост со всеми, кому это может быть полезно.

Замечания по существу и поправки принимаются.

---

Вопрос: Везде говорят об опасной уязвимости WordPress. Каких версий это касается?

Ответ: Это каcается всех версий по 2.8.3 включительно в связи с одной активно обсуждаемой уязвимостью и версий от 2.2.3 до 2.8.2 в связи со второй (более опасной).

Вопрос: Ужас какой! Так их две?!!

Ответ: На самом деле их намного больше, да и эти две «знающие люди» используют никак не меньше года. Никто в результате пока не умер, так что паниковать не следует. Наоборот можно даже порадоваться: раз WordPress массово «ломают», значит, он очень популярен и широко распространен.

Первая уязвимость, о которой сейчас шумят, позволяет, обратившись с определенным параметром к скрипту wp-login.php, сбросить административный пароль. Ничего особо страшного не происходит, поскольку новый пароль высылается не злоумышленнику, а на почтовый ящик администратора. Хотя ничего приятного в этом тоже нет.

Вторая «дыра» опаснее. Злоумышленник (через сетевого червя) регистрируется на сайте как обычный пользователь, затем, эксплуатируя уязвимость, повышает свои полномочия до административных и начинает безобразничать. Все это делается не просто так: злоумышленники получают доступ к старым записям блога и публикуют в них вредоносный контент, как правило, скрытый.

Вопрос: Как узнать, взломан мой блог или нет?

Ответ:

1. Загляните в файл .htaccess, который находится в корневой директории вашего сайта. Если вы сами его не редактировали, он должен выглядеть так:

[php]# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress[/php]

Эти строки нужны для того, чтобы в вашем блоге работали «Постоянные ссылки» (они же ЧПУ или человекопонятные URL).

Если зловред внес какие-то изменения, вы это сразу заметите. Примеры подозрительных записей вы найдете здесь.

2. В списке пользователей («Панель управления» — «Пользователи») такие лжеадминистраторы не отображаются, однако их можно обнаружить, обратившись непосредственно к базе данных. Например, зайдите в phpMyAdmin, перейдите к нужной базе и кликните по вкладке SQL. В появившемся окне введите следующий запрос:

[php]SELECT u.ID, u.user_login
FROM wp_users u, wp_usermeta um
WHERE u.ID = um.user_id
AND um.meta_key = 'wp_capabilities'
AND um.meta_value LIKE '%administrator%';[/php]

...и нажмите OK. Вам будет выведен список администраторов. Лишних можно удалить нажатием соответствующей иконки.

Вопрос: И как лечиться?

Ответ:

1. Верните файл .htaccess к первоначальному виду (см. предыдущий вопрос).

2. Свой код в .htaccess мог добавить плагин WP Super Cache. Если сомневаетесь, легитимен ли код, который вы видите, можно удалить все подозрительные строчки, а затем прописать правильные нажатием кнопки в настройках плагина.

3. Перейдите в «Панель управления» — «Настройки» — «Постоянные ссылки». Если вместо ваших настроек стоят какие-то другие — верните к первоначальному виду.

3. Удалите лишних администраторов из базы (см. предыдущий вопрос). Здесь предлагается еще один способ, как это сделать.

4. Проверьте, нет ли невидимого контента в ваших старых записях. Зайдите в phpMyAdmin, выберите нужную базу и снова перейдите на вкладку SQL. Наберите:

[php]SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'[/php]

Если будет выведен не пустой результат, то записи с выведенными номерами нужно будет проверить и при необходимости исправить через встроенный в WordPress редактор (окно редактирования переключите с визуального редактирования на html).

Вызвать нужные записи для просмотра и редактирования можно так:

[php]http://ваш-домен.ru/wp-admin/post.php?action=edit&post=XXXX[/php]

...где XXXX — номер записи.

Некоторые программы-клиенты для блоггинга (например, Windows Live Writer) могут добавлять код типа img style="display". Он не является вредоносным.

Вопрос: Если у меня запрещена регистрация, мне нечего бояться?

Ответ: Как уверяют некоторые пользователи, признаки взлома наблюдались и у тех, кто вообще запретил регистрацию. Мы не можем ни подтвердить, ни опровергнуть эти заявления. Но для дополнительной защиты не повредит закрыть доступ к папке /wp-admin на уровне сервера (см. ниже).

Вопрос: Я вычистил весь мусор/У меня ничего и не было. Стоит ли мне обновляться на WordPress с 2.7.1 на 2.8.4?

Ответ: Да, стоит. В свежей версии устранены обе упомянутые уязвимости и улучшен административный интерфейс.

Однако, увы, не во всех случаях апгрейд полезен. В частности, проведенное нами тестирование показало, что на одном и том же сервере при прочих равных условиях одна и та же страница блога с новой версией движка может генерироваться в среднем от двух до десяти раз дольше (примеры конкретных цифр с нашего VPS: 1,9 секунды против 0,456 на главной странице и 0,356 секунды против 0,045 на странице одиночной записи).

Также вряд ли можно советовать апгрейдиться тем, кто держит свои сайты на российском виртуальном хостинге. В этом году некоторые, в том числе, крупные и раскрученные хостеры, начали активную борьбу за снижение нагрузки на сервера (читай — решили втиснуть больше пользователей на сервер, потеснив в правах остальных). Меры воздействия широко применялись хостерами даже к тем, кто пользовался WordPress 2.7.1. Так, провайдер «Мастерхост» на одном из наших сайтов выдавал предупреждения всего лишь при посещении админки: даже простая операция смены темы оформления блога вызывала превышение допустимой нагрузки на процессор до семи раз. А это была «легонькая» (по сравнению с текущей) версия движка.

Вопрос: Так что же, если у меня виртуальный хостинг, обновляться не стоит?

Ответ: Почему же, могут быть исключения. Способность или неспособность сервера справиться со скриптами WordPress без превышения допустимого уровня нагрузки зависит от мощности оборудования и от грамотного конфигурирования серверного ПО. Само собой разумеется, не у всех провайдерских админов руки растут из нужного места и не у всех есть желание регулярно обновлять «железо». Как обстоят дела у вашего провайдера — вам должно быть виднее.

Попробуйте. Не понравится — сможете безболезненно «откатиться» на прежнюю версию. Мы это делали и никаких проблем не возникло.

Вопрос: Я боюсь обновляться, потому что меня забанит хостер за нагрузки. И что теперь, оставаться с уязвимостями?

Ответ: Есть хорошая новость. Обе этих уязвимости, судя по всему, лечатся просто, и больших изменений не требуется.

1. Для исправления уязвимости со сбросом админ-пароля следует пропатчить файл wp-login.php (скачать патч от одного из разработчиков), находящийся в корневой директории WordPress 2.7.1

2. Для исправления уязвимости с повышением прав необходимо в файл /wp-includes/vars.php после строки

[php]$pagenow = $self_matches[1];[/php]

...добавить следующее выражение:

[php]$pagenow = trim ($pagenow, '/');[/php]

(Источник.)

3. Дополнительная мера безопасности: если в вашем блоге не требуется регистрация пользователей, вы можете запаролить папку wp-admin, чтобы туда вообще не могли зайти посторонние.

Вопрос: Как запаролить папку?

Ответ: Для веб-сервера Apache инструкция будет выглядеть так:

1. Создайте (если его там еще нет) файл .htaccess в требуемой папке. Впишите туда:

[php]AuthName «Restricted»
AuthType Basic
AuthUserFile /путь_к_файлу_с_логином_и_паролем/passwd.file
require user имя_пользователя[/php]

2. Скачайте утилиту htpasswd.exe (если опасаетесь скачивать с подозрительных сайтов, вы найдете ее в архиве с веб-сервером Apache для Windows) и запустите ее в командной строке. Для этого перейдите в папку, со скачанной утилитой и наберите:

[php]htpasswd -c passwd.file username[/php]

...где username — желаемое имя пользователя. Утилита дважды попросит ввести пароль для указанного пользователя и создаст файл passwd.file с зашифрованным паролем.

3. Разместите файл там, куда вы указали путь в пункте 1. Желательно, чтобы это была папка, к которой нет доступа у пользователей Интернета.

Если вместо Apache на вашем сервере используется связка Nginx+FastCGI:

1. В конфигурации сервера впишите дополнительный location (или попросите это сделать администратора):

[php]location ~* ^/wp-admin/(?:$|.+/$|.+\.php$) {
auth_basic «Restricted»;
auth_basic_user_file /etc/nginx/passwd.file; # Путь может быть и другим, если вам удобнее
fastcgi_index index.php;
fastcgi_pass localhost:53217;
fastcgi_param SCRIPT_FILENAME /путь/к/корневой/директории/вордпресса$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}[/php]

2. Файл passwd.file можно создать тем же способом, что и указано выше. Обратите внимание, что Windows-утилита htpasswd по умолчанию кодирует файл иначе, чем та же утилита под Linux. Для Nginx надо использовать линуксовый вариант (шифрование crypt).

3. Перезапустите Nginx.

Ссылки по теме

• Уязвимость WordPress, патчи для 2.8.3 и 2.7.1
• Шутка дня
• Цывилезадция