ВХ05. Upload, заливка шелла

upload1

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

  • А нужно ли что-то заливать?
  • Форма для заливки файла
  • Правка кода/шаблона
  • Правка конфига
  • RFI / LFI
  • Доступ по ftp/ssh
  • Заливка через SQL-инъекцию
  • RCE
  • Ссылки

А нужно ли что-то заливать?

На самом деле нет.

Всего доброго, с вами был дядя кроба.

Если наша конечная цель это диктатура пролетариата получение полного контроля над хостом, то промежуточная цель - это исполнение своего кода (RCE, remote code execution, то самое, сокровенное ЭР-ЦЭ-ЙЭ).

Допустим, вы нашли скрипт с кодом типа такого:

Можно сразу пробовать кинуть бекконект на свою машину и дальше уже поднимать права и т.д. и т.п. Заливка веб-шелла, в данном случае, всего лишь буржуазная прихоть для комфорта и удобства.

Но на практике, подобные скрипты будут попадаться очень нечасто. И шелл заливать, все же придется. И поможет нам ...

Форма заливки файла

Вы наверняка не один раз видели что-то типа такого:


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

Возможные препятствия:

1. Защита на стороне клиента (html/javascript). Можно даже не считать за защиту, так как в большинстве случаев, какой бы изощренный скрипт ни был на стороне клиента, его можно будет обойти с помощью локального прокси (burp suite или что-то подобное, например, крякнутый burp suite).

Пример кода (ничего, кроме картинок, залить нельзя):

Ну по идее нельзя, а на самом деле можно (если помимо бурпа что-то  есть).

2. Проверка mime-type файла. Простая проверка, при которой тип файла определяется по http-заголовкам и сверяется со списком допустимых (например - image/jpeg). которую можно обойти с помощью того же локального прокси.

Пример кода:

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

А вариантов много:

Очень часто Apache так настроен, что не распознав первое расширение файла, он считывает следующее (пример с .php.blablabla) и исполняет код (зависит от того, что в файле mime.types). А может и исполнить файл как php, если он без расширения.

Что касается .htaccess, то можно заставить Apache выполнять код, записанный в файлы с расширением, которое проходит валидацию, либо вообще заставить выполнять код, записанный в .htaccess:

И еще возможные вариации:

  • смена регистра (.PHP, .PhP)
  • добавление валидных расширений (.php.png, .phg,php)
  • добавление нуллбайта (.php%00.png - работает до версии php 5.3.4)
  • изменение длины имени файла(AAAA....AAAAA.php - может быть так, что имя файла обрезается до определенного кол-ва символов)
  • подставляем точку с запятой  (.php;.png - работает на IIS 6 и ниже)
  • подставляем ../ и все возможные варианты для обхода, выхода из директории
  • urlencode, двойной urlencode,
  • микс всего вышеперечисленного

4. Проверка через getimagesize(). Если код на бекенде такой:

В данном случае берем картинку и пишем php-код в exif-данные. Для этого можно воспользоваться онлайн-редактором или десктопными утилитами (Linux - gimp, exiftool etc, Win - Exif Pilot, AnalogExif, ExifManager etc).

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

5. Прочее. Фантазия разработчиков неисчерпаема, (как и твои обещания перестать колоться спайсом) и помимо ситуаций, описанных выше, могут быть и совершенно другие:

  • Скрипт принимает на заливку zip-файлы, которые потом распаковывает на сервере в папке. Помимо достаточно очевидного варианта (положить шелл в архив и залить), можно отправить zip-бомбу.
  • Скрипт принимает файлы с xml-содержимым или sql-запросами (для импорта в бд, например), читает файл, выполняет определенные операции, а потом файл удаляет. В таком случае нужно вызвать ошибку или замедлить выполнение скрипта, чтобы успеть обратиться к нему.
  • Файлы могут заливаться как есть, но затем переименовываться по какому-то неизвестному способу (в духе md5(дата + имя файла + кличка собаки разраба)). И проблема не в том, чтобы залить свой код, а в том, чтобы его просто найти.
  • Может быть ситуация, что из-за директив в .htaccess файл прекрасно заливается, но не исполняется. Придется искать LFI или способ удалить/подменить .htaccess (если проблема вообще в нем).
  • И еще десятки вариантов...

Еще один момент - не надо недооценивать простой брут директорий/файлов. Иногда совершенно не обязательно получать доступ к админ-панели (брутфорсом или sql-инъекцией), достаточно найти скрипты с функционалом для заливки. Это могут быть wysiwig-редакторы, менеджеры файлов, отладочные скрипты, бекаперы и т.д.

Даже если мы не можем залить шелл, но можем залить свои файлы, это тоже можно использовать. Если в том же .html и не будет отрабатывать php-код, то вот javascript прекрасно отработает (а это XSS).

В целом это всё, что касается заливки шелла через форму для загрузки файлов.

Правка кода/шаблона

В некоторых веб-приложениях есть возможность править код (самого приложения или плагинов). Как в том же WordPress:

Залить шелл несложно - достаточно дописать код без ошибок, который не будет влиять на основной функционал, типа такого:

Порой можно править шаблоны, однако если вставить просто php-код, то он не отрабатывает. Поэтому нужно смотреть, что это за CMS, какой там шаблонизатор используется (и используется ли вообще) и как в нем вставить код (если это вообще возможно).

Для примера:

1. Шаблонизатор Smarty.

2. Шаблонизатор Blade фреймворка Lavarel.

3. Старая версия Livestreet CMS

4. Старая версия Xoops

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

Правка файлов настроек

Наверняка вы встречали что-то вроде такого:

Имя администратора
Пароль администратора
Допустимые расширения
Цвет боевых медведей

Ну или подобное:

Или подобное:

В чем здесь проблема?

Иногда, настройки хранятся не в базе данных, а файлах типа config.php и подобных. И это нормально, те же настройки подключения к базе данных не получится хранить в базе данных (тут должен быть мем с xzbit'ом).

И когда вы меняете настройки, файл перезаписывается. Если вводимые данные недостаточно фильтруются, можно дописать свой код и залить шелл.

Например (было):

Мы отредактируем настройки и вместо пользователя root напишем:

В итоге:

Если в скрипте экранируются или удаляется кавычки (одинарные/двойные), мы можем использовать обратный слеш и все равно добиться своей цели:

В одном поле мы используем обратный слеш, в другом - внедряем наш код и комментируем оставшуюся часть, чтобы скрипт не упал с ошибкой.

Если и обратные слеши нельзя использовать, мы можем использовать такой трюк:

Но это сработает только со строками в двойных кавычках. С одинарными - 2 предыдущих способа либо никак (ну можете пофаззить, мож найдете 0day).

Идем далее.

Заливка через LFI/RFI. Все достаточно банально и за годы не сильно изменилось. Можно прочитать в прошлой статье.

Доступ по ftp/ssh

Вариантов тут много - сбрутить доступ, украсть стилером, найти в раздаче чужих логов, прочитать файлы конфигурации, написать (ага, конечно) эксплоит на уязвимый сервис или добыть с помощью СИ. Причем помимо доступа по ftp/ssh, можно вспомнить, что есть еще и Webdav, и доступы по vnc/rdp. До кучи можно вспомнить панели управления хостингами (cpanel, isp, vesta, webmin, plesk etc) - хотя в этом случае смысла в дополнительных файлах мало, но идею вы уловили.

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

Может кому-то и покажется излишним, но я всё же продемонстрирую priv8 технику залива на примере доступа через ssh в filezilla:

ХОЧЕШ ЕЩЕ ПРИВАТНЫХ ТЕХНЕК, ПОДПИСУВАЙСЯ НА НАШ КАНАЛ В ТЕЛЕГРАММЕ - @DARK_CARDING_RICH_PRIVATE_MONEY_HACKING_CASH_DEEP_NET

Заливка шелла через SQL-инъекцию

Залить шелл, используя sql-инъекцию, не так просто, как может показаться на первый взгляд. Например, для самого частого случая (субд mysql), должны быть соблюдены все условия:

  1. SQL-инъекция в SELECT запросе (into outfile не работает в insert, update, delete)
  2. Full Path Disclosure. Должен быть известен абсолютный путь до папки (или мамки), куда мы хотим залить шелл.
  3. У нас должно быть достаточно прав, чтобы залить шелл в папку (может быть ограничение с помощью директивы mysql secure-file-priv)
  4. У пользователя, от которого мы выполняем запросы, должны быть права на это (file_priv=y)
  5. Одинарные кавычки не фильтруются.

И если звезды сошлись, то используя sqlmap с ключом --os-shell либо адски насилуя адресную строку, можно залить шелл через скулю.

Если есть учетка и доступ к adminer, phpmyadmin или можно подключится к серверу напрямую (порт 3306), то можно залить шелл запросом вроде такого:

Но не всё так просто. Помимо того что необходимо соблюдение кучи условий, веб-сервер может находится на одном хосте, а СУБД на другом. Залить - зальетесь, а вот куда именно - придется еще выяснять.

Что касается прочих СУБД, то они вам будут встречаться существенно реже. Но если уж вам и встретится тот же Oracle, то вы уже будете на том уровне, чтобы разобраться самостоятельно. Открываем документацию по синтаксису конкретной СУБД, ищем функции для работы с файлами/исполнения команд. Ну или в гугл, как вы это любите.

RCE

Как изначально и было сказано, RCE - это и есть конечная цель, а не заливка шелла. Нет толку от шелла, если нельзя исполнить свой код.

Но всё же.

Есть уязвимости, которые сразу дают возможность выполнять свой код или давать команды серверу. Однако порой куда проще залить шелл, чтобы рулить сервером легко, весело и непринужденно, чем выполнять команды через написанный на коленке скрипт.

Веб-шелл - для комфорта.

Ссылки

  • https://www.owasp.org/index.php/Unrestricted_File_Upload
  • https://rdot.org/forum/showthread.php?t=3 (Заливка шелла в разные CMS)
  • https://rdot.org/forum/showthread.php?t=4 (Заливка шелла в разные форумы)
  • https://habr.com/ru/post/100961/ (Уязвимость связки PHP+nginx)
  • https://habr.com/ru/post/224351/ (Опасный getimagesize() или Zip Bomb для PHP)
  • https://habr.com/ru/post/44610/ (Безопасная загрузка изображений на сервер. Ч.1)
  • https://habr.com/ru/post/44615/
  • (Безопасная загрузка изображений на сервер. Ч.2)
  • https://habr.com/ru/post/459254/ (Ещё лучшая ZIP-бомба)