Cookie Consent by PrivacyPolicies.com
Posts Hack the Box - Tabby
Post

Hack the Box - Tabby

Introduction

Tabby starts off with careful recon enumeration leveraging local file inclusion to harvest credentials then using those credentials to establish a foothold through Apache manager script usage. User escalation then came through a backup zip file encrypted with the user's system password, gathered by using zip2john. Lastly root privesc was achieved by leveraging LXD system container manager as the regular user was part of the lxd control group. Overall this was a fun box to get back into the swing of things after a couple months of hiatus and I learned a few tips and tricks along the way.

Initial Recon

Let's kick it off with an NMAP scan.

kali@kali:~/Desktop/HTB$ nmap -sV -sC -p- 10.10.10.194
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-06 15:35 EST                
Nmap scan report for 10.10.10.194                                              
Host is up (0.036s latency).                                                        
Not shown: 65531 closed ports                                                       
PORT     STATE SERVICE  VERSION                                                     
22/tcp   open  ssh      OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)              
| ssh-hostkey:                                                                           
|   3072 45:3c:34:14:35:56:23:95:d6:83:4e:26:de:c6:5b:d9 (RSA)                           
|   256 89:79:3a:9c:88:b0:5c:ce:4b:79:b1:02:23:4b:44:a6 (ECDSA)                              
|_  256 1e:e7:b9:55:dd:25:8f:72:56:e8:8e:65:d5:19:b0:8d (ED25519)                            
80/tcp   open  http     Apache httpd 2.4.41 ((Ubuntu))                                       
|_http-server-header: Apache/2.4.41 (Ubuntu)                                                    
|_http-title: Mega Hosting                                                                       
8080/tcp open  http     Apache Tomcat                                                              
|_http-open-proxy: Proxy might be redirecting requests                                             
|_http-title: Apache Tomcat                                                                           
8443/tcp open  ssl/http LXD container manager REST API                                                   
|_http-title: Site doesnt have a title (application/json).                                              
| ssl-cert: Subject: commonName=root@ghost/organizationName=linuxcontainers.org                             
| Subject Alternative Name: DNS:ghost, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1                        
| Not valid before: 2020-06-16T13:34:28                                                                             
|_Not valid after:  2030-06-14T13:34:28                                                                                  
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel                      

A couple Apache instances, SSH, and an interesting REST API port for LXD. Let's start off with taking a look at the first Apache instance.

Nothing too exciting on the page until we hit one of the tab redirects...

Alright time to add the domain to our hosts file and retry.

kali@kali:~/Desktop/HTB$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       kali
10.10.10.194    megahosting.htb

Well that's sure an interesting message. It also looks like it pulling a local file using file=. Seems like a prime LFI candidate. Let's see if we can pop out some information.

Excellent, good progress so far. We learn that there is a user named ash. Unfortunately without a hint as to where to look there isn't much more progress that can be done here. Let's table the LFI for use later and move on to the other Apache instance under port 8080.

Oh ho ho the pieces are starting to come together! By clicking on manager-webapp and host-manager webapp were are presented with Basic auth. With the additional information provided we also know the root structure is under /usr/share/tomcat9 and are also given the location of the credential file at /etc/tomcat9/tomcat-users.xml. We should be able to leverage our previous LFI capability to access the credentials! One thing to note here is the final location is not /etc/tomcat9/tomcat-users.xml as that location is relative to the base of the instance, which is under /usr/share/tomcat9 giving us an ultimate final location of /usr/share/tomcat9/etc/tomcat9/tomcat-users.xml. Sure enough we see the results come through our BURP listener when triggered.

Other than the obvious user creds the interesting note is just above in the comments - specifically talking about the manager-gui role, which unfortunately our credentials don't possess. This may limit us, but one step at a time, let's log on and see what we can do.

Sure enough as soon as we start going past the main page we start getting hit with the denial stick. We do have manager-script entitlements however, so we should in theory be able to run all these admin commands using curl calls. Let's take a quick look at the documentation and give that a shot.

Perfect now if we keep reading through the documentation we see there is a possibility to upload our own WAR applications. We can create a malicious file using msvenom, upload it using our manager-script entitlements, and then all things running smoothly be able to trigger it at will. Only one way to find out if it works.

Now let's see if it is actually there.

All that is left is to trigger it with a local listener on 4444.

User exploitation

Now unfortunately we only have a foothold as the tomcat user and as such do not have access to the user flag (which we now confirm is ash by checking /home/ash). After some poking around we managed to find a backup zip file owned by ash.

Popping that over to our host we see it is password protected. Seems as good an avenue as any to crack.

We prep the hash file using zip2john and run that through our trusty rockyou list. Sure enough within a few seconds we find the password - admin@it.

At this point the assumption was that ash used their own password to encrypt the zip. Let us see if we can pivot over using the new creds.

Sure enough, user down!

Root exploitation

Time to bring all the remaining pieces together and finish this machine off. If we take a look at the original recon we remember there was an LXD Rest API running. You'll notice above that our user ash is also part of the lxd group. A quick online search and we find a privesc method using LXD and seems like a probable path. The theory behind this approach is essentially that since we have root access to containers created we can mount the host file system and leverage the container's root access to access any file we want.

Following along with the instructions we get ourselves an Alpine image. We quickly pop that over to our local Apache instance and get it over to the host as ash. I had to go through an lxd init to get the environment on the host ready, however once completed everything worked like a charm.

All that is left is to navigate to our mounted root location (/mnt/root) and proceed to the usual /root/root.txt location.

And with that our journey with tabby comes to an end. After taking a few months off for various things ongoing this was a nice box to shake the rust off and get back into it.

Thanks folks, until next time!

This post is licensed under CC BY 4.0 by the author.