Разбираем множественные уязвимости в движке SAP NetWeaver J2EE

Интерес мирового бизнеса к системам планирования и управления ресурсами предприятия неуклонно растет. Сегодня более 120 000 компаний, включая такие гиганты, как IBM, AT&T, Apple, Coca-Cola и BMW, используют программные продукты компании SAP. Проведенные нами исследования позволили обнаружить множество уязвимостей, с помощью которых удаленный пользователь может обойти механизм аутентификации и выполнить любое действие в SAP-системе, не используя никаких клиентских данных.

Введение

SAP — это разработчик программного обеспечения для автоматизации бизнес-процессов, выпускающий огромное множество одноименных продуктов. Наиболее популярна из них SAP ERP (Enterprise Resource Planning) — система управления ресурсами предприятия, которая хранит и обрабатывает все критически важные данные о компании, например информацию о поставщиках, зарплатные данные, финансовую отчетность и прочее. Такая автоматизированная система позволяет эффективно решать комплексные задачи, включая оптимальное распределение бизнес-ресурсов, обеспечение быстрой и эффективной доставки товаров и услуг потребителю. В отличие от, например, бухгалтерских программ, которые позволяют только вести бизнес-учет, ERP обеспечивает информационную поддержку принятия управленческих решений. Стоит отметить, что ERP позволяет оптимизировать не только внутренние процессы предприятия, но и бизнес-процессы деловых партнеров и клиентов.

Существует миф о том, что SAP ERP — это безопасная система и единственная проблема безопасности в этой системе — матрица SOD (матрица разграничения полномочий), то есть матрица, где описывается, какие наборы привилегий в системе не стоит давать одному пользователю. К примеру, если пользователь может создать платежное поручение на какую-нибудь фирму, а также проапрувить это поручение, то он может совершать различные мошеннические операции. Таких пересечений существует больше двухсот, в зависимости от области бизнеса. Естественно, данная матрица очень важна, и ее создание и соблюдение крайне сложная задача, но еще более важно, чтобы лица, которые вообще не имеют никакого доступа в SAP, не смогли стать там администраторами.

За последние пять лет появилось много исследований в области безопасности SAP (по недавним подсчетам, около ста уникальных работ), начиная от атак на SAP GUI и SAP Router и заканчивая архитектурными уязвимостями в протоколе RFC и уязвимостями программ, написанных на ABAP. SAP, в свою очередь, тоже не дремлет и расширяет отдел Security Response Team, который отвечает за контакты с внешними исследователями. С ними мы постоянно сотрудничаем, консультируя о новых способах взлома и возможных вариантах защиты. Кроме того, компания SAP выпускает стандарты по техническим вопросам безопасности SAP, подтверждая существование проблемы, связанной с отсутствием единой базы требований к безопасности, а также покупает компании разработчиков систем безопасности, таких как, например, поставщик решений по шифрованию трафика Secude.

Начнем, пожалуй

Все основные продукты SAP используют одну из трех платформ: NetWeaver ABAP, NetWeaver JAVA и Business Objects. Платформа NetWeaver JAVA используется во множестве продуктов SAP, обеспечивающих интеграцию и контроль над бизнес-приложениями. Это такие продукты, как SAP Portal, SAP Mobile Infrastructure, SAP XI и Solution Manager, а также ряд менее популярных решений. Критичность данных систем нельзя недооценить, так как они обеспечивают интеграцию с другими системами и, например, взломав SAP Portal предприятия через интернет, можно получить доступ к другим ресурсам компании через Single Sign-On или, например, через уязвимый SAP Solution Manager (аналог контроллера домена и сервера обновлений в Windows-среде) можно внедрить злонамеренный код во все подключенные к нему SAP-системы.

Наши исследования безопасности JAVA движка SAP, начатые более трех лет назад, привели к тому, что было обнаружено около двухсот уязвимостей, большая часть которых на данный момент закрывается производителем, и осталось еще много неизученных областей, над которыми ведется работа. Практически все уязвимости не являются единичными, а представляют собой целый класс проблем, примеры которого постоянно обнаруживаются. Наиболее критичные из обнаруженных уязвимостей позволяют обойти механизм аутентификации и выполнить любое действие в системе удаленно, не используя никаких пользовательских данных. В случае если система имеет доступ в интернет, то даже двухфакторная аутентификация не спасет от данной атаки и злоумышленник сможет элементарно получить доступ к сердцу компании удаленно.

Другие статьи в выпуске:

Хакер #170. Малварь для OS X

• Содержание выпуска
• Подписка на «Хакер»-60%

SAP в интернете

Сейчас нет ни одной статьи про какую-нибудь систему, где бы не добавляли ко всему прочему Google Dorks для поиска этих систем в интернете. Поступим так же и мы. Поместив в строку поиска несложное выражение, например inurl:/irj/portal (находит десятки тысяч систем), inurl:/wsnavigator/jsps/test.jsp (находит 2430 записей) или inurl:IciEventServicesap, inurl:IciEventService/IciEventConf, inurl:/irj/go/km/docs/, можно обнаружить SAP-серверы крупнейших мировых компаний, доступные через интернет, ну а теперь перейдем к основным уязвимостям и практике.

Атаки на платформу и приложения

SAP NetWeaver J2EE Engine представляет собой сервер приложений стандарта J2EE, который позволяет размещать приложения, написанные на Java. Его можно сравнить со знакомым всем Apache Tomcat, только на несколько порядков больше и сложнее, а там, где есть сложность, непременно появляются уязвимости. На данном сервере, собственно, и располагаются сами бизнес-системы (SAP Portal, SAP XI, SAP PI или, например, SolutionManager), а также приложения собственной разработки. Такие крупные системы состоят из более мелких приложений (Applications), которые по сложности зачастую сопоставимы с полноценным веб-проектом. Данных приложений по умолчанию устанавливается множество. Например, в версии NetWeaver 6.40 их около 500, а в версии 7.2 их уже 1200. На самом деле, помимо веб-сервиса с уймой приложений, движок слушает множество портов различными службами. Там тоже очень много интересного, но это тема для отдельной статьи.

Масштабы впечатляют, а если учитывать, что каждое приложение имеет, помимо общих, также и свои настройки безопасности и уязвимости, то адекватная защита всей платформы, не считая вариант отключения от сети, представляет собой крайне непростую задачу. Рассмотрим основные типы уязвимостей, которые были обнаружены нашим исследовательским центром.

Разглашение информации

Средняя критичность. Зачастую не позволяет атаковать компанию напрямую, но помогает для дальнейших атак. Были обнаружены следующие уязвимости:

• получение версии и патча движка и приложения (можно узнать, какие уязвимости присутствуют). К примеру, если обратиться по ссылке /rep/build_Info.jsp или /bcb/bcbadmSystemInfo.jsp, можно получить информацию о релизе, которую можно потом использовать для проведения дальнейших атак;
• неавторизованное чтение некоторых файлов журналирования (в них часто хранятся пароли и прочие важные данные);
• неавторизованное разглашение имен пользователей (можно подбирать пароли);
• неавторизованное сканирование внутренних хостов сети (возможен даже перебор паролей на внутренние серверы и блокировка учетных записей).

Наверное, самый интересный пример — это последний. В одном из веб-сервисов была обнаружена интересная деталь. В качестве входных данных можно передать IP-адрес и порт сервера для просмотра неких данных. Нам же гораздо интереснее с помощью данной уязвимости просканировать внутреннюю сеть компании на предмет открытых портов и запущенных сервисов. Скрипт вызывается следующим образом. В качестве server и port указываем произвольные данные для сканирования и по ответу сервера узнаем, открыт порт или нет.

http://sapserver/ipcpricing/ui/BufferOverview.jsp?server=172.16.0.13&port=31337&password=
&dispatcher=&targetClient=&view=

Межсайтовый скриптинг

Средняя критичность. Одна из самых популярных уязвимостей, все с ней знакомы, и в детали вдаваться нет смысла. Добавлю лишь только, что по умолчанию сессия не привязана к IP-адресу, то есть, перехватив cookie, можно без проблем аутентифицироваться в портале. Зачастую достаточно разместить ссылку на XSS как документ в системе SAP Portal; это повысит шансы того, что по ней пойдут. На данный момент выпущено около 30 исправлений, закрывающих около 50 уязвимостей данного типа, обнаруженных нами, над остальными ведется работа.

SMBrelay

Высокая критичность. Фактически это уязвимость Windows-сетей, которая так и не закрыта для некоторых атак. Для ее эксплуатации требуется, чтобы SAP-сервер стоял на Windows-кластере или чтобы два сервера SAP работали из-под одной доменной учетной записи. Помимо этого, уязвимое веб-приложение на SAP должно иметь интерфейс обращения к файлам. Для эксплуатации уязвимости злоумышленник поднимает поддельный SMB-сервер и передает веб-приложению SAP ссылку на файл, находящийся на удаленном SMB-сервере. Процесс сервера SAP пытается запросить файл с правами своей учетной записи, мы перехватываем ее на поддельном SMB-сервере и заходим от ее имени обратно на сервер, получая тем самым права администратора на ОС (описание процесса несколько упрощено, но основная его суть такова). Аналогичную уязвимость можно использовать в связке с CSRF — в случае если данный интерфейс требует аутентификации, необходимо заставить администратора нажать по ссылке так же, как для XSS-уязвимости. К примеру, уязвимость можно проэксплуатировать, обратившись по следующей ссылке.

Обход авторизации через Invoker Servlet

Высокая критичность. Всем известно, что намного круче обнаружить целый класс (ну или хотя бы подкласс) уязвимостей, чем отдельную проблему, так как, обнаружив новый класс, можно будет найти массу примеров. Вообще говоря, большинство уязвимостей обнаруживается на грани программистской и администраторской ответственности, когда каждая сторона считает, что это не ее область. Тем не менее злоумышленнику, как правило, без разницы, чья это область, и он не откажется воспользоваться обнаруженной уязвимостью, пока ответственные будут выяснять свои отношения. В данном случае для настройки безопасности веб-сервисов используется файл WEB.XML, который программисты зачастую игнорируют или используют минимально, полагаясь на то, что это задача администраторов. Администраторы же, в свою очередь, нередко вообще понятия не имеют, что есть такой файл и что его настройка влияет на безопасность. Но сначала взглянем на структуру типичного файлика WEB.XML:

<servlet>
<servlet-name>CriticalAction</servlet-name>
<servlet-class>com.sap.admin.Critical.Action</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Critical</</servlet-name>
<url-pattern>/admin/criticalfunc</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>Restrictedaccess</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

А в результате получается множество уязвимостей, подобных следующей. В движке J2EE есть такой механизм, как Invoker Servlet. Он позволяет вызвать любой сервлет (часть приложения, выполняющая функционал на сервере), напрямую набрав в строке URL имя класса для данного сервлета таким образом: /servlet/<servlet-name-or-class>. Проблема начинается в тот момент, когда вы размещаете ссылку на сервлет в какой-либо директории типа /admin (в данном примере к сервлету можно обратиться по ссылке /admin/criticalfunc) и закрываете к ней доступ для всех, кроме администратора. В данном случае злоумышленник может обратиться напрямую к сервлету через Invoker-механизм по ссылке /servlet/com.sap.admin.Critical.Action и получить необходимые данные без аутентификации, так как прямой доступ к директории /servlet не заблокирован по умолчанию. Мы обнаружили немало таких приложений, которые позволяют выполнять различные действия в обход авторизации, хотя для защиты всего лишь требуется поставить ограничение на доступ к корневой директории или к директории /servlet.

Основная проблема для нас заключалась в том, что надо было найти среди всех 500 приложений те, что не фильтровали доступ к InvokerServlet и выполняли через этот сервлет опасные действия, — ведь нужно же показать реальный риск, а не просто ткнуть пальцем в кривую архитектуру со словами: «это теоретически, в особых ситуациях, при условии a + b – c * d может привести к чему-то не очень хорошему».

Один забавный веб-сервис, к примеру, позволяет читать произвольный файл с ОС, и он уязвим к данной баге, а значит, можно читать файлы, хранящиеся на сервере. При желании можно даже выкачать напрямую данные из СУБД и покопаться в финансовых транзакциях… (главное, чтобы не завис браузер от открытия и скачки файлов по несколько гигабайт).

Обход аутентификации через подделку HTTP-запросов

Нам было мало этой уязвимости, да и не комильфо как-то без шелла на Black Hat ехать. В итоге я нашел баг, который позволяет независимо от версии SAP и версии ОС, на которой работает SAP, получить права администратора в системе удаленно (причем для ее эксплуатации не требуется ничего, кроме стандартных средств ОС и минимальных знаний протокола HTTP), и, что самое главное, большинство систем в интернете действительно к ней уязвимо.

Уязвимость обнаружена все в том же WEB.XML, и потенциально к ней уязвимо около 40 приложений. На данный момент нами обнаружено три реально уязвимых приложения. Проблема заключается в том, что механизм WEB.XML позволяет ограничить доступ к ресурсу, позволив определенной роли пользователей выполнять определенные HTTP-методы.

<security-constraint>
<web-resource-collection>
<web-resource-name>Restrictedaccess</web-resourcename>
<url-pattern>/admin/*</url-pattern>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

В нашем примере в папку /admin может заходить только пользователь с ролью admin и выполнять метод GET. Как оказалось, все, что явно не запрещено, то разрешено, то есть, например, обращение методом HEAD, который делает ровно то же самое, что и GET, только не показывает результат пользователю, может быть реализовано анонимно без наличия и пользователя, и роли. То есть, если бы название метода не было указано явно, это бы значило, что всеми методами можно ходить только админу, и все бы было ОK. А раз указал один метод, то уж изволь все остальные перечислить.

Таким образом, задача заключается в том, чтобы найти все критичные приложения, которые:

• поддерживают HEAD-запрос и обрабатывают его так же, как GET;
• выполняют критичное действие, причем нам неважно тело ответа, поскольку это HEAD;
• желательно присутствуют во всех инсталляциях, а не просто как демопример.

Одно из найденных нами приложений, которое является системным, позволяет создавать в системе пользователя и назначать ему любую роль. Также в файле WEB XML, помимо данной уязвимости, есть множество других параметров безопасности, таких как использование шифрования.

В заключение можно сказать, что это далеко не весь набор проблем J2EE-движка, о ряде других я, возможно, расскажу в ближайших номерах, ну а остальные проблемы пока еще не закрыты производителем. Вот и все на сегодня. А тех, кто интересуется темой безопасности SAP или других бизнес-приложений, а также любой другой работой, связанной с безопасностью, милости просим в нашу команду. У нас много открытых вакансий, и даже если вы не нашли их на сайте, то не стесняйтесь писать напрямую.