Securing Your SAP Through Research
In the latest Notes Tuesday Onapsis was credited with discovering and reporting almost half (10 out of 23) of the vulnerabilities addressed by SAP (or alternatively three quarters or one third, depending on how you do the math: there were only 13 Notes that were attributed to third party security researchers of which Onapsis discovered 10. And SAP released 23 security notes on Notes Tuesday; but had also released an additional 10 notes since the last patch Tuesday; bringing the total released during that period to 33).
Having received a number of messages of appreciation and additional questions about the work done by Onapsis Labs to find so many of the vulnerabilities remediated by SAP this month, I thought people should know about the effort and work done to discover and responsibly report these risks every month. So how do we find these issues in the first place? There are a number of possible ways. It could be a result of a number of activities that the Onapsis Research Labs team or Professional Services team perform. It might be we discover the vulnerability during a services engagement for a client; or as the output from a dedicated bug hunting activity (where our labs team will take a deep dive with SAP technology and attempt to find previously unknown issues in SAP modules and applications) or they are born out of ideas that lead to “What if” and other brain storming conversations that take place internally.
In addition we stay aware of security research being carried out and presented at conferences around the world. This research could be specific to SAP or security focused research in an unrelated segment of the industry; however we like to analyze the attack or concepts being presented and trying to determine if it can then in turn be applied to SAP security; with often interesting results. When we suspect we might be on the trail of what appears to be an interesting vulnerability we will assign a member of our research or professional services teams to pursue the vulnerability. They will be provided the time and resources need to determine the true scope and impact of the vulnerability; or to demonstrate that the vulnerability did not exist in the place we believed. Either result is valuable, as time spent on a vulnerability that turns out not to be present still results in our teams having a deeper knowledge of the under workings of a piece of technology. When we do identify a new vulnerability our first responsibility is to report the finding to SAP.
We take the time to put together a report detailing the finding and the instructions and proof of concept code necessary for SAP's security team to demonstrate the vulnerability to themselves and others. This reporting can start a back and forth dialog with the SAP Security Team, as they might have questions or requests for clarification and additional information. As you would expect we work hard to make sure their team has a clear understanding of the issue and the information they need to produce a note addressing the issue. Once SAP has released the security note addressing the issue we might then consider if the technique used to discover or exploit the vulnerability is something that others might find value in understanding; if we believe that is the case then we may present on our findings at relevant security conferences.
Ultimately we do this work because it raises the security of SAP products and helps all customers of SAP, not just our mutual customers, to become more secure and more immune to attacks. Given the recent reports by Microsoft of malware looking for and inventorying SAP systems we can safely assume the bad guys are looking for the same vulnerabilities. By disclosing the ones we find to SAP and presenting techniques we discover to security practitioners we hope to help enable the SAP and security community to better secure their SAP systems.