Bad time for security in SAP systems! Onapsys released yesterday their report about the 10KBLAZE vulnerability related to SAP Gateway and SAP Message Server. To be honest this it not new. Security issues related to both SAP Gateway and SAP Message Server has been around for a long time. The problem is that these exploits were made public in the OPCDE in Dubai some days ago. So basically we have a huge problem that nobody fixed for the last 14 years being popular for all the hackers in the world. Cool!

Some security companies estimates that thousands of SAP Systems are affected by this issue. Let’s take a look to the problems itself and how to fix it.

SAP Gateway and Message Server

If you know a bit about SAP Architecture you would probably know about SAP Gateway and SAP Message Server. Both are basic elements of a SAP system as you can see in the following diagram:

The Message Server is included in the Central Services (ASCS or SCS) and the Gateway is included in each SAP instance. So basically a SAP system won’t work without them. When we start a SAP system the first thing to start is the Message Server and the Enqueue Server. In the OS you can see it since the process start with ms followed by the ASCS instance name:

Same with SAP Gateway, you can see the gwrd process for each instance:

The SAP Message Server performs the following tasks (Monitoring and Administration of the SAP Message Server):

• Central communication channel between the individual application servers (instances) of the system
• Load distribution of logons using SAP GUI and RFC with logon groups
• Information point for the Web Dispatcher and the application servers (each application server of the system firsts logs on to the message server)

The SAP Gateway performs the following tasks:

• Community between work processes and external program.
• Community between work processes from different instances.

Please do not mistake the internal Gateway with a SAP Gateway System used for Fiori implementations. In this case we are talking about an internal part of each SAP instance.

10KBLAZE Exploit

Just to be clear, 10KBLAZE was the name Onapsys gave to this vulnerabilities. The conference’s name was SAP Gateway to Heaven, I recommend reading the presentation included in the last link and watch video 1 and and video 2.

For the SAP Gateway the problem is that it is possible to execute remotely OS commands. If you don’t use a custom ACL (Access Control List) then it could be possible to use RFCEXEC and SAPXPG to authenticate or bypass authentication into the SAP Gateway and gain access into the SAP system. The following video shows how to execute remote commands on a system with an unsecure Gateway:

The problem with the SAP Message Server is that we can fool it to trust our SAP instance as an instance of the system. This way the Gateway will trust the new added instance so the new instance will be able to access the SAP system… This image from the SAP Gateway to Heaven explain the exploit really good:

We don’t even need an instance for doing the exploit, it is possible to perform the whole operation using a python script… Both exploits are available in case you want to check them and see how they work: SAP GW RCE Exploit & SAP Message Server Research.

[adinserter block=”7″]

You are probably thinking about how you access to both SAP Message Server and SAP Gateway if you SAP systems are not publicly available, right? That’s the problem, usually production environments should not be available on Internet but the researchers found an incredible high number of SAP Systems available on the Internet for both SAP Gateway and SAP Message Server. Even systems that are not available on the Internet can be access to the SAP Gateway and Message Server using a SAP Router.

10KBLAZE Solution & Fix

Know that we know about the issue we can try to solve it. First of all and most important is to check if your SAP Systems are available on Internet. You can use zmap and zgrab. Check your firewall and network configuration. If your SAP System is available publicly from the Internet or from a SAP Router I will advice to check the reason and close the connections immediately, at least from the Internet. Connections from SAP Router are easier to check and configure, it is possible to filter by IP and port (never use P * * * when configuring a SAP Router).

Second and even more important, you will need to create a custom ACL files for both SAP Gateway and SAP Message Server. The ACL acronym is related to Access Control List and it was a mechanism SAP implement a long time ago to restrict the use of both components by external programs, users and systems. Some of the most important SAP Notes related to this topic are the following ones:

• 821875 – Security settings in the message server
• 1425765 – Generating sec_info reg_info
• 1408081 – Basic settings for reg_info and sec_info
• 1421005 – Secure configuration of the message server

In case of the SAP Message Server we will filter the IPs of the SAP instances that can register themselves into the Message Server of the Central Instance. In case of the SAP Gateway we will filter the users, host and program that will be able to connect to the gateway and execute local commands. The steps to configure both SAP MS and SAP GW ACLs are explained in the SAP Notes. I want to give you a small tip about how to configure them.

Usually configure the ACLs are a pain in the ass. For example, if the ACL is not correctly configured in the gateway we will have issues related to RFCs from external systems and applications. For configuring the SAP Gateway we can access to transaction SMGW. Then select the option Goto – Expert Functions – External Security – Maintain ACL Files:

Over there click on the Log Analysis button:

Select the date period you want to analyze. Click on the SystemWide Search button before executing it:

Select all the log files and click Generate ACL Propossal button:

The system will send a proposal of entries to include in the ACL File:

In the last screenshot you can see the entries for the Secinfo file but it is possible to do the same for the Reginfo file.

[adinserter block=”7″]

Also Onapsys released a Snort Signature File that you can use with Snort in order to monitor these exploits. It should be possible also to check in the Firewall connections to both SAP Gateway and Message Server ports done by external system outside and inside the network.

To be continued

I’m quite sure we will hear about 10KBLAZE a lot in the following months. I’m still hoping that SAP will release a different and better way to configure the ACL files for the message server and the gateway since right now it is a bit complicated. I also think that this issue should be fixed a long time ago. ACL files are just a temporary fix for a bad architecture design, there should be a better way for the SAP system to check which instance/system is connecting to the gateway and message server before trusting it.

And last but not less important, the main fault this exploit is so huge is because both customers and SAP Administrators. The EWA Report shows clearly that the ACL is not configured for both SAP Gateway and Message Server and it one of the most important points in the report. The ACL configuration was released on 2005 and 14 years later there are a lot of system not correctly configured. Even worst, I cannot understand how it is possible that so many systems are available and open on the Internet…