- Зміст статті WordPress - одна з найпопулярніших CMS, давно виросла з звичайного блогового движка...
- Перші кроки
- Права доступу
- Продовження доступно тільки учасникам
- Варіант 2. Відкрий один матеріал
Зміст статті
WordPress - одна з найпопулярніших CMS, давно виросла з звичайного блогового движка в конструктор, що дозволяє створити веб-ресурс практично будь-якого призначення. На ньому працюють інтернет-магазини, форуми, каталоги, веб-хостинги, сайти підтримки користувачів і багато іншого. У той же час популярність має і зворотну сторону: сайт на WP атакують постійно, і якщо тебе ще не зламали, то тільки тому, що просто ще не знайшли серед мільйонів інших подібних ресурсів.
тривожний сигнал
Незважаючи на те що WordPress розвивається вже досить давно і код весь час аналізується, уразливості в движку знаходять постійно, і можна припустити, що продовжать знаходити і в майбутньому. Потрібно віддати належне розробникам: вони оперативно реагують на всі повідомлення і усувають проблеми, а простота оновлення дозволяє адміністраторам легко убезпечити свій ресурс. Хоча аналіз показує, що далеко не всі поспішають оновлюватися. Але ось основні проблеми безпеки WP не в самому двигуні. Сьогодні є велика кількість тем і плагінів, які пишуться програмістами різного рівня і нерідко містять уразливості. Деякі теми і плагіни поширюються через сумнівні сайти і вже з самого початку можуть містити бекдори. Додамо сюди некоректні налаштування сайту, невірні права і використання облікових записів за замовчуванням, що дозволяють атакуючому спокійно підбирати паролі, - і без додаткових заходів захисту сайт на WP приречений.
Отже, маємо кілька сайтів на WP різного призначення, розміщених в VDS. Стандартна зв'язка PHP5 + Apache 2 + MySQL. ОС Ubuntu 14.04.3 LTS. Також були встановлені панель управління хостингом Vesta Control Panel і phpMyAdmin. Останнім, втім, ніхто не користувався, і, по-моєму, про його існування навіть не знали, хоча журнали показали, що і те і інше теж намагалися зламати. На момент атаки движок блогу, активні плагіни і Vesta були оновлені до актуального стану. Використовувані теми в більшості взяті з безкоштовного каталогу і підігнані під свої умови. Бекап SQL робився щотижня, бекап файлів - дуже давно. Все це працювало до пори до часу.
Перший сигнал надійшов від MySQL. VDS, до цього не сильно навантажений, перестав тягнути. В результаті сервер баз даних просто відвалився, а разом з ним і припинили відповідати сайти. При цьому кількість відвідувачів на лічильнику вписувалося в стандартну відвідуваність. Перезапуск відновив роботу, але навантаження, показана htop, була дуже високою.
Наступний сигнал надійшов від пошукових систем. Причому повідомлення і, очевидно, алгоритми роботи у Яндекса і Google відрізняються і по-різному корисні. Яндекс повідомив, що на сайті виявлений шкідливий контент, в панелі веб-майстра сайт був позначений відповідним значком, зазначений передбачуваний тип (троян JS), і в пошуку виводилася інформація про те, що ресурс може нашкодити. Відразу скажу, що код, який дратував Яндекс, був знайдений в файлі заголовків майже всіх тем в файлі header.php, і після того, як він був прибраний, всі сайти протягом одного-трьох днів були визнані чистими. Хоча в цей час битва ще тривала.
Google надіслав повідомлення через шість годин після Яндекса, але зазначив, що на сайті виявлений «зламаний контент», в панелі можна було переглянути список підозрілих файлів (на момент отримання листа більшість було знайдено і вилучено). Інформація сама по собі цікава, так як в ній зазначені нові файли, залишені хакером, на які немає прямих посилань на сайті. Такі файли, швидше за все, однозначно потрібно буде видаляти. Гугл в повідомленні пропонує посилання на «Інструмент для відновлення зламаних сайтів», що дозволяє переглянути, як виглядає сайт, і рекомендації . Після видалення файлів необхідно вручну відправити на повторну перевірку ті сайти, у яких при використанні site: в рядку пошуку показує «Можливо, цей сайт був зламаний». Пізніше Гугл прибрав позначку про небезпеку частини сайтів і почав видавати повідомлення про те, що на сайтах з'явилася велика кількість помилок. Проблема 404 виникла або через некоректно впровадженого коду, коли частина URL не працювала, або через те, що код посилався на шкідливий файл, який вже був знайдений і вилучений.
Забігаючи вперед, скажу про результат. Атака йшла з декількох IP і масовано почалася за три дні до злому. Виявилася велика кількість зайвих файлів з розширенням php, які були розкидані по всіх каталогах, плюс каталог gopni3d з купою HTML-файлів всередині. Тут і шелл, і бекдор-завантажувач, і дор, і розсильників спаму. Запроваджено PHP- і JS-код в тему header.php і деякі файли WP, включаючи wp-config.php. Змінено файл .htaccess. У WP з'явилися дві додаткові облікові записи з правами адміністратора. Каталог SMTP-сервера / var / spool / exim4 / input був завалений великою кількістю спам-листів.
Тепер розберемо, як це все знайти, витративши мінімальні зусилля і маючи мінімум знань. Подальші кроки зрозумілі: знайти чужий код, зрозуміти дії хакера, усунути уразливості або знизити їх кількість, утруднити подальші атаки. Все це потрібно буде робити швидко і паралельно.
Код, залишений хакером
Перші кроки
Можна відключити сайт, зупинивши веб-сервер або перевівши WP в режим обслуговування, але ми поки не знаємо, що шукати. Якщо відключити неможливо, то на цьому етапі можна заборонити реєстрацію нових користувачів і коментарі, змінити паролі адміністратора WP і паролі до СУБД. При наявності свіжого бекапа можемо відновити сайт, потім перейти до аналізу і зайнятися локалізацією проблем і посиленням захисту. Інакше доведеться чистити файли вручну. Як мінімум можна відразу замінити файли WP новими з архіву, видаливши попередньо старі файли і каталоги (крім, природно, каталогів тим, плагінів і upload). Далі оновлюємо (якщо не зробили це раніше) движок, тему і плагіни. Неактивні теми і плагіни беззастережно видаляємо. Перевіряємо самі плагіни. Хакер деякі просто відключає, змінивши назву каталогу (додавши знак підкреслення в початок). Перевіряємо коректність файлів .htaccess, їх вміст хакер може просто обнулити. Якщо файл .htaccess був неправильно налаштований, то до файлів сайту можна отримати доступ з пошукача: site: example.org inurl: / wp-admin /. Перейменують тему, деякі атаки йдуть пакетом, коли просто підбираються уразливості до популярних тем. Перейменувавши тему, ми змінимо URL, а значить, така атака її мине. Якщо до цих пір не використовувалася капча, то став будь-який вподобаний плагін. Це знизить ймовірність брутфорса. Деякі до того ж надають додаткові можливості: блокування IP в разі неправильного введення кілька разів, обмеження за часом введення, білий список. Перевіряти на зараженість можна як зсередини за допомогою інструментів, доступних в ОС, так і через зовнішні сервіси. Запускаємо антивірусну перевірку.
$ Sudo clamscan -i -r / var / www /var/www/wp-content/plugins/akismet/_inc/img/sidebar-widescreen.php.suspected: Php.Malware.Agent-1426825 FOUND
Крім антивіруса, можна прогнати ще сканер Linux Malware Detect і скрипт AI-Bolit . Але чи знайдуть вони не всі.
Перші дані від зовнішніх сервісів вже є. Гугл видав підказку, просто шукаємо файли, перевіряємо, чи дійсно вони шкідливі, і видаляємо. Для подальшого пошуку зберігаємо невеликий специфічний текст, який будемо використовувати в якості сигнатури. Аналіз самого коду дозволить отримати IP, URL та інші специфічні параметри, їх будемо шукати в логах і блокувати за допомогою брандмауера.
У Мережі є безліч ресурсів, які перевіряють, чи безпечні сайти. Не всі вони корисні. Деякі, наприклад, просто отримують дані про шкідливість від API Яндекса і Гугла. послугу перевірки URL пропонують і виробники антивірусів. Наприклад, сканер від Dr.Web перевіряє сторінки та аналізує, чи є редирект на інші сайти. На жаль, крім того, що сайт заражений, і типу вірусу, більше ніякої корисної інформації він не дав. ресурс 2ip.ru показав, що на сайті виявлені iframe-вставки. На жаль, для повторної перевірки він непотрібний, оскільки, очевидно, запам'ятовує результат і повідомляє, що сайт заражений, коли всі інші вже вважають його безпечним.
Найбільшу користь у пошуку приніс онлайн-сканер SiteGuarding.com , Спеціально розроблений для пошуку специфічних шкідливих програм. У звіті були не тільки показані проблемні посилання, але і дана конкретика, що дозволяє в подальшому знайти цей код в файлах за допомогою grep. Проект пропонує і свій плагін WP Antivirus Site Protection , Доступний з каталогу плагінів WP. У безкоштовної версії він сканує файли, перевіряючи їх на наявність небезпечного коду, і видає звіт по виявленим malware і файлів, здався підозрілим евристичному аналізатору. Правда, термін дії котрої не стовідсотково проблема, але це вже щось. Число сканувань обмежена, але цього достатньо, щоб вирішити проблеми і деякий час контролювати ситуацію.
Звіт плагіна про виявлений malware
Отриману на SiteGuarding.com інформацію про код малварі скармливаем grep. Принцип простий: беремо якийсь унікальний шматок (наприклад, там вказано URL сайту, на який йде редирект, або ім'я файлу) і пробуємо знайти цей текст в інших файлах веб-сайту.
$ Grep -iR example.org / var / www /
Якщо при ручному розбиранні будуть потрапляти заражені файли, то аналізуємо і невеликий шматок унікального тексту також пропонуємо grep для пошуку інших аналогічних файлів. Код в файли сайту вставляється або в початок, або в кінець, і він, на відміну від решти, погано структурований, тобто йде суцільною масою. Це відразу кидається в очі в будь-якому текстовому редакторі, особливо з підсвічуванням коду. Але буває, код спеціально відбивають за межі видимої частини екрану вправо або вниз. Можна скласти невеликий скрипт, щоб відразу вирізати шматок коду. Правда, залишки потім знайти буде складніше. Наприклад, в decode використана послідовність HtI9Opn ... Z. Створюємо такий скрипт:
$ Nano virusdel.sh #! / Bin / bash virus = 'eval (base64_decode ( "HtI9Opn. * Z =="));' find. -type f -name '* .php' -exec sed --in-place -e "s / $ virus // g" '{}' \;
запускаємо:
$ Chmod + x virusdel.sh $ ./virusdel.sh
Знайдене ім'я файлу відразу перевіряємо на інших підкаталогах і сайтах за допомогою find.
$ Find / var / www / -name confg.php
Час доступу до файлів не завжди видає його модифікацію, але ось відмінність в розмірах файлу і кількість файлів в каталозі в порівнянні з оригінальним кидається в очі відразу. І ми можемо легко порівняти два каталоги за допомогою diff або вручну, відкривши два вікна в mc. Найпростіший diff -aqr dir1 dir2 покаже тільки відрізняються файли без самих змін, повний diff -ruN> out.diff видасть інформацію в стилі patch. Всередині каталогів виявилася велика кількість зайвих PHP-файлів, деякі називаються схоже на файли WP або так само, але лежать в іншому каталозі. Наприклад, class-wp - *. Php, wp-config .php (з пропуском). А також всякі users.php, confg.php, about.php і випадкові імена (на кшталт a249yh.php, їх легко помітити).
Каталог / var / spool / exim4 / input був буквально забитий спам-повідомленнями. Кількість повідомлень в черзі, виведене exim -bpc, сягала кількох тисяч. Висновок ps aux показував процес sendmail, який намагався відправити лист від невідомого користувача з доменом сайту. Щоб не розсилати спам, SMTP-сервер краще поки зупинити. При спробі очистити командою rm -rf / var / spool / exim / input / * bash вивалювався з помилкою через великої кількості файлів. Можна використовувати маску і видаляти файли по частинах, але у випадку з exim простіше ввести
$ Sudo exipick -i | xargs exim -Mrm
Права доступу
Далі слід переглянути права доступу - посилити їх по максимуму. Це дозволить зупинити атаку, не давши хакеру продовжувати модифікувати файли. Потім можна буде повернути нормальні права.
Продовження доступно тільки учасникам
Варіант 1. Приєднайся до товариства «Xakep.ru», щоб читати всі матеріали на сайті
Членство в співтоваристві протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалами «Хакера», збільшить особисту накопичувальну знижку і дозволить накопичувати професійний рейтинг Xakep Score! Детальніше
Варіант 2. Відкрий один матеріал
Зацікавила стаття, але немає можливості стати членом клубу «Xakep.ru»? Тоді цей варіант для тебе! Зверни увагу: цей спосіб підходить тільки для статей, опублікованих більше двох місяців тому.