Как PAM-модуль позволил получить доступ к БД

В критичных базах PostgreSQL во внутренней инфраструктуре часто применяют внешнюю аутентификацию через PAM-модуль. Это позволяет реализовать ротацию паролей и ролевую модель на основе LDAP (AD), что при корректной настройке значительно повышает уровень защищённости.

В одном из проектов мы столкнулись с ситуацией, когда в подобной схеме аутентификации не были учтены все потенциальные векторы атаки. В результате нам удалось получить доступ к PostgreSQL с высокими привилегиями. В этой статье мы подробно разберём, в чём заключалась ошибка конфигурации, которая привела к компрометации БД, а также расскажем о последовательности эксплуатации.

Обход аутентификации через ошибки в конфигурации

В ходе проведения тестирования на проникновение удалось найти выполнение кода из внешней сети, получить реверс-шелл и повысить привилегии до Администратора домена (AD). Опустим подробности данной цепочки, так как они не совсем важны в контексте данной статьи.

После этого основной задачей, по запросу Заказчика, стало получение доступа к базе данных PostgreSQL, расположенной во внутреннем сегменте сети.

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

Анализ инфраструктуры начался с изучения конфигураций, обнаруженных во внутреннем GitLab-репозитории devops/ansible-playbooks, к которому удалось получить доступ благодаря высоким привилегиям в AD. В одном из плейбуков описывалась конфигурация сервиса PostgreSQL, включая настройки аутентификации.

Выяснилось, что использовались разные механизмы проверки пользователей в зависимости от источника подключения. В частности, для подключений из нашей подсети (Подключение выполнялось с адреса 192.168.1.59) требовалась аутентификация по логину и паролю, проверяемому через PAM-модуль.

Содержимое файла pg_hba.conf из GitLab:

Аутентификация в такой схеме проходит в два этапа:

1. При попытке входа PAM инициирует LDAP-запрос, проверяя, входит ли пользователь в группу CloudsqlAdmin.
2. Если проверка проходит успешно, PAM разрешает аутентификацию.

На первый взгляд конфигурация выглядела достаточно безопасной: доступ к базе разрешается только тем LDAP-пользователям, которые входят в группу CloudsqlAdmin. Проверка осуществляется через стандартный ldapsearch:

При использовании PAM-аутентификации в PostgreSQL следует учитывать важную особенность: PAM проверяет только логин и пароль (а также, при необходимости, IP-адрес или имя хоста). Однако сам модуль PAM не управляет учетными записями в PostgreSQL. Это означает, что роль пользователя должна быть предварительно создана в базе данных. Без этого, даже при успешной аутентификации через PAM, подключение будет отклонено.

С более подробной информацией можно ознакомиться в официальной документации — https://www.postgresql.org/docs/current/auth-pam.html 

Изучение сценариев реализации доступа

Для получения доступа к базе данных были рассмотрены следующие варианты:

1. Изменение пароля существующего пользователя, входящего в CloudsqlAdmin.
2. Поиск хостов, на которых используется альтернативный способ аутентификации.
3. Создание новой учётной записи в Active Directory, добавление в группу CloudsqlAdmin и создание необходимого пользователя в базе данных.

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

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

В PostgreSQL по умолчанию существует роль postgres, и мы решили проверить, а есть ли в Active Directory пользователь с таким именем. PAM-аутентификация настроена на проверку логинов и паролей через LDAP, который в данном случае интегрирован с Active Directory. И данный пользователь отсутствовал в AD. Таким образом, попадая в проверку PAM-модуля, проверялся пароль в AD, а не в самом PostgreSQL. Учитывая эту особенность, удалось определиться с дальнейшей последовательностью эксплуатации.

Ключевые шаги при эксплуатации

1. В ходе проведения атаки в Active Directory была создана новая учётная запись postgres.
2. Эта учётная запись была добавлена в группу CloudsqlAdmin, которая имеет доступ к базе данных PostgreSQL.
3. При подключении к PostgreSQL с использованием созданной учетной записи PAM-модуль аутентификации обратился к LDAP-серверу Active Directory и подтвердил, что пользователь входит в группу CloudsqlAdmin. После успешной аутентификации PostgreSQL сопоставил имя пользователя с локальной ролью postgres, обладающей правами суперпользователя, и предоставил соответствующий доступ.

В результате было выполнено подключение к БД с правами суперпользователя:

Заключение

Рассмотренный в статье пример демонстрирует, насколько важно уделять внимание безопасности взаимодействия всех компонентов инфраструктуры — как, например, в нашем случае: PostgreSQL, PAM и LDAP (AD) — при построении системы аутентификации. Нам удалось наглядно показать, как недостаточная проверка конфигурации PAM-модуля в подобной цепочке может привести к компрометации базы данных.