Unable to understand why the web app is vulnerable to a Directory traversal attack

Question

I was working with this web-app, when someone pen-tested it and sent me a huge report that says my app is vulnerable to a Directory traversal attack.

Here is one sample:

Testing Path: http://127.0.0.1:80/??/etc/issue <- VULNERABLE!

I put http://127.0.0.1:80/??/etc/issue in my browser, but it gave me the home page, it didn't at all return the /etc/issue file.

Then I tried with curl and it too returned the homepage.

Could somebody please explain me how my app is vulnerable, if the /etc/issue file is not returned.

The app is coded in Python 2.7, with flask as the framework and Nginx as a reverse proxy.

Two more samples from the report, along with the corresponding response :-

1. Testing Path: http://127.0.0.1:80/??/etc/passwd <- VULNERABLE!

   GET Request - app: 0|req: 1587/1587] 127.0.0.1 () {34 vars in 488 bytes} [Tue Sep 6 15:47:13 2016] GET /??/etc/passwd => generated 982 bytes in 4 msecs (HTTP/1.1 200) 2 headers in 80 bytes1

2. Testing Path: http://127.0.0.1:80/??/??/etc/passwd <- VULNERABLE!

   GET Request - app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep 6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

Answer 1

I sent a report for a similar vulnerability recently and got a similar response.

Turns out most browsers and CLI http clients remove path traversal components from the URL.

For instance if on Firefox you type the URL http://example.com/../../../etc/passwd the GET request that arrives at example.com will look like this:

GET /etc/passwd HTTP/1.1
[Ommitted headers]

Same deal with wget.

You should try with a lower level tool, like telnet or netcat:

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)

Then again, it might have been a false positive, your auditor should've included the contents of /etc/issue in the report. That's kind of the point of using issue and not passwd.

You should at least follow up with your auditor to confirm whether it was a false positive. If that's not possible, arrange a new pentest or perform your own with a path traversal fuzzer like dotdotpwn

Never assume you're secure, ensure you are. Especially after a report like that.

Answer 2

First, Nobody pen-tested it. They ran a scanner and handed you the results.

A pen-tester would have confirmed the vulnerability and explained how to recreate it.

It is possible that the scanner mistakenly flagged the fact that it got your home page as a response to these payload as a positive finding.

I also think, like Jesse, that the double question mark is hiding the real payload because I've never heard of ?? as part of a directory traversal payload and can't find anything to make me think it is one. Try substituting .. in all the places you see ??

The scanner would have used a browser version that didn't follow https://www.rfc-editor.org/rfc/rfc3986#section-5.2 which is the spec for removing/resolving those dots in the URL.

If the scanner had flagged just one payload as vulnerable while dozens of others were not, I'd be more concerned, but it looks like you got dozens of results with various payloads, right? Like @Gnp said, ask the scanner for proof (and ask about that ?? payload).

Answer 3

This was most probably a false positive.

After seeing the below updated information in your question

GET Request -

app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep  6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

Its pretty clear it was produced by some automated scanner.

Then comes the question how the scanner decided its vulnerable?

As you mentioned,

Then I tried with curl and it too returned the homepage.

The automated scanner just assumed that since it got a HTTP/1.1 200(OK) as the server response it was able to read that file /etc/passwd on server. Silly Automated Scanner.

The automated scanner is expecting something like a HTTP/1.1 404 (Not Found) or HTTP/1.1 302 ( URL redirection) for that page to be not vulnerable.