While traveling through Sweden, I had the opportunity to hang out with a friend of mine, David Jacoby from TrueSec. As we were walking around he told me about a new technique he is working on to use a remote file include exploit in a scenario where the system doesn’t allow outbound access from the webserver. If you actually care about security you’re hopefully doing egress filtering on your firewall which has the great side benefit of making remote file includes fail. Additionally, hopefully you’re using a modern version of PHP which by default disallows remote files to be included. Well, it turns out David found that there’s a way around that.
Barring any other file upload, it’s usually impossible to use a remote file include attack in that situation, but an attacker can inject information into Apache access logs either by URL strings or User Agents, or they can include PHP information in the mail logs by sending email from contact forms, etc… The reason this works, is that the web user typically has the rights to read from those files and those files are in somewhat predictable locations. So instead of including a file from the Internet, you include it from the local file system itself. PHP will parse the file, and run the attacker’s code. Boom.
I typically tell people to make sure the entire file system is not writeable by the web user, but unfortunately those types of files are pretty important to be able to write to for the site’s basic functionality on most systems. However, there is still an option there. You can use commands like chattr (change attribute) under *NIX platforms to make the files writable but not readable by the web user, which would solve that problem, or making it not readable by the web user using chmod - either way. Pretty cool research from David!