веб шелл что это
От обычного пользователя до полноправного администратора сервера (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-Shells или как управлять сервером после получения доступа
Всем Салам. Сегодня решил поделится с вами довольно таки интересной темой. Когда мы получаем доступ к серваку, то делать руками гадать, что где находится довольно таки сложно и все это может затянуться. Поэтому, самым оптимальным решением является залить веб-шелл, через бекдор. Сегодня я не буду показывать, как найти бекдор или способы взлома, сегодня рассмотрим пару веб-шеллов, которые мне больше всего нравятся и по-моему они самые лучшие.
А как находить и закрывать эти бекдоры, я уже рассмотрю в следующей статье в цикле про безопасный php. Особо грузить вас тоже не будем, рассмотрим 2 веб-шелла.
Как по мне, веб-шелл b374k самый топовый. Давайте познакомимся с ним поближе.
Скачать данный шелл можно с гитхаба:
Но там же не один файл, как же его залить на сервак, не стоит беспокоится, разрабы об этом позаботились и внедрили удобный packer, с помощью одной команды, все это дело мы можем собрать в 1 файл.
Шелл для загрузки готов, жертва у нас будет наша любимая площадка с уязвимостями DVWA.
Файл успешно залит, давайте по нему перейдем и посмотрим, что за монстр:
Кроме экплорера, для удобного управления файлами на сервере, у нас также имеется полноценный терминал, Eval для выполнения скриптов, прямо отсюда мы можем подключится к БД, смотреть какие процессы запущены и еще дофига всего. Подробности можете прочитать на гитхаб.
С этим веб-шелом, я знаком уже давно. Выглядит он тоже более по хакерски и круто и обладает множеством крутых фишек.
Взял триальный хостинг, вот вам ссыль на шелл, можете зайти и поиграться:
На этом с веб-шеллами я закончу. Скоро будем, находить бэкдоры и рассматривать варианты заливки шелла на сервак. А так же рассмотрим момент с безопасным кодом, чтобы избежать заливки шела, к нам на сервак. Всем Удачи!
r0hack
Debug
Ondrik8
prodigy
r0hack
ActionNum
larchik
wooolff
explorer
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
wooolff
explorer
mrtyrel
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
Как будто топовую статью прочел))
Active member
w2ll3t0Rl1v3
Member
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Веб-оболочка: что это такое, как это работает и как защитить ваши системы
Что такое веб-оболочка?
Это вредоносный скрипт, который внедряется в атакуемые системы. В большинстве случаев веб-серверы являются частью цели. Как только эти системы имеют веб-оболочку, киберпреступник может иметь удаленный контроль над ней. Следовательно, вы будете иметь постоянный доступ к системе и сможете управлять ею так, как вы хотите. Это означает, что веб-оболочки имеют возможность создавать бэкдоров на скомпрометированных системах иметь некоторый контроль и даже полный контроль.
Кроме того, веб-оболочки имеют гораздо большую досягаемость. Они также могут нарушать интерфейсы управления сетевыми устройствами. Поэтому крайне важно иметь хорошие практики безопасного управления сетью. Прежде всего, если это те, к которым ежедневно подключаются сотни и тысячи устройств. Рост телеработы влечет за собой риски безопасности, которые, хотя они и так известны, заслуживают особого внимания, поскольку, очевидно, работа в «защищенной» сетевой среде компании отличается от работы на дому. Тем не менее, вы можете спросить, не достаточно ли использовать VPN услуги, чтобы мы могли с полной безопасностью подключаться к ресурсам нашей организации, это только часть того, что должен делать администратор сети.
Обнаружение веб-оболочки
Основная сложность в обнаружении вредоносного ПО этого типа заключается в том, что злоумышленники могут применять методы шифрования для сокрытия своей вредоносной активности. Это является прямым следствием легкости ввода сценариев. Как мы знаем, для кибератак существует бесконечные возможности, и защита сетей должна быть усилена все больше и больше. Вот некоторые из эффективных методов обнаружения:
Какие инструменты и какие процедуры следует применять для процесса обнаружения этих вредоносных сценариев? Ниже мы даем ключевые рекомендации для эффективной защиты вас.
Как защитить свои системы и сети от веб-оболочек
Как мы уже отмечали ранее, эти веб-оболочки также вводятся непосредственно в системы и сети, которые являются жертвами, это происходит главным образом потому, что веб-приложения (в основном) и их уязвимая инфраструктура имеют разрешения на внесение изменений непосредственно в веб-каталог или на доступ к ним. кусочки веб-кода. Однако этот тип разрешения не должен предоставляться.
Следовательно, сами системы открывают двери для киберпреступников без каких-либо проблем для осуществления атак. Поэтому рекомендуется заблокировать разрешения на изменение. Теперь, если такой возможности нет, есть альтернатива.
Системы IDS / IPS и брандмауэр веб-приложений
Эта альтернатива заключается в реализации мониторинг целостности схема для файлов, размещенных в инфраструктуре приложения. Таким образом, администраторы будут иметь необходимую видимость любых возможных изменений, которые могут произойти в веб-каталогах и фрагментах кода.
Ресурсы АНБ
Мы даем Microsoft PowerShell Например. В общем хранилище вы найдете поддержку для обнаружения веб-оболочек с использованием схемы сравнения «Known Good». Кроме того, вы можете обнаружить подозрительные запросы в журналах веб-серверов.
Как мы видим, важно знать об основных уязвимостях, которые присутствуют не только на серверах веб-приложений, но и на тех, которые связаны с традиционными приложениями и даже с самими сетями передачи данных. Что касается кибератак, то здесь есть бесконечные возможности, и защитный экран должен быть максимально надежным. К счастью, высокодоступные онлайн-ресурсы и инструменты могут помочь нам как администраторам предотвратить более чем одну трагедию.
Обзор php веб шеллов
В интернете можно найти странное объяснение что веб шелл это такая страшная штука может пароли перебирать, украсть конфиденциальные данные и обязательно где то в этом предложении фигурирует приставка «вредоносный «.
Мне больше нравится определение *nix оболочка которая работающая по http
На деле все немного не так часто шел можно охарактеризовать как «благодарующий» или «незаменимый» например, тому существует множество примеров, например нужно сдампить сайт а у клиента только доступы к админке cms.
Конечно не безнадежно, но мне лично трудно представить как долго я буду с этим мучаться без соответствующего инструмента, а так дело пары минут.
К слову так же я не понимаю людей которые просят оценить работу при этом не дают ftp либо доступа к хостингу но при этом легко предоставляют доступ в админку cms, это пожалуй само непонятное для меня и бессмысленное проявление осторожности которое только может быть, любой даже самый не опытный фрилансер скорее всего сможет получить доступ ко все вашим данным даже при таком раскладе. И тут либо доверять либо не строить иллюзий.
Так как речь сейчас о php, то примеры так же будут на php, это совсем не означает не означает что подобное не реализуемо на других серверных языках.
Простой пример шелла может выглядеть так
как видите все очень просто 5 строк, но при некоторых условиях тоже самое можно реализовать в 10 символов (это даже не шутка).
В сети существует много проектов более продвинутых шелов включающих в себя полноценные файловые менеджеры, продвинутые архиваторы архиваторы sql промты, инструменты для брута ftp, отсылки email и бог знает что ещё.
Первый и один из самых старых — с99shel
На скрине мажорная версия 1.0 с почему то неизменной приставкой beta хотя я знавал и более ранние версии, а это как мы видим на скрине не шутки 21 мая 2005 года.
В работе был неприхотлив но имел несколько багов файлового менеджера и странных на мой взгляд нюансов работы с SQL, но возможно я пользовался совсем уж старой и кривой версией.
Второй не по значимости но по внешности продукт со скромным названием webConsole
как я догадываюсь относительно молодой и в основном и just for fun, но вы оцените только внешний вид это же почти терминал даже подсветка команд все в лучших традициях, красиво.
И напоследок мой любимый WSO2
Отличный дизайн, крутая функциональность позволяет контролировать чуть ли не все что бежит на вашем сервере используя удобный GUI, даже есть кнопка «Self remove», безусловно лидер, сам около десятка раз удалял его со взломанных сайтов, народ его любит.
Но противодействие идет полным ходом даже убогий Microsoft Security Essentials научился опознавать его сигнатуры, но это не единственная проблема всяческий секьюрити софт
научилось детектировать GET/POST.
В ответ на это были выпущены форки с обфусцированным кодом и шифрованием не отправлять данные в открытом виде, а с шифрованием на клиентской стороне.
Так например по всей видимости форк WSO2 под названием P.A.S как раз обладает всеми этими достоинствами.
Иногда попадаются такие кусочки кода:
Где то посреди логики шелла я обнаружил такой javascript
web shell (веб шелл)
php shell-php файл,залив который на сервер вы получаете доступ к некоторым управленческим функциям.Например можно изменять файлы сайта,вставлять туда свой код и ещё ряд привелегий.Рассмотрим один интересный шелл,он маскируется под страницу ошибки 404,что несколько затрудняет его обнаружение.Заливаем его на хост,переходим в браузере по адресу site.ru/404.php и видим такую картину:
На первый взгляд-страница ошибки,но если покликать в нужном месте посерединке появляется поле для ввода пароля,вводим пароль(по дефолту он 1337)и попадаем в админку шелла,по сути это ваш личный тайный доступ к сайту по ftp.Пароль заменить на свой можно открыв файл и в коде в самом вверху указать его(пароль должен быть хеширован в md5):
Захешировать свой пароль в md5 можете например на сайте md5list.ru:
Среди прочих функций,в шелле можно видеть брутфорс,подбирает пароли к FTP/Mysql.
И ещё подборочка шеллов различных форматов:
На код некоторых шеллов могут ругаться ав,так что поместите их сразу в папку hacktool,находящююся в исключениях ав,думаю у каждого такая есть.. :smile-25: