Як продовжити існування web shell
Забігаючи вперед скажу, що тут мова буде йти не стільки про продовження життя iframe і web shell, скільки про альтернативу йому, що дозволяє зливати траф довше, навіть після того, як адмін отямитися, так що під "фреймом" буде матися на увазі інший елемент (який до речі технічно фреймом і є).
Рано чи пізно, після виявлення бага на сайті, що дозволяє залити web shell (або вже після залиття) можуть виникати питання з приводу того, як би надійніше заховати його (web shell), а також - як би подовше зберегти iframe на сторінці, щоб не грати потім з адміном в "додай-видали" і як можна довше не привертати увагу до того факту, що на сайті треться хтось сторонній. Такі питання виникали (і виникають) у мене, особливо, після кількох випадків, коли фрейм з шеллом не веліли довго жити. Методами проб і помилок, а також на досвіді людей, що займаються тим, що "фікс" сайти людям, у яких залитий шелл або стоїть фрейм, які часом зустрічаються дуже тямущий і заховати від них код буває вкрай важко (або заховати на відносно тривалий час ).
Тому тут хочу поділитися деякими прийомами і процедурами, які свого часу допомогли зберегти / продовжити перебування не одному web shell і кадру. І звичайно можна буде надходити більш гнучко і не кидати в бій всі можливі способи для запрятиванія коду, якщо наприклад сайт не особливо відвідуємо і не має особливої інший якийсь цінності, хоча для кого-то зайва шифрация ніколи не буває зайвою.
Зазвичай ці люди спочатку видаляють web shell, а потім його наслідки у вигляді фреймів, але технічно це два відокремлених процесу, тому можна їх розібрати не по порядку.
Ускладнюємо детект фрейма.
Будемо виходити з того факту, що всі (або майже всі) ці фахівці грунтуються на тому, що ми ллємо трафік через iframe, але трохи пізніше покажу альтернативний спосіб.
Щоб знайти фрейм, можна використовувати 3 способи:
1) В html-коді безпосередньо (читаючи його);
2) В html-коді через пошук (по DOM-дереву або по текстової версії) з яких-небудь ознаками;
3) Через JS в консолі браузера;
Значить наше завдання - сильно ускладнити кожен з них. Тепер якомога ускладнити життя по кожному з трьох пунктів:
1) Треба просто настворювала через JS купу рандомних вкладених тегів, в одному з яких і буде наш код, а решта - сміття. Тут навіть якщо хтось зважитися вручну прошерстить код, то бажання швидко поугасніт;
2) Для того щоб ускладнити, визначимо ознаки, за якими може здійснюватися пошук - за назвою тега "iframe", по URL, до якого робиться запит з нашого коду (цю інфу можна добути і через проксі, і через звичайну вкладку моніторингу мережі в панелі розробника в барузер). Тому наше завдання - не використовувати тег iframe і якось обфусціровать URL;
3) Тут в консолі будуть забивати щось типу document.getElementsByTagName ( "iframe") і дивитися на результат. Ускладнити можна перевизначивши функцію getElementsByTagName або вирішивши завдання з пункту 2, не використовуючи iframe;
З першим все ясно, реалізацію приведу трохи пізніше, а ось 2 і 3 пункти натякають, що треба зливати трафік, але не через iframe. Я ще не бачив згадки про те, що можна зливати НЕ через фрейм, але колись зацікавився цим питанням, адже це дасть хорошу фору, поки фішку НЕ просіче більшість. Загалом я спробувавши кілька тегів, мало не забув про дуже схожий на iframe тег - object, який дозволяє також довантажувати різний інтерактивний контент типу flash, java, pdf та інші дані, для яких визначені mime-типи. Ну і спробував довантажити html код сайту і спрацювало:
А можна просто зробити так, щоб для тега object створювалася велика структура з іншими тегами, вкладеними на безліч рівнів углиб, а цю структуру потім скрипт додасть кудись в середину документа (помітити буде важко, навіть якщо верстку перевіряти).
Ну а можна обидва процеси відразу задіяти.
Перед використанням, звичайно ж, треба мінімізувати і обфусціровать цей JS код (наприклад, тут).
Додавати цей (або будь-який інший) код JS, який буде ініціювати слив трафіку можна різними способами, але я б не радив додавати його в якісь спільні JS файли типу jquery.min.js, тому що якщо попадеться досвідчений дядько, то він може почати по одному видаляти підключаються до сторінок скрипти, виявляючи коли запити на evil.com/traf перестануть йти. Тим самим він через кілька хвилин визначить файл, в якому наш JS є і знесе його або оновить до нормальної версії (якщо є обфускація, то штука з object навряд чи спалити - це друга причина обфусціровать JS-код, а не тільки для складності детектив через grep).
Також небажано підключати JS код через якісь створені файли з розширеннями картинок або CSS, так як це теж буде помітно досвідченим людям в панелі моніторингу мережі (що розширення одне, а типу файлу інший) і швидко детектив, якщо за це візьметься спец.
Тому краще код підключати через PHP скрипти безпосередньо, де знайти його буде складніше і ще додати самоліквідацію ініціюючого JS коду після того, як він відпрацював. Адже щоб зрозуміти в якому-небудь WordPress'e, звідки код підключається, треба дізнатися місце або фрейма, або самого коду, що зробити важко при виконанні тих трьох пунктів.
Ускладнюємо детект web shell.
Таке розміщення коду трохи підвищить шанси, так як деякі люди при пошуку по папках сайтів не включають файли картинок в пошук (важливо, що ні файли з розширеннями картинок, так як там дуже навіть ймовірно, є шелл, а саме файли, які синтаксично є картинкою ).
Це начебто все моменти, які встиг пригадати, якщо щось ще з'явитися, допишу. І буде цікаво, якщо хтось напише якісь свої методи (або недоліки описаних вище).
[Всього голосів: 4 Середній: 3/5]
Вам може бути цікаво також:
10 способів зламати пошту
XXE атаки на простих прикладах.
Як сформувати посилання з XSS в POST-параметрі.
Що таке CRLF ін'єкція, приклади використання. Ур.