В мире веб-приложений и внешних периметров крупных компаний до сих пор встречаются классические, почти музейные уязвимости. Они как запертый на замок шкаф в центре мегаполиса: кажется, что все будут просто проходить мимо, но рано или поздно найдется тот, кто попробует дернуть за ручку.
В статье мы расскажем, как грамотная разведка и внимательность к деталям позволили превратить цепочку из не самых сложных уязвимостей в полную компрометацию внешнего сервера крупной ритейл-компании. Речь пойдет о забытых сервисах и оставленных в открытом доступе учетных данных. Итог — Remote Code Execution (RCE), доступ к коммерческой тайне и внутренней сети.
Этот кейс — наглядное подтверждение того, что для успешной атаки не всегда нужны сложные эксплойты или 0-day уязвимости. Зачастую достаточно старых и известных проблем, которые по-прежнему живут в инфраструктуре крупных компаний.
Разведка
Начнем с этапа разведки. Со стороны заказчика нам был предоставлен только скоуп размером в более 300 IP-адресов.
Сканирование хостов проводилось при помощи утилиты Nmap, в несколько итераций:
сначала были определены «живые» хосты;
далее эти хосты мы просканировали по всем портам;
для открытых портов при помощи флага -sV мы идентифицировали сервисы, запущенные на этих портах, и их версии.
Так, мы обнаружили хост (x.x.x.x), привлекший наше внимание большим количеством low-hanging fruit портов, среди которых был и 21-й порт. И, конечно, базовой проверкой при обнаружении FTP-сервера является проверка возможности прохождения аутентификации от лица анонимного пользователя. Мы это попробовали, и у нас получилось! Однако мы столкнулись с тем, что у анонимного пользователя нет прав ни на просмотр содержимого каталога, ни на загрузку или выгрузку файлов.
Помимо 21 порта на этом хосте были открыты 80 и 443 порты, на которых работал Apache веб-сервер. При обращении к корневой странице сервер возвращал пустое тело ответа, что стало поводом для проведения перебора директорий. В результате перебора по адресу https://x.x.x.x/soft мы обнаружили Directory Listing:
Анализируя содержимое каталогов, мы обнаружили очень много полезной информации, которая помогла развивать атаку. Так, мы нашли исходники и конфигурации используемого программного обеспечения, bash- и bat-скрипты, содержащие учетные данные, используемые для подключения к внутренним сервисам, а также один интересный текстовый файл, который представлял собой последовательность команд для FTP-сервера:
Как видно на скриншоте выше, выполняется подключение к FTP-серверу x.x.x.x (1 строка), далее вводятся логин и пароль (2 и 3 строки) и выполняется загрузка файла на сервер (5 строка).
Используя полученные учетные данные, мы прошли аутентификацию на FTP-сервере и обнаружили, что у данной учетной записи есть права на просмотр содержимого каталогов, а также на загрузку и выгрузку файлов.
Анализируя содержимое FTP-сервера, мы обнаружили, что его содержимое — то же, что мы видели в листинге каталогов веб-сервера. Так, мы определили, что при помощи опции Directory Listing веб-сервера Apache отображается содержимое корневого каталога FTP-севера, и соответственно, если мы загрузим файл на FTP-сервер, мы сможем обратиться к загруженному файлу через веб-интерфейс.
Эксплуатация
Мы написали простой web-shell на PHP: при обращении к данному файлу команда, переданная в параметре запроса cmd, передается в стандартную функцию языка программирования PHP system(), позволяющую выполнять команды на уровне операционной системы сервера:
Так как у полученной учетной записи были права на загрузку файлов, нам без проблем удалось загрузить PHP-файл в корневую директорию FTP-сервера:
При обращении к загруженному файлу PHP-код интерпретировался на стороне сервера, и, таким образом, мы могли выполнять команды в контексте операционной системы сервера:
Исследуя содержимое хоста через web-shell, мы обнаружили, что на этом хосте содержится большое количество файлов, относящихся к коммерческой тайне. Также на этом хосте мы нашли несколько файлов с кредами, в том числе для PostgreSQL, который был запущен локально на этом хосте:
Помимо этого, мы выяснили, что этот хост смотрит во внутреннюю сеть:
Мы незамедлительно сообщили заказчику о критической дыре в их внешнем периметре. Заказчик принял решение не развивать атаку дальше и оперативно устранил все выявленные проблемы.
Заключение
Вот так через листинг директорий веб-сервера Apache нам удалось получить учетные данные для подключения к FTP-серверу, подключившись к которому мы загрузили web-shell, что в дальнейшем дало возможность выполнять команды на сервере.
Итого:
загрузили web-shell и смогли выполнять команды на уровне операционной системы сервера, который смотрит во внутреннюю инфраструктуру;
получили доступ к конфиденциальной информации, хранящейся на скомпрометированном сервере;
получили информацию об используемом программном обеспечении, конфигурации для него и учетные данные для некоторых сервисов.
Подобные «дыры» в безопасности могут позволить потенциальным нарушителям получить доступ к конфиденциальной информации, например, к юридическим контрактам или персональным данным клиентов, нарушить доступность каких-либо ресурсов, осуществить дальнейшее проникновение во внутреннюю инфраструктуру.
Как избежать вышеперечисленного?
Необходимо правильно сконфигурировать веб-сервер Apache, в частности, отключить Directory Listing. Для этого в каталоге, для которого необходимо отключить листинг, нужно создать файл .htaccess и в нем добавить строку «Options -Indexes». Либо изменить основной конфигурационный файл apache2.conf, заменив в нем строку «Options Indexes FollowSymLinks» на «Options FollowSymLinks». Если эта функциональность необходима для определенных бизнес-сценариев, она должна быть доступна только для ограниченного круга авторизованных пользователей.
Также рекомендуется для веб-севера Apache явно запретить интерпретацию загруженных PHP-файлов. Для этого необходимо создать или изменить уже имеющийся файл .htaccess, добавив для необходимого каталога строку php_admin_flag engine off, отключая тем самым обработку PHP. Также при помощи параметра ForceType можно указать, чтобы для файлов возвращался определенный Mime Type, например, text/plain. При помощи параметра RemoveHandler можно удалить обработчиков для указанных расширений файлов.
Помимо этого, рекомендуется запретить анонимный доступ к FTP-серверу. Для этого в конфигурационном файле vsftpd.conf необходимо изменить строку anonymous_enable=YES на anonymous_enable=NO.
Также советуем отказаться от хранения учетных данных и иной конфиденциальной информации в текстовых файлах и использовать для этого, например, менеджеры паролей.
Часто ли вы сталкиваетесь с подобными уязвимостями на своих или клиентских проектах? И как решаете эту проблему — точечными правками конфигов или выстраиваете более сложные процессы для автоматического сканирования и контроля конфигураций?
Автор: Александр Федосеев, младший специалист по анализу защищенности