11

I have a Linux-based embedded system with web-interface for management purposes. According to one security paper, this web-server has rudimentary filter against directory traversal attacks in URL parameters. So in order to bypass the "../" filter, an URL with special strings needs to be used. What are the common path traversal filter bypass techniques?

  • 1
    This is quite broad. Bypass techniques vary greatly depending on the blacklist that is used, the backend application environment (Windows, Linux-based, ASP.NET, Ruby, Perl, etc.). ..\ can be used, ..//..// can be used, various encodings %252e%252e%252f is an example, and other techniques. – user79537 Aug 16 '15 at 22:39
  • 3
    It would be helpful if you mentioned what linux system, what web application/server, and what 'security paper' you are asking about. – KDEx Aug 17 '15 at 4:53
  • It is a VoIP phone based on Linux. However, while I analyzed the firmware image with hex editor, checked the phone boot log messages and used nmap service and OS detection scans, I got fairly little information. All I can say is that phone firmware is based on Linux 2.6 for MIPS, uses /proc file-system, uses JFFS2 file-system and web-server type is unknown. Even debugging log provides fairly little information regarding web server. All it says is that PHN: WEBSV: init http_https, protected 0. Security paper can be seen here. – Martin Aug 17 '15 at 10:37
  • I recommend editing your question and adding the additional data including the link to the vulnerability report. – Neil Smithline Aug 18 '15 at 19:44
  • So you are looking to test whether your firmware has a fix for a specific vulnerability? Do you have access to a known vulnerable version of the firmware? I'd recommend testing there until you find the problem and then testing on the patched firmware. – Neil Smithline Aug 18 '15 at 19:48
10
+100

There are various encodings you can try to enable you to bypass a filter:

  • 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 get a different response trying one of the above then you have managed to change either the execution path or the file system path that is being accessed. This may indicate that the particular sequence used may be worthy of additional investigation.

  • Thanks for all those encodings! Now I should use those instead of expected user input? I mean for example instead of 192.168.1.87/line_features.htm?l=1 I need to use 192.168.1.87/line_features.htm?l=%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2fetc/passwd and other similar combinations? – Martin Aug 17 '15 at 16:09
  • 2
    Without knowing which server or the vulnerability this is hard to answer. Look especially for parameters that take a file parameter, and test as you described. – SilverlightFox Aug 18 '15 at 8:39
  • All the information I have is here. As much as I analyzed the phone (bootup) log files and did nmap service detection scans, then it does not seem to have some well-known web server. I also used the dotdotpwn tool(for example dotdotpwn.pl -m http-url -u http://192.168.1.87/line_features.htm?l=TRAVERSAL -f /etc/passwd%00 -o unix -x 80 -U user -P passwd -k "user") in order to generate URL's automatically, but I feel like I'm just randomly trying. – Martin Aug 18 '15 at 11:41
  • I would guess that in the reference The string [removed] at the end is necessary that [removed] could be the null byte (%00). Bear in mind this is guess work and it is impossible to hack by proxy in such a way. – SilverlightFox Aug 20 '15 at 9:15
  • I see. I tested with %00 at the end when I used dotdotpwn.pl -m http-url -u http://192.168.1.87 /line_features.htm?l=TRAVERSAL -f /etc/passwd%00 -o unix -x 80 -k "root". This will send GET requests like GET /line_features.htm?l=%2e.%c1%af%2e.%c1%afetc%c1%afpasswd%00 HTTP/1.1 to phone. – Martin Aug 25 '15 at 9:58
4

For web app security, many common hacks are documented in the associated OWASP test guides and attack pages. OWASP provides a path traversal attack and testing guide.

The general concept is to use characters that can fool the path traversal code. Things like embedded nulls, unicode notation, and such can sometimes bypass the path traversal filter.

Note that a strong implementation will not be susceptible to any of these. It will use a character white-list and other measures that will prevent any of these tricks from succeeding.

  • Thanks! As I understand, first step is to enumerate all the parts of web-application which accept content from the user. For example http://192.168.1.87/line_login.htm?l=1 or http://192.168.1.87/index.htm?dialeddel=clear? I guess usually those are found by crawling the web-application and searching for ?(query string) in URLs? – Martin Aug 17 '15 at 10:49
  • 1
    That's a start but far from the entire process. Paths can be passed as POST data that won't show up in query parameters. Also, you could have an URL like http://example.com/upload.jsp/c:/foo/bar where the c:/foo/bar is a filename. It is best if you are intimate with the functionality of the app you are testing to identify the path locations. – Neil Smithline Aug 17 '15 at 21:08

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.