Существует множество способов скомпрометировать 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) находим SDM
2) компрометируем SDM
3) используя SDM, деплоим shell
4) имея доступ к ОС сервера SAP-системы, легко получить доступ к данным, обрабатываемым в ней
Начнем.
Встретить SDM-сервис в типичном SAP-ландшафте не так уж сложно. Достаточно поискать порты:
5NN17 — Admin Port
5NN18 — GUI Port
где NN — номер SAP-инстанции.
Нас больше интересует порт 518, так как он предоставляет интерфейсы для загрузки апплетов, административный же порт предназначен для того, чтобы остановить, перезапустить или запустить SDM-сервисы, например, отправив следующий пакет на порт 517:
Да-да, вот так просто, без аутентификации, можно отключить сервис деплоинга. Но это скучно и непродуктивно. Вернемся к порту 518.
Используя SDM-клиент (стандартный клиент написан на Java) и подключившись к порту 5NN18, атакующий увидит диалоговое окно с просьбой авторизоваться.
Как думаете, где атакующему взять эти самые логин и пароль?
Собственно, с логином все просто. Имя пользователя стандартно — 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 Viewer
2) регистрируем файл sdmrepository.sdc как лог-файл
3) успешно его читаем
Имея на руках хеш пароля SDM администратора, остается только использовать его для аутентификации. Для этого можно:
1) написать свой SDM-клиент
2) модифицировать стандартный клиент (благо Java позволяет это сделать)
3) подменить значение хеша до отправки его на сервер с помощью прокси
Я выбрал третий вариант как наиболее простой.
Как результат — получаем доступ в SDM-сервер с правами администратора. SDM-сервер скомпрометирован.
На данном этапе у атакующего появляется широчайший спектр возможностей. Наиболее интересные:
1) модифицировать существующую программу, внедрив бекдор, например, или изменив логику ее работы
2) получить доступ к ОС SAP-сервера, загрузив на сервер приложений простейший JSP shell
Атакующему, как правило, тяжело вникнуть в бизнес-процессы компании, поэтому у него появляется стойкое желание получить доступ в БД и, как результат, ко всем критичным данным.
Имея доступ к операционной системе, на которой работает SAP, очень легко получить доступ и в БД, залогинившись под пользователем sysdba, для чего атакующему достаточно выполнить команду (в случае использования Oracle как СУБД):
sqlplus / as sysdba
В результате атакующий получает доступ ко всем критичным данным, используемым в компании:
Казалось бы, что еще обсуждать, — атакующий добился поставленной цели. Однако на данном этапе может начаться самое интересное. К примеру, злоумышленник может попытаться скомпрометировать соседние SAP-системы, например используя доверенные RFC-соединения, однако эта тема выходит за рамки данной статьи.
Подводя итог, хочется вновь написать известную всем фразу: безопасность — штука комплексная. Нельзя защитить одну систему, не защитив соседние. Злоумышленник всегда попробует атаковать там, где вы этого меньше всего ожидаете, так будьте же к этому готовы.
Как результат, каждый месяц компания 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) находим 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, атакующий увидит диалоговое окно с просьбой авторизоваться.
Как думаете, где атакующему взять эти самые логин и пароль?
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 Viewer
2) регистрируем файл 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-соединения, однако эта тема выходит за рамки данной статьи.
Подводя итог, хочется вновь написать известную всем фразу: безопасность — штука комплексная. Нельзя защитить одну систему, не защитив соседние. Злоумышленник всегда попробует атаковать там, где вы этого меньше всего ожидаете, так будьте же к этому готовы.
