Home

Awesome

SAP Message Server research

Copyright (c) 2018-2019 by Mathieu Geli, Dmitry Chastuhin

Proof of concept code for two new attacks on the SAP Message Server component:

with an utility for SAP MS storage monitoring.

Presentation

OPCDE 2019 Dubai:

The slides of the presentation are available here

Threat analysis

Recent news coverage can be misleading for non SAP-savvy IT responsible and is missing some threat analysis on our publication.

Gateway issue

This is issue is known publicly since 2007, and securing guidelines were published by SAP since 2009. From our experience this issue has mostly disappeared as servers are updated, and old one are being secured.

When the issue is present, with the code released by my ex-colleague Dmitry Chastuhin here, it is possible to run OS commands on the remote server via anonymous network access.

In order to get access to business data, the attacker need to have specific SAP internals knowledge. A script kiddie/automated tool will barely launch a cryptocurrency miner.

Message Server issue

This is the enabler for bypassing the secure Gateway configuration.

The issue relies on the Message Server ACL file that is too open (HOST=*) by default. SAP first published in 2005 guideline on building secure ACL files (basically writing your AS names instead of *).

Published PoC sap_ms_betrusted.py is not reliable and highly dependant on SAP kernel version. It means success is not ensured even if the proper version is implemented. Having something stable will require a good amount of SAP and reverse engineering expertise.

As we explained in our presentation, lab testing was done using full SAP server as the attacker's host, so an attacker do not need our python script to gain successful exploitation.

Exploitation detection

Those measures allow to track sign of exploitation.

Gateway activity

Security firms already published signatures to detect this specific attack. As any signature-based measure it could be bypassed and should not be taken as a silver bullet for detection, but still is better than nothing.

Message server activity

As for the gateway, NIDS signatures could be built by matching the string _SEND_NILIST with:

Remediation

Gateway

Message Server

Assessment

You should make sure you know all your assets, especially those that are internet exposed.

Gateway threat

You can check all your landscape with the anonGW code by trying to execute for instance OS command whoami

Message Server threat

Assessing this one is a bit more tricky, as the "be_trusted" PoC is not 100% reliable and may have side effects on Logon Group availability. We strongly do not advise testing on production systems.

If you really want to showcase that during a blackbox assessment, you better choose a landscape that is not user-facing.

For whitebox, you can assume the issue exists if both condition are met:

Moreover you can use scripts from SecureAuth's Martin Gallo ms_dump_info.py and ms_dump_param.py to remotely check profile parameters against the Message Server internal port, as described in this thread https://twitter.com/MartinGalloAr/status/1124347630555938820

Internet

What about those world maps with scary numbers?

That is SAP specialized TCP SYN scans to detect presence of a specific SAP service (here SAP Gateway, SAP Router, SAP Message Server) behind a certain port. That DOES NOT imply that the services are affected by the discussed vulnerabilities. It is here to help quantify the "external threat" and show that backend servers holding usually sensitive data can be exposed via internet.

That is specialized in a way that usual search scan engines like shodan, censys, zoomeye or onyphe does not yet fully provide this information.

Links

At the moment the only article we think is valuable to be read is this one.

All the other articles related to our research looks like news orders with sole interviewee a company which is selling SAP security tools and consultancy.

Greetz