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-Shells или как управлять сервером после получения доступа
Всем Салам. Сегодня решил поделится с вами довольно таки интересной темой. Когда мы получаем доступ к серваку, то делать руками гадать, что где находится довольно таки сложно и все это может затянуться. Поэтому, самым оптимальным решением является залить веб-шелл, через бекдор. Сегодня я не буду показывать, как найти бекдор или способы взлома, сегодня рассмотрим пару веб-шеллов, которые мне больше всего нравятся и по-моему они самые лучшие.
А как находить и закрывать эти бекдоры, я уже рассмотрю в следующей статье в цикле про безопасный php. Особо грузить вас тоже не будем, рассмотрим 2 веб-шелла.
Как по мне, веб-шелл b374k самый топовый. Давайте познакомимся с ним поближе.
Скачать данный шелл можно с гитхаба:
Но там же не один файл, как же его залить на сервак, не стоит беспокоится, разрабы об этом позаботились и внедрили удобный packer, с помощью одной команды, все это дело мы можем собрать в 1 файл.
Шелл для загрузки готов, жертва у нас будет наша любимая площадка с уязвимостями DVWA.
Файл успешно залит, давайте по нему перейдем и посмотрим, что за монстр:
Кроме экплорера, для удобного управления файлами на сервере, у нас также имеется полноценный терминал, Eval для выполнения скриптов, прямо отсюда мы можем подключится к БД, смотреть какие процессы запущены и еще дофига всего. Подробности можете прочитать на гитхаб.
С этим веб-шелом, я знаком уже давно. Выглядит он тоже более по хакерски и круто и обладает множеством крутых фишек.
Взял триальный хостинг, вот вам ссыль на шелл, можете зайти и поиграться:
На этом с веб-шеллами я закончу. Скоро будем, находить бэкдоры и рассматривать варианты заливки шелла на сервак. А так же рассмотрим момент с безопасным кодом, чтобы избежать заливки шела, к нам на сервак. Всем Удачи!
r0hack
Debug
Ondrik8
prodigy
r0hack
ActionNum
larchik
wooolff
explorer
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
wooolff
explorer
mrtyrel
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Надеюсь внёс немного ясности
Как будто топовую статью прочел))
Active member
w2ll3t0Rl1v3
Member
Ну а кто более продвинутый, тот может и сам сделать хорошую обфускацию. Только на вирустотале проверять не нужно ))) Как тогда проверить что обфускация удалась? Просто на локальный сервер установите несколько программ для поиска бэкдоров и прогоняйте.
Реальный пример веб-шелла, обнаруженного в Вордпресс
Найти и удалить вредоносный код с сайта не сложно. Гораздо сложнее отыскать в системе брешь, через которую он туда попал. Сегодня я покажу реальный пример веб-шелла, который недавно обнаружил на одном из сайтов.
Во-первых, что такое «веб-шелл»
Веб-шелл (web-shell) — вредоносный скрипт, который используется злоумышленниками для управления чужими сайтами и серверами.
Веб-шеллы чаще всего обеспечивают доступ к файловой системе, базам данных, позволяют выполнять команды терминала, осуществлять брутфорс паролей и т.п.
Веб-шелл представляет собой серьёзную угрозу безопасности сайта.
Обнаружить визуально веб-шелл в Вордпресс не просто. Сильно упростить задачу помогает сканирование хорошим антивирусом. Известные шеллы обычно находятся быстро. Как проверить сайт антивирусом я расскажу в следующий раз.
В этот раз обнаружился Web-shell by (c)ShAnKaR.php
Он лежал в папке локализаций Вордпресс, имел вполне логичное имя, и при беглом осмотре не вызывал никаких подозрений.
Конечно, если включить голову, расширение php в languages должно насторожить. Но когда файлов огромное количество, и от них рябит в глазах, заметить такое сложно.
Если обратиться к нему в браузере, выглядит это так:
Интерфейс Web-shell (c)ShAnKaR.php
Как видим, веб-шелл представляет собой полноценный файловый менеджер. Можно создавать, удалять, редактировать файлы, прям там же есть простенький текстовый редактор.
И самое главное — все это прекрасно работает.
Ну, а как попадают веб-шеллы на хостинг — это уже другая, более долгая история, которая тянет на книгу, как минимум.
Еще вернемся к этому.
Делаю сайты на Вордпресс с 2008 года. Не просто сайты, а уникальные инструменты для решения сложных бизнес‑задач с оптимизацией и поддержкой.
Веб-оболочка: что это такое, как это работает и как защитить ваши системы
Что такое веб-оболочка?
Это вредоносный скрипт, который внедряется в атакуемые системы. В большинстве случаев веб-серверы являются частью цели. Как только эти системы имеют веб-оболочку, киберпреступник может иметь удаленный контроль над ней. Следовательно, вы будете иметь постоянный доступ к системе и сможете управлять ею так, как вы хотите. Это означает, что веб-оболочки имеют возможность создавать бэкдоров на скомпрометированных системах иметь некоторый контроль и даже полный контроль.
Кроме того, веб-оболочки имеют гораздо большую досягаемость. Они также могут нарушать интерфейсы управления сетевыми устройствами. Поэтому крайне важно иметь хорошие практики безопасного управления сетью. Прежде всего, если это те, к которым ежедневно подключаются сотни и тысячи устройств. Рост телеработы влечет за собой риски безопасности, которые, хотя они и так известны, заслуживают особого внимания, поскольку, очевидно, работа в «защищенной» сетевой среде компании отличается от работы на дому. Тем не менее, вы можете спросить, не достаточно ли использовать VPN услуги, чтобы мы могли с полной безопасностью подключаться к ресурсам нашей организации, это только часть того, что должен делать администратор сети.
Обнаружение веб-оболочки
Основная сложность в обнаружении вредоносного ПО этого типа заключается в том, что злоумышленники могут применять методы шифрования для сокрытия своей вредоносной активности. Это является прямым следствием легкости ввода сценариев. Как мы знаем, для кибератак существует бесконечные возможности, и защита сетей должна быть усилена все больше и больше. Вот некоторые из эффективных методов обнаружения:
Какие инструменты и какие процедуры следует применять для процесса обнаружения этих вредоносных сценариев? Ниже мы даем ключевые рекомендации для эффективной защиты вас.
Как защитить свои системы и сети от веб-оболочек
Как мы уже отмечали ранее, эти веб-оболочки также вводятся непосредственно в системы и сети, которые являются жертвами, это происходит главным образом потому, что веб-приложения (в основном) и их уязвимая инфраструктура имеют разрешения на внесение изменений непосредственно в веб-каталог или на доступ к ним. кусочки веб-кода. Однако этот тип разрешения не должен предоставляться.
Следовательно, сами системы открывают двери для киберпреступников без каких-либо проблем для осуществления атак. Поэтому рекомендуется заблокировать разрешения на изменение. Теперь, если такой возможности нет, есть альтернатива.
Системы IDS / IPS и брандмауэр веб-приложений
Эта альтернатива заключается в реализации мониторинг целостности схема для файлов, размещенных в инфраструктуре приложения. Таким образом, администраторы будут иметь необходимую видимость любых возможных изменений, которые могут произойти в веб-каталогах и фрагментах кода.
Ресурсы АНБ
Мы даем Microsoft PowerShell Например. В общем хранилище вы найдете поддержку для обнаружения веб-оболочек с использованием схемы сравнения «Known Good». Кроме того, вы можете обнаружить подозрительные запросы в журналах веб-серверов.
Как мы видим, важно знать об основных уязвимостях, которые присутствуют не только на серверах веб-приложений, но и на тех, которые связаны с традиционными приложениями и даже с самими сетями передачи данных. Что касается кибератак, то здесь есть бесконечные возможности, и защитный экран должен быть максимально надежным. К счастью, высокодоступные онлайн-ресурсы и инструменты могут помочь нам как администраторам предотвратить более чем одну трагедию.
Пентестинг 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.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.