In April 2019, researchers Dmitry Chastuhin and Mathieu Geli presented a talk at the OPCDE Cyber Security Conference about two pieces of exploit code that allow anyone to interact with SAP and perform unauthorized transactions. For example, attackers could use the code to shut down an entire SAP system, execute commands as the operating system or extract valuable data.

It is important to note up front that this is not a systems integrator problem. These are known exploits that were never made public, and as such were not available to attackers. SAP released a configuration fix six years ago. If you implemented the fix at that point, it is highly unlikely you are vulnerable to these exploits; however, it is still a best practice to re-assess your SAP configuration to verify that is the case. If you did not implement a fix, because the exploits are now public and available to the world, it is imperative to apply the configuration fix now.

Apply Fixes Where Possible

I asked SAP about what organizations should be doing today to reduce their risk of a compromise. Here is their statement:

“SAP is aware of recent reports about vulnerabilities in SAP Gateway and SAP Message Server, however these were patched by SAP a few years ago.   

Security notes 821875, 1408081 and 1421005 released in 2009 and 2013 will protect the customer from these exploits. As always, we strongly advise our customers to apply these security notes immediately and ensure secure configuration of their SAP landscape.

SAP takes the security of customer data seriously. The recommendations published in the white papers A Practical Guide for Securing SAP® Solutions and Securing Remote Function Calls (RFC) emphasize secure configuration of the SAP landscape. Customers can leverage related security checks in the EarlyWatch Alert (note 863362) and the SAP Security Optimization Service. 

SAP stands for secure and reliable software solutions. As the global leader in business software, SAP has based its development processes on a comprehensive security strategy (“Prevent – Detect – React”) across the enterprise that relies on trainings, tools and processes to enable the delivery of secure products and services.”

Our discussions with SAP shed light on an important point. Promptly patching vulnerabilities and fixing configuration issues should be a security and business imperative. For organizations that manage their own remediation programs, this incident demonstrates why applying fixes when they are released is the most effective way to minimize the risk of a compromise. SAP emphasized to us that if customers applied the configuration fixes when they were released years ago, the likelihood of an attacker using the exploits to compromise their organization is low.

The good news is that a confirmed imminent attacker is not lurking in the shadows. We have not seen any confirmed compromises using these exploits. However, the risk is elevated, and therefore the industry must step up and apply the fixes.

What Do the Experts Say About Securing SAP Systems?

I spoke with Onapsis Director of Research Sebastian Bortnik and IBM X-Force Red SAP hacking expert Dustin Heywood (a.k.a. Evil Mog) about the public release of the SAP exploits and how companies can protect themselves.

Abby: Thank you for speaking with me today, Sebastian and Dustin. Onapsis has said that 90 percent of SAP customers globally may be exposed to these exploits. That is a frighteningly high number. Dustin, what makes these exploits so dangerous?

Dustin: SAP is essentially a collection of systems that talk to each other over a protocol called Remote Function Calls. It is a communication mechanism built into SAP that enables transactions. There was a defense mechanism that prevented unauthorized communications — an access control list, which was applied to the SAP router itself and designed so that only trusted systems could authenticate to the router or gateway. These exploits can allow attackers to bypass the access control list, giving them the power to perform whichever transactions they want. And, since the exploits are published on GitHub, anyone can access them.

Abby: Sebastian, considering Onapsis developed exclusive SAP exploit tooling, which was protected to make sure it was only in the right hands, what is your reaction to the fact that these two exploits were developed and made public?

Sebastian: For folks working on information security teams, this may seem like a common happening: an exploit for a well-documented security configuration that has been there for years. But when you really understand how SAP works and how big and complex an SAP environment is, you also quickly realize that SAP security is more complex than other well-used platforms. Because of this, you need to consider other disclosure policies based on the complexity and the type of data that is stored in those systems.

That is why at Onapsis we have always followed a responsible disclosure policy and have reported and helped SAP fix hundreds of vulnerabilities. We always ensure that we first work with the vendor to help them develop the patch and, even if we talk about a finding (after it is patched), we never release exploits or technical details that could potentially help someone accelerate a malicious attack targeting SAP customers.

That is also why we have taken the confidentiality of the tools we use for penetration testing and similar services so seriously. We know the impact public exploits like these may have on global companies that use SAP and their customers.

Abby: Dustin, were you surprised by the findings?

Dustin: Not at all. SAP gateways, routers and Remote Function Calls have been a top target for attackers. What does surprise me is that the exploit code is now public and uses the pysap module, which is an open-source implementation of the SAP protocols, eliminating the need for the SAP software development kit. That means anyone can attack the SAP environment without ever needing an SAP licensed code. The exploits significantly lower the barrier of entry to potential attackers of various skill levels.

Abby: I imagine the announcement has put companies on high alert. Is there any easy fix they should be implementing now, Sebastian?

Sebastian: Unfortunately, we are not talking about a simple software bug that can be solved by a patch, but a misconfiguration that should be solved by properly creating and configuring access lists (which should be done during the implementation phase). That being said, not all companies will be able to quickly move to a secure state. If an organization fears they are at risk, it is important to prioritize this implementation since it may take some time. In the meantime, organizations need to implement detection and prevention capabilities as a workaround in order to at least control and monitor what is happening in the network while access lists are properly configured.

More importantly, after solving this issue, organizations should not become complacent. They need to analyze how properly patching and configuring SAP with a risk management process should be an ongoing effort rather than an alert reaction.

Dustin: The good news is that SAP released guidelines several years ago to prevent these attacks. Companies should review the SAP patch notes (SAP Note 1408081, SAP Note 821875, SAP Note 1421005), which can be found on the SAP site. If they apply the appropriate access controls and configuration changes, they can better protect themselves.

Abby: But how do companies know which SAP vulnerabilities to focus on first?

Dustin: Our team, X-Force Red, offers vulnerability assessments and vulnerability management services, which identify and automatically prioritize SAP exploitable vulnerabilities so that companies know which ones to focus on first. We use Onapsis’ tools to uncover SAP vulnerabilities so companies can see where to apply their SAP patch notes.

Sebastian: Prioritization is key. Risk assessments are always complex and can become even more challenging in a complex system. A lot of companies are still working on a governance program to ensure proper owners are established for handling SAP security. It is too common for a chief information security officer (CISO)’s organization to think all security but SAP is under their control, considering an SAP team has always been there (even before the CISO existed) and has been applying traditional SAP security methods such as separation of duties (SoD) and governance, risk and compliance (GRC). The good news is this trend is changing. Organizations are working cross-functionally to ensure their most critical systems are secure. They are able to define the scope and responsibilities for each team and ensure SAP security does not fall under the radar.

Abby: Thank you, Dustin and Sebastian, for discussing these exploits today. Hopefully, readers will find your recommendations to be useful. Any last words?

Dustin: It is important to remember that these exploits were known for a few years now. What is unique at this point is that there is absolutely zero barrier to entry. Anyone can write the exploit code since it was published on GitHub. That is why companies must make finding the exploitable vulnerabilities and fixing them a top priority.

Sebastian: Thanks to both of you. As Dustin said, we are not talking about new stuff, but still new risks. Now it is the responsibility of organizations to take these alerts seriously and move fast to secure these risks to prevent any malicious activity.

Abby: Thank you!

Learn more about X-Force Red’s vulnerability management and penetration testing services.