SAP Hana users warned of security vulnerability

"If an attacker can exploit this vulnerability, he can get access to all encrypted data stored in an SAP Hana database," said Alexander Polyakov, CTO with ERPScan, which presented the details Thursday at the Black Hat Sessions XIII conference in the Netherlands.

Polyakov's firm specializes in testing enterprise resource planning (ERP) software from companies such as Oracle and SAP for security purposes. Last year, it had already found SAP Hana installations to be vulnerable to SQL injection attacks, he said.

More recently, "our goal was to understand if we can get access to more data and to other servers in the company," Polyakov explained.

What it found was that it was possible to get access to information such as user passwords and root keys because they were typically stored using the same default encryption key across Hana systems, giving potential hackers relatively easy access.

"The key is the same for every installation until the administrator changes it," Polyakov said. "After a couple of other penetration tests we found out that nobody was really changing this key."

The same issue exists on SAP mobile platforms, he added. Specifically, the application password stored in the configuration file was encrypted with the same default key in every installation.

At least one of the SQL injection vulnerabilities in Hana has already been patched, Polyakov said. In addition, SAP's own guidelines and security recommendations stipulate that the master key should be changed, Polyakov noted.

"Unfortunately, very few customers follow those recommendations," he said.

SAP works closely with external companies including ERPScan to ensure the security of its products, the company said in a statement.

"Our recommendation to all of our customers is to follow the advice in the SAP Hana Security Guide and change the static master keys that are issued with our products," it said.

If such problems exist in SAP's code, it's likely there's a similar issue in custom applications developed by third parties or by in-house developers "who are much less aware of secure development and can make more mistakes," Polyakov said.

It used to be common for software to use default passwords, he noted.

"Now we have a new problem: encryption keys with a default value," he said.

Eventually, Polyakov added, "vendors will give users the option to enter a security key during installation rather than putting somewhere in 160 pages of documents that the default key should be changed."