Bank: разбор сложной машины aclabs.pro со взломом PIN-кода, пивотингом и побегом из контейнера
Краткое описание задания
Bank - сложная лабораторная машина от aclabs.pro, рассчитанная на последовательное прохождение нескольких этапов атаки. В сценарии задействованы две системы: Windows-хост, доступный из внешней сети, и Linux-машина, скрытая во внутреннем сегменте. Всего предусмотрено шесть флагов.
Сначала необходимо исследовать веб-приложение на Windows-сервере, обнаружить утечку учетных данных и получить удаленный доступ через WinRM. Затем предстоит повысить привилегии с помощью ошибочно настроенных ACL, найти второй сетевой интерфейс и выполнить переход к Linux-хосту. На нем потребуется подобрать PIN-код, получить доступ к закрытому сервису, использовать уязвимость FTP, организовать обратное подключение через PostgreSQL, проанализировать неизвестный бинарный файл и, наконец, выйти из контейнера на хостовую систему.
Задание хорошо демонстрирует несколько техник из MITRE ATT&CK: разведку сетевых служб, поиск скрытых файлов, эксплуатацию публичного приложения, использование незащищенных учетных данных, удаленный доступ через WinRM, подбор секретов, злоупотребление SUID-файлами и побег из контейнера через Docker socket.
Первичная разведка
На первом этапе выполняется сканирование доступных портов. Набор обнаруженных служб напоминает Windows-инфраструктуру с доменными компонентами, а веб-сервис на стандартном HTTP-порту становится главным направлением дальнейшего анализа.
На главной странице размещена шуточная информация о сотруднике банка Котофее Шерстяном. Само описание не дает прямого пути к флагу, однако исходный код страницы содержит более полезные сведения. В нем обнаруживается ссылка на `devops.php` - страницу, которую необходимо изучить особенно внимательно.
Содержимое `devops.php` подсказывает, что данные сотрудников хранятся в каталоге `employees`, причем приложение не показывает скрытые файлы. Важная деталь заключается в том, что такие объекты не отображаются пользователю, но продолжают учитываться внутренним счетчиком. Это позволяет предположить наличие скрытых файлов и перейти к перебору имен.
Для поиска удобно использовать фаззинг каталогов и файлов. В качестве шаблона следует проверять варианты со скрытой точкой перед именем, а также учитывать расширение `.txt`. В результате обнаруживается файл `script.txt`, недоступный из обычного списка.
Утечка учетных данных и первый флаг
При открытии файла в браузере кириллические символы отображаются некорректно, поэтому содержимое лучше получить консольной утилитой. Внутри находится параметр `encoded_credentials`. Формат строки указывает на кодирование Base64.
После декодирования становятся доступны имя пользователя и пароль. Эти данные необходимо проверить на других сервисах, прежде всего на WinRM. Успешная проверка подтверждает, что учетная запись действительно позволяет удаленное подключение к Windows-системе.
После авторизации через WinRM первый флаг находится на рабочем столе пользователя `web-srv`. На этом этапе важно не ограничиваться автоматическими средствами постэксплуатации. Вывод WinPEAS, SharpHound и PowerUp может содержать множество потенциальных направлений, но далеко не каждое из них применимо к конкретной конфигурации.
Повышение привилегий через ACL
Следующий шаг - ручной анализ разрешений пользователя, групп и объектов Active Directory. В системе обнаруживается некорректно настроенное право `GenericWrite`. Оно позволяет изменять свойства учетной записи или связанного объекта, что открывает путь к злоупотреблению ACL.
Такие ошибки часто остаются незаметными при поверхностной проверке: пользователь может не состоять в привилегированной группе напрямую, но иметь возможность менять параметры объекта, который связан с административным доступом. Используя предоставленное разрешение, удается изменить учетные данные или параметры нужной учетной записи и получить более высокий уровень доступа.
После повышения привилегий становится доступен второй флаг. Этот этап показывает, почему при анализе Windows-систем нужно изучать не только локальные группы, но и разрешения на объекты домена, даже если сами группы выглядят пустыми или не содержат очевидных привилегированных пользователей.
Поиск внутреннего сегмента
На привилегированной Windows-машине обнаруживается второй сетевой интерфейс. Он связывает систему с изолированным внутренним сегментом, недоступным напрямую с атакующей машины.
Проверка маршрутов, адресов интерфейсов и соседних узлов позволяет определить Linux-хост. Далее выполняется сканирование внутренней сети через уже полученный доступ. Такой подход соответствует технике обнаружения удаленных систем: сначала используется скомпрометированный узел, затем через него изучается дополнительная инфраструктура.
На найденной Linux-машине работает веб-приложение, защищенное PIN-кодом. Для его обхода нужно понять логику проверки, формат запроса и способ формирования контрольного значения.
Подбор HMAC PIN-кода
Приложение использует короткий PIN-код, а запросы защищает HMAC. Это не означает, что секрет невозможно подобрать: при небольшом диапазоне значений перебор остается реалистичным, особенно если сервер не применяет ограничение частоты запросов.
Для автоматизации удобно написать небольшой Python-скрипт. Он формирует очередное значение PIN, вычисляет соответствующую HMAC-подпись и отправляет запрос приложению. Признаком успеха становится изменение ответа, HTTP-кода или появление нового содержимого.
После нахождения правильного PIN открывается доступ к защищенному хранилищу. Внутри появляется новый сервис, которого не было видно во время первоначального внешнего сканирования. Это наглядно демонстрирует, что поверхность атаки может меняться после получения доступа к приложению.
Эксплуатация FTP и подключение через PostgreSQL
На Linux-хосте обнаруживается уязвимый FTP-сервис. Его версия содержит известную ошибку, позволяющую выполнить действия до аутентификации. Эксплуатация дает начальную точку внутри контейнера или служебного окружения.
Дополнительный путь связан с PostgreSQL. При наличии подходящих прав функция `COPY FROM PROGRAM` позволяет запустить команду операционной системы от имени процесса базы данных. Если соединить эту возможность с заранее подготовленным обработчиком обратного подключения, можно получить реверс-шелл.
После установления соединения становится доступен контейнер. Четвертый флаг расположен в корневом каталоге, что подтверждает успешное проникновение в изолированную среду.
Анализ неизвестного бинарного файла
В контейнере находится пользовательский бинарник. Простого запуска недостаточно: необходимо понять, какие проверки он выполняет и какие файлы читает.
Работу начинают со статического анализа - проверяют строки, зависимости, вызываемые функции и права файла. Затем бинарник исследуют в отладчике, отслеживая обращения к файловой системе, сравнения строк и системные вызовы. В процессе выясняется, что программа позволяет получить содержимое `/etc/shadow` или обойти ограничения, связанные с чтением этого файла.
Полученный хэш пароля учетной записи root можно анализировать офлайн. После восстановления пароля удается перейти на привилегированного пользователя внутри контейнера и забрать пятый флаг.
Побег через Docker socket
Финальная проверка начинается с анализа `/var/run/docker.sock`. Этот Unix-сокет доступен из контейнера и разрешает запись. Такая конфигурация крайне опасна: тот, кто может взаимодействовать с Docker API, потенциально способен создать новый контейнер с расширенными правами и подключить к нему файловую систему хоста.
Для проверки риска достаточно определить, какие операции разрешены через сокет, и выяснить, доступен ли запуск контейнера с примонтированным корневым разделом. Если хостовая файловая система подключается внутрь нового окружения, становятся доступны системные файлы основной машины, включая каталог root.
После перехода за пределы контейнера остается прочитать финальный флаг на хосте. Таким образом, цепочка завершается полноценным выходом из контейнера и захватом корневой системы.
Основные выводы
Машина Bank построена как связная цепочка, где каждый этап открывает следующий:
1. веб-разведка и поиск скрытого файла;
2. декодирование учетных данных;
3. подключение через WinRM;
4. повышение привилегий с использованием ACL;
5. обнаружение второго сетевого интерфейса;
6. пивотинг во внутреннюю сеть;
7. перебор HMAC-защищенного PIN-кода;
8. эксплуатация FTP и PostgreSQL;
9. анализ кастомного SUID-бинарника;
10. побег через доступный Docker socket.
Главный практический урок - не полагаться только на автоматические сканеры. Веб-исходники, необычное поведение счетчиков, права объектов, сетевые интерфейсы и особенности контейнерной конфигурации часто дают больше информации, чем стандартный набор утилит.
С точки зрения защиты необходимо закрывать скрытые файлы от публикации, не хранить пароли даже в кодированном виде, регулярно проверять ACL, ограничивать доступ к внутренним интерфейсам, обновлять FTP-серверы, запрещать опасные возможности PostgreSQL и не монтировать Docker socket в контейнеры без крайней необходимости. Именно совокупность небольших ошибок в этой лаборатории превращает отдельные уязвимости в полноценный сценарий компрометации инфраструктуры.