Cenzic 232 Patent
Paid Advertising
web application security lab

File upload leading to script execution

Last week Choi Min-sung found a file upload exploit in Zeroboard. This was a particularly interesting vulnerability to me because it shows how two completely unrelated non issues can together create an issue. First of all Zeroboard allows you to upload a .htaccess file, which controlls the state of the directory in which it resides. Depending on what level of access controll that the system allows this may or may not be an issue.

Normally uploading a .php script is not allowed, but you can upload a .txt file or a .abc file or whatever. The .htaccess can direct the webserver to treat those file extensions as a valid PHP application extension. When the user uploads the .txt file or whatever it is treated as a valid file, and when the user goes to that file it is executed as the webserver user. Pretty normal script injection at that point, but fairly unique circumstances that allowed it to happen.

This reminds me of how Apache.org was successfully hacked a few years ago. Basically the FTP root was the same as the webserver root directory. Although they couldn’t upload their script injection directly through the web interface, they could through the FTP interface because it was world writeable. They simply uploaded the compromising PHP file and then ran it through the web interface and poof! Instant webserver access as the web user.

These out of band attacks are hard to find but they really do show how two unrelated and very hard to test for circumstances can cause major vulnerabilities. I’d love to see an automated scanner that claims it can find vulnerabilities that would locate that one. Humans are just better at finding obscure exploits, like script and command injection.

2 Responses to “File upload leading to script execution”

  1. Jon Lucenius Says:

    Very nice. I was working on an attack that bypassed the filter in place that removed ALL “http://” possible encodings/combinations.

    I am commenting here because the solution was to simply use , which I was kinda surprised to see the browser not really care about the delivery protocol.

    There must be many more cross-channel/protocol attacks out there waiting to be discovered.

    After some investigating, it appears that the only other protocol that allows file transfer based on a single URL is nntp:, is that correct? (have not actually tried that one). There are a lot, gopher, wais, prospero, telnet, and other ones, but HTTP, FTP, and NNTP seem to actually retrieve something and be understood in a browser.

    HTH and HAND,
    Jon (head.hacker @ bigbank :-)

  2. RSnake Says:

    Thanks, Jon. But don’t forget about the new SCP exploit that just came out. http://ha.ckers.org/blog/20060612/winscp-uri-handler-command-switch-parsing/ As you add things onto the browser (like other protocols) you are allowing all sorts of nasty things to happen. Also, don’t forget that protocol resolution is a big issue (depending on what you are attempting to stop). http:// works the same as htt:// etc…