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-соединения, однако эта тема выходит за рамки данной статьи.

    Подводя итог, хочется вновь написать известную всем фразу: безопасность — штука комплексная. Нельзя защитить одну систему, не защитив соседние. Злоумышленник всегда попробует атаковать там, где вы этого меньше всего ожидаете, так будьте же к этому готовы.
    • +22
    • 7,7k
    • 4
    Digital Security 191,11
    Безопасность как искусство
    Поделиться публикацией
    Похожие публикации
    Комментарии 4

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

    Самое читаемое