Hack the box — Tabby writeup
Hello. This is writeup about “Tabby” machine. It’s IP is 10.10.10.194. First of all, let’s do some simple recon. Start nmap with service and version detection:
So, we have ports 80 and 8080 (usually I ignore port 22 on HTB)
Tomcat and some site. Nice. Exploring the site on port 80 I’ve found this link:
Do you see it? “file” argument seems suspicious for me.
Of course, it’s simple LFI without protection. Let’s read these PHP files and check, if there any useful info, like comments, backup files links, etc. (spoiler - nothing interesting):
As there is nothing more interesting on 80 — let’s get back to port 8080 and it’s tomcat. I know nothing about it, so first of all I need some information. Is it exploitable? If so — how?
Alright, this article says, that I can upload war file with reverse shell, if I have credentials. Well, I already have LFI and this “it works!” page says me, where I can find passwords. Huh.
We need creds, which are stored in “tomcat-users.xml” file. I’ve tried a lot of paths, including:
/etc/tomcat9/
/usr/share/tomcat9/
/var/lib/tomcat9/
/etc/default/tomcat9/
But no results. Well, then I installed tomcat locally on arch (it’s Ubuntu on the machine, but who cares, I thought)
Next my step was just googling. I found this list:
/etc/cron.daily/tomcat9
/etc/rsyslog.d/tomcat9.conf
/etc/tomcat9/policy.d/01system.policy
/etc/tomcat9/policy.d/02debian.policy
/etc/tomcat9/policy.d/03catalina.policy
/etc/tomcat9/policy.d/04webapps.policy
/etc/tomcat9/policy.d/50local.policy
/lib/systemd/system/tomcat9.service
/usr/lib/sysusers.d/tomcat9.conf
/usr/lib/tmpfiles.d/tomcat9.conf
/usr/libexec/tomcat9/tomcat-start.sh
/usr/libexec/tomcat9/tomcat-update-policy.sh
/usr/share/doc/tomcat9/README.Debian
/usr/share/doc/tomcat9/changelog.Debian.gz
/usr/share/doc/tomcat9/copyright
/usr/share/tomcat9-root/default_root/META-INF/context.xml
/usr/share/tomcat9-root/default_root/index.html
/usr/share/tomcat9/default.template
/usr/share/tomcat9/etc/catalina.properties
/usr/share/tomcat9/etc/context.xml
/usr/share/tomcat9/etc/jaspic-providers.xml
/usr/share/tomcat9/etc/logging.properties
/usr/share/tomcat9/etc/server.xml
/usr/share/tomcat9/etc/tomcat-users.xml
/usr/share/tomcat9/etc/web.xml
/usr/share/tomcat9/logrotate.template
/var/lib/tomcat9/conf
/var/lib/tomcat9/logs
/var/lib/tomcat9/work
Some bruteforcing— boom! Out password is $3cureP4s5w0rd123!
Huh, I have access to http://10.10.10.194:8080/host-manager/html, but not http://10.10.10.194:8080/manager/html. Interesting.
After some googling I’ve found that I can upload war file via CLI.
Then just go to http://10.10.10.194:8080/shell/ and observe that you have shell!
Usually I would upgrade shell to full TTY, but somehow it was not possible so I used this dumb as a box of rocks shell even without prompt :\
Remember that /etc/passwd content? There was user named ash
. Let's find all it's files
Oh, let’s download this archive. It’s password protected. So I used john (which is much simpler for zip bruteforcing than hashcat). Use zip2john, cut it and pipe to file hashes.txt.
And it’s ash
password. Nice job, user own3d!
You know, containers can be used for privilege escalation. For example, check out this:
And if you noticed — there is lxd on the server, which is kinda container too. To own root — just follow this article:
Simple root, simple user, medium enumeration. Thanks.