CIO

Does SAP handle security researchers better than Oracle?

  • Liam Tung (CSO Online)
  • 13 August, 2015 10:28

SAP was once a security laggard, according to one security researcher, but in light of yesterday’s rant by Oracle’s CSO, SAP is looking pretty good.

As Oracle spent Tuesday back-peddling from its chief security officer’s attack on security researchers, its German rival in ERP systems SAP was busy releasing over two dozen own fixes for flaws affecting multiple platforms including its in-memory database HANA and SAP Mobile, the platform for enterprise customers to build smartphone apps to access business systems. Both systems are used in dozens if not hundreds of Fortune 500 companies.

The highest risk bug in SAP’s August update was remote command execution bug in one product that allows an attacker to run commands remotely, according to SAP and Oracle security specialist ERPScan.

Another affects a component of SAP NetWeaver called AFP Servlet, while two more bugs affected SAP’s in-memory platform HANA

Fellow SAP specialist security firm, Onaspis, found three bugs deemed by SAP as “high risk” that undermine the security of SAP Mobile’s DataVault, which is used to store and encrypt sensitive information on the mobile device.

In all three cases, an attacker would need physical access to the device to exploit the bugs, but if they were to gain that they’d be able to decrypt credentials and other information stored on the device; modify configuration identifiers used to access SAP business applications; or read encrypted log in credentials stored in the device.

SAP released fixes for 22 security flaws in its August update and a further four updates to fix previously released patches — and most of them were provided by external security researchers that SAP credited with discovering.

While SAP hasn’t had the best history of dealing with security researchers and fixing the flaws they’ve reported, it is a different story to the colourful post by Oracle’s CSO Mary Ann Davidson yesterday who drew a line at reverse engineering its software and chastised its customers and researchers for doing so.

Customers might be concerned about advanced hackers using zero-day flaws in Oracle software to breach their data, but in Davidson’s view it was a cut and dry argument over customers violating their end user license agreement (EULA). Therefore, Oracle didn’t welcome bug reports derived from this technique and wouldn’t reward reporters with any acknowledgement for finding them.

SAP has similar terms in its EULA in its statement 6.2 Protection of Rights that states "Reverse engineering of the Software and other SAP Materials is prohibited" — a clause that ERPScan’s chief technology officer Alexander Polyakov is very familiar with.

Despite this, Polyakov told CSO Australia that SAP doesn’t penalise researchers if they do violate its EULA.

“[Credit doesn’t] depend on how vulnerability has been found,” said Polyakov.

Polyakov has found over 30 bugs in Oracle’s ERP software and a multitude of bugs in SAP’s.

Davidson also said that Oracle didn’t need outside help since its own engineers — with the benefit of legal access to its source code — found over 80 percent of bugs it fixes while external researchers found just three percent. Bug bounties were of little value to Oracle since it made more sense to simply hire its own white hat hackers.

But Polyakov argues that the research that third-party consultants is valuable and results they produce are often the result of far less invasive ways to uncover bugs in both Oracle’s and SAP’s software.

“There is no need to use such aggressive techniques [as reverse engineering] to discover most of vulnerabilities. Just basic checks, such as putting a quote in the name field to identify potential SQL Injection vulnerability, work perfectly,” he said.

Despite Davidson’s warning to researchers and customers over reverse engineering, Polyakov said he’d never received such a message from Oracle, though he added that Oracle still hasn’t fixed a flaw he reported to it three years ago.

“We have never received messages telling us to stop researching Oracle products. It may be so because our notifications usually provide examples of real vulnerabilities. Well, sometimes it turned out that the vulnerability we found had been discovered earlier by Oracle itself or by other researchers. We were credited 16 times and always were acknowledged. Another matter is that we were often waiting for it for more than 3 years, like it was with this vulnerability. And this is not an isolated case,” said Polyakov.

SAP’s handling of security researchers was recently called in to question after it appeared to take offence to Onaspis' claim that 95 percent of SAP customers largely failed to apply SAP’s patches — a situation the firm said was partly due to SAP’s secretive approach to disclosing flaws.

SAP may have some room to improve but according to Polyakov, the company is far better than it was just five years ago.

“In 2007, when we just started to send vulnerabilities to SAP, there was only one person who was responsible for security response in SAP. And until about 2010 we had do describe in detail almost every step we take to exploit a vulnerability and give examples of real threats. Sometimes our correspondence lasted for months,” he said.

“Nowadays SAP Security Response Team consists of dozens of people worldwide. They require little or no additional information, as they are highly skilled in security. SAP also holds annual training sessions for the team and developers. We were invited to these meetings to share our knowledge.”

Given that Oracle and SAP underpin the majority of IT systems in industries deemed “critical infrastructure” it’s likely to benefit everyone if vendors take a less adversarial approach to security researchers.

“Nuclear power plants, manufacturing, banking - name anything and you will find either Oracle or SAP or both systems, which manage mission-critical processes. When this kind of vendor is telling that they don't need any help from external researchers, in terms of vulnerability findings, well, this world is too dangerous,” Polyakov.

Want to know more?

Why not become a CSO member and subscribe to CSO's mailing list. 

Get newsletters, updates, events and more right here