Oracle Database 12c Release 1 - Unquoted Service Path
# Exploit Title: Oracle Database 12c Release 1 - Unquoted Service Path
# Date: 2024-07-31
# Exploit Author: Milad Karimi (Ex3ptionaL)
# Contact: miladgrayhat@gmail.com
# Zone-H: www.zone-h.org/archive/notifier=Ex3ptionaL
# MiRROR-H: https://mirror-h.org/search/hacker/49626/
# Vendor Homepage: https://www.oracle.com/
# Software Link: https://www.oracle.com/
# Version: 12c Release 1
# Tested on: Windows 10 Pro x64
C:\>sc qc "OracleDBConsoleorcl"
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: OracleDBConsoleorcl
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME :
C:\Oracle\product\11.2.0\dbhome_1\bin\nmesrvc.exe
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : OracleDBConsoleorcl
DEPENDENCIES :
SERVICE_START_NAME : LocalSystem
C:\>systeminfo
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19045 N/A Build 19045
OS Manufacturer: Microsoft Corporation Understanding the "Unquoted Service Path" Issue in Oracle Database 12c R1 on Windows
The unquoted service path vulnerability is a common Windows privilege-escalation weakness that can affect many applications, including Oracle Database installations. In Oracle Database 12c Release 1 deployments on Windows, service BinaryPathName entries that contain spaces but are not wrapped in quotes create an attack surface: a local attacker with write access to intermediate directories may be able to place an executable that Windows will execute with the service's higher privileges.
Why this matters for Oracle 12c R1
Oracle database installations typically create several Windows services (monitoring agents, consoles, listeners). When a service BinaryPathName contains spaces and is unquoted, the Windows service control manager resolves the first token that it can execute; if an attacker can place an executable in a higher-priority token location, they may gain elevated execution under the service account (often SYSTEM or a privileged service account).
Typical characteristics
- Service BinaryPathName contains directory names with spaces (e.g., C:\Program Files or C:\Oracle\product 11.2.0).
- The path in the service configuration is not quoted.
- The service runs with elevated privileges (LocalSystem / Administrators / service-specific high-privilege account).
- Improper NTFS permissions on intermediate directories allow untrusted users to write files.
Example: identifying an unquoted path
Querying service configuration with standard Windows tools reveals BinaryPathName values. For example, using sc qc shows the path information:
sc qc "OracleDBConsoleorcl"
Sample (sanitized) output:
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: OracleDBConsoleorcl
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
BINARY_PATH_NAME : C:\Oracle\product\11.2.0\dbhome_1\bin\nmesrvc.exe
DISPLAY_NAME : OracleDBConsoleorcl
SERVICE_START_NAME : LocalSystem
Note the BINARY_PATH_NAME is not wrapped in quotes and contains spaces in ancestor folder names such as "product 11.2.0" (or in other installations, "Program Files"). This pattern indicates a potential unquoted service path.
Impact and risk assessment
- Local privilege escalation: Primary risk is a local user obtaining elevated privileges (SYSTEM or other service account).
- Post-compromise persistence: If an attacker already has limited local access, unquoted service paths are an easy lateral privilege escalation method.
- Not a remote exploit by itself: This issue generally requires local write access to file system locations or other local footholds.
- Depends on NTFS ACLs: If intermediate directories are locked down (no write permission for low-privileged users), the risk is mitigated.
Detection: searching for unquoted service paths
You should routinely scan Windows hosts for unquoted service paths. The following lightweight PowerShell snippet is a defensive detection example that enumerates services and flags unquoted BinaryPathName entries that contain spaces.
Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Services |
ForEach-Object {
$svc = Get-ItemProperty $_.PSPath
if ($svc.ImagePath -and $svc.ImagePath -match '\s' -and $svc.ImagePath -notmatch '^".*"$') {
[PSCustomObject]@{
Service = $_.PSChildName
ImagePath = $svc.ImagePath
StartType = $svc.Start
ObjectPath = $_.PSPath
}
}
} | Format-Table -AutoSize
Explanation: this script iterates service registry keys, reads the ImagePath (BinaryPathName), and reports entries that contain whitespace and are not fully quoted. It is intended for discovery and triage only.
Sample sanitized output might show:
Service ImagePath
------- ---------
OracleDBConsoleorcl C:\Oracle\product\11.2.0\dbhome_1\bin\nmesrvc.exe
Remediation and hardening
Fixing unquoted service paths is a defensive operation. Prioritize high-value, high-privilege services and those running as LocalSystem.
- Quote the BinaryPathName — ensure the service binary path is fully enclosed in double quotes. This is the canonical fix and prevents Windows from parsing the path into separate tokens.
- Use least-privilege accounts — avoid running services as LocalSystem or highly privileged accounts unless absolutely necessary. Use dedicated service accounts with minimal privileges.
- Lock down NTFS permissions — ensure intermediate directories in the service path are not writable by unprivileged users (e.g., remove write permissions for Users and Authenticated Users).
- Install software to non-space paths — where feasible, avoid installing critical server binaries into paths with spaces (or ensure installers quote service paths correctly).
- Apply vendor patches and follow hardening guides — check Oracle advisories and Windows updates for related fixes or guidance.
Safe configuration update (administrative action)
To correct a service path, administrators can set the BinaryPathName to a quoted value. Example defensive command (administrator context):
sc config "OracleDBConsoleorcl" binPath= "\"C:\Oracle\product\11.2.0\dbhome_1\bin\nmesrvc.exe\""
Explanation: This sc.exe command updates the service configuration so the service's executable path is wrapped in quotes. Running it requires administrative privileges. Always validate the exact path, test in maintenance windows, and ensure no side effects before applying changes in production.
Alternative mitigations
- Use Group Policy or endpoint controls (AppLocker, SmartScreen, EDR) to restrict execution of unapproved binaries in common directories.
- Monitor and alert on service configuration changes and suspicious file creation in service-related folders.
- Automate scanning for unquoted service paths across endpoints and include remediation tickets in patch cycles.
Operational guidance and best practices
- Run periodic audits for unquoted service paths and insecure permissions as part of baseline security posture checks.
- Prioritize services running as SYSTEM and database-related services for remediation.
- Document changes, ensure backups of service configurations, and use change control when modifying services in production.
- Combine patching (OS and Oracle), hardening (least privilege), and detection (host-based scanning) for defense-in-depth.
Conclusion — practical takeaways
Unquoted service paths remain a simple but effective local attack vector. For Oracle Database 12c R1 on Windows, verify service BinaryPathName entries, ensure they are quoted, and harden file system permissions. Regular scanning, least-privilege service accounts, and vendor hardening guidance reduce the attack surface and limit local privilege escalation risks.
| Activity | Recommendation |
|---|---|
| Detection | Scan registry service entries for unquoted ImagePath values (PowerShell, SIEM integration) |
| Immediate Fix | Quote service BinaryPathName and verify NTFS ACLs on parent folders |
| Long-term | Apply vendor hardening, use least-privilege accounts, monitor service changes |