ВХ08. Web-shell

Как сказал один из моих старых знакомых: "Ну и что ты тут распишешь? Шелл это шелл, бекдор это бекдор, всем спасибо, с вами был кроба, отправляйте донат, чтобы я купил говяжий дошик. Так?" Да. Примерно это вы и прочтете в статье.

Термины.

Довольно часто слова "бекдор", "шелл", "вебшелл" используют как синонимы. Хотя по факту это достаточно разные вещи.

Шелл (консоль, терминал, командная строка) - текстовый интерфейс для взаимодействия с системой.

Вебшелл - это скрипт, который используется для пост-эксплуатации взломанного сервера. Помимо кучи самых разных, нужных и не очень функций, позволяет получить доступ к консоли взломанного сервера через веб (потому и вебшелл). Иногда сокращают и пишут просто "шелл", отчего порой возникает путаница.

Минимальный вебшелл (ок, не самый минимальный).:

Бекдор (в переводе - ч0рный ход, задняя/тайная дверь) - в самом общем смысле - лазейка для установления скрытого контроля над ресурсом.

Например:

С помощью подобного кода можно залить шелл, но сам этот код вебшеллом не является (так как команды выполнить нельзя). Более того, бекдор это не обязательно хитрый кусок кода запрятанный в недрах исходников, это может быть хранимая процедура в бд, добавленный пользователь, протрояненный ssh и т.д.

Любой вебшелл - это по факту бекдор, но не любой бекдор это вебшелл.

Кстати. В seo'шной тусовке вебшеллы иногда называют пирогами, пряниками, выпечкой и производными от этого (можно натолкнуться на что-то вроде "продам продукты жизнедеятельности моей печной мануфактуры"). Предположительно, это пошло от ныне неактуального гугловского SEO-показателя PR, отсюда и ПиРоги/ПРяники. Основной контекст - это "дорвеи на пирогах/пряниках". Как по мне, то это детский шифр на уровне игры "казаки-разбойники" или "мама, я не курил, просто рядом стоял с ребятами которые курили и на меня дышали".

Музей вебшеллов

Мельком взглянем на несколько широко известных шеллов.

r57 webshell

По всей видимости, один из самых старых шеллов. По сравнению с более новыми, кажется очень неудобным. Есть корявый файл-менеджер, консоль, работа с SQL. Но зато всё на одной вкладке. Весит чуть больше 100кб.

С99 webshell

Файл-менеджер, выполнение команд, кода, бекконект, брутфорс фтп, поиск эксплоитов на милворме (ха-ха), передача данных GET-параметрами. Весит в районе 200кб.

b374 webshell

Файл-менеджер, консоль, выполнение кода, очень красивый вывод списка процессов и инфы из phpinfo (аж 6 вкладок), работа с базами данных (целых 4 метода), проброс бекконектов 2 способами. Весит 180кб.

WSO (Web Shell by Orb)

Наверное, один из самых распространенных шеллов. По сути является качественной доработкой и переработкой более старых шеллов. Все параметры передаются через POST. Запакованный весит примерно 25кб, распакованный - 65кб.

P.A.S. - webshell by Profexer

Кстати, автор шелла, был сдеанонен, а после этого схвачен кровавой гебней. Тот же WSO, вид сбоку. Порой работал там, где обычный WSO палился, потому и имел некоторое распространение. В сжатом виде весит чуть больше 20кб.

Продолжать можно было бы еще долго, но почти все популярные шеллы мы хоть и мельком, но глянули. Само собой, есть вебшеллы и под asp и под java (и найдутся под любой язык и платформу, где это принципиально возможно).

Рассмотренные нами шеллы построены по одному принципу - всё свое ношу с собой. Это удобно, но за удобство приходится расплачиваться.

Недостатки классических вебшеллов.

Легко найти. Шеллы прекрасно индексируются:

Даже если шелл удалили, мы узнаем, какой был путь к шеллу и какое у него было имя. Далее - достаточно прогнать несколько миллионов доменов на такой же путь и имя, и почти всегда найдется от 2-3 до нескольких тысяч шеллов (если развить эту мысль, то можно прийти к интересным выводам). И пароль на каждый шелл, скорее всего, один и тот же.

Палятся АВ. В изначальном виде, без обфускации, каждый шелл палится десятком АВ. От этого помогает обфускация, но даже после обфускации, шелл найти все равно легко. Если его и не найдет какой-нибудь айболит или подобный скрипт, то при ручном просмотре кода шансов почти нет.

Вряд ли кого смутит такой код внутри s.php в корне сервера:

Несколько килобайт малопонятного кода почти невозможно спрятать так, чтобы их не нашли (даже если их прятать в картинках или на стороннем сервере).

Палятся WAF. Даже если вы и сделаете из кода вебшелла совершенно нечитаемую портянку кода, то передаваемые параметры останутся теми же самыми. Частая история - шелл залить можно, а пользоваться им нельзя, так как любое действие блокирует mod_security. Потому, код придется не только обфусцировать, но и переписывать. А это, забегая вперед, может существенно усложнить работу с разного рода автоматизацией.

Палятся по логам. Часть из вышеперечисленных вебшеллов отправляет команды через GET-параметры. Всё что вы делали - в логах будет видно как на ладони. Если отправляются POST-запросы, тело запроса тоже могут логгировать. А если будут только GET-запросы и команды будут передаваться в http-заголовках, то вебшелл можно будет вычислить по разной длине ответа.

Вдобавок, пока мы пользуемся вебшеллом, генерится очень много лишних запросов. Оглядется, посмотреть, что на сервере - уже несколько десятков запросов. Посмотреть файлики, полазить по бд, сделать touch на файлы/папки, чтобы "скрыть" свои следы - еще десятки запросов.

Внутри вебшеллов есть бекдоры. Классическая ситуация "вор у вора дубинку украл". Если погуглить WSO, а потом посмотреть исходники, которые нам хотят подсунуть, то очень часто можно найти какую-нибудь стучалку. Например:

Как вы видим, адрес шелла и пароль отправляется на мыло некоему Джону Баркеру. И если в этом случае всё очень просто, то могут попадаться и куда более изощренные бекдоры.

Уязвимы. Например, папка на сервере, с незатейливым названием:

При просмотре через WSO вызовет XSS.

Хотя это и достаточно странный вектор, он хорошо иллюстрирует ситуацию - немногим приходит в голову (а если и приходит, то нет времени) чекать на уязвимости инструменты, которыми сами пользуются для взлома. В некоторых шеллах можно обойти защиту паролем и сходу получить RCE (в том числе и за счет внедренных бекдоров).

Излишний функционал. Почти в каждом вебшелле есть абсолютно бесполезные фичи, которые только занимают место (в коде и на экране). Как минимум - функционал для кодирования/декодирования в base64, как максимум - обрыганские картинки арабских хакеров или движущиеся обои.

Что делать?

Если все вебшеллы такое говно, что тогда делать? Наверное, имеет смысл разделить вебшелл на клиент и сервер. К подобной мысли подходили многие. В сервер, который будет заливаться на взломанный ресурс, добавить только выполнение кода:

А всю логику и функционал разместить уже на клиенте.

Одна из самых популярных реализаций этой идеи это Weevely:

Всё очень просто. Генерируете микро-бекдор, заливаете на сервер, подключаетесь через weevely (консольная тулза, написанная на питоне) и рулите серваком. Всё очень просто, пока вы не попробуете, например, подредактировать файл.

Как вебшелл - неудобный, а до обычного шелла не дотягивает. В вивели больше 40 модулей, по штуке на каждое действие (удалить файлик, посмотреть файлик, перднуть и т.д.), и тут либо запоминать, либо постоянно подсматривать. И если нужен шелл с tty - придется кидать бекконект, а если уж кидать бекконект, то зачем нужен weevely?

Немного другой путь - это использование менеджеров шеллов. Если убрать из того же WSO всё, кроме выполнения кода, то в итоге можно подружить его и какой-нибудь из менеджеров (shwark, shell enslaver или другие).

Однако, вылезут новые проблемы.

Например, я не видел, чтобы где-то был нормально реализован поиск всех доменов на сервере. Из очевидных подходов - поиск по названиям папок на сервере и поиск по конфигам веб-сервера. Угадайте, какой домен определится, если сделать виртуальный хост google.com? (ответ - "мать доставай водку, баян, сын гугол поломал")

Если снифать запросы, которые идут на шеллы, то можно натурально охуеть. Я видел менеджер, где делалось целых 4 запроса, чтобы только убедится, что шелл на месте(!).

Или такая штука как "определение CMS". Там, где подобная фича есть авторы следуют девизу "1 домен, 1 движок, 1 фюрер". А то что в подпапке может быть один движок, в соседней - другой, а в корне - третий, такая ситуация не рассматривается.

Ну и к сути. Шелл - это канат, натянутый между началом атаки и сверхчеловеком получением рут-прав. Что нам могут предложить эти менеджеры, помимо вывода uname? Обратимся к справке менеджера шеллов shwrk:

Я не знаю, имеет ли смысл тут что-то комментировать. Разумеется, эту уберприватную (а потому и нерабочую) технику оперативно выпилили. Иными словами, и инфу собирать и рутать вам придется ручками. Даже если у вас 100500 шеллов.

Финальные мысли.

3 мысли, которые я пытался донести:

  • Чтобы комфортно пользоваться вебшеллом - его надо немного переписать и обфусцировать.
  • Ищите чужие шеллы и бекдоры - зачастую, это быстрее и проще, чем ломать с нуля (даже на fb был бекдор).
  • Нормального менеджера шеллов в паблике нет (или я не нашел). Вам придется написать его самому или заказать у кого-то.

На этом, пожалуй всё.

Ссылочки

  • https://github.com/wireghoul/htshells
  • http://www.justanotherhacker.com/2011/12/writing-a-stealth-web-shell.html
  • hxxps://raz0r.name/releases/mega-reliz-samyj-korotkij-shell
  • https://habr.com/ru/post/215139/
  • https://habr.com/ru/post/215817/
  • https://devco.re/blog/2016/04/21/how-I-hacked-facebook-and-found-someones-backdoor-script-eng-ver/
  • https://xss.is/threads/33941/ (!)