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
http://www.linkedin.com/in/danielewood
Product: Starbucks iOS mobile application
Version: 2.6.1 (May 02, 2013)
Vendor: Starbucks Coffee Company
URL: https://itunes.apple.com/us/app/starbucks/id331177714
Issue: Username, email address, and password elements are being stored in
clear-text in the session.clslog crashlytics log file.
Location:
/Library/Caches/com.crashlytics.data/com.starbucks.mystarbucks/session.clslog
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.
From session.clslog:
I have a Starbucks
account.
[...snip...]
Username *
Password *
43440 $ -[AccountManager forgotPasswordEmail:withUserName:] line 1609 $ BODY
STRING:[ {"emailAddress":"CLEARTEXT","userName":"CLEARTEXT"} ]
Note: All references of 'CLEARTEXT' above are the cleartext values of each
referenced string.
Mitigation:
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 CommonCrypto
- 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 characters.
- 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.
References:
http://try.crashlytics.com/security/
https://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/SecurityDevelopmentChecklists/SecurityDevelopmentChecklists.html#//apple_ref/doc/uid/TP40002415-CH1-SW1
https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/