Oracle Has Yet Again Underestimated The Criticality Of Vulnerabilities. Now in JD Edwards ERP

Tuesday, February 26, 2013

Alexander Polyakov

7d55c20d433dd60022642d3ab77b8efb

ERPScan researchers have once again helped Oracle to eliminate a dangerous vulnerability. The vulnerable system is JD Edwards Enterprise One, namely the way the thick client is used on workstations. The vulnerability was closed in the January patch by Oracle (CVE-2012-1678).

The details of this issue were partially disclosed 2 years ago at BlackHat conference in DC, where Alexander Polyakov, ERPScan CTO, reviewed the architecture problems of various business applications, whereas the vulnerability itself was exposed a whole year earlier in the course of a security assessment of a JD Edwards installation.

The problem is that the configuration file JDE.INI, containing database credentials, is frequently stored on the workstations of users. It means that any legitimate user can get full access to the ERP system.

For some reason, Oracle has underestimated the CVSS rating of this vulnerability (it is, by the way, not the first time they do that). This rating shows adequate results for typical vulnerabilities, but it can be misleading for some unusual issues. What’s more, the developer may cheat and, for instance, evaluate the impact on CIA as “partial” instead of “complete”. As a result, a critical vulnerability has rating 3.5 (low criticality). In reality, a vulnerability which allows any ERP system user to access all data and assign themselves any privileges is hardly low,” Alexander Polyakov remarks indignantly.

It is worth mentioning that the problem was already pointed out by our colleagues from ApplicationSecurity in an interview for PCWorld:

“Oracle likes to downplay the risk of its vulnerabilities," said Alex Rothacker, director of security research for AppSec. As a result, organizations using Oracle's vulnerability ratings to prioritize system updates may unduly delay applying some critical patches, he said.

Here is how authentication works in JD Edwards:

1. The user enters his/her name (for example, “APPUSER”) and password (for example, “APPASSWORD”) in the client application.

2. The client application tries to connect directly to JD Edwards database with username “JDE” (default) and the password of this user, which is read form the configuration file of client workstation: JDE.INI (the password is stored in the field “SECURITY”, which has the value “JDE” by default).

3. Upon getting direct access to the database, the client application checks the password for the user “APPUSER” in the table “F980WSEC”, and if the entered password matches, draws the GUI for this user based on his/her roles in the table “APPUSERS”.

This kind of authentication process is outrageous, being virtually performed in the client application. If an attacker gets access to a user’s workstation, or if he is an insider himself, or if he can intercept traffic between client and server (for example, password is easily decrypted by the CAIN & ABEL utility in the older versions of MSSQL), he will get the credentials of user “JDE”, who has administrative rights in the database. Nothing will restrain his malicious actions after that.

Oracle used to recommend restricting access to JDE.INI on workstations as a stopgap fix (not the best solution). Now, in 3 years since the vulnerability was discovered, it is solved, and users can download the official patch from Oracle website. However, there is still a question of how it was actually solved.

Possibly Related Articles:
10473
Vulnerabilities
ERPScan vulnerability Oracle JD Edwards Enterprise One
Post Rating I Like this!
E84b8707ffd8e4ab0fca0183c03df800
Brian Blank Oracle has been utter crap about security for years. Back in the days of Java 1.4 and 1.5, I would constantly ask them for supported upgrades to the embedded Java. Given the option, I would never use Oracle's products again.
1361977740
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.