The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

342

Chapter 10 

■

Exploiting Path Traversal

70779c10.qxd:WileyRed  9/14/07  3:14 PM  Page 342

---

Taken together, these caveats presented a barrier to straightforward

exploitation of the vulnerability. First, although it was possible to write arbi-

trary files to the server file system, it was not possible to overwrite any exist-

ing file, and the low privileges of the web server process meant that it was not

possible to create a new file in any interesting locations. Second, it was not pos-

sible to request an arbitrary existing file (such as 

/etc/passwd

) without reverse

engineering the custom encoding, which presented a lengthy and unappealing

challenge.

A little experimentation revealed that the obfuscated URLs contained the

original filename string supplied by the user. For example:

■■

test.txt

became 

zM1YTU4NTY2Y

.

■■

foo/../test.txt

became 

E1NzUyMzE0ZjQ0NjMzND

.

The difference in length of the encoded URLs indicated that no path canon-

icalization had been performed before applying the encoding. This behavior

gave us enough of a toe-hold to exploit the vulnerability. The first step was to

submit a file with the following name:

../../../../../.././etc/passwd/../../tmp/foo

which in its canonical form is equivalent to

/tmp/foo

and so could be written by the web server. Uploading this file produced a

download URL containing the following obfuscated filename:

FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrMHdUbXBWZWs1NldYaE5lb

To modify this value to return the file 

/etc/passwd

, we simply needed to

truncate it at the right point, which is

FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrM

Attempting to download a file using this value returned the server’s 

passwd

file as expected. The server had given us sufficient resources to be able to

encode arbitrary file paths using its scheme, without even deciphering the

obfuscation algorithm being used!