By Kelly Jackson Higgins
“We strongly suggest that all users apply the patches as soon as possible. Honestly, I don’t think they will do so,” says Mariano Nunez, CEO of Onapsis, whose firm discovered the flaws in the software.
“Many customers in our experience do not even apply security patches at all. Some only do when they upgrade, some once or twice a year, and some every quarter,” Nunez says. “We have still not seen any customers fully updated to the latest patches” in their ERP systems, he says.
That’s because ERP applications, like their closely coupled database applications, pose a patching conundrum for users. Applying patches to systems that run business-critical functions such as finances, sales, customer relationship management, and manufacturing, can be disruptive, time-consuming, and complicated. An ERP is often customized, so there’s always the danger of breaking some piece of the business process when you install a patch.
“The issue with ERP is complexity — [a] vastly complex core application, a very complicated database structure to support it, and you’ve got most companies using a huge number of customizations sitting on top of the application,” says Adrian Lane, CTO for Securosis.
Lane says the dependencies between the application and the database also pose challenges when it comes to patching. He recommends patching the ERP application and its database at the same time so that everything syncs up properly and users aren’t faced with downtime disruptions.
[A researcher discovered a critical set of security vulnerabilities that afflicts more than half of SAP servers on the Internet. See Over Half Of SAP Servers On The Internet Are Vulnerable To Attack, Researcher Says. ]
Onapsis first reported the flaws to Oracle in the fall of 2010. The bugs are technically design flaws versus pure security vulnerabilities, according to Juan Pablo Perez-Etchegoyen, CTO at Onapsis. “That is why they are hard to fix,” he says.
The critical or high-risk flaws include an arbitrary file-write flaw in JD Edwards 9.0 EnterpriseOne Server + EnterpriseOne Tools 8.98 and older versions, which if exploited, would let an unauthenticated attacker remotely access or alter any business information in the ERP system. Onapsis says this in effect would mean a total compromise of the ERP infrastructure. Another flaw found in the same products is a so-called information disclosure flaw, which could allow an unauthenticated attacker to steal passwords of authorized users of the system. And a kernel flaw found by the researchers would allow an attacker to change configuration files and take over the ERP system.
Onapsis’ Nunez, who will be speaking at the RSA Conference next week in San Francisco, says patching an ERP system is actually more difficult than patching a database. “An ERP has other components, such as application servers or standalone systems, which can be prone to vulnerabilities completely independent of the underlying database” like the vulnerabilities Onapsis has disclosed today, he says. “You cannot patch an ERP’s database until the ERP vendor ‘certifies’ that the database patch is approved by them and won’t break the ERP. ERPs are much more customized than databases, which makes its testing much more complex to ensure business processes are not broken. Because of their architecture and wide range of versions, it’s quite a challenge to find out to which systems in the platform an ERP patch applies.”
But Securosis’ Lane says you can’t truly differentiate the ERP from the database. “No ERP app works without a database. It may be Oracle, it may be IBM, but a database is involved,” he says.
Details on the Oracle JD Edwards vulnerabilities are here in Onapsis’ security advisories.