- Home / The Risk of Reverse Engineering SAP Security Notes: The Importance of SAP Patch Management
The Risk of Reverse Engineering SAP Security Notes: The Importance of SAP Patch Management
In this article, we want to highlight the importance of SAP Patch Management in implementing monthly security patches promptly.
Introduction
Every Patch Tuesday, SAP releases their monthly security patches to fix vulnerabilities in the SAP ecosystem. This is great for defenders since it allows them to bring their SAP code base to the latest version, thereby lowering risk in their SAP systems for exploitation of known vulnerabilities. The downside, however, is that while releasing these patches, SAP also releases information to the public that might be used to deconstruct/reverse engineer these patches and develop exploits for them. This process makes it possible to target SAP applications with this information. It is therefore important that after SAP releases their patches, customers assess these patches as soon as possible and implement them to make sure these vulnerabilities cannot be exploited any longer. This stresses the need to have a proper Patch Management process in place.
An example
Let’s look at an example from last month’s SAP Security notes. Among the 20+ fixes, there was SAP Security note 3294954, Fixing a Directory Traversal vulnerability in SAP NetWeaver:
his note has a HIGH priority and a CVSS score of 8.7 out of 10, which means that the risk can be substantial. The note is a typical SAP ABAP Security note, which means that within the details, you can find all the exact changes made to the code. By going to the Correction Instructions, you can see that the vulnerability is present in 13 versions of the SAP_BASIS component, one of the core components of every SAP ABAP system. By clicking on a specific version, e.g. SAP_BASIS 7.57, you can see the impacted ABAP objects, in this case, Function Module EPS_SEEK_OUTPUT_FILE, and the changes in the code.
This Function Module is supposed to open a file for output/overwriting in the EPS/in folder by default. By going through the code, it is not that hard to spot that you can break out of the EPS/in folder and specify any other file location on the file system:
Even though there is an Authorization Check, this should not occur. If you specify, for example, an existing file in another location than the EPS/in directory, like in the example below, you can empty the file:
This introduces the risk of overwriting/emptying of sensitive files, leading to Denial of Service or bypassing security measures by e.g. overwriting of Access Control Lists that protect the RFC Gateway of the Message Server. The latter especially can lead to fully compromised SAP systems.
Since everyone with access to the SAP marketplace can see these code changes, it is not that hard for someone with developer knowledge to reverse engineer the corrected code and learn how to exploit it. For that reason, as mentioned before, the need for a speedy, thorough and complete Patch Management is clear.
Conclusion
Once SAP releases their monthly SAP security patches, make sure to do an assessment and see which patches are relevant to your systems and apply these as soon as possible. Attackers may use the released patches to reverse engineer and start exploiting them. To stay secure, implement a repeatable Patch management process as part of your Vulnerability Management process and stay in control of the security of your SAP systems.
SecurityBridge Security & Compliance helps you in this process by automating periodic scanning of your SAP systems and largely automates your monthly implementation of SAP security notes.
Get in touch for a demonstration or follow us on LinkedIn for more SAP security-related news, articles, and whitepapers.
