Підтвердження того, що я повністю видалив злом WordPress?


105

Мій веселий блог WordPress на веб-сайті http://fakeplasticrock.com (запуск WordPress 3.1.1) зламався - він показував <iframe>на кожній сторінці так:

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 

Я зробив наступне

  1. Оновлено до 3.1.3 за допомогою вбудованої системи оновлення WordPress
  2. Встановлено сканер Exploit (багато критичних попереджень про незвичайні файли) та AntiVirus (це показало все зеленим та чистим, тому я видалив та видалив його після запуску)
  3. Змінено пароль MySQL.
  4. Змінено всі паролі користувачів WordPress.
  5. Підключено через FTP та завантажило всю файлову систему (не велика, це спільний хост для WordPress лише для Linux)
  6. Розмежували файлову систему на офіційному ZIP WordPress 3.1.3 та видаляли або переписували все, що не відповідало.

Я впевнений у цьому

  • всі файли на диску є офіційними файлами WordPress 3.1.3
  • на диску немає інших зайвих файлів, окрім мого /theme, плагін Exploit Scanner (який я тільки що завантажив), /uploadsпапка та невеличка купка інших очікуваних файлів. Мій інший плагін, wp-recaptcha, відповідає поточній завантаженій офіційній версії.
  • Я також перевірив .htaccessфайл і там нічого не виглядає неправильно

Wordpress 3.1.3 порівняння файлів у програмі "Більше порівняння"

Я не торкався бази даних , але я намагаюся думати, як щось у базі даних може бути шкідливим без спеціального коду PHP, щоб змусити його працювати?

Мій блог WordPress здається нормальним і без злому (я думаю), але чи варто ще щось перевірити?


1
Ви повинні постійно оновлювати блог. :)
fuxia

Відповіді:


80

Ви визначили вектор експлуатації? Якщо ні, то, можливо, ви залишаєте себе відкритими для майбутньої експлуатації.

Інші речі, які слід врахувати:

  1. Зміна паролів користувачів адміністратора WordPress - готово
  2. Змініть пароль користувача облікового запису хостингу
  3. Змінення паролів FTP
  4. Зміна пароля користувача MySQL db - готово
  5. Змініть префікс таблиці db
  6. Оновіть свої wp-config nonces / sol
  7. Перевірте дозволи для каталогу / файлів
  8. Блокуйте доступ до веб-каталогів через .htaccess
  9. Перегляньте все, що є у записі Hardening WordPress Codex
  10. Прогляньте все, що знаходиться у розділі FAQ на мій сайт був зламаний Codex

1
Вибачте, знехтував згадати - я змінив паролі WordPress. Оновлена ​​публікація та зареєстрована тут у списку! Я не можу придумати жодного способу, щоб у них був мій пароль хостингу або пароль FTP, просто потрапивши в WordPress; цієї інформації немає ніде у файловій системі чи в базі даних.
Джефф Етвуд

9
У вас є ймовірний вектор експлуатації; це не ймовірно WordPress -> обліковий запис хостингу , а скоріше обліковий запис хостингу (через сервер або FTP) -> WordPress .
Чіп Беннетт

2
@Jeff деякі експлуатують серверний рівень, ви не маєте контролю над ними (окрім пошуку кращого хоста). Але те, що ви не використовували облікові дані хоста / FTP, не означає, що хтось їх не вкрав , отримавши доступ до вашого облікового запису хостингу.
Чіп Беннетт

7
Існує дуже розповсюджений експлуатування раундів, коли зловмисне програмне забезпечення заражає вашу робочу станцію (або робочу станцію підрядника), викопує збережені паролі у вашій улюбленій програмі FTP (або FTP) і надсилає їх зловмиснику, який потім компрометує вашого веб-сайту та використовує його для поширення того ж зловмисного програмного забезпечення для інших веб-майстрів. Це один з поширених способів, коли ваш пароль FTP викрадається. Особливо підступним є те, що його поширення через звичайні сайти, як ваше, а не на насіннєвих, де ви, ймовірно, будете обережні.
tylerl

3
FYI, якщо у вас є доступ до командного рядка, WP-CLI має команду перевірки контрольних сум, яка перевірятиме кожен файл на wordpress.org
William Turrell

26

Переглядаючи повідомлення про "безпечний перегляд" Google Chrome, ви отримуєте ".cc iFrame hack", який, здається, останнім часом збирається багато. Я думаю, що 3.1.3 це виправить, але перевірте ваш файл index.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:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'
SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

Сподіваюся, це допомагає!


4
Я додам SELECT * FROM wp_* WHERE comment_content LIKE '%<?%'і SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%'просто, щоб бути впевненим ...
SeanJA

4
О, одна фінальна записка. Я припускаю, що у вас є інструменти для веб-майстрів Google, прив'язані до цього домену. Після того, як ви очистите речі, ви можете надіслати запит із свого облікового запису інструментів для веб-майстрів, щоб Google переробив сайт і видалив попередження. Вони обробляють запити з інструментів веб-майстрів, як правило, протягом дня. Інакше потрапляєш у "неслухняний список" на добрі 90 днів.
Діллі-О

Знайдено купу результатів, але це через вбудовані рамки для Vimeo.
tooshel

20

База даних також може містити шкідливий код: приховані облікові записи користувачів або значення, які друкуються кудись не відображено. Також перевірте свій каталог завантажень на наявність файлів, які там не належать.

О, і спробуйте зрозуміти, як зловмисник потрапив на ваш сайт. У спільних облікових записах це часто весь сервер. Перегляньте інші сайти на сервері на наявність зламаних блогів чи інших сторінок. Прочитайте свій FTP-журнал. Якщо ви не знаєте, як це сталося, ви не зможете запобігти наступній перерві.


Чи не знайде сканер Exploit знайдених прихованих облікових записів користувачів?
Джефф Етвуд

@Jeff Atwood Я б на це не покладався. Ваша таблиця користувачів не така вже й велика. Ви можете легко прочитати його без будь-якого плагіна.
fuxia

Я перевірив wp_usersтаблицю і лише 2 ряди, обидва очікували .. нічого в /uploadпапці незвичайне (лише gif-файли та pngs та jpegs)
Джефф Етвуд

@Jeff Atwood Ви заглядали у файли чи просто у розширення? Чи всі файли перераховані в медіатеці?
fuxia

4
Файли зображень є досить поширеним методом доставки корисної навантаження. Дивіться тут , і Команда з перегляду тем також наткнулась на Теми, використовуючи подібний подвиг TIFF.) Отже, так: я перевірив би кожну, щоб переконатися, що вона є частиною медіатеки. (Легке сканування високого рівня: перевірити наявність зображень, які не мають розмірів мініатюр.)
Chip Bennett

13

Вибачте, що вас зламали - схоже, ви зробили чудову роботу з відновлення!

Ваша файлова система звучить золотисто, я б не сказав, що ви можете щось тут зробити.

Я думаю, що Exploit Scanner видасть попередження, якщо у вашій базі даних знайдеться будь-які сценарії, рамки, PHP (хоч і небезпечні лише, якщо eval'd), або інший незвичний код.

Я не впевнений, що якщо він перевіряє таблиці, окрім публікацій та коментарів, можливо, варто перевірити їх /wp-admin/options.phpшвидкий погляд і побачити, чи помітили ви щось дивне.

Я також перевірив таблицю ваших користувачів у клієнті MySQL (користувачі можуть знаходитись у базі даних, але не помітні в адміністраторі).


безумовно, гарна ідея запустити запит на MySQL на таблиці користувачів, щоб переконатися, що нічого несподіваного немає, і я це зробив. Гарна порада!
Джефф Етвуд

8

Перевірте два інструменти для веб-майстрів Google:

  • переконайтеся, що ваш сайт не позначений як порушений, і вимагайте його повторного розгляду, якщо він є
  • перевірте свій сайт як Googlebot і переконайтеся, що в ньому не вставлено спам, який видно лише Googlebot - приклад цього - хак WP Pharma

Крім того, я б знову реалізував тему або перевірив її надзвичайно ретельно. Кілька рядків PHP можуть переосмислити основні функції PHP, щоб вони витягували шкідливий код із бази даних, особливо таблиці wp_options key / value store


так, я безумовно повторно подав сайт через Google Webmaster Tools, і зараз він видається "очищеним".
Джефф Етвуд

6

Шукайте в базі даних через phpmyadmin "iframe" або скидайте в базу даних та шукайте текст.

І перевірити наявність невидимих ​​користувачів у таблиці користувачів; Я бачив користувачів у таблицях, які не відображалися в WP Admin >> Users.

Очистити параметри «Плагіни WordPress покажуть, що небажана інформація зі старих та, можливо, вразливих плагінів залишилася в базі даних.

У вашій темі також відсутній <head>тег, тому я перевірю, чи ви редагували тему, щоб видалити погані посилання.

І звичайне: і як знайти заднім куточком у зламаному WordPress та загартуванні WordPress «WordPress Codex


5

"чи ще щось я повинен перевірити?" Вам потрібно вивчити свій процес і з’ясувати, як вас зламали (майже напевно, тому що ви не встигли виправити своєчасно чи правильно) і виправити це, а не лише симптоми.


5
Я сумніваюсь, це стосувалося не оновлення WordPress (хоча це можливо , це просто не можливо ). Сам WordPress майже ніколи не є вектором експлуатації. Звичайні вектори - це незахищена конфігурація хоста та викрадені облікові дані FTP.
Чіп Беннетт

4

Що трапилося зі мною один раз, через витік на медіапроб. Мені довелося написати плагін, щоб перевірити базу даних на наявність введених посилань. Ви можете схопити це тут як суть гітбуба .

Це досить зручно для користувачів, має кілька кроків, які надають зворотній зв'язок і повторно перевіряють вашу базу даних після закінчення.

Удачі!


4

У мене був дуже схожий злом, який я мав виправити на одному зі своїх клієнтських сайтів.

У файловій системі були шкідливі скрипти (php base64_decode речі). Однак таблиці "повідомлення" та "коментарі" бази даних були порушені, і iframe-код також розпорошився по цих даних.

Я хоч би здійснив кілька пошукових запитів у БД, просто щоб бути безпечним. :)


3

Перевірте свої плагіни !, поки що цього року було 60 випусків експлуатування з .org плагінів, я б підозрював, що реальна кількість набагато вище, оскільки ніхто не справді займається цим повним робочим часом.

Ви перерахували, що у вас є тільки один плагін, добре, що він мав отвір для безпеки (не впевнений, як довго він був, і він може бути не вектором).

wp-recaptcha-plugin
Експлоатація випущена: 2011-03-18
Версія Exploit: 2.9.8

Автор заявив, що переписав версію 3.0, але про патч безпеки не згадується.

http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

Журнал змін: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/


2

Я використовую хмарний сервер, і випадкові норовисті номери портів ssh взагалі не мають ftp. Паролі зламати надзвичайно важко. Увесь кореневий доступ повністю заборонено. Я погоджуюся, що WordPress не стане вашим винуватцем. Інша річ, на яку слід перевірити, чи не закриваються сеанси ftp, вірус на персональний комп'ютер (пам’ятайте, що ви можете завантажити файл на свій сайт і хто коли-небудь завантажує цей файл, може отримати той самий вірус), також не зберігайте ваші паролі на загальнодоступних сайтах або приватних сайти завжди виправляють їх на папері, ніколи, ні на текстовому документі, ні на блокноті.

Нарешті, запитайте свого хоста, чи недавно вони мали порушення, оскільки вони повинні мати налаштування брандмауера


2

Перевірте дату файлів. У жодному файлі не повинно бути даних про зміни, новіших від останнього редагування / встановлення!

Але також це можна підробити. Найновішим способом бути впевненим буде порівняння (наприклад, хеш-порівняння) всіх файлів з оригінальними інсталяційними файлами.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.