Onapsis has released its latest list of security vulnerabilities for SAP HANA and SAP TREX. There are 15 issues on the list including two critical and seven high risk. This latest list comes three months after a report issued by the highly respected Ponemon Institute highlighted serious issues with SAP security.
The full list of vulnerabilities spans two pages and is found here. Onapsis will email details of each vulnerability to interested users. Those details are very limited but do include details of when the vulnerability was first detected and reported to SAP. It also gives a timeline of what has happened since.
Sebastian Bortnik, Head of Research, Onapsis: “This set of advisories is unique as most of the vulnerabilities attackers can leverage are undervalued. Meaning, the way in which they can be exploited is not always obvious and can go undetected. For example, one of the critical vulnerabilities that can be exploited creates an error message which includes sensitive information about its environment, users, or associated data.”
Onapsis giving little away about each vulnerability
When you look at the details that Onapsis provides for each vulnerability they are very brief. There is often little more than a one line description of each issue. They do contain the SAP Security Note reference pointing to a fix and a timeline of how long it took from discovery to the issue of the patch.
The timelines tell an interesting story not least in how quickly SAP responds. The SAP HANA critical issue which allowed a brute force attack was dealt with quickly. Notification on August 7 2015, acknowledgement by September 7 and customers notified on October 20. Not so for the critical vulnerability in SAP TREK which allowed remote command execution. This was reported to SAP on 21 March 2015, acknowledge 14 April but not part of a security note until 13 October.
SAP failing its own fix time
The SAP Community Network lists SAP security notes each month. It states: “A responsible vendor usually tries to fix an issue in a timely fashion. As a rule, it takes a vendor approximately 1-3 months to release a patch. However, some of vulnerabilities are not easy to close (especially architectural ones). As long as SAP is concerned, the required time to patch a security issue is 3 months, according to rough estimations.”
The June security advisory admits that one of the vulnerabilities patched was three years old. There is no explanation why, just that it took three years. In the case of the SAP TREK remote execution issue above it took six months for SAP to fix. Many customers will wonder why it took so long. SAP could have provided an advisory so that security teams could begin monitoring systems.
Customers not applying security patches
It is not just SAP that is struggling with timelines. The same June report references an article from ERPSCAN about the May 2016 US-CERT alert of a SAP Cyberattack. This addresses the Invoker Servlet vulnerability that was reported to SAP back in 2010. SAP did publish details of this attack and told customers to disable the functionality if they didn’t need it. An article from ERPSCAN responded saying: “..they [SAP] didn’t provide any specific details about risks. In other words, the customers were not encouraged to disable it.”
Despite SAP issuing a patch it appears that a number of customers didn’t apply that patch to their system. The US-CERT alert shows that more than five years after a resolution, customers were vulnerable because they didn’t patch. It is easy to criticise vendors for not issuing patches. Customers also have to accept their responsibility. Audits should identify where a failure to patch critical system is a risk management issue. The problem for many SAP customers is that their environments are so complex that fixing issues takes a considerable period of time and testing.
Will SAP in the cloud fix this?
Yes, no, maybe. It really is that hard to answer. Yes because SAP have complete control of the environment and should be able to apply a patch quickly. No because they would still have to create a process that didn’t destabilise the underlying cloud-based solution. Maybe because there would still be concerns over the impact on customers which means that caution would win over security.
Addressing security issues where customers have heavily customised the software is a major challenge. The complexity of the software doesn’t help and SAP is clearly struggling to meet its own standard on fixing issues. Customers also have to play their part in keeping systems secure. This is not simple. Many SAP customers are still where they were five years ago doing one or two updates a year.
This is beginning to change as SAP customers respond to user demand for faster release times of updates and new features. The challenge for SAP is proving that is can do a better job with its cloud solutions. This includes faster resolution of vulnerabilities and then applying them quickly. SAP could then resolve issues such as the Servlet Vulnerability which continues to affect customers more than five years after it was fixed.
After we went to press we were contacted by SAP’s PR Agency. Despite our mentioning that SAP responded to each of the Onapsis vulnerabilities and that it monthly published a list of security fixes, they wanted a “right of reply” to the article. This is their statement:
“SAP Product Security Response Team collaborates frequently with research companies like Onapsis to ensure a responsible disclosure of vulnerabilities. All SAP HANA and Trex vulnerabilities disclosed in Onapsis current press release have been fixed already and published between August 2015 and January 2016. Security patches are available for download on the SAP Service Marketplace. We strongly advise our customers to secure their SAP landscape by applying the available security patches from the SAP Service Marketplace immediately.”
All of this was covered in the piece. We also made it clear that SAP was itself failing to meet its own guidelines for fixing patches and customers needed to respond quicker.