02:54 PM
John H. Sawyer
John H. Sawyer

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

Analysis reveals mobile apps designed to protect files and passwords do a poor job, often storing them in plain text and use weak obfuscation techniques.

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:

  • /mnt/sdcard/com.camfiler.photosafe/.thumbnails/
  • /mnt/sdcard/com.camfiler.photosafe/.hide/

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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/7/2012 | 2:36:22 PM
re: Analyzing Android, iOS Apps For Weak Data Protection, Cleartext Passwords
Great job John.- This validates other securfity flaws I am reading about regarding the security weaknesses of the Andriod system.- What is most concerning-mobile payments are migrating quickly to the Andriod and iOS platforms that are great targets for cyber crime.
Register for Dark Reading Newsletters
White Papers
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.