Невелике занурення всередину зламаного сайту

Не секрет, що більшість сайтів в наші дні зламуються не вручну. Є велика армія ботів, які шукають уразливість в скриптах сайтів, брутфорсят адмін-панелі CMS, FTP, SSH акаунти, потім завантажують невеликі скрипти-завантажувачі або бекдори, через них впроваджують у скрипти сайту кілька десятків керуючих «агентів», а також розкидають по випадковим каталогами, відкритим на запис, веб-шеллі, спам-рассыльщики та інші шкідливі php (і іноді perl) скрипти. Зсередини заражений сайт виглядає приблизно так (фрагмент звіту сканера AI-BOLIT):



Патерни зараження (кількість, склад і призначення шкідливих скриптів) можуть змінюватися. В даному випадку статистика по зараженню наступна:

  • 41 вставка бекдор
  • 5 WSO веб-шелл
  • 4 скрипта, що впроваджують шкідливий код .php файли
  • 7 mail() спам-людей, які розсилають
  • 2 спам-рассыльщика, що працюють через SMTP
  • 1 бекдор
  • 1 скрипт, впроваджує шкідливий код в wordpress/joomla скрипти
Серед «шкідливий» є всякі цікаві екземпляри. Але мова сьогодні піде не про них. Цікавіше аналізувати не стільки статичний шкідливий код в файлах, скільки процес роботи з «шкідливими програмами» в динаміці: які терміни і в якому форматі шлють командні центри впровадженим бэкдорам, з якою інтенсивністю, з якими параметрами і т. п. Крім того, статичний аналіз для сучасних зловредів працює погано, тому що деякі скрипти не містять payload'ів.

Візьмемо популярний бекдор:



Він складається з однієї-двох рядків і служить для приймання і виконання PHP-коду. Payload «прилітає» в параметрах POST запиту і виконується в той же момент. Природно, код payload'а ніде не зберігається, тому процес динамічного аналізу зазвичай впирається у відсутність даних: немає логів з тілом запитів, які містили б досліджуваний код.

Щоб проаналізувати спілкування командного центру зі своїми «агентами», потрібно логгировать HTTP запити до шкідливим скрипта, а для цього потрібно своєчасно налаштувати протоколювання тіла POST запиту в файл, що ніколи не робиться на shared-хостингах. На виділених серверах, зрештою, POST запити з даними теж не логгируются. Це пов'язано з економією ресурсів сервера і, в загальному випадку, відсутністю необхідності. Але це ще не все. Друга проблема, пов'язана з аналізом злому і зараження сайту — це пізнє звернення власника зараженого сайту до фахівців.
Майже завжди «пацієнти» звертаються через 2-3 тижні після появи першого шкідливого скрипта. Тобто коли завантажений код вже впроваджено, «отлежался» і починає активно експлуатується зловмисниками, а сайт блокується хостингом через спам-розсилки, фішингових сторінок або атак на сторонні ресурс. До речі, «відлежується» код для того, щоб замести сліди злому і відразу не викликати підозр у власника сайту. Через два тижні ротація логів робить свою «брудну» справу, стираючи інформацію про те, яким чином шкідливий код був завантажений на сайт, і впроваджені шкідливі програми починають створювати шкідливу «корисну» навантаження: атакувати інші ресурси, завантажувати на сайт дорвей-сторінки, спам-рассыльщики, впроваджувати код редиректів на зв'язки сплойтов, розсилати тонни спам листів з фішинговим контентом та ін

Але час від часу все-таки вдається налаштувати логгирование на зараженому сайті і зібрати нутрощі запитів до шкідливих скриптів. Отже, що ж приховано від чужих очей?

Досить типово для такого зараження – це впровадження в кореневій .htaccess редіректу на pharm-партнерку (продаж «віагри», і т. п), wap-click партнерку (підписка на медіа-контент за SMS) або шкідливий ресурс (для проведення drive-by атак або завантаження трояна під виглядом поновлення flash-плеєра або антивіруса).



Редирект в даному випадку впроваджується наступним чином: в POST запиті передається php-код, який обгорнутий в base64. Код виконується з допомогою бекдор на зламаному сайті і додає свій обробник 404 помилки, при якій перекидає відвідувачів на сайт зловмисника. Причому, досить мати на якій-небудь сторінці сайту відсутню картинку, скрипт або .css файл, щоб у відвідувача спрацював редирект. Домени, на які спрямовуються відвідувачі, періодично змінюються.

Ще один приклад лода запитів до впровадженим бэкдорам і завантаженим скриптам для спам-розсилки:



Тут також всі дані передаються в кодуванні base64 через POST і COOKIE-змінні. Причому, виконувані фрагменти двічі обгорнуті в base64 кодування, щоб обійти WAFы і веб-сканери, які в курсі про base64 і вміють її декодувати. У раскодированном варіанті запит до бэкдору виглядає так:





У payload'е виконується обхід каталогів і інжектування коду, який буде шукати wordpress файли в каталогах і робити одну з двох речей: або впроваджувати в них шкідливий контент, або відновлювати оригінальний контент файлів (командний центр впроваджує шкідливий на час або за розкладом). Щоб було складніше знайти змінені скрипти, дата модифікації (mtime) у файлів виставляється за датою зміни одного з wordpress скриптів. На додаток, виставляються атрибути «тільки для читання», щоб недосвідчені веб-майстри не змогли їх відредагувати (багатьох це дійсно бентежить).

Що стосується іншої «корисною» навантаження — розсилки спаму — контент двічі загортається в base64 і передається в параметрах POST запиту до спам-рассыльщику. А час від часу можуть відсилати якісь перевірочні листи зі службовою інформацією:



Цікаве спостереження: якщо з сайту видалити всі шкідливі скрипти, то через кілька невдалих запитів процес спілкування з «агентами» зупиняється. Тобто командний центр не намагається відразу ж повторно зламати сайт і завантажити на нього бекдори, мабуть з тієї ж самої причини – приховати процес первинної завантаження бекдорів. Але якщо залишити при лікуванні хоча б один бекдор, то через нього знову завантажать цілу «в'язанку» хакерських шелл, бекдорів та спам-людей, які розсилають.
Тому лікувати сайт завжди потрібно дуже акуратно.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.