Showing posts with label DMZ. Show all posts
Showing posts with label DMZ. Show all posts

Sunday, October 12, 2025

Oracle E-Business Suite Hit by New High-Severity Vulnerability — CVE-2025-61884

 

Overview

Oracle has disclosed a new high-severity vulnerability (CVE-2025-61884) impacting Oracle E-Business Suite (EBS) versions 12.2.3 through 12.2.14, as outlined in My Oracle Support (MOS) Note 3107176.1.
This vulnerability follows closely on the heels of another critical issue — CVE-2025-61882, announced on October 4, 2025, which has already been observed in active exploitation campaigns.

Both vulnerabilities underscore the growing importance of timely patching, network hardening, and proactive monitoring for organizations running Oracle EBS on-premises or in the cloud.


⚠️ CVE-2025-61884 — What We Know So Far

  • Component Affected: Oracle Configurator (Runtime UI)

  • Affected Versions: EBS 12.2.3 to 12.2.14

  • Severity: High (CVSS v3.1 Base Score 7.5)

  • Access Vector: Network — unauthenticated HTTP access

  • MOS Reference: Doc ID 3107176.1

This vulnerability allows unauthenticated network access to the Oracle Configurator component, potentially exposing sensitive configuration data or enabling unauthorized access to system resources.
Oracle has released a security patch to address the issue, available through the Patch Availability Document in MOS.

In addition to applying the patch, Oracle recommends specific post-patch verification steps and tightened access controls around Configurator-related URLs.


🧩 CVE-2025-61882 — The Earlier Critical CVE Still Demands Attention

  • Component Affected: Oracle Concurrent Processing / BI Publisher Integration

  • Severity: Critical — Remote Code Execution (RCE)

  • MOS Reference: Doc ID 3106344.1

  • Status: Actively exploited in the wild

This earlier CVE exposed an RCE vulnerability that could be triggered via HTTP, allowing attackers to execute arbitrary code on EBS application servers.
It has been actively exploited by threat actors (including ransomware groups), leading Oracle and cybersecurity agencies to issue urgent patching advisories.

Organizations should ensure that:

  1. The CVE-2025-61882 patch has already been applied.

  2. Prerequisite CPU/PSU patches are installed before applying the emergency fix.

  3. Threat hunting and log analysis are performed for signs of compromise.


🔍 Key Differences Between CVE-2025-61882 and CVE-2025-61884

AspectCVE-2025-61882CVE-2025-61884
SeverityCritical (RCE)High (Unauthorized Access)
Attack VectorHTTP, Remote Code ExecutionHTTP, Configurator Runtime UI
Public ExploitsActively exploitedNo public exploit observed yet
MOS Note3106344.13107176.1
Additional MitigationIOC scanning, log monitoring, CPU baseline patchesRestrict access to Configurator UI, apply post-patch hardening

🛠️ Recommended Actions for EBS Administrators

  1. Immediately apply the patches for both CVEs as per Oracle’s MOS notes.

  2. Validate patch prerequisites (previous CPUs or required patch baselines).

  3. Restrict HTTP access to Configurator and BI Publisher components to trusted internal users only.

  4. Enable web application firewall (WAF) filtering for known exploit patterns.

  5. Perform threat hunting using HTTP access logs, BI Publisher logs, and concurrent manager trace files.

  6. Regularly monitor Oracle’s Security Alert portal and subscribe to their Critical Patch Update (CPU) notifications.


💡 Why This Matters

Many enterprises still rely on Oracle E-Business Suite for core ERP functions such as finance, supply chain, HR, and manufacturing.
Given its business-critical nature, EBS environments remain a prime target for cyberattacks, especially when exposed to the internet.

Applying the latest patches promptly and reviewing access controls can dramatically reduce risk exposure.
Organizations running EBS on Oracle Cloud Infrastructure (OCI) or private cloud should also ensure that network security lists and WAF rules are up to date.


🧠 Final Thoughts

The appearance of two major vulnerabilities in quick succession highlights the need for a proactive security posture in Oracle ERP environments.
Stay current with patches, monitor advisories, and collaborate closely with your DBA, Sysadmin, and InfoSec teams.

For more technical guidance, refer to:

  • CVE-2025-61882 – MOS Note 3106344.1

  • CVE-2025-61884 – MOS Note 3107176.1

Sunday, December 5, 2021

Oracle E-Business Suite 12.2.10 Configuration for DMZ

 This post is about on how we can configure DMZ for Oracle E-Business Suite 12.2.10. Now what is DMZ? From the first tone, it sounds to be something related to Defence where you have a line or border beyond there are restrictive access. In Oracle terminology, the DMZ, which stands for DeMilitarized Zone consists of the portions of a corporate network that are between the corporate intranet and the Internet. The DMZ can be a simple one segment LAN or it can be broken down into multiple regions . The main benefit of a properly-configured DMZ is better security. In the event of a security breach, only the area contained within the DMZ is exposed to potential damage, while the corporate intranet remains somewhat protected.




Source-Metalink


In my setup, the external DMZ node is accessible through LB and also the application file system is not shared between primary and the external node. I had to manually setup the SSH. Also, the setup was done on a cloned environment and thus update hierarchy setup was already in place. Now coming to the steps.

1. Create passwordless connection between internal and external node

ssh-keygen(in the primary node)
this will create two keys private and public keys
copy the public key content and paste it to external node application user's authorized_hosts file.

2. In the primary node:-

update hierarchy type--Already done as part of clone from PROD


3. Add the secondary node:

prerequistes:-

a. Patch admin server should be up and running
b. External node should be able to telnet external host(run & patch file system) admin port
example

telnet internal.example.com 7001--run file system
telnet internal.example.com 7002--patch file system

If the connection fails:
1. In the run file system config.xml, remove any deny and bounce the admin server. Follow the same for patch file system.
If the above doesn't work, then in the respective admin console, context filter in the run/patch file system should be set from the admin console and then stop it from console and start it from server


In the primary

a.run adpreclone in the run & patch file system and in database tier
b. copy the below directories to the external tier

Run File System (FS1)     :  /u01/install/APPS/fs1/EBSapps
Patch File System (FS2)   :  /u01/install/APPS/fs2/EBSapps
Non-Editioned File System(fs_ne)  :  /u01/install/APPS/fs_ne


In the external tier


perl adcfgclone.pl appsTier dualfs

                     Copyright (c) 2002, 2015 Oracle Corporation
                        Redwood Shores, California, USA

                        Oracle E-Business Suite Rapid Clone

                                 Version 12.2

                      adcfgclone Version 120.63.12020000.65

Enter the APPS password :

Enter the Weblogic AdminServer password :

Enter the password for DataSource ISGDatasource :

Do you want to add a node (yes/no) [no] : yes

Verifying: Run file system AdminServer is running
Verifying: Patch file system AdminServer is running
Running: Context clone...

Once the run and patch file system is configured, edit the context file to put the LB details and port etc

CONTEXT VARIABLES TO BE CHANGED FOR THE ABOVE LBR CONFIGURATION

<webentryurlprotocol oa_var="s_webentryurlprotocol">https</webentryurlprotocol>

<webentryhost oa_var="s_webentryhost">partners</webentryhost>

<webentrydomain oa_var="s_webentrydomain">example.com</webentrydomain>

<activewebport oa_var="s_active_webport">443</activewebport>

<login_page oa_var="s_login_page">https://partners.example.com:443/OA_HTML/AppsLogin</login_page>

<EndUserMonitoringURL oa_var="s_endUserMonitoringURL">https://partners.example.com:443/oracle_smp_chronos/oracle_smp_chronos_sdk.gif</EndUserMonitoringURL>

<externURL oa_var="s_external_url">https://partners.example.com:443/OA_HTML/AppsLogin</externURL>

4. run autoconfig in the external tier


run file system

$ . ./u01/install/APPS/EBSapps.env run

$ $INST_TOP/admin/scripts/adautocfg.sh


patch file system

. ./u01/install/APPS/EBSapps.env patch

$ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload contextfile=context.xml logfile=/tmp/patchctxupload.log


5. Sync Up the Context File and Update Configuration on All Nodes

 In the primary node

$ . ./u01/install/APPS/EBSapps.env run

$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

As part of node addition, all the nodes have the information of the managed servers of the other nodes. if these managed servers are not required, we need to delete the manage servers for the other nodes

perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> -configoption=removeMS -oacore=testserver1.example.com:7201 -forms=testserver2.example.com:7601

in the patch file system, repeat the above steps

In the external node

run file system

$ . ./u01/install/APPS/EBSapps.env run

$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

As part of node addition, all the nodes have the information of the managed servers of the other nodes. if these managed servers are not required, we need to delete the manage servers for the other nodes

perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> -configoption=removeMS -oacore=testserver1.example.com:7201 -forms=testserver2.example.com:7601

or 

from apps.conf and mod_ohs.conf file, the managed servers can be manually removed.

in the patch file system, repeat the above steps

6. Run autoconfig

On all the application nodes

run file system

run autoconfig

In the external nodes

In the primary node

Shut down the Admin Server and the Node Manager on the Patch Edition File System of the primary node as follows:

$ <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop

$ <ADMIN_SCRIPTS_HOME>/adnodemgrctl.sh stop

In the DB node

<RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

lsnrctl reload <ORACLE_SID>


7. Login to the internal application node


Profile option


"Node trust level" should be set to external for external server

update list of responsibilities to be visible in external node login page

"Responsibility trust level"  should be set to external for respective responsibilities


8. run autoconfig in internal and external node

    Bounce the services and check