SAP SDM. 6 букв — много проблем
Существует множество способов скомпрометировать ERP-систему SAP. Это и неудивительно, ведь SAP-инсталляция представляет собой огромное число различных модулей, написанных на разных языках программирования и доступных пользователю по самым разнообразным протоколам: от классического HTTP до проприетарного DIAG.Как результат, каждый месяц компания SAP AG выпускает патчи (security notes), закрывающие «дыры» в ERP-системе, а эксперты по информационной безопасности получают благодарности на официальном ресурсе компании-разработчика (мелочь, но приятно).Не будем вдаваться в подробности и выяснять, зачем и для чего кому-то пытаться скомпрометировать ERP-систему. Времена дефейсов сайтов просто ради забавы прошли, в индустрии у всех на слуху термины «киберкрайм», «таргетированные атаки» и прочие APT. Зачем ломать сайт интернет-магазина, о безопасности которого наверняка заботятся владельцы, если можно сразу (при определенных условиях, конечно) атаковать ERP-систему, которая менее защищена, но при этом хранит и обрабатывает наиболее критичные данные? И вот, наконец, после нескольких вводных «бла-бла», перейдем к тому, как можно скомпрометировать SAP-систему.В сегодняшней статье разберем слегка экзотический способ. Попробуем проверить на прочность сферу, где атакующего не ждут, — инфраструктуру разработки приложений.Будем атаковать SAP NetWeaver Deployment Infrastructure, а именно Software Deployment Manager (SDM).
Как видно на схеме, инфраструктура разработки приложений для SAP-системы состоит из множества различных сервисов:
Design Time Repository (DTR) — репозиторийComponent Build Service (CBS) — отвечает за конфигурацию JDI и администрирование транспортного ландшафтаChange Management Service (CMS) — используется для отслеживания версионности развернутых приложений на различных серверахSoftware Landscape Directory (SLD) / NS — Name Server отвечает за уникальность имен объектов. SLD позволяет управлять имеющимися компонентами системы.The Developer Studio — SAP«s development environment базирующийся на Eclipse
Все это — вполне обычные сервисы, используемые для разработки. Однако отдельно стоит упомянуть о ключевом для нас (и для атакующего) компоненте, который дает прямой доступ к ERP-системе, — Software Deployment Manager (SDM).SDM — это сервис, при помощи которого разработчики деплоят приложения и сервисы на Java Application Server. Собственно, он позволяет загружать и запускать на сервере приложений Java-приложения (*.ear, *.war, *sda).Итак, идея для атаки проста:1) находим SDM2) компрометируем SDM3) используя SDM, деплоим shell4) имея доступ к ОС сервера SAP-системы, легко получить доступ к данным, обрабатываемым в ней
Начнем.
1. Находим SDM-сервисВстретить SDM-сервис в типичном SAP-ландшафте не так уж сложно. Достаточно поискать порты:5NN17 — Admin Port5NN18 — GUI Portгде NN — номер SAP-инстанции.
Нас больше интересует порт 518, так как он предоставляет интерфейсы для загрузки апплетов, административный же порт предназначен для того, чтобы остановить, перезапустить или запустить SDM-сервисы, например, отправив следующий пакет на порт 517:
[10 spaces]56
Используя SDM-клиент (стандартный клиент написан на Java) и подключившись к порту 5NN18, атакующий увидит диалоговое окно с просьбой авторизоваться.
Как думаете, где атакующему взять эти самые логин и пароль?
2. Компрометируем SDM Собственно, с логином все просто. Имя пользователя стандартно — admin. Проблема с паролем. Перебирать — не лучшая идея, так как после 3 неудачных попыток ввода пароля службы SDM останавливаются (привет, еще один DoS).Давайте же разберемся: как работает аутентификация?
А работает она следующим образом:1) пользователь вводит пароль2) клиент считает хеш введенного пароля3) клиент отправляет хеш пароля на сервер4) сервер сравнивает полученный хеш с хешем из конфиг-файла5) если все ОК, то юзер получает доступ в SDM
Выходит, что атакующему вовсе не обязательно знать пароль, достаточно узнать хеш и отправить его на сервер. Как мы знаем, хеш хранится на сервере в конфиг-файле:…\SDM\program\config\sdmrepository.sdc
Перед атакующим новая задача: прочитать конфиг sdmrepository.sdc и таким образом узнать хеш пароля администратора, после чего использовать его для аутентификации в SDM-сервере.
Что ж, уязвимостей в SAP-системе, позволяющих удаленному атакующему без аутентификационных данных прочитать файл, вполне достаточно. Это может выглядеть так:1) RCE через CTC-сервлет (notes 1467771, 1445998)2) множество различных XXE-уязвимостей (note 1619539)3) уязвимости выхода за пределы каталога (note 1630293)4) анонимное чтение файлов с использованием функции SAP MMC (notes 927637, 1439348)
Рассмотрим в данной статье еще один способ чтения файлов с сервера SAP (естественно, без аутентификации).
Существует такой сервис, как SAP Log Viewer. Как понятно из названия, предназначен он для просмотра лог-файлов SAP-систем. Через Log Viewer можно посмотреть содержимое лог-файла как на локальной системе, так и на удаленной, — главное, чтоб был открыт один из этих портов сервера Log Viewer: 26000 (NI), 1099 (RMI), 5465 (Socket).
Ну, а дальше все просто и понятно (кроме одного момента, почему же SAP не аутентифицирует пользователя на сервере Log Viewer):1) подключаемся к серверу Log Viewer2) регистрируем файл sdmrepository.sdc как лог-файл3) успешно его читаем
Имея на руках хеш пароля SDM администратора, остается только использовать его для аутентификации. Для этого можно:1) написать свой SDM-клиент2) модифицировать стандартный клиент (благо Java позволяет это сделать)3) подменить значение хеша до отправки его на сервер с помощью прокси
Я выбрал третий вариант как наиболее простой.
Как результат — получаем доступ в SDM-сервер с правами администратора. SDM-сервер скомпрометирован.
3. Используя SDM, деплоим shell
На данном этапе у атакующего появляется широчайший спектр возможностей. Наиболее интересные:1) модифицировать существующую программу, внедрив бекдор, например, или изменив логику ее работы2) получить доступ к ОС SAP-сервера, загрузив на сервер приложений простейший JSP shell
Атакующему, как правило, тяжело вникнуть в бизнес-процессы компании, поэтому у него появляется стойкое желание получить доступ в БД и, как результат, ко всем критичным данным.
4. Получаем доступ к БД Имея доступ к операционной системе, на которой работает SAP, очень легко получить доступ и в БД, залогинившись под пользователем sysdba, для чего атакующему достаточно выполнить команду (в случае использования Oracle как СУБД): sqlplus / as sysdbaВ результате атакующий получает доступ ко всем критичным данным, используемым в компании:
Выводы Казалось бы, что еще обсуждать, — атакующий добился поставленной цели. Однако на данном этапе может начаться самое интересное. К примеру, злоумышленник может попытаться скомпрометировать соседние SAP-системы, например используя доверенные RFC-соединения, однако эта тема выходит за рамки данной статьи.Подводя итог, хочется вновь написать известную всем фразу: безопасность — штука комплексная. Нельзя защитить одну систему, не защитив соседние. Злоумышленник всегда попробует атаковать там, где вы этого меньше всего ожидаете, так будьте же к этому готовы.
