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 john[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.
Mobile Malware Incidents Hit 100% of Businesses
Dawn Kawamoto, Associate Editor, Dark Reading,  11/17/2017
3 Ways to Retain Security Operations Staff
Oliver Rochford, Vice President of Security Evangelism at DFLabs,  11/20/2017
Register for Dark Reading Newsletters
White Papers
Current Issue
Managing Cyber-Risk
An online breach could have a huge impact on your organization. Here are some strategies for measuring and managing that risk.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.