Что такое веб шелл
Обзор 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) — вредоносный скрипт, который используется злоумышленниками для управления чужими сайтами и серверами.
Веб-шеллы чаще всего обеспечивают доступ к файловой системе, базам данных, позволяют выполнять команды терминала, осуществлять брутфорс паролей и т.п.
Веб-шелл представляет собой серьёзную угрозу безопасности сайта.
Обнаружить визуально веб-шелл в Вордпресс не просто. Сильно упростить задачу помогает сканирование хорошим антивирусом. Известные шеллы обычно находятся быстро. Как проверить сайт антивирусом я расскажу в следующий раз.
В этот раз обнаружился Web-shell by (c)ShAnKaR.php
Он лежал в папке локализаций Вордпресс, имел вполне логичное имя, и при беглом осмотре не вызывал никаких подозрений.
Конечно, если включить голову, расширение php в languages должно насторожить. Но когда файлов огромное количество, и от них рябит в глазах, заметить такое сложно.
Если обратиться к нему в браузере, выглядит это так:
Интерфейс Web-shell (c)ShAnKaR.php
Как видим, веб-шелл представляет собой полноценный файловый менеджер. Можно создавать, удалять, редактировать файлы, прям там же есть простенький текстовый редактор.
И самое главное — все это прекрасно работает.
Ну, а как попадают веб-шеллы на хостинг — это уже другая, более долгая история, которая тянет на книгу, как минимум.
Еще вернемся к этому.
Делаю сайты на Вордпресс с 2008 года. Не просто сайты, а уникальные инструменты для решения сложных бизнес‑задач с оптимизацией и поддержкой.
От обычного пользователя до полноправного администратора сервера (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.
Знакомство с 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.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.
Веб-оболочка: что это такое, как это работает и как защитить ваши системы
Что такое веб-оболочка?
Это вредоносный скрипт, который внедряется в атакуемые системы. В большинстве случаев веб-серверы являются частью цели. Как только эти системы имеют веб-оболочку, киберпреступник может иметь удаленный контроль над ней. Следовательно, вы будете иметь постоянный доступ к системе и сможете управлять ею так, как вы хотите. Это означает, что веб-оболочки имеют возможность создавать бэкдоров на скомпрометированных системах иметь некоторый контроль и даже полный контроль.
Кроме того, веб-оболочки имеют гораздо большую досягаемость. Они также могут нарушать интерфейсы управления сетевыми устройствами. Поэтому крайне важно иметь хорошие практики безопасного управления сетью. Прежде всего, если это те, к которым ежедневно подключаются сотни и тысячи устройств. Рост телеработы влечет за собой риски безопасности, которые, хотя они и так известны, заслуживают особого внимания, поскольку, очевидно, работа в «защищенной» сетевой среде компании отличается от работы на дому. Тем не менее, вы можете спросить, не достаточно ли использовать VPN услуги, чтобы мы могли с полной безопасностью подключаться к ресурсам нашей организации, это только часть того, что должен делать администратор сети.
Обнаружение веб-оболочки
Основная сложность в обнаружении вредоносного ПО этого типа заключается в том, что злоумышленники могут применять методы шифрования для сокрытия своей вредоносной активности. Это является прямым следствием легкости ввода сценариев. Как мы знаем, для кибератак существует бесконечные возможности, и защита сетей должна быть усилена все больше и больше. Вот некоторые из эффективных методов обнаружения:
Какие инструменты и какие процедуры следует применять для процесса обнаружения этих вредоносных сценариев? Ниже мы даем ключевые рекомендации для эффективной защиты вас.
Как защитить свои системы и сети от веб-оболочек
Как мы уже отмечали ранее, эти веб-оболочки также вводятся непосредственно в системы и сети, которые являются жертвами, это происходит главным образом потому, что веб-приложения (в основном) и их уязвимая инфраструктура имеют разрешения на внесение изменений непосредственно в веб-каталог или на доступ к ним. кусочки веб-кода. Однако этот тип разрешения не должен предоставляться.
Следовательно, сами системы открывают двери для киберпреступников без каких-либо проблем для осуществления атак. Поэтому рекомендуется заблокировать разрешения на изменение. Теперь, если такой возможности нет, есть альтернатива.
Системы IDS / IPS и брандмауэр веб-приложений
Эта альтернатива заключается в реализации мониторинг целостности схема для файлов, размещенных в инфраструктуре приложения. Таким образом, администраторы будут иметь необходимую видимость любых возможных изменений, которые могут произойти в веб-каталогах и фрагментах кода.
Ресурсы АНБ
Мы даем Microsoft PowerShell Например. В общем хранилище вы найдете поддержку для обнаружения веб-оболочек с использованием схемы сравнения «Known Good». Кроме того, вы можете обнаружить подозрительные запросы в журналах веб-серверов.
Как мы видим, важно знать об основных уязвимостях, которые присутствуют не только на серверах веб-приложений, но и на тех, которые связаны с традиционными приложениями и даже с самими сетями передачи данных. Что касается кибератак, то здесь есть бесконечные возможности, и защитный экран должен быть максимально надежным. К счастью, высокодоступные онлайн-ресурсы и инструменты могут помочь нам как администраторам предотвратить более чем одну трагедию.