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, if used by attackers, can allow anyone to interact with an organization’s SAP enterprise resource planning platform and perform unauthorized transactions.
With the exploits, for example, attackers could use the code to shut down an entire SAP system, execute commands on behalf of the operating system or extract valuable data. The researchers published the exploit code on GitHub so that it is publicly available to the world. While publishing exploits is a known practice by security researchers aiming to benefit the penetration testing and vulnerability research community, unfortunately, it may also lead to detrimental consequences if the code gets into the wrong hands.
However, before concerns run high, it’s important to know upfront that a confirmed imminent attacker is not lurking in the shadows, and if your organization is vulnerable to these exploits now, that vulnerability may have existed for a long time. This is not a new risk; it’s a matter of security administrators taking corrective measures and making configuration changes to mitigate the risk. Off the bat, the SAP patch notes to review are as follows:
- SAP Note 1408081
- SAP Note 821875
- SAP Note 1421005
Apply Fixes Where Possible
SAP has known about these exploits for several years now and has released configuration information to help organizations update their software and limit the potential of exposure. However, it appears that many organizations did not apply the fixes, potentially because the exploits used to be nearly impossible to access, making the overall risk marginal.
Historically, to exploit SAP systems, you either needed a specific software development kit developed by SAP and only available to licensed SAP customers, or specific and closed-source tooling that interfaces with SAP and aims to provide security to SAP customers. Knowing the dangers of anyone getting their hands on the kit and/or tooling, SAP and authorized security vendors, such as Onapsis, kept them closely guarded.
But with the publishing of these exploits, the risk of an attack on organizations that use SAP has increased significantly, making it ever more important for them to apply SAP’s recommended configuration fixes.
What Do the Experts Say About Securing SAP Systems?
In light of the changes to the risk to SAP systems, I spoke with Onapsis Director of Research Sebastian Bortnik and IBM X-Force Red’s SAP hacking expert Dustin Heywood (aka Evil Mog) about 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!