I recently came across a forum post where a website admin's site was hacked and he found this in his php error logs:
[error] [client 18.104.22.168] PHP Warning: Unexpected character in input: '\x01' (ASCII=1) state=0 in /var/www/html/photo/123.gif : eval()'d code on line 1, referer: site.com
This reminded me of the technique I illustrated in this blog post where php code could be smuggled into real images: http://hackers2devnull.blogspot.co.uk/2013/05/how-to-shell-server-via-image-upload.html.
That method, however, is dependent on the file extension uploaded actually being interpreted as PHP which relies on insecure upload code. The /photo/ folder was also being blocked from accessing directly in the httpd.conf file:
Deny from All
So how was it done? Here is one possible explanation- RCE via LFI/Image upload (which assumes there is a local file inclusion vulnerability somewhere else on the website):
The photo folder isn't accessible to site users, however this restriction doesn't apply to local file includes. So, assuming we can upload a 'trojanised' image to the server, we can use a local file inclusion vulnerability elsewhere on the site to include it and run arbitrary php code.
This process has been illustrated below: the following code was inserted into a simple image (see earlier link on how to do it) which passes parameters to shell_exec.
<-- Inserted into comments meta data field.
In the document root we have an insecure (too say the least) php file that is vulnerable to local file inclusion:
The result, by including the path to the image, is RCE:
Any errors in the code that was inserted into the image would be reported as PHP errors in the image itself as opposed to the include file which might explain the weird error reported by the website admin.
Caveat, this is obviously dependent on the severity of the LFI vulnerability in being to include a non-php extension file.
(If you find this useful, why not checkout a advert below to support the blog? :O ) ~r0ng