Every month, SAP publishes a collection of new and updated SAP Notes involving vulnerabilities in the SAP software on patch day. It’s a key date in the calendar for everyone concerned about security and the subsequent system patching is often very work-intensive and time-consuming. But where do the reports come from and how does SAP find out about them? Does the software vendor intentionally search for vulnerabilities to correct?
This month, we actively took part in the identification of a vulnerability on SAP patch day. It gave us the opportunity to analyze the structure of patch day in more detail and describe the reporting process.
With 31 reports, the current April patch day contains updates to patches for 10 known vulnerabilities, while an additional 21 vulnerabilities are new. But who reports vulnerabilities? Is it an internal SAP process or external? Surprisingly, of the 31 total vulnerabilities this time around, five were reported by SAP and 26 from outside – meaning over 80 percent of the reports were submitted externally. This can be seen in each SAP Note, in the “Reported Externally” field: If this field is set to “Yes”, the report came from individuals or organizations outside of SAP.
One explanation for the large external share is the fact that vulnerabilities can arise due to SAP’s dependency on integrated external software solutions, such as the often-used component Log4j.
The process from identifying a vulnerability to reporting to SAP
As part of our analysis, we identified a .jsp (Java server page) in a current SAP system. In an older version, this file contained additional lines of code for an authentication check. This caused some confusion, because why should SAP have removed the authentication in a newer file? Potential answers include a restructuring of the source code or a relict – an older file from a previous release that may still have been present in the system.
After some additional research, we discovered that a vulnerability had already been identified in the same context in the past. It was supposed to be corrected as of a specific patch level, but the system was already far above this level. We therefore advised SAP to review this case immediately.
Two ways for reporting a vulnerability
One option is to submit an incident for the affected component. Another method involves a pupblicly accessible form, which is intended for security researchers. Since this case involved a customer system, we decided to use the second method.
In the form for security researcher, you select the product and the affected version and platform, then enter a title – this information serves as meta information for the report.
Extensive reporting for reproducibility
Reports of vulnerabilities should always be accompanied by a good description. For this reason, we described the vulnerability itself, as well as the procedure for reproducing it, in the report. The idea is to make it as easy as possible for the vendor to reproduce the situation. Thanks to its similarity with a previous vulnerability, we were even able to specify a specific component – which is helpful for SAP in forwarding the report to the responsible product team.
Rapid response after report receipt
Just one day after sending the report, we received an acknowledgment from the Product Security Response Team, together with the unique number assigned to our report. Just four days later, our finding was confirmed, together with the information that the vulnerability would be fixed on the April patch day. SAP requested an official CVE number and patched the identified vulnerability immediately.
We were pleased with the fast response by SAP and by the fact that we were able to help improve SAP security this month.
Don’t delay patching your SAP systems – always implement the corrections described in the SAP security notes as quickly as possible. If you have any questions or need support with safeguarding your systems, visit our website or e-mail us.
Alexander Bertram (SAP Security Consultant, SAST SOLUTIONS)
More info on the topic: