Full Disclosure: Re: [CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application

[Daniel Wood <daniel.wood () owasp org>]

Friday, January 17, 2014
Updated Security Review for the new Starbucks v2.6.2 mobile iOS application

After publishing my vulnerability report on the Starbucks v2.6.1 mobile iOS application, I have been in continuous 
communication with Starbucks.  As you know, Starbucks released an updated version of the application to address these 
security concerns.  I have evaluated the latest version of the Starbucks mobile application (v2.6.2) from the Apple App 
Store and conducted exhaustive retesting of the application in order to confirm whether the vulnerabilities were 
successfully addressed.

Prior to starting the new version of the Starbucks mobile app, session.clslog was 64kb (varies on how many user actions 
you took prior to capturing the data) in size.  After running the new version of the application, it clears the 
session.clslog data file effectively removing all sensitive data elements that were being previously stored.  

Caveats:
If you install the latest Starbucks 2.6.2 app update without actually running the application, the session.clslog file 
remains with the sensitive data contained within it, however, as soon as you launch the new version of the application 
it clears session.clslog out, effectively wiping this data off your device.   This behavior makes sense as the 
application is required to run in order to execute the programmatic functions that address the issue of a static file 
that was being spooled to.

There is still a file, located in /Starbucks/Library/Preferences/com.starbucks.mystarbucks.plist that contains 
geolocation data of a users last logged geolocation.  The difference here is, it is not a running log of a customers 
geolocation like was being stored in session.clslog.  This information is only the last location where a customer has 
used their device.  As such, I do not believe this file is a security concern as it does not aggregate geolocation data 
over time.  Your stored geolocation is overwritten each time and cannot be used to track your movement patterns over 
time.

In summary, Starbucks has effectively addressed the security issues that were documented in my original report 
published January 14, 2014, however, I do recommend that the above issue be remediated within the next release cycle of 
the mobile application to prevent a customers' last logged geolocation data from being stored.

To address some misinformation that has been released:
The application does not need to crash in order for a customer's sensitive data elements to be written to 
session.clslog - this happened automatically prior to v2.6.2 being released.  The application can be backgrounded and 
the phone can be in Sleep mode by pressing the ‘Lock’ button on the top of the device and the data was written to 
session.clslog.  

During the initial testing of the application, at no point was there credit card data contained within this file, only 
your Starbucks Card number and balance amount.  During my testing I opted not to enter a valid credit card due to 
personal privacy precautions, thus the resulting entry within session.clslog had a value of <null>.

At no point were Starbucks's data servers compromised, exposing their 10 million customers to the application as some 
reports have suggested.  This was a local exploitable vulnerability on a users device, not a remotely exploitable 
vulnerability on their servers or any other type of remote code execution vulnerability.

The PIN bypass methods described by some outlets mention the device's PIN, in actuality it is the PIN within the 
Starbucks application that did not prevent access to the sensitive user data elements being stored within 
session.clslog.  While it is still possible to access application files stored on the device, since the v.2.6.2 update, 
this is no longer an issue as these data elements are not being written to session.clslog in clear text as was the case 
with the original vulnerability.  Keep in mind this is true for ANY application that uses a PIN to 'protect' your data. 
 It is only as secure as how the data written to the device is being secured either through encryption or never saving 
the data to disk to begin with.  A PIN only prevents someone from access the application itself, not the data being 
stored.  If you don’t store any data or you encrypt it, you have nothing to worry about if done properly.  Application 
sandboxing does not prevent this type of vulnerability if it is being written to the disk.


- Daniel Wood



On Jan 13, 2014, at 10:28 PM, Daniel Wood <daniel.wood () owasp org> wrote:

> 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

Attachment: 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/