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.w...@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:
