Paid Advertising
web application security lab

Remote File Include Voodoo

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!

20 Responses to “Remote File Include Voodoo”

  1. Ivan Ristić Says:

    In a typical Apache deployment the log files are opened and written to as root, which means that the web user–which is a non-root account used to process requests–needs neither read nor write. As you comment, allowing read access allows for abuse. Allowing write access is even more dangerous, enabling privilege escalation from the web user to root. The logs directory should be owned by root and have 0700 permissions configured.

  2. James Le Cuirot Says:

    I decided to see how nginx would handle this. It seems that the logs are owned by the user running the master process (i.e. the user that starts it) and not by the user that actually deals with the requests. In my case, this is root so I can save myself worrying about the file permissions and just set root-only permissions on the /var/log/nginx directory itself. I guess this is a good thing?

  3. Tyler K Says:

    Log files should absolutely NOT be readable by the web server user, and if they are, the server config is broken and probably has bigger problems.

  4. anantasec Says:

    I’m sorry RSnake but this technique is not new. It’s a least a few years old (that’s when I first heard about it, could be older).

    One article is available here:

  5. wheelq Says:

    it is not so ‘new technique’.
    I admit, going in through the /proc is a new thing for me and I really like this one :)

    But breaking in through sending mail to apache@ it known for a little while.

    From my own experience I can add one, sometimes you can set a variable in the session, for example a language for a website. Instead of setting a lang to PL you can set it to and then include a session file ( /tmp/sess_[id]). Although I thing I might have seen this one too, on another website some time ago.

  6. Raz0r Says:

    Very, very, very old trick…

  7. laZee Says:

    I don’t get why this should work. If I would include an access log in PHP, I would get uncountable parse errors.

  8. nex Says:

    this isn’t really a new discovery.
    it was already exposed long time ago by team calling this technique lfi2rce, since there’s not really much about “remote”.

  9. Anonymous Says:

    As it usually happens, people discover/learn same things fragmentically instead of at the same time - on our testing/securing this has been part of since early 2000s. Maybe shows partially how it might benefit community as a whole if telling wide open about this kind of things as soon as possible, although that does not remove possibility that not all bother to or can learn from history.

  10. David Jacoby Says:

    Hi laZee!

    Well, the thing is that the function include() does not validate the file that you are including, it just ignores everything that does not start with “

  11. blabla Says:

    no because PHP interprets what’s between
    so the rest is ignored, there wont be any parsing errors.


  12. Vortex Says:

    Assuming you have a method (via PHP) to display the web logs and negate to sanitize the data, then yes, I could see this being an interesting hook in.

    One has to ask however, what self respecting sysop would allow these logs to be looked at in this way however ;) — Perhaps this is a function of control panels? (Personally I never use them)

  13. Gabriel Pato Says:

    It works. Take a look here, . Its a good article with PoCs. And, lazee, parse errors will only happens if the rest of the log stays inside a tag. The rest of the text in log will not be interpreted.

  14. Gabriel Pato Says:

    (LOL!) Sorry, guys, for the wrong url in my comment. This is the correct one: (haha, i was sending the suhosin patch’s url to a friend while I was starting to write the comment)

  15. dt Says:

    From PHP, you can restrict web user access to other files using open_basedir. And of cource, place logs in other part.

    Emails are sometimes stored on user account where web user have access, but if you send an email with a php code, is hard to guess the exact path where is delivered. Or not, on mail servers that still use mailbox.

  16. tomten Says:

    Well, if you look at a homepage, it can contain html, and in the html a . If we run this in php, all it will run is the phpcode.

    So if you have an access log that contains a phpline, you will probably get a lots of errors, but the code will execute.

  17. RSnake Says:

    @anantasec and others - sorry, I hadn’t seen that before, my apologies for saying it was new (it was the first time I had heard of it).

  18. David Jacoby Says:

    Hi laZee!

    My answer was incomplete due to my html-tags, as blabla said, php simply ignores all content before and after the php code.

  19. Sam Aldis Says:

    Not really a new trick, I was using this a long time ago,
    even included it in the first pre-publish version of my
    web security book (although that was one of the things
    that was lost when the police searched then cleaned my
    computer). Nice to see it is still in use though.
    Sam Aldis

  20. moo Says:

    This technique is called log poisoning. I am surprised you had never heard of it until your friend told you about it. This technique is well known.