Введение
Иногда цепочка, на первый взгляд незначительных уязвимостей, может обернуться серьёзной угрозой для безопасности организации. В этой статье мы расскажем о том, как совокупность таких «мелочей» привела к полной компрометации инфраструктуры.
Ключевым звеном в атаке стал APK-файл, обнаруженный на внешнем периметре.
Мы подробно разберём каждый этап этой цепочки — от первичного доступа до полного контроля над внутренними системами — и покажем, как критичные недостатки в защите, будучи объединёнными, могут нанести сокрушительный удар по безопасности компании.
На следующей схеме показана цепочка эксплуатации:
Далее мы подробно разберем каждый этап атаки.
Первый этап — сбор информации
Как обычно, тестирование началось со сбора данных о ресурсах компании из открытых источников: IP-адреса, домены, открытые порты, а также данные, которые могли оказаться в открытом доступе. Далее мы приступили к перебору директорий и на одном из доменов нашли каталог /home. В этой директории хранились отладочные сборки мобильных приложений в формате APK. Наличие в открытой директории отладочных APK сразу привлекло внимание — подобные файлы редко оказываются в общем доступе и могут содержать важную информацию.
Скачав APK-файлы, мы приступили к их исследованию с помощью декомпилятора — использовали jd-gui для просмотра декомпилированного Java-кода. Изучая исходный код, мы нашли в нём параметры авторизации для доступа к одному из внешних хостов. Получив доступ к этому хосту, закрытому аутентификацией, мы изучили доступный функционал, но не обнаружили ничего интересного. Далее приступили к перебору доступных виртуальных хостов и обнаружили среди них приложение — платформу для обмена текстовыми данными (все приложения на данном ресурсе были закрыты Basic Auth, и ранее обнаруженные учётные данные позволили получить доступ к этому сервису). Поискав информацию о нём в интернете, мы обнаружили репозиторий с исходным кодом этого приложения на GitHub.
После первичного сбора информации и получения доступа к внутренним ресурсам мы сосредоточились на исследовании обнаруженного open-source приложения, поскольку оно представляло наибольший интерес с точки зрения возможных уязвимостей.
Изучение open-source приложения и обход директорий
В ходе аудита безопасности open-source приложения мы первым делом проверили раздел GitHub Issues. Перед тем как переходить к изучению исходного кода, всегда стоит посмотреть, какие проблемы были обнаружены ранее.
После этого мы начали вручную смотреть исходный код приложения и довольно быстро заметили необычную реализацию: путь к файлу формировался из пользовательского ввода практически напрямую.
В результате в одной из функций приложения мы обнаружили уязвимость обхода пути (path traversal). Она позволяла передавать произвольный путь в параметрах запроса, что давало доступ к файлам за пределами рабочей директории веб-приложения.
Интересно, что в коде была реализована защита от обхода директорий. Перед формированием пути к файлу все вхождения ../ просто удалялись из пользовательского ввода:
|
1 2 |
$css_file= implode('/', $segments); $css_file =str_replace('../', '', $css_file); |
Однако эта защита оказалась недостаточно эффективной — она не учитывала альтернативные способы обхода. Например, используя конструкции с чередованием ..././, можно обойти фильтр, поскольку при нормализации путей ./ игнорируется, а ... воспринимается как часть имени папки, что позволяет фактически выйти за пределы разрешённой директории.
Таким образом, для обхода используемой защиты был сформирован следующий GET-запрос, позволяющий получить доступ к каталогу /etc/passwd:
|
1 |
GET hostname.com/vulnerable/path/..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././..././etc/passwd |
Содержимое файла /etc/passwd было успешно возвращено сервером:
Успешная эксплуатация уязвимости открыла доступ к конфиденциальным файлам — включая конфигурации веб-сервера, сведения об установленных сервисах и журналы. Доступ к файловой системе стал ключевым этапом в цепочке атаки, который в дальнейшем позволил получить удалённое выполнение кода (RCE).
Изучение внутренней конфигурации сервера
В результате эксплуатации уязвимости path traversal мы получили возможность читать произвольные файлы, включая данные конфигурации веб-сервера.
Так как мы знали, что используется nginx, мы стали изучать какие виртуальные хосты присутствуют на сервере. Определив список активных виртуальных хостов, мы перебрали доступные директории и выделили среди них потенциально интересные. После этого мы приступили к исследованию файлов, расположенных в этих директориях. Так нам удалось обнаружить временные файлы и логи, которые могли содержать чувствительную информацию. В результате анализа файлов access.log и error.log на одном из хостов были обнаружены пути к нескольким php файлам. Дальнейшее изучение логики работы одного из них помогло найти уязвимость, позволяющую внедрять и выполнять произвольные команды на сервере, что стало основным шагом в развитии дальнейшей атаки.
Инъекция кода
Анализ принципа работы обнаруженного ранее PHP-скрипта показал, что он принимает значение параметра id из строки запроса и напрямую передаёт его в системную оболочку без какой-либо фильтрации или экранирования. Такая реализация не является безопасной, что открывает прямой путь для внедрения и выполнения произвольных команд операционной системы.Ниже показано содержимое обнаруженного PHP-файла:
|
1 2 3 4 5 6 7 8 9 10 |
<?php $id=$_REQUEST['id']??null; if(!$id){ echo 'no id'; exit; } chdir("/path/to/executable"); $output=shell_exec('./run_tool -c config.json -i '.$id); echo $output; ?> |
Мы решили проверить работоспособность этого вектора атаки и сформировали специальный запрос, в котором к параметру id добавили команду вывода списка файлов в каталоге пользователя (Тут и ниже для читаемости не закодированы пробелы):
|
1 |
GET /file.php?id=asd; ls -la /home/www-data/wwwroot/; HTTP/1.1 |
В ответ сервер вернул содержимое директории, подтвердив, что передаваемые команды действительно выполняются на сервере.
Далее мы отправили ещё один запрос с командой uname -a, чтобы получить полную информацию о ядре операционной системы и аппаратной платформе:
|
1 |
GET /file.php?id=asd; uname -a; HTTP/1.1 |
Ответ сервера содержал полный вывод команды: название ядра, версию, архитектуру и время сборки:
Такая уязвимость предоставляет возможность удалённого выполнения системных команд, что существенно увеличивает возможности для дальнейшего развития атаки и закрепления в инфраструктуре Заказчика. Получив доступ к командной оболочке, мы смогли глубже исследовать внутренние сервисы и механизмы взаимодействия между компонентами системы — подробнее об этом расскажем в следующей статье.
Заключение
Поэтапная эксплуатация обнаруженных уязвимостей позволила нам получить удалённый доступ и добиться выполнения произвольного кода на сервере. Ключевым элементом во всей цепочке стала уязвимость обхода путей в open-source приложении, открывшая доступ к конфиденциальной информации и внутренним механизмам конфигурации сервера.