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!

credits-kaotic!

Posted in: LFI