Oracle has released an out-of-cycle security advisory (CVE-2017-10151) for a vulnerability affecting Oracle Identity Manager. This vulnerability has a CVSS 3.0 base score of 10 out of 10. Oracle Identity Manager is the identity governance component within the Oracle Identity Management solution. All supported versions of Identity Manager are impacted from 220.127.116.11 to 18.104.22.168.0. Most likely 22.214.171.124 through 126.96.36.199 are also vulnerable. Previous Identity Manager versions (10g and 9.x) that are not based on Oracle WebLogic are probably not vulnerable.
The vulnerability is that the Oracle Identity Manager system user account (OIMINTERNAL) can be accessed using the default password through the Oracle WebLogic server. As this is a highly privileged user, the entire Identity Manager environment can be completely compromised via an unauthenticated network attack.
The work-around is to change the OIMINTERNAL user password to a random string in the WebLogic administration console under Domain -> Security Realms. A patch will be available in the future to automatically change the password. See My Oracle Support Note "Oracle Security Alert CVE-2017-10151 Patch Availability Document for Oracle Identity Manager (Doc ID 2322316.1)" for more information.
As Oracle released an out-of-cycle security advisory, either detailed information regarding the vulnerability has been released or will soon be released, or Oracle has been informed the vulnerability is being actively exploited.
As with almost all previous Oracle E-Business Suite Critical Patch Updates (CPU), the October 2017 quarterly patch is significant and high-risk. 47 of the past 52 quarterly patches are significant and high-risk as they fix one or more SQL injection vulnerabilities or other damaging security vulnerabilities in the web application of Oracle E-Business Suite. Despite the publicity, marketing, or naming of specific vulnerabilities, this quarter is no different than previous quarters in terms of risk and prioritization within your organization.
For this quarter, there are 3 SQL injection vulnerabilities, 16 cross-site scripting (XSS) vulnerabilities, 3 information disclosures, and 4 other types of vulnerabilities fixed. Most important is that 25 of the 26 vulnerabilities are remotely exploitable without authentication.
Externally facing Oracle E-Business Suite environments (DMZ) running iStore or iSupport should take immediate action to mitigate the two vulnerabilities impacting iStore and four vulnerabilities impacting iSupport (and Knowledge Management). These web pages are allowed by the URL Firewall if the iStore or iSupport modules are enabled. All six are cross-site scripting (XSS) vulnerabilities, which requires interaction with the end-user such as clicking a link but allows for the attacker to hijack the end-users session.
October 2017 Recommendations
As with almost all Critical Patch Updates, the security vulnerabilities fixes are significant and high-risk. Corrective action should be taken immediately for all Oracle E-Business Suite environments. The most at risk implementations are those running Internet facing self-service modules (i.e., iStore, iSupplier, iSupport, etc.) and Integrigy rates this CPU as a critical risk due to the number of SQL injection vulnerabilities that can be remotely exploited without authentication. These implementations should (1) apply the CPU as soon as possible or use a virtual patching solution such as AppDefend and (2) ensure the DMZ is properly configured according to the EBS specific instructions and the EBS URL Firewall is enabled and optimized.
Most Oracle E-Business Suite environments do not apply the CPU security patch in a timely manner and are vulnerable to full compromise of the application through exploitation of multiple vulnerabilities. If the CPU cannot be applied quickly, the only effective alternative is the use of Integrigy's AppDefend, an application firewall for the Oracle E-Business Suite. AppDefend provides virtual patching and can effectively replace patching of EBS web security vulnerabilities.
Oracle E-Business Suite 11i
As of April 2016, the 11i CPU patches are only available for Oracle customers with Tier 1 Support. Integrigy’s analysis of the October 2017 CPU shows at least 18 of the 26 vulnerabilities are also exploitable in 11i. 11i environments without Tier 1 Support should implement a web application firewall and virtual patching for Oracle E-Business in order to remediate large number of unpatched security vulnerabilities. As of October 2017, an unsupported Oracle E-Business Suite 11i environment will have approximately 170 unpatched vulnerabilities – a number of which are high-risk SQL injection security bugs.
11i Tier 1 Support has been extended through December 2018, thus October 2018 will be the final CPU for Oracle E-Business Suite 11i.
Oracle E-Business Suite 12.0
CPU support for Oracle E-Business Suite 12.0 ended January 2015 and there are no security fixes for this release. Integrigy’s analysis of the CPU shows at least 22 of the 26 vulnerabilities are exploitable in 12.0. In order to protect your application environment, the Integrigy AppDefend application firewall for Oracle E-Business Suite provides virtual patching for all these exploitable web security vulnerabilities.
Integrigy will be presenting again this year on database security at Oracle Open World 2017 (San Francisco, October 1-5). If you will be attending Open World, please join us for this informative session on database security.
Sunday, Oct 01, 10:45 a.m. - 11:30 a.m. | Moscone South - Room 159
Stephen Kost, Founder and CTO, Integrigy Corporation
Properly securing an Oracle Database requires significant effort and often expensive security add-on products. The Thrifty DBA likes having secure databases, but doesn’t like to spend money on expensive security products when equivalent zero or low-cost solutions are available. In this session discover thrifty yet effective security solutions to solve auditing, encryption, virtual private database, and authentication challenges.
Integrated Cloud Platform: Database, Identity and Security
Please let us know if you would like to meet while at Open World to discuss Oracle Database or Oracle E-Business Suite security.
The attached is a SCAP OVAL sql57_test example for the Oracle E-Business Suite - it will suffice for any Oracle database. To use the attached, rename the .txt extension to .xml and if you have questions and/or comments please direct them to: email@example.com.
The key points you will know is for the JOVAL connection string for Oracle:
Version values: 11.2.0, 11.1.0, 10.2.0, 10.1.0, 9.2.0, 9.0.1
Connection string (do not use JDBC syntax): user=your_username;password=your_password;SID=your_instance
Last week’s unprecedented ransomware cyber attacks (http://preview.tinyurl.com/lhjfjgk) caught me working through some research on security automation. The cyber attacks evidently were attributed to an unpatched Windows XP vulnerability. When challenged with securing 1,000s of assets such as all the Windows desktops and Linux servers in an organization, automation quickly becomes a requirement.
Automation is increasingly coming up in our client conversations about how to secure the technology ‘stack’ supporting large ERP implementations such as the Oracle E-Business Suite, PeopleSoft, and SAP. For example, how do you from a security professional perspective, communicate an objective risk assessment comprehensive of both the secure baseline configuration (control adherence/violation) and security patch levels (patch/unpatched CVEs) for the Linux operating systems, virtualization software, web server, database and the ERP application itself? Without automation, it is not feasible to promptly produce risk-based assessments of the complete technology stack and to produce results that are readily expressed in a common risk measurement (e.g. CVE) not requiring deep subject matter expertise.
Automation, however, can only be considered after requirements have been defined. I have long used Security Technical Implementation Guides (STIGs) in both my research and work with clients to define security requirements. STIGs are secure configuration standards developed by the US Department of Defense for products such as the Oracle RDBMS and are freely available (http://iase.disa.mil/stigs/Pages/index.aspx). While most clients do not need their databases hardened to military specifications, STIGs are an invaluable source of security best practice thinking.
To answer the question of how do you automate STIG and/or security checklists, again the Department of Defense has thought through the challenges and has created the Security Content Automation Protocol (SCAP).
SCAP is a multi-purpose framework to automate the security scanning of configurations, vulnerabilities, patch checking and compliance. SCAP content is developed by the National Institute of Standards and Technologies (NIST) and the components are described in the table below. The key point is that SCAP security content (checklists) is free and that the SCAP content scanning tools are available both in open source and commercial options.
eXtensible Checklist Configuration Description Format (XCCDF)
XML-based language for specifying checklists and reporting the results of checklist evaluations.
Open Vulnerability and Assessment Language (OVAL)
XML-based language for specifying test procedures to detect machine state
Common Vulnerabilities and Exposures (CVE)
Nomenclature and dictionary of security-related security flaws
Common Configuration Enumeration (CCE)
Nomenclature and dictionary of software security configuration issues
Common Vulnerability Scoring System (CVSS)
Methodology for measuring the relative security of software flaws
Open Checklist Interactive Language (OCIL)
XML-based language for specifying security checks that require human interaction or that otherwise cannot be bundled by OVAL
Asset Reporting Format (ARF)
Standardized data model for sharing information about assets to facilitate the reporting, correlating, and fusing of asset security information.
There are many tools, Integrigy’s AppSentry included (https://www.integrigy.com/products/appsentry), that will perform a STIG scan of an Oracle database. The question I was researching this week, is could I use a single SCAP tool to automate the scanning of both the Linux server and the database as well as possibly ERP configurations for PeopleSoft and/or the Oracle E-Business Suite – can could I possibly do this with open source software?
The first tool I considered was OpenSCAP (https://www.open-scap.org/). This open source tool is easy to install either on your laptop or Linux database server and has remote scanning capabilities. The example below shows the capabilities of the GUI tool ‘SCAP Workbench’ and the freely available content that is installed by default for scanning a Linux server.
This exercise quickly confirmed that there is a great deal of security automation available for Linux system security configurations. Here, though, is where I hit a wall: could OpenSCAP work with Oracle databases? While the SCAP standards clearly showed support for scanning SQL database configurations using OVAL’s SQL probes (e.g. sql_test, sql57_test etc…), I may be corrected, but the standard build of OpenSCAP do not appear to include the SQL probes.
To obtain the SQL probes for SCAP scanning of database configurations, after some research, I obtained an evaluation copy of Joval Professional (http://jovalcm.com/). Joval describes themselves as allowing you to Scan anything from anywhere and to allow continuous configuration assessments for developers, enterprises, content authors and security professionals.
The installation of Joval Professional was quick and I was able to scan my laptop and remotely scan the remote Oracle Linux server without issues. The screen shot below shows the results of the remote scan of the Linux server running the Oracle RDBMS.
With a bit of experimentation (and great customer service from Joval), I was able to quickly prove I could develop OVAL content for automated SCAP scanning of Oracle databases, either for standard database security checks or for Oracle E-Business and/or PeopleSoft configurations. One key concern with the proof-of-concept is that connection string hardcodes the user name and password. The hardcoding is certainly a security issue, but JOVAL (as well as OpenSCAP) offers python bindings. The screen shot below is a single OVAL scan that included two SQL checks as well as checks against content in the sqlnet.ora file using the OVAL probe: textfilecontent54_test.
My OVAL definition is referenced below. I am providing it as an example for others. The key points you will know is for the JOVAL connection string for Oracle:
Version values: 11.2.0, 11.1.0, 10.2.0, 10.1.0, 9.2.0, 9.0.1
Connection string (do not use JDBC syntax): user=<username>;password=<password>;SID=<instance name>
If you want to replicate the proof-of-concept:
Download a trial version of Joval Professional.
Run a scan of your local laptop
Run a remote scan of Linux server running your Oracle RDBMS
Edit sample benchmark file (here) for your database
Upload the edited sample benchmark into Joval
Run the sample benchmark scan
Having proven I can use OVAL to write Oracle and ERP audit checks, I will spend a bit more time expanding the POC. I am also interested in automation options for Joval and OpenSCAP exports to a NoSQL database such as MongoDB using the Asset Reporting Format (ARF) (https://scap.nist.gov/specifications/arf/). Both Joval and OpenScap have standard functionality to export results using ARF.
To properly secure an Oracle database requires significant effort and often expensive security add-on products. The Thrifty DBA likes having secure databases, but doesn't like to spend money on expensive security products when equivalent zero or low-cost solutions are available. The Thrifty DBA shows you thrifty yet effective security solutions to solve auditing, encryption, virtual private database, and authentication challenges.
The Thrifty DBA is a trademark of Integrigy Corporation.
The most recent version of the Oracle E-Business Suite, Release 12.2, introduces on-line patching to reduce downtime requirements. This new technical functionality is based on Edition-based redefinition provided by the Oracle 11gR2 database. For the E-Business Suite to make use of Editioning, Oracle has added a new schema to the ‘APPS’ family – the APPS_NE schema.
The APPS_NE schema is the owner of those objects previously owned by APPS that cannot be Editioned or in other words; the APPS_NEW is the APPS schema for the non-editioned database objects.
There are several security implications with regard to APPS_NE:
The same password must be shared among APPLSYS, APPS, and APPS_NE. The default password for APPS_NE is 'APPS.'
APPS_NE has similar elevated system privileges to APPS (e.g. SELECT ANY TABLE), but is not identical. See the listing below for the 56 privileges granted to APPS_NE.
APPS_NE must be logged, audited and monitored APPS_NE as you do APPS. APPS_NE needs to be added to your audit scripts and procedures as well as monitoring solutions
The following lists summarize the system privilege differences between APPS and APPS_NE
This is the eleventh and final posting in a blog series summarizing the new Oracle E-Business Suite 12.2 Mobile and web services functionality and recommendations for securing them.
Deploying Internet-based Oracle E-Business Suite web services requires proper configuration of the URL Firewall, both the url_fw.conf and url_fw_ws.conf and the use of a WAF – ideally the Oracle API Gateway. This recommendation applies equally to all whose only use of web services is the Oracle Supplier Network (OSN). One opening of the attack surface exposed to the Internet exposes the entire Oracle E-Business Suite.
For Mobile and Smartphone applications, due to the overall complexity and additional license requirements, it is recommended to continue using VPN for deployment instead of using an External Node.
The evolution of the Oracle E-Business Suite since its inception in the late 1980s has gone through many significant changes. For example, I can personally remember in the late 1990s upgrading clients to release 10.5 of the E-Business Suite with the big change being the introduction of the APPS schema.
The introduction of the APPS schema greatly simplified the technical interdependencies of the then 40+ applications of Release 10.5 of the E-Business Suite. The most recent version of the Oracle E-Business Suite, Release 12.2, with 200+ modules, introduces on-line patching to reduce downtime requirements. This new technical functionality is based on Edition-based Redefinition provided by the Oracle 11gR2 database. For the E-Business Suite to make use of Editioning, Oracle has added a new schema to the ‘APPS’ family – the APPS_NE schema.
The APPS_NE schema is the owner of those objects previously owned by APPS that cannot be Editioned or in other words; the APPS_NE is the APPS schema for the non-editioned APPS foundation database objects. APPS_NE has similar elevated system privileges to APPS (e.g. SELECT ANY TABLE), but is not identical. The same password must be shared among APPLSYS, APPS, and APPS_NE. The default password for APPS_NE is 'APPS.'
--This SQL gives a high-level summary of the difference between APPS and APPS_NE
SELECT OWNER, OBJECT_TYPE, COUNT(*)
WHERE OWNER = 'APPS_NE'
GROUP BY OWNER, OBJECT_TYPE
SELECT OWNER, OBJECT_TYPE, COUNT(*)
WHERE OWNER = 'APPS'
GROUP BY OWNER,OBJECT_TYPE
ORDER BY 1,3 DESC;
The table below is a high-level summary of the APPS schemas.
Oracle E-Business Suite ‘APPS’ Schemas
Introduced with 10.5 of the E-Business Suite, APPS, owns all of the applications code in the database and has access all data in the Oracle E-Business Suite. All end-user connections as well connect as APPS after being authenticated using the APPLSYSPUB schema. The APPS schema must have same password as APPLSYS and APPS_NE schemas.
Owns the foundation objects (AD_* and FND_* tables) of the E-Business Suite used to define users and menus etc…. The APPLSYS schema must have same password as APPS and APPS_NE.
New with 12.2, the APPS_NE schema is the Non-Editioned runtime ‘APPS’ user for the E-Business Suite. The APPS_NE schema must have same password as APPLSYS and APPS schemas.
APPS_MRC was created to support functionality for multiple reporting currencies (MRC). This schema has been obsolete since 11.5.10 and is no longer used. Its default was APPS_MRC, but country code suffixes were added (e.g. APPS_UK, APPS_JP). APPS_MRC is dropped by the upgrade to 11.5.10 and should not exist in R12 instances.