In my last post I wrote about the 10KBLAZE exploit that it’s hitting really hard the SAP world during the last weeks. I gave you a few tips you can follow in order to fix the vulnerability. Today I would like to explain a bit more about these solutions you can follow in order to create your ACL files easily. This way so will survive the SAPocalypse like Daryl Dixon in a The Walking Dead episode!

I would like to start recommending you to read the presentation SAP Runs SAP –Remote Function Call: Gateway Hacking and Defense. It was released in 2012 durig SAP TechEd and it is one of the best documents I found about securing the SAP Gateway. As you can see it was long time before the 10KBLAZE so the exploit it’s not new at all.

If you remember I wrote about using the Gateway Log Analysis so we can get a proposal for creating both secinfo and reginfo:

• The secInfo file is used to allow only authorized systems to execute operating system commands
• The regInfo is used to allow only authorized systems to register RFC servers

The secInfo structure is as follows:

So we can filter by user, program, source and destination hosts. In case of the regInfo file the structure is like this:

By default the content of both files are like this:

In both cases local means the local application server meanwhile internal means all the application servers and database server of a SAP system.

SAP Gateway simulation mode

I didn’t know about this and my coworker Estefania (hell of a girl and an extraordinary SAP Basis Consultant) told me about it. As you may know the parameter gw/acl_mode activates the use both ACL files for the SAP Gateway. A value of 1 means the Gateway will use the ACL files to allow/deny the access of external servers to the Gateway.

[adinserter block=”7″]

There is also the parameter gw/sim_mode that enables a simulation mode. This means that even if you activated the parameter gw/acl_mode and the external system is not in the ACL files the Gateway will allow the access to the Gateway. It will also write in the Gateway log file an entry about an access lacking permission in the ACL files.

The Gateway Access Control Lists Wiki shows an image with the whole ACL workflow:

I think the schema is not quite accurate but you can see how the simulation mode works. This is extremely helpful because we can use it to recover the external programs connecting to the SAP Gateway so we can create an accurate ACL files. Combine this with the Gateway Log Analysis and the Gateway Logging and it’s a god mode!

SAP Gateway Logging

In the SMGW we can modify the logging paramters for the Gateway. To do it just click on Goto – Expert Functions – Logging. The main screen will be something like this:

You can choose to trace different events on the Gateway. Even more important, you can activate the simulation mode in this place. I recommend setting the parameters as follows:

Once you save click on the activate button and the new configuration will be applied. You don’t need to restart the Gateway for activating the new parameters.

[adinserter block=”7″]

Leave the Gateway logging for several days. Each time a system/application that is not in the ACL files tries to connect to the Gateway it will appear something like this:

As you can see we get the user, program, source and destination hosts. We will use this later for generating both ACL files. It is also really important to delete in both regInfo and secInfo any wildcard to all the servers you are using. The entry would be something like this:

Otherwise the logging won’t trace any denial since the Gateway will permit all the connections. If you already activated the gw/acl_mode parameter and your ACL files are like this… Congratulations! You just wasted your time! Modify the ACL files, activate the simulation mode (even with the gw/acl_mode parameter on) and continue to the next section.

SAP Gateway Log Analysis

So here it comes the magic! After a couple of days logging the connections in the SAP Gateway we will generate the ACL files. For doing that we will use the SAP Gateway Log Analysis. This feature is included in one of the latest Support Package of the SAP Basis component. I don’t know exactly which one but I updated a system recently to the latest SPS available and I compared with the same system without upgrading. Seems the feature was included in one of the patches.

You can read my last post if you don’t know where to find the SAP Gateway Log Analysis. Select the files the GW generated and click on Generate ACL proposal:

Connections that failed while the simulation mode was enabled will appear over here:

After this you can select each entry and click on the Copy button.

You can modify the entry when you copy so you can write a * or different value for each entry. After it just click on Save and the file will be activated automatically. When you are sure you have all the possible entries then modify the SAP Gateway parameter gw/acl_mode to 1 and disable the simulation mode.

Also remember to include in the regInfo and secInfo files the entries for the SAP systems that can connect to this system.

Steps to follow

If you want a recap of the steps to done I would follow this list:

1. Check with the different teams the servers/applications/systems that connect to the SAP system.
2. Delete any wildcard entry you have in your regInfo and secInfo files.
3. Enable the logging and simulation mode in the SAP Gateway. Leave it running for several days.
4. Generate the ACL Prososal in transaction SMGW.
5. Run a lot of test to check that everything works correctly.
6. Run even more test to double check.
7. If you are sure that you ACL files are complete then disable the simulation mode and enable the parameter gw/acl_mode to 1.

Always start on DEV/QAS systems and when you are sure do it on the production systems.

Wait… What about the Message Server?

I didn’t forget about the Message Server. It is just easier to fix than the Gateway. For fixing the exploit in the Message Server just modify the ms_acl_info file. It is usually available in the GLOBAL directory. The entries will be like this:

In the host line you just need to include the hostname of the application servers that will connect to the Message Server. It is really important that the entry has exactly the same hostname than the instance profile. For example, if your instance name has the hostname in capital letters the entry should be in capital letters too. I’m telling you this because sometimes the server’s hostname is on lower letters while the instance name includes the hostname in capital letters. You can also include several hostnames/IPs in the same line separated by commas and not including any spaces between them.

[adinserter block=”7″]

After modifying the ms_acl_info file restart the instance. If the instance is not able to connect to the Message Server the dev_ms log file in the *SCS instance work directory will show this message:

It is also possible to harden the Message Server even more. I recommend reading the Security Settings for the SAP Message Server in the help page for learning a bit more about this topic. I hope you liked this second part of the 10KBLAZE article! If you have any questions let me know 😉