Title: [CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application
Published: January 13, 2014
Reported to Vendor: December 2013 (no direct response)
CVE Reference: CVE-2014-0647
Credit: This issue was discovered by Daniel E. Wood
Product: Starbucks iOS mobile application
Version: 2.6.1 (May 02, 2013)
Vendor: Starbucks Coffee Company
Issue: Username, email address, and password elements are being stored in clear-text in the session.clslog crashlytics
Within session.clslog there are multiple instances of the storage of clear-text credentials that can be recovered and
leveraged for unauthorized usage of a users account on the malicious users’ own device or online at
https://www.starbucks.com/account/signin. It contains the HTML of the mobile application page that performs the
account login or account reset. session.clslog also contains the OAuth token (signed with HMAC-SHA1) and OAuth
signature for the users account/device to the Starbucks service.
I have a Starbucks account.
43440 $ -[AccountManager forgotPasswordEmail:withUserName:] line 1609 $ BODY STRING:[
Note: All references of ‘CLEARTEXT’ above are the cleartext values of each referenced string.
To prevent sensitive user data (credentials) from being recovered by a malicious user, output sanitization should be
conducted to prevent these data elements from being stored in the crashlytics log files in clear-text, if at all.
iOS Specific Best Practices (from OWASP Mobile Top 10 – M1 Insecure Data Storage):
– Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login
scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to
meet the user experience requirements.
– Where storage or caching of information is necessary consider using a standard iOS encryption library such as
– If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or
exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which
as stated above is trivial in some cases.
– For databases consider using SQLcipher for Sqlite data encryption
– For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the
default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4
– For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see
NSData Class Reference for protection options).
– Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files.
– Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.