VulnVPN (Vulnerable VPN) Solutions New edition

some possible ways to hack and gain root on VulnVPN. In these examples VulnVPN is based at 192.168.0.10 and the attacking box/client is 192.168.0.11.

Attacking the VPN Server

The first few steps involve finding the listening services. As it’s a VPN image, I’ve performed a single scan on UDP port 500 from which the result can be seen in the following screenshot.

To keep this thorough I’ve also performed a full TCP port scan although, as expected,  only the open port is 81. This is used to host a help page and is out of scope for testing.

Using ike-scan it’s possible to determine that the host is running an IKE based VPN in aggressive mode, from which we can basically perform an offline attack on the hash to return the unencrypted PSK. More information on this attack can be found here.

It’s then possible to use a program such as psk-crack to perform dictionary or brute-force attacks on the hash. From the following screenshot it is evident to see that the clear text PSK value is 123456.

If you’re using the client config files supplied, you’ll need to enter the PSK into the ipsec.secrets file (as follows).

Before attempting to connect to the host you’ll need to perform a service restart i.e. /etc/init.d/ipsec restart.

It’s then possible to initiate the VPN connection using the command as shown in the following screenshot.

If the connection has been successful you’ll see ‘IPsec SA established’ message as highlighted above. If  things don’t go as planned, the following may help:

• 022 “vpn”: We cannot identify ourselves with either end of this connection – This means that your IP address is not the same as specified in the ipsec.conf file. Either change your address, or change the value in the file (the default for the client is set as 192.168.0.11).
• 021 no connection named “xxxx” –  The name of the connection is not as specified in ipsec.conf, i.e. vpn (the default for this challenge).
• STATE_AGGR_I1: INVALID_HASH_INFORMATION – This error indicates that the hash information in ipsec.secrets is incorrect. Ensure you enter the PSK as previously obtained.

After any changes make sure you restart the ipsec services.

The next step involves creating/initiating a PPP connection to the ‘inside’ interface. If you’ve downloaded the client files you can use the ‘start-vpn.sh’ script to do this. If you wish to perform this manually, the command is as follows:  echo “c vpn” > /var/run/xl2tpd/l2tp-control 

To verify this has worked as expected you can use the command ‘ip link‘ from which you should see a new adaptor, most probably named ppp0. If this hasn’t been created, ensure you have a successful phase 1 connection (see above) and then try running the script again. If you have problems you should refer to both client logs and the help page at http://192.168.0.10:81.

From the output of ifconfig it’s possible to see that the adaptor has the new address of 10.99.99.2, with the server based at 10.99.99.1.

A basic ping command shows that the connection between the two hosts is working as expected.

Performing a port scan on the internal address identifies that there are now many more services to target in further attacks 

Enumeration & Attacking the Host #1

It’s possible to see that a SMTP server is available on port 25. Using telnet to connect to this confirms that Postfix is running, which also allows VRFY commands to be run (essentially this allows us to locate valid users on the system). The following screenshot shows the difference between a true/false response.

By using the program ‘smtp-user-enum’ from pentestmonkey.net we can use a username list and brute force this service to return valid users very quickly.

From the following output it’s possible to see all located users. A number of these are default accounts, but one, ‘bob’, looks to be interesting.

Now we have a valid username we can potentially use this in a brute force attack. From the earlier port scan it is possible to see that the SSH service is available.

Using hydra we can see if it’s possible to find the password for the account ‘bob’… It is!

Now we’re logged into the server as bob, we’ve opened up a whole new attack vector, privilege escalation…

A quick view of /etc/passwd reveals another possibly interesting account that we should soon target…

Attacking the Host #2

From the earlier port scan it’s possible to see that a web server is listening on TCP port 80. Navigating to this reveals a default Apache page.

It’s always worth using a tool such as Dirbuster to help uncover any interesting directories/pages.

Navigating to /wordpress reveals a ‘resume submission’ page, with upload functionality. There is a known issue with the plugin ‘WordPress Resume Submissions & Job Postings v2.5.1’ – further details can be found here at exploit-db.

It’s possible to create a simple php webshell and upload it to this page, example follows:

<?php

passthru($_GET[1]);

?>

Once uploaded, a link isn’t given to the file, but it’s possible to navigate through known WordPress directory structure to /wordpress/wp-content/uploads, from where, helpfully, directory listing is enabled.

It’s then possible to interact with the webshell to launch OS commands.

From here you may want to use msfpayload to create an interactive shell to make the next few stages easier.

Attacking the Host #3

A little while back I created the Vulnix challenge. Part of this involved using NFS and SSH to gain an unprivileged shell into the remote host. This technique is also applicable here. More details can be found under Entry Point #3 on the Vulnix write-up here.

Local Privilege Escalation #1

At this point we have to find ‘interesting’ files or vulnerabilities. There are a number of commands/tools/methods of doing this, but I’m going to jump straight to the point. Running the following command should bring some interesting results:

find / -perm -2 -type f 2>/dev/null > results.txt

…and the REALLY interesting file is…

From looking at the permissions it’s possible to see that the file is owned by root, but others have read/write access. Also, due to the location (/etc/cron.daily), it’s probably a scheduled task that’s running on a regular basis.

Ignoring the fact that the mysql root user password is stored in the clear, we could amend the contents of the file and hope that the cron job is run as root in the near future. This job is actually run after a system reboot and therefore you’ll need to hard reset the system for the affects to be seen. In the below example (I’ve already copied a shell into bob’s home directory) we’re adding a few lines to the cron job which should in essence give us access to a root shell. It’s worth noting that sh was used instead of bash as the suid bit was ignored on the bash shell, and hence didn’t run with the owners permissions, in this case root, privileges.

Hopefully, after a reboot, you’ll see the following results:

We’ve got root!

Local Privilege Escalation #2

From the nmap scan it’s clear to see that NFS (TCP 2049) is listening. Using the showmount command we can see if anything’s accessible.

Anyone has permission to mount this share from any host, so here we go…

Viewing the contents of this directory shows that the user 1000, in this case bob (assumed due to the /home directory name), has access.

NFS root squashing is enabled in this instance so root will essentially have nobody permissions. Therefore, on our local attacking system, we can create a new user and assign the uid of 1000, switch to this user and then upload files to the directory, as per the following screenshots.

As you can see, we’ve created the ‘upload’ directory and now we’ll assign very lax permissions to this. Essentially this will allow anyone to upload files to this directory. It’s also worth noting that I’ve already copied /bin/bash (32-bit version) to the upload directory (read on).

As you may remember, the output of /etc/passwd revealed another user named jane with the uid of 1001. A quick trick here is to create another user on your attacking system with the uid of 1001 (in this case for ease of reference, also called jane). We can then su to jane (on your local system), copy bash (in the upload directory) to bash-jane and then finally set the permissions of 4777 to the bash shell. Essentially this set’s the suid bit on the shell and allows anyone read/wite/execute access. When executed on VulnVPN  this will run as ‘jane’.

Back within bob’s ssh session we can then execute the ‘bash-jane’ shell as follows:

Now that we have the euid of jane, what can we do? Perhaps see if jane is authorised to sudo?

Not exactly the result we wanted. There are a  few ways around this, but the easiest is to compile and run this simple code:

#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(void){
setreuid(1001,-1);
char *args[] = {“/bin/bash”,0};
execve(args[0],args,0);
return 0;
}

It’s worth noting that in this case the uid of jane is 1001, hence this is reflected in the code.

Now can we compile this on VulnVPN?

It wouldn’t be that easy would it 

You’ll have to compile this on a 32-bit host and then upload this to the ‘upload’ directory via NFS, and then run, as follows:

As you can see, after running the uid program we now have the uid of 1001 and can successfully run sudo -l, as below:

We can see that jane can run vim as root – vim is very easy to breakout of!

So, as jane we’ll run sudo vim, and then…

We’ve got root!

Quick and easy ‘root’ in #1 & #2

Looking at the nmap results it’s possible to see that TCP port 10000 is open. This is commonly associated with webmin. Navigating to the internal address reveals the following:

We’ll assume that we’ve already got bobs credentials through brute force methods (described earlier), can we log into webmin with these? Yes we can!

Looking at the home screen it’s possible to see that the version stands at 1.590, and bob has access to the ‘File Manager’ module. Performing a quick web search reveals several vulnerabilities with this, and prior versions (you may need to reference several resources as the info for both of the following Metasploit modules state version 1.580, but in fact also work on 1.590).

• http://www.metasploit.com/modules/exploit/unix/webapp/webmin_show_cgi_exec
• http://www.metasploit.com/modules/auxiliary/admin/webmin/edit_html_fileaccess

Firstly, using the auxiliary module, we can complete the relevant fields and attempt to get a copy of the shadow file. Executing this proves successful. We can continue to copy any file we wish.

The second of the metasploit modules allows us to gain a remote shell. Again, complete the relevant fields and select an appropriate payload. In this case cmd/unix/bind_perl is chosen, executed and we have root!

I hope you enjoyed the challenges  … Hopefully there’ll be more to come soon. Thankyou plz comment