Lucene search
K

Starbucks 2.6.1 Information Disclosure

🗓️ 14 Jan 2014 00:00:00Reported by Daniel E. WoodType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 48 Views

Insecure data storage of user elements in Starbucks v2.6.1 iOS mobile ap

Related
Code
ReporterTitlePublishedViews
Family
CVE
CVE-2014-0647
28 Jan 201400:00
cve
Cvelist
CVE-2014-0647
28 Jan 201400:00
cvelist
EUVD
EUVD-2014-0678
7 Oct 202500:30
euvd
NVD
CVE-2014-0647
28 Jan 201400:55
nvd
Prion
Design/Logic Flaw
28 Jan 201400:55
prion
securityvulns
[CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application
19 Jan 201400:00
securityvulns
securityvulns
Starbucks mobile application information leakage
19 Jan 201400:00
securityvulns
The Hacker News
Starbucks' iOS app storing user credentials in plain text
16 Jan 201420:55
thn
`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:  
<div class="block_login">  
<form action="/OAuth/sign-in" class="siren" id="accountForm" method="post">  
<fieldset class="login_position">  
<legend><span class="group-header">I have a Starbucks account.</span></legend>  
  
[...snip...]  
  
<li>  
<label for="Account_UserName" class="">Username <span class='req'>*</span></label>  
<span class="x">  
<input class="field text medium" id="Account_UserName" maxlength="200" name="Account.UserName" tabindex="0" type="text" value="CLEARTEXT" />  
</span>  
</li>  
<li>  
<label for="Account_PassWord" class="">Password <span class='req'>*</span></label>  
<span class="x">  
<input class="field text medium" id="Account_PassWord" maxlength="200" name="Account.PassWord" tabindex="0" type="password" value="CLEARTEXT" />  
</span>  
</li>  
  
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  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation