What makes an Android application vulnerable to Directory Traversal?

Question

Definition of Directory Traversal

Directory traversal is a form of HTTP exploit in which a hacker uses the software on a Web server to access data in a directory other than the server's root directory. If the attempt is successful, the hacker can view restricted files or even execute commands on the server.

How Directory Traversal impacts the Android O.S

Directory Traversal within Android, allows attackers to perpetrate a path traversal attack in the context of a user application and read/write files inside internal storage.

Android Directory Traversal attack Example

App Name:

ES File Explorer v3.2.4.1 - Path Traversal Vulnerability

Product & Service Introduction:

ES File Explorer is a free all-in-one including a file manager & application & tasks, support for online storage spaces (Dropbox, Google Drive, SkyDrive, Box.net, Sugarsync, Yandex, Amazon S3),

CVE-ID:

CVE-2015-1876

References (Source):

http://www.vulnerability-lab.com/get_content.php?id=1435

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1876

Technical Details & Description:

A Path Traveral web vulnerability has been discovered in the official in the official ES File Explorer v3.2.4.1 mobile android web-application. The security vulnerability allows a remote attacker to unauthorized request local files and device system paths to compromise the application or device.

The vulnerability is located in the content://com.estrongs.files/system/ path request with the context. The vulnerability can be exploited by local or remote attackers without user interaction. The attacker needs to replace the sdcard path request in the com.estrongs.files/system with a malicious path request like ./etc/passwd ./etc/hosts and continues the request. The attack vector is located on the application-side of the service and the request is http.

My Question

Although I understand what Directory Traversal is and how Directory Traversal can take place. I don't know what factors makes a selection of Android code vulnerable to such an attack.

Answer 1

The generic answer for "is my code vulnerable to directory traversal?" is to ask yourself if your code:

1. Uses filename strings that you got from an untrusted source to read/write files on disk? "Untrusted sources" could be direct user input, things you read from files (which could have been tampered with), or from 3rd party code that your code interacts with.

2. If you answered 'yes' to (1), then what happens if instead of "filename.txt", you enter the string "../someOtherDir/secret.txt" (assuming this file exists)? Will the program reject it as a malicious file access, or will it happily open this file?

This kind of traversal works because unix-like environments will accept /tmp/../etc/passwds as a valid path for /etc/passwds.

---

Mitigation

Mitigating against Directory Traversal Attacks usually involves making sure that if you allow filenames from untrusted sources, that you restrict those file accesses to a single directory. AFAIK there's no single best way to do this, but some things to think about are:

1. If you are only allowing the user to specify a filename (not a folder or path) then simply reject any filename strings that contain the '/' or '\' characters. Just silently drop that request. Better is to look up the list of legal file name characters on your OS (Android in this case) and reject any string that contains a non-legal character.

2. If all the files that you are allowing the user access to are in /publicDir, then before you open a file with the untrusted string, make sure that the file pointed at is actually inside /publicDir. This sounds obvious, but turns out to be really tricky to get right since there are many ways to construct malicious paths, for example: "/publicDir/../etc/passwds" will fool many naive checks. So I wouldn't advise this option.

A final note is not to get into the game of "cleaning" user input, just reject it. For example, a common thing programmers like to do is to remove dangerous characters and attempt to process the request on the "cleaned" string. Don't do this. If they gave you a bad string, just reject it and let them try again. I have two reasons for this:

3. If the user asked you to open "../../../etc/passwd", that wasn't a typo, they didn't mean "passwd.txt", they're being an asshat. Just ignore it.

4. As soon as you write a function to clean strings, the game becomes to pass in a string which your cleaner with make malicious. The more complicated your string cleaner gets, the more room there is to abuse it.

So don't play the game, if it look suspicious, just reject it. I personally use mitigation option #1: rather than trying to guess which characters could be malicious, I just reject anything that contains a character other than letters, numbers, and '.'