web shell что это
web-shell
Начнем с определения что такое «веб-шелл» (WEB-Shell). Что нам говорит интернет по этому поводу: это некий вредоносный скрипт (программа), который злоумышленники используют для управления чужими сайтами и серверами: выполнения команд терминала, перебора паролей, доступа к файловой системе и т.п. Для размещения скрипта чаще всего используются уязвимости в коде сайта или подбор паролей.
Хотя тут требуется уточнение. Вредоносным он становится в случае если он загружен не вами на ваш сервер, а злоумышленником. Если он загружен вами, то обычно это очень даже полезный инструмент.
PHP WEB-Shell обычно построен на PHP команде exec();
и по большому счету
уже является шеллом.
Но, как правило, от шелла хочется немного больше комфорта. Ведь неудобно каждый раз менять PHP код, чтобы выполнить команду.
Web Shells – это специальные скрипты, которые написаны и кодируются на многих языках, таких как PHP, Python, ASP, Perl и т.д. В дальнейшем они используются в качестве бэкдора для получения доступа к любому серверу, загружая их на него.
Таким образом, злоумышленник может непосредственно выполнить операцию чтения и записи, как только бэкдор будет загружен в пункт назначения. Он способен отредактировать любой файл или удалить его с сервера.
Установка в Kali Linux, Mint, Debian, Ubuntu (и вообще любой другой Linux)
При эксплуатации удаленной уязвимости шелл-код может открывать заранее заданный порт TCP уязвимого компьютера, через который будет осуществляться дальнейший доступ к командной оболочке. Такой код называется привязывающим к порту (англ. port binding shellcode).
Если шелл-код осуществляет подключение к порту компьютера атакующего, что производится с целью обхода брандмауэра или NAT, то такой код называется обратной оболочкой (англ. reverse shell shellcode).
Шелл-код обычно внедряется в память эксплуатируемой программы, после чего на него передается управление. Результатом этого является выполнение шелл-кода, который открывает командную строку для использования взломщиком.
Пентестинг Web Shell
В этой статье описаны различные способы загрузки PHP Web Shell для получения доступа к веб-серверу путем инъекции вредоносного фрагмента кода, написанного на PHP.
Знакомство с PHP Web Shells
Web Shells — это специальные скрипты, которые написаны и кодируются на многих языках, таких как PHP, Python, ASP, Perl и т.д. В дальнейшем они используются в качестве бэкдора для получения доступа к любому серверу, загружая их на него.
Таким образом, злоумышленник может непосредственно выполнить операцию чтения и записи, как только бэкдор будет загружен в пункт назначения. Он способен отредактировать любой файл или удалить его с сервера. Сегодня пользователь познакомится со всеми видами PHP Web Shells, которые когда-либо были доступны на Kali Linux.
Kali Linux имеет встроенные PHP-скрипты для использования их в качестве бэкдора и облегчения работы во время пентестинга. Они хранятся внутри /usr / share/webshells / php, и пентестер может применить их, не тратя времени на написание специального PHP-кода для получения вредоносного скрипта.
Выделяют несколько видов PHP Web Shells:
Simplebackdoor.php shell
Simple-backdoor.php – это Web Shell, который может генерировать удаленное выполнение кода, однажды введенного в веб-сервер и скрипт, сделанный John Troon. Он уже доступен на Kali в папке /usr/share/web shells/php, как показано на рисунке ниже. После этого пользователь запустит команду ls-al, чтобы проверить разрешения, предоставленные файлам.
Теперь нужно найти способ загрузить Shell в свое приложение. Поскольку пользователь делает все это ради пентестинга, он сначала попробует использовать простой бэкдорный PHP Shell, который уже доступен на Кali. Следует нажать кнопку Отправить файл, чтобы осуществить саму загрузку.
Как можно увидеть, пользователь успешно загрузил вредоносный php-файл и получил гиперссылку на него.
Таким образом, человек пытается получить доступ к simple-backdoor.php и наблюдает следующий результат. Как заметно на картинке, здесь «cmd=cat+ / etc/passwd» является четким указанием на удаленное выполнение кода.
Итак, стоит все-таки попробовать запустить cat+ / etc / passwd, чтобы получить все пароли сервера.
В результате пользователь извлек все записи из файла passwd, следовательно, он может выполнить любую команду, такую как ls, cp и другие. Теперь он способен получить Web Shell, используя REC.
qsd-php backdoor shell
Эксплойт Web Shell обычно рассматривается как бэкдор, который позволяет злоумышленнику удаленно получать доступ к серверу и управлять им, а qsd-php backdoor shell — это своего рода оболочка, которая предоставляет платформу для выполнения системных команд и отличного скрипта, разработанного Daniel Berliner.
Как можно заметить, пользователь успешно загрузил файл qsd-php-backdoor.php.
Затем он попробовал получить доступ к qsd-php-backdoor.php, как это было сделано на предыдущем шаге. Таким образом, пользователь обнаружил то, что показано на рисунке ниже. Здесь он способен выполнить обход каталога, а также получить прямой доступ к нему, введя команду и нажав на кнопку «Go».
Как можно понять, пользователь смог получить доступ к текущему каталогу непосредственно без выполнения какой-либо системной команды.
Он также может выполнить произвольную системную команду, так как этот бэкдор предоставляет платформу для выполнения команд оболочки, таких как cat/etc/passwd, ls-al и многих других. Человек способен запустить две команды одновременно и наблюдать за конечным результатом.
Как можно заметить, результат не может не радовать.
PHP-reverse shell
Теперь настала пора перейти к следующему PHP Web Shell, который является php-reverse-shell.php. Он откроет исходящее TCP-соединение с веб-сервера на хост и скрипт, выполненный “pentestmonkey». Shell будет также подключен к TCP-соединению (реверсивное TCP-соединение). С помощью этого скрипта пользователь получит возможность запускать интерактивные программы, такие как telnet, ssh и т.д. Важен тот момент, что он отличается от других скриптов Web Shell, поскольку с помощью него можно отправить одну команду, а затем мгновенно вернуть результат себе на компьютер.
Для этого пользователю нужно открыть этот скрипт через nano:
Здесь человеку нужно предоставить желаемое соединение LISTEN_IP (Kali Linux), а вот номер LISTEN_PORT можно установить любой.
Далее следует загрузить этот Web Shell, чтобы получить обратное (реверсивное) соединение. Таким образом, пользователь загрузит вредоносный файл и со своей стороны запустит netcat listener внутри нового терминала.
Видно, что загрузка была завершена успешно.
Теперь, как только пользователь запустит загруженный файл и, если все пройдет хорошо, то веб-сервер должен будет сбросить PHP-reverse shell листенеру netcat. Человек может убедиться, что он успешно захватил Web Shell.
PHP Backdoor с помощью MSFvenom
Пользователь также может создать PHP Web Shell с помощью msfvenom. Поэтому он использует следующую команду для генерации вредоносного php-кода в формате raw.
Затем ему необходимо скопировать этот код и сохранить его под именем meter.РНР
Пользователь загрузит этот вредоносный Shell в лабораторию DVWA, чтобы получить реверсивное соединение. Теперь он может увидеть, что meter.php был успешно загружен. Это сообщение, показанное на скриншоте, означает, что PHP-бэкдор добрался до нужного места.
Для того чтобы запустить Shell, пользователю следует открыть URL-адрес DVWA.
Одновременно он запустит мультиобработчик, где получит meterpreter shell, и введет следующие команды: нужно указать lhost и lport, чтобы установить обратное соединение.
Как только пользователь исследует загруженный путь и выполнит бэкдор, он получит сеанс meterpreter.
Weevely Shell
Weevely — это скрытый PHP Web Shell, который имитирует ссылку на Telnet и предназначен для выполнения удаленного администрирования серверов и тестирования на проникновение. Он может быть использован в качестве скрытого бэкдора Web Shell для управления законными веб-учетными записями. Weevely также является важным и незаменимым инструментом для постэксплуатации веб-приложений. Пользователь, таким образом, может создать PHP-бэкдор, защищенный паролем.
Человеку необходимо открыть терминал и ввести weevely, чтобы сгенерировать PHP-бэкдор, а также установить пароль. В данном случае пользователь взял учетные данные “raj123 » и сохранил этот Web Shell как weevely.php.
Теперь ему нужно загрузить PHP Web Shell в целевую папку, как в данном случае он отправил его в Web for pen testers. После этого пользователь откроет URL-адрес в браузере, чтобы запустить сам Web Shell.
Следует ввести следующие данные, чтобы инициировать атаку веб-сервера и поместить скопированный URL-адрес в команду Weevely с помощью пароля raj123. Пользователь сможет увидеть, что он получил Shell жертвы через weevely. Это можно проверить с помощью команды id:
Пользователь способен также проверить всю функциональность weevely с помощью команды help.
PHPbash shell
Пользователь может использовать Phpbash Web Shell, который является автономным и полу-интерактивным. Он загрузит его с GitHub, а затем зайдет в каталог phpbash и выполнит команду ls-al, чтобы проверить доступные файлы.
Итак, внутри phpbash пользователь нашел php-скрипт с именем «phpbash.php». Его нужно загрузить в целевую папку.
Теперь человек загрузит этот PHP Web Shell в DVWA lab и увидит сообщение о том, что все прошло успешно.
После этого пользователь откроет URL-адрес для выполнения Shell.
Вредоносный файл phpbash уже выполняется, и человек получает Web Shell. Преимущество phpbash заключается в том, что он не требует какого-либо типа листенера, такого как netcat, потому что shell сам по себе имеет встроенный bash, что можно наблюдать ниже.
В результате пользователь получил bash www-data Shell. Он способен выполнять системные команды непосредственно через эту платформу.
Таким образом, в данной статье были исследованы и проверены практическим путем множество способов получения Web Shell.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.
От обычного пользователя до полноправного администратора сервера (XSS, LFI, Web-Shell)
В начале года мне написал сотрудник одной фирмы. Как я понял, в компании произошел небольшой конфликт. Из-за которого существовал риск компроментации системы каким-то из сотрудников. Решение провести аудит системы определенно было правильное. Ведь результаты проверки приятно удивили меня, и «неприятно» удивили заказчика.
Архитетура системы в принципе была стандартная. В основе лежал сервис аутентификации. Дальше по выданному jwt токену пользователь мог использовать функционал системы на различных поддоменах.
Тестирование ограничилось одним поддоменом. Но самым основым по мнению заказчиков. Не буду рассказывать в деталях все ошибки и проблемы. Их было обнаружено много. Я лишь опишу те, которые для меня показались самыми любопытными.
Избыточность информации при поиске пользователей
Запрос на поиск пользователей позволял получать набор информации следующего характера — userID, Name, Login, avatar… 
Без особых проблем можно было собрать всю базу Login_name пользователей. Особых ограничений в функционале login так же небыло. Дальше можно было подбирать пароль в несколько потоков или выполнить точечный фишинг на наиболее важных пользователей системы.
Blind XSS в обращении за поддержкой от пользователя.
У меня сложилось впечатление, что данная проблема присуствует в 90% систем с которыми я сталкиваюсь. Ко мне ранее неоднократно прилетали «отстуки» от платформ для агрегации отзывов. Так же прилетали доступы к системам мониторинга поведения пользователей в интернете. Много всего было. При этом мало кто понимает на сколько это может быть опасно. Конкретно об этом уязвимости писали тут.
В данному случае я убедился в работоспособности атаки случайно получив уведомление от XSS Hunter. Вектор атаки был следующий:
Но заказчик не верил что я смогу получить контроль панели администратора через данный вектор атаки. Ведь вся ценная информация хранится в local storage. Т.к XSS Hunter не поддерживает получение local storage информации, пришлось развернуть собственный XSS логер. Очень помогла следующая публикация. В результате повторной атаки удалось убедиться, что jwt token администратора системы легко может быть получен злоумышленниом даже из local storage.
Ну а дальше с правами администратора в системе можно делать все, что угодно.
Stored XSS в электронном письме.
В системе был обнаружен функционал позволяющий делать оформленные email приглашения для регистрации новых пользователей. В форму письма можно было вставить Имя человека. Чтобы email был более персональным. В результате все содержимое не экранировалось и попадало в письмо. Для того чтобы провернуть подобную успешную xss атаку через письмо — надо знать email клиент жертвы, и надо знать zero day xss для данного клиента. В общем, успешность данной атаки по определению была ничтожна. До момента, когда я обнаружил любопытную кнопочку в верхнем углу письма.
Это была возможность открыть web версию письма. И вот тут меня ждал сюрприз. Моя XSS сработала. При этом веб версия письма открывалась на поддомене admin.*.com
Двойное удивление так сказать.
Доступный файл access.log
В процессе аудита я нашел интересное место. При попадании разных симоволов в запрос — в ответ от сервера прилетало 404. Но периодически ответ 404 немного отличался от предыдущего. Иногда был дополнительный header. Иногда нет. Определенная мутация ответов системы натолкнула меня на мысль проверить в этом месте локальное включение файлов (LFI). Настроил lfi словарь и стал ждать когда система вернет ответы на все мои запросы. В результате при просмотре результатов теста я был сильно удивлен ответу со статусом 200 с весьма увесистым размером переданных данных.
Оказалось, что я обнаружил доступный на чтение файл access.log. В данном файле записывалась вся активность на сервере. В том числе в данном файле можно было обнаружить jwt токены пользователей.
Expiration time этих токенов был достаточно большой. И это тоже было не очень хорошо.
Полный web-shell доступ к серверу
В принципе все описанные выше — проблемы доволно распространенные. Но определенные типы уязвимостей встретить уже достаточно сложно. Речь о доступе к серверу через аккуратно загруженный код в файлике shell.php. После которого получаются скомпроментированны все проекты находящиеся на этом сервере. О подобной проблеме в 2016 году писал Bo0oM в своем блоге.
Но вернемся к моему примеру. В системе была возможность делать публикации. При этом к публикации можно было загрузить картинку. Картинка сохранялась на том же домене. Но у файла принудительно менялось имя. Т.е вы загружаете — mypicture.jpg. А вот в результате получаете 12345.jpg. Я решил проверить, а что будет если я передам файлик xml (на тот момент я видимо мечтал встретить XXE). И на мое удивление получил ответ 123556.xml. И тут я понял, что есть 99% шансов на успех с php расширением файла для web shell. Для этой атаки я использовал b374k shell. При прямом обращении к файлу — я получил то, что хотел. Доступ к директориям сервера.
Но это было не самое печальное. Самое печальное оказалось в том, что через данную уязвимость можно было скомпроментировать более 10 проектов, которые находились в корневой директории этого сервера.
Мой приятель cyberpunkyc сказал, что подобное можно было встретить в году 2007-2010. Увы на дворе 2019. А подобная проблема существует по сей день.
В результате тестирования, заказчик был сильно удивлен результатами. А я был сильно рад, что оказался очень полезен при проведении тестирования. Если у вас есть предложения с интересными проектами — смело пишите мне в телеграм 😉
WEB-Shell на PHP. Что это такое и способы его спрятать
Начнем с определения что такое «веб-шелл» (WEB-Shell)? Что нам говорит интернет по этому поводу: Это некий вредоносный скрипт (программа), который злоумышленники используют для управления чужими сайтами и серверами: выполнения команд терминала, перебора паролей, доступа к файловой системе и т.п. Для размещения скрипта чаще всего используются уязвимости в коде сайта или подбор паролей.
Хотя тут требуется уточнение. Вредоносным он становится в случае если он загружен не вами на ваш сервер, а злоумышленником. Если он загружен вами, то обычно это очень даже полезный инструмент.
PHP WEB-Shell обычно построен на PHP команде exec();
и по большому счету
уже является шеллом.
Но, как правило, от шелла хочется немного больше комфорта. Ведь неудобно каждый раз менять PHP код, чтобы выполнить команду.
Пример более удобного шелла можно найти в разделе файлы.
Но вот все хорошо, шелл размещен на сервере, но возникает вопрос как его скрыть от посторонних глаз.
Первое что приходит в голову, это сменить название на то, которое не вызовет подозрений (скажем functions.php).
Далее а стоит поменять время создания/изменения файла. В этом нам поможет команда touch с параметром -t
-t время
Использовать вместо текущего указанное время. Время задается десятичным числов вида:
[[CC]YY]MMDDhhmm[.SS]
где каждая пара цифр представляет следующее:
Так же можно Shell встроить в уже существующий PHP файл, но это лучше делать с компактным шеллом.
Например с таким:
Данный шелл проверяет, вызван ли скрипт с GET параметром pwd, который задан в переменной $pa (вызов скрипта должен выглядеть как: http://путь_и_имя_скрипта.php?pwd=qwe)
Перед его добавлением в существующий PHP файл следует удалить из него комментарии и максимально его сжать.
После удаления комментариев, лишних пробелов и переносов строк получится:
Но в любом случае лучше подстраивать стиль под стиль кода в существующем файле.
Хотя можно пойти и другим путем. Предварительно обфусцировать код, чтобы он стал не читаемым.
Пример легкой обфускации:
Это тот же простой шелл, просто с запутанным кодом.
Пример сильной обфускации:
Это все тот же простой шелл, но с шифрованием в base64. он так же будет исполняться.
Можно встроить загрузчик шелла в существующий скрипт. Этот путь хорошо в качестве резервного. Если основной шелл стерли и уязвимость закрыли, то возможно остался загрузчик, через который можно повторно закачать шелл. Хотя это иногда бывает довольно творческой работой, потому что не всегда все папки доступны на запись.
Пример загрузчика(в данном случае используется утилита wget через exec):
данная строка закачает файл shell.txt с сервера example.com и сохранит его под именем shell.php в папке, из которой исполнялся скрипт, если скрипт, в который она внедрена, вызван с параметром ?pwd=dl
Так же можно сделать загрузку с помощью самого PHP:
данный код так же закачает файл shell.txt с сервера example.com и сохранит его под именем shell.php в папке, из которой исполнялся скрипт, если скрипт, в который она внедрена, вызван с параметром ?pwd=dl
Только не забываем предварительно разместить шелл на сервере, с которого он будет закачан. И с не исполняемым расширением файла.
Скрипт закачки шелла на сервер так же желательно сжать, освободить от комментариев и, по желанию, обфусцировать.
Еще шелл можно спрятать в базе данных, но это уже зависит от используемой CMS и ее настроек. Если текст страниц хранится в базе данных, и CMS по каким-либо причинам не фильтрует PHP код при выводе текста из базы на страницу для конечного пользователя, то эти скрипты вполне могут жить в базе данных. Правда данный материал уже выходит за рамки этой статьи.
Вообще методов сокрытия шелла существует огромное множество. И данная работа больше напоминает творческую.
Что касается защиты: старайтесь держать эталонные версии скриптов и список файлов на сервере в резервной копии (естественно находящейся не на том же сервере). Тогда можно будет быстро сравнить все изменения, в случае если у вас есть подозрения.
Заказать создание и поддержку безопасной IT-инфраструктуры любой сложности
Быть уверенным в своей IT-инфраструктуре — это быть уверенным в завтрашнем дне.
Статья Web-Shells или как управлять сервером после получения доступа
Всем Салам. Сегодня решил поделится с вами довольно таки интересной темой. Когда мы получаем доступ к серваку, то делать руками гадать, что где находится довольно таки сложно и все это может затянуться. Поэтому, самым оптимальным решением является залить веб-шелл, через бекдор. Сегодня я не буду показывать, как найти бекдор или способы взлома, сегодня рассмотрим пару веб-шеллов, которые мне больше всего нравятся и по-моему они самые лучшие.
А как находить и закрывать эти бекдоры, я уже рассмотрю в следующей статье в цикле про безопасный php. Особо грузить вас тоже не будем, рассмотрим 2 веб-шелла.
Как по мне, веб-шелл b374k самый топовый. Давайте познакомимся с ним поближе.
Скачать данный шелл можно с гитхаба:
Но там же не один файл, как же его залить на сервак, не стоит беспокоится, разрабы об этом позаботились и внедрили удобный packer, с помощью одной команды, все это дело мы можем собрать в 1 файл.
Шелл для загрузки готов, жертва у нас будет наша любимая площадка с уязвимостями DVWA.
Файл успешно залит, давайте по нему перейдем и посмотрим, что за монстр:
Кроме экплорера, для удобного управления файлами на сервере, у нас также имеется полноценный терминал, Eval для выполнения скриптов, прямо отсюда мы можем подключится к БД, смотреть какие процессы запущены и еще дофига всего. Подробности можете прочитать на гитхаб.
С этим веб-шелом, я знаком уже давно. Выглядит он тоже более по хакерски и круто и обладает множеством крутых фишек.
Взял триальный хостинг, вот вам ссыль на шелл, можете зайти и поиграться:
На этом с веб-шеллами я закончу. Скоро будем, находить бэкдоры и рассматривать варианты заливки шелла на сервак. А так же рассмотрим момент с безопасным кодом, чтобы избежать заливки шела, к нам на сервак. Всем Удачи!
r0hack
Debug
Ondrik8
prodigy
r0hack
ActionNum
larchik
wooolff
explorer
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
wooolff
explorer
mrtyrel
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
Как будто топовую статью прочел))
Active member
w2ll3t0Rl1v3
Member
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.