Безопасность как искусство
120,11
рейтинг
2 сентября 2014 в 13:11

Разработка → 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).

image

Как видно на схеме, инфраструктура разработки приложений для 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) находим SDM
2) компрометируем SDM
3) используя SDM, деплоим shell
4) имея доступ к ОС сервера SAP-системы, легко получить доступ к данным, обрабатываемым в ней

Начнем.

1. Находим SDM-сервис


Встретить SDM-сервис в типичном SAP-ландшафте не так уж сложно. Достаточно поискать порты:
5NN17 — Admin Port
5NN18 — GUI Port

где NN — номер SAP-инстанции.

Нас больше интересует порт 518, так как он предоставляет интерфейсы для загрузки апплетов, административный же порт предназначен для того, чтобы остановить, перезапустить или запустить SDM-сервисы, например, отправив следующий пакет на порт 517:

[10 spaces]56<?xml version="1.0"?> <ShutDownRequest></ShutDownRequest>


Да-да, вот так просто, без аутентификации, можно отключить сервис деплоинга. Но это скучно и непродуктивно. Вернемся к порту 518.

Используя SDM-клиент (стандартный клиент написан на Java) и подключившись к порту 5NN18, атакующий увидит диалоговое окно с просьбой авторизоваться.

image

Как думаете, где атакующему взять эти самые логин и пароль?

2. Компрометируем SDM


Собственно, с логином все просто. Имя пользователя стандартно — admin. Проблема с паролем. Перебирать — не лучшая идея, так как после 3 неудачных попыток ввода пароля службы SDM останавливаются (привет, еще один DoS).

Давайте же разберемся: как работает аутентификация?

А работает она следующим образом:
1) пользователь вводит пароль
2) клиент считает хеш введенного пароля
3) клиент отправляет хеш пароля на сервер
4) сервер сравнивает полученный хеш с хешем из конфиг-файла
5) если все ОК, то юзер получает доступ в SDM

Выходит, что атакующему вовсе не обязательно знать пароль, достаточно узнать хеш и отправить его на сервер. Как мы знаем, хеш хранится на сервере в конфиг-файле:
..\SDM\program\config\sdmrepository.sdc

image

Перед атакующим новая задача: прочитать конфиг 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 Viewer
2) регистрируем файл sdmrepository.sdc как лог-файл
3) успешно его читаем

image

Имея на руках хеш пароля SDM администратора, остается только использовать его для аутентификации. Для этого можно:
1) написать свой SDM-клиент
2) модифицировать стандартный клиент (благо Java позволяет это сделать)
3) подменить значение хеша до отправки его на сервер с помощью прокси

Я выбрал третий вариант как наиболее простой.

image

Как результат — получаем доступ в SDM-сервер с правами администратора. SDM-сервер скомпрометирован.

image

3. Используя SDM, деплоим shell


На данном этапе у атакующего появляется широчайший спектр возможностей. Наиболее интересные:
1) модифицировать существующую программу, внедрив бекдор, например, или изменив логику ее работы
2) получить доступ к ОС SAP-сервера, загрузив на сервер приложений простейший JSP shell

image

image

Атакующему, как правило, тяжело вникнуть в бизнес-процессы компании, поэтому у него появляется стойкое желание получить доступ в БД и, как результат, ко всем критичным данным.

4. Получаем доступ к БД


Имея доступ к операционной системе, на которой работает SAP, очень легко получить доступ и в БД, залогинившись под пользователем sysdba, для чего атакующему достаточно выполнить команду (в случае использования Oracle как СУБД):
sqlplus / as sysdba

В результате атакующий получает доступ ко всем критичным данным, используемым в компании:

image

Выводы


Казалось бы, что еще обсуждать, — атакующий добился поставленной цели. Однако на данном этапе может начаться самое интересное. К примеру, злоумышленник может попытаться скомпрометировать соседние SAP-системы, например используя доверенные RFC-соединения, однако эта тема выходит за рамки данной статьи.

Подводя итог, хочется вновь написать известную всем фразу: безопасность — штука комплексная. Нельзя защитить одну систему, не защитив соседние. Злоумышленник всегда попробует атаковать там, где вы этого меньше всего ожидаете, так будьте же к этому готовы.
Автор: @chipik
Digital Security
рейтинг 120,11
Безопасность как искусство

Комментарии (4)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка