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.

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. As a result, organizations using Oracle’s vulnerability ratings to prioritize system updates may unduly delay applying some critical patches.

Alex Rothacker, director of security research for AppSec

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.