Контакты
Подписка
МЕНЮ
Контакты
Подписка

SAP Internet Communication Manager, или Посторонним вход разрешен

SAP Internet Communication Manager, или Посторонним вход разрешен

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций

SAP Internet Communication Manager, или Посторонним вход разрешен

Мы продолжаем цикл статей, посвященных безопасности SAP-приложений. В четвертом номере мы рассмотрели основные проблемы приложений, основанных на платформе SAP NetWeaver J2EE Engine, в этот раз коснемся платформы SAP NetWeaver ABAP Engine. На данной платформе основаны практически все приложения компании SAP для автоматизации бизнеса, такие как ERP, HCM, CRM, SRM и прочие.
Дмитрий Частухин
аудитор по информационной безопасности,
Digital Security

SAP в Интернете

Все больше и больше компаний используют SAP в своей работе и пользуются всем разнообразием его интерфейсов для доступа к необходимой информации. С каждым днем утверждение 0  том, что SAP – это только внутренняя система компании, теряет свою актуальность. Используя любой поисковый движок, потенциальный атакующий может без особых трудностей найти SAP-систему компании, доступную через Интернет. Таким образом, проблема внешнего нарушителя становится все актуальнее с каждым днем.

Выделим преимущества внешнего и внутреннего нарушителей:

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

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

Компонент ICM

ICM, или Internet Communication Manager, является развитием компонента ITS и предназначен для организации доступа к SAP-системе через Интернет. Рассмотрим ряд уязвимостей ICM, которые позволяют потенциальному атакующему получить критичную информацию и доступ во внутреннюю сеть компании.

Идентификация SAP-компонентов и их версий через баннеры

В заголовках HTTP-ответов от SAP ICM содержится информация о версии компонента, например:

  • server: SAP Web Application Server (1.0;640);
  • server: SAP NetWeaver Application Server (1.0;700);
  • server: SAP NetWeaver Application Server/ABAP 701;
  • server: SAP NetWeaver Application Server 7.10/ICM 7.10.

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

В качестве меры защиты необходимо отключить отображение версий в заголовках HTTP-ответов для ICM-сервера. Для этого установите значение параметра is/HTTP/show_server_header в FALSE.

Более подробную информацию можно найти в SAP Note 1329326.

Идентификация SAP-компонентов и их версий через сообщения об ошибках

Сформировав специальный запрос, содержащий, например, некорректные параметры, атакующий может получить сообщение об ошибке, которое будет содержать в себе информацию 0 компонентах SAP-системы, их версиях и другую техническую информацию о системе. Так, например, по умолчанию HTTP 404-й и 403-й ответы возвращают информацию об имени хоста, номере системы, SID. Данную информацию потенциальный атакующий может использовать так же, как и в случае с выводом версий через баннеры.

Для того чтобы отключить вывод данной информации в сообщениях об ошибках, необходимо либо индивидуально для каждого сервиса через транзакцию SICF настроить страницу с выводом ошибок, либо изменить стандартную форму для вывода ошибок в ICM, указав свою в параметре icm/HTTP/error_templ_path.

Опасные ICF-сервисы

В базовой инсталляции SAP ECC версии 6.0 более 1500 стандартных ICF-сервисов.

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

Рассмотрим процесс работы ICF-сервиса. Когда ICF получает запрос, дальше происходит следующее:

1. Фреймворк проверяет, приватным или публичным является данный сервис:

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

2.   После аутентификации проверяется ICF-авторизация, если она успешна, то выполняется код сервиса.

Большинство сервисов по умолчанию требуют аутентификацию, однако есть и такие, для выполнения которых не нужны пользовательские данные. Одним из примеров таких сервисов является /sap/public/info, который в результате своей работы возвращает критичную информацию о системе.

Уязвимость 1
Как уже было сказано выше, после аутентификации система проверяет, имеет ли пользователь авторизационный объект S_ICF с полем Authorization, у которого в качестве значения установлено имя сервиса, к которому осуществлялся запрос. Однако по умолчанию для всех ICF-сервисов не назначено поле Authorization, то есть авторизационная проверка не применяется. Это значит, что атакующему необходимы любые пользовательские данные для выполнения ICF-сервиса. То есть любой пользователь без каких-либо прав может получить доступ к любому сервису. Злоумышленник, к примеру, может воспользоваться учетными записями, оставленными по умолчанию, чтобы получить доступ к сервисам.

Уязвимость 2
Стандартные пароли в SAP. Многие системы поставляются с пользователями, у которых установлены пароли по умолчанию, это такие пользователи, как SAP*, DDIC, EARLYWATCH, SAPCPIC и TMSADM. Используя данный недостаток, потенциальный злоумышленник может выполнять код ICF-приложений и таким образом получать доступ к разного рода критичной информации и действиям.

Уязвимость 3
Наверняка все знакомы с таким протоколом, как RFC, который используется для вызова ABAP Function Modules на удаленных SAP-серверах. Доступ к данному протоколу у атакующего являлся бы существенной угрозой безопасности для системы, однако, как правило, RFC недоступен из сети Интернет. Но... существуют ICF-сервисы, которые могут быть использованы для выполнения RFC-вызовов. То есть, получив доступ к такому сервису, атакующий может выполнять ABAP Function Modules так, как будто он находится в локальной сети компании.

В случае если происходит вызов RFC-функций через Web-интерфейс, система не проверяет наличие у пользователя авторизации на определенную группу RFC-функций, что является первичной проверкой доступа, после которой уже проверяется наличие у пользователя авторизации на выполнение конкретной RFC-функции. Так как зачастую в некоторых функциях отсутствует проверка авторизации (что было обнаружено и нашим исследовательским отделом, и различными sap note), то без первичной проверки авторизации на группу у злоумышленника есть все шансы выполнить любой RFC-вызов удаленно.

Так, например, через SOAP-сервис /sap/bc/soap/wsdl11 атакующий может выполнить такие функциональные модули, как SXPG_COMMNAND_EXECUTE, который позволяет запустить команду ОС или функциональный модуль TH_GREP.

Данный функциональный модуль предназначен для поиска строк в файлах, расположенных в операционной системе и может быть выполнен стандартным пользователем EARLY-WATCH. Однако недавно была обнаружена уязвимость в данном модуле, позволяющая выполнять произвольные команды операционной системы. Таким образом, атакующий сможет выполнить любую команду ОС, на которой работает SAP-сервер от имени SAP-администратора (<sid>adm) и сможет соединиться с базой данных как DBA, да и вообще полностью контролировать работу всей системы. К каким угрозам для бизнеса компании это может привести, я думаю, описывать не стоит.

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

Для защиты SAP-системы необходимо:

  1. Сменить стандартные пароли у пользователей.
  2. Закрыть уязвимость в TH_GREP, установив сапноты 1433101 и 1580017.
  3. Провести анализ всех ICF-сервисов и отключить те из них, которые не требуются для нормальной работы компании.
  4. Разграничить права на доступ к ICF-сервисам, предоставив их только тем пользователям, которым данный функционал необходим для работы.

Стоит отметить, что два последних этапа являются наиболее трудоемкими, так как ICF-сервисов и пользователей в системе может быть огромное количество и задача требует автоматизированного подхода, но данные меры необходимы для обеспечения безопасности SAP-системы.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2011

Приобрести этот номер или подписаться

Статьи про теме