Starbucks revisited

Product: Starbucks iOS mobile application
Version: v3.0 (pre-release)
Vendor: Starbucks Coffee Company


The Starbucks iOS v2.6.1 mobile application was tested in November of 2013, and publicly reported on January 13, 2014 on the Full Disclosure security mailing list here.  The findings centered on the insecure storage of user data elements within a third-party API's (Crashlytics) log file, session.clslog.

In coordination with Starbucks, on January 17, 2014, the Starbucks iOS v2.6.2 mobile application, an emergency fix, that was pushed to address the issues identified in v2.6.1, was independently tested to confirm that the updated application was not logging sensitive user data elements to this log (or any other) file.  Results from the testing, as well as clarifications from the first round of testing were posted to the Full Disclosure security mailing list here.

Due to the aforementioned independent testing, Starbucks extended an invitation to test their latest version of their mobile application (v3.0) prior to the public release of the application.

Summary of Findings
Exhaustive testing was conducted on the Starbucks v3.0 iOS mobile application, covering the range of the OWASP Top 10 Mobile Risks utilizing a combination of automated and manual static and dynamic analysis methods.  No vulnerabilities were identified during the testing of the mobile application.  An exhaustive and detailed report was provided to Starbucks on March 3, 2014 prior to the public release of v3.0 of their iOS mobile application.

Workflow for Mobile App Testing

Since the publication of the Starbucks mobile iOS app vulnerability, I have received many questions by journalists, security researchers and other people interested in understanding what occurs during a mobile app security assessment and exactly just how much work is involved.

I am currently working on analyzing a few applications from the App Store that I will be publishing findings about due to their vulnerabilities.  Hopefully within a weeks time I will have a write-up complete that uses one or more of these apps as examples.   Everyone loves pretty pictures :)


DW

Musings on Starbucks

Much has happened since I posted the original research on the Full Disclosure mailing list regarding Starbucks and how their mobile application was logging sensitive user data elements in clear text.

Many people have contacted me regarding the reporting timeline and the details of such.  Unfortunately many individuals are also posting incorrect information on the matter so I thought I would address these issues, and many others here.

I originally reached out to Starbucks on December 6, 2013 to their customer service.  Over the next month I traded communications back and forth with Starbucks' Customer Service department with ultimately leaving the ball in their court regarding contacting me with a follow-up on what I deemed important if not critical sensitive information.  Unfortunately, this never happened and here we are.  On January 13, 2014 I published some (but not all) of my findings regarding the application on Full Disclosure.  The information was picked up by the media and before I knew it, it made it onto national and international headlines.  

This led to Starbucks expressing interest in speaking with me privately.  I reached out to a PR official at Starbucks directly to let them know I was willing to attempt lines of communication again.  Long story short, I've been in communication with Starbucks throughout the past week and have tested their latest release of the updated application to confirm that the security vulnerability was remediated appropriately.  You can read Starbucks' original post that was updated with the new iOS mobile app here.

There has been a lot of media sensationalizing the Starbucks iOS mobile app vulnerability.  I've seen articles written with titles claiming Starbucks was hacked, that it's related to Neiman Marcus and Target, and that 10 million customers data was at risk.  All this is unequivocally not true.  In my latest update on the matter I address this and many other incorrect conclusions drawn by the media.  

Probably the biggest issue I have with the entire situation were the quotes I've read about the vulnerability being "theoretical" in nature.  This was not a theoretical vulnerability, it was a very real issue.  I think the term was applied due to the perceived complexity of the attack to exploit the vulnerability.  In all honesty, it isn't difficult to pull of and it's not unheard of to have your phone stolen while you're out and about, or leave it on a table somewhere.  While the chance of someone knowing where to look for this information or how to even do it is very slim in nature, I cannot in good faith say it couldn't happen.  This by no means should be downplayed and classified as "theoretical" in nature. 

With that said, I want to thank everyone - my wife, family, friends and colleagues for being supportive during the past week; the media that was accurately reporting events, and Starbucks.  I believe Starbucks had acted in good faith to address this issue in a timely manner to push a security fix out so soon after this was reported on.  Starbucks was forced to learn some hard lessons with this incident, however, I believe they will take this in stride and only improve upon the areas they were lacking in.

Daniel Wood

Adobe Data Mining and Ethics

Several days ago I released a script to aid security researchers and organizations in identifying if their account(s) were in the recent Adobe account database leak.  I had originally aided several organizations in identifying more accounts they had not known about and figured others could use this as well on their own.

You can grab it here: https://github.com/securitycrush/adobextract

Adobe sent out notifications to potentially compromised accounts, however, since they originally stated the number of accounts were roughly 2.9 million, and now we know the potential amount of accounts are closer to 150 million (minus dupes, fakes, etc); I figured having an independent way of verifying is probably a good idea.

This script will parse through the original leaked database file within users.tar.gz, which uncompressed is approximately 9GB in size for user supplied TLD's.  I have included a sample domains.txt as well as roughly the Top 500 (U.S.) sites from Alexa, as of October 6, 2013.  These text files are for mass data mining, however, you can trim them down to only your organization's owned domains or however else you would like to use them.

I've received several questions from individuals concerned stating that a script like this could be used for both good and nefarious purposes.  This is true with any tool; it all depends on the purpose and motivation of the user.  The leaked database is already floating around on publicly available forums, chat rooms, and twitter - so that danger is not just limited to scripts like these.  The information that can be mined from this database leak could allow security researchers to obtain better name, username, and password lists to aid in password auditing or conducting phishing exercises (all legally authorized); or could allow potentially malicious actors to conduct the same types of audits and 'attacks'.  Again, it's all based upon the motivations of the user.

Hopefully, those within the infosec community will find it useful and even tweak it to their own needs.  It's meant to be a starting point and not a finished product.  Over time I will bake more features in it, however, I won't be adding needless features just to bloat it.

UPDATE:  Several developers and researchers have adapted my code and idea for their own projects to provide these types of services to users as well.  Great!


Daniel Wood