I've got an application vulnerable to directory traversal (I know this because it's part of the wording of the question). The application has two directories, public and private, and two php files:

  • A.php?folder=[public|private] list the content of both directories.
  • B.php?folder=public&file=test.txt&action=[view|download] view or download the specified file.

I need to view a file called users.txt which is allocated in the private directory. B.phpseems to have a restriction that only allows the action on the public directory, so if I type B.php?folder=private&file=users.txt&action=view, actually it's trying to read \public\private\admin\users.txt (notice the backslash, it's a Windows system if that matters).

My next step was to jump back in the directory tree, but neither .. nor %2E%2E are allowed by the application. It returns a message saying that the dot char can't be used for the folder or the file.

There is no cookies nor POST data.

So, how could I "break the jail" of the public directory in B.php? Any ideas?

PS: spoke with my instructor and he confirms this is a tricky question.

  • Well first of all, there is some code preventing you from reading files, what does this code look like? We can't just magic away an error message.
    – rook
    Dec 8 '14 at 15:36
  • @Rook it's a black box testing. The message it returns is just a string saying that "Error, using '..' is forbidden in folder and file name.
    – Ay0
    Dec 8 '14 at 16:01
  • Try injecting your canocolizations into both the parameters names and values
    – atdre
    Dec 8 '14 at 17:06
  • have you tried using other URL parameters in A.php? It is supposed to just list the contents but perhaps it responds to the action and/or file parameters.
    – mcgyver5
    Dec 8 '14 at 17:12
  • @mcgyver5 didn't think about that, but just tried and if I replace folder with anything else, there is a 302 to folder=public which is the default page.
    – Ay0
    Dec 8 '14 at 17:18

I can't tell you how to break that specific system as there is not enough information supplied, although I can provide some general things to try:

  • Try / and \ at the start of the folder name to try and reach the root directory.
  • Try %2f and %5c (percent encoded versions of the above).
  • Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216).
  • Try double URL encoding (. = %252e, / = %252f, \ = %255c).
  • Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae, %c0ae, / can be %c0%af, %e0%80%af, %c0%2f, etc, \ can be %c0%5c, %c0%80%5c).

If you suddenly get a different response then you have managed to change either the execution path or the file system path that is being accessed so you may be onto something.

You can use a tool such as Burp Suite to automate your attack and substitute different representations of path characters.

  • the application only accepts ascii and hex. It seems it doesn't properly handle 16-bit unicode, double URL encoding or UTF-8 unicode.
    – Ay0
    Dec 9 '14 at 17:55
  • @yzt: So is that beneficial to your attack or not? Dec 9 '14 at 19:09
  • well... we can say that it is beneficial but it doesn't solve the problem. I found the answer already, it doesn't depend on encoding, but I'm accepting this as it can benefit other people with directory traversal attacks.
    – Ay0
    Dec 10 '14 at 13:15
  • @yzT: How did you break it? Dec 10 '14 at 14:07
  • 1
    It was pretty easy... The trick was in that .. wasn't allowed, but a single dot yes, so using a dot in folder and another dot in file, I could go to the other directory.
    – Ay0
    Dec 10 '14 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.