Analyzing Android, iOS Apps For Weak Data Protection, Cleartext Passwords

In the last few blog posts, I covered an approach to mobile device security research based on techniques I've used over the years as a forensic investigator, network intrusion analyst, and penetration tester. I've described using mac-robber directly on Android and iOS devices, followed by mactime to generate a timeline of the filesystem as a basic method of identifying system activity that can find mobile app vulnerabilities. After covering how to get macrobber running on Android and iOS, I'm now going to show examples of vulnerable information that can be found through filesystem analysis, including some real-world examples.

Did you know that Android stores the preshared keys for wireless networks in cleartext? While this isn't news to most mobile researchers, I happened upon it again after I'd added a new WPA2-protected wireless network, and my timeline of the filesystem showed that /data/misc/wifi/wpa_supplicant.conf had recently changed. Major vulnerability? No, not at all, but it could be useful during a targeted attack if an attacker were able to steal a mobile device from the target or get malware onto the device to steal the keys.

I spent some time looking at applications designed to "protect" or "hide" specific images from your photo/image gallery. What surprised me were the methods for hiding the images. On Unix-based systems like Android (Linux) and iOS (Mac OS X), files and folders with names starting with a period (e.g., ".cantseeme") are considered hidden files. Most directory listing tools will not display them without passing specific parameters saying to list all files and folders including hidden ones. See where I'm going with this?

Yep. That's how several of the different photo "protection" apps work. For example, a timeline created after using PhotoSafe for Android showed that the following paths were used for storing thumbnails of all images it has loaded loaded and the files it hides, respectively:

Thankfully, when I looked at PhotoSafe 2.8, it did include the following disclaimer:

"PS is a software the changes photo files to hide them from the default photo gallery. Disclaimer: Do not use this for sensitive or important files."

While that's great, I doubt it's going to prevent people from actually using it to hide "sensitive and important files." But at least the developer is being honest. My guess is he may have already been called out for the weak protection measures used by the app and added the disclaimer to deal with it.

Gallery Lock Lite for Android does similar things but goes a step further to obfuscate the photos. After hiding a few photos, I created a timeline to see what was going on. I noticed a couple of new files and directories created. Of particular interest was another hidden directory, /mnt/sdcard/.gallery_lock/. Inside was a directory named media that contained a directory whose name was based on the date and time I hid the files. The files contained inside had two of each with the same base file name (e.g., 1331609828596), but with file extensions I didn't recognize: slt and slm.

I copied a pair of the files over to my laptop and used the file command to try and figure out what they were. The slm file was an unknown format and identified as just being raw data; however, the slt file turned out to be a JPG image file. When opened, it turned out to be a thumbnail of the original hidden image. Next, I ran the strings tool against the slm file to see if any interesting text strings showed up. Immediately, I saw the original filename of the file I'd hidden along with the string "Exif" that made me think the hidden photo might be inside this oddly named file.

Opening the file with a hex editor editor (Hex Fiend), I saw the original name of my hidden file followed by zeroes that filled the first 1,024 bytes of the file. After the zeroes, I recognized the beginning header of a JPG file -- bytes "FF D8." I selected the content of the file starting there on back to the end of the file where I saw the JPG footer (bytes "FF D9") and copied the content into a new file called carved.jpg. A quick check in an image viewer revealed this was indeed my "hidden" file.

To see screenshots from the process used during the Gallery Lock Lite analysis, see slides 19 and 20 (PDF) from my "Smart Bombs: Mobile Vulnerability and Exploitation" given at the SANS Mobile Device Security Summit.

During the joint version of the "Smart Bomb" talk (slides) that Tom Eston, Kevin Johnson, and I gave at the recent OWASP AppSecDC conference, we identified a few more issues that could lead to sensitive data exposure. For example, Evernote users that store sensitive information within Evernote might be surprised to know that some of the data may be stored in unencrypted files cached on the device even though only Premium users are supposed to be able to store data offline.

Similarly, MyFitnessPal for iOS stores sensitive personal data in cleartext in SQLite database files right on the Apple device. And Password Keeper "Lite," which is supposed to protect your passwords ... well, it stores the PIN and passwords in cleartext in a SQLite database file.

Of course, this only scratches the surface. There are hundreds of thousands of applications, and the ones we looked at only make up a small sampling of what's out there.

If there are apps you're considering using for sensitive data, either for personal use or in your enterprise environment, then I highly recommend you take the time to perform analysis to see whether they're adequately protecting your data.

John Sawyer is a Senior Security Analyst with InGuardians, Inc. The views and opinions expressed in this blog are his own and do not represent those of his employer. He can be reached at [email protected] and found on Twitter @johnhsawyer.