An Analysis of the Starbucks Cyber Attack and How To Stay Protected

How much is a cup of coffee really worth? Several weeks ago, many Starbucks customers began reporting their Starbucks card balance emptied and then topped again. On May 13th, Starbucks released a written statement  denying the un-authorized activity was a result of a hack or an intrusion to its servers or mobile app. But the hard facts show that indeed customers had their accounts abused by hackers. 

The question is, how were the credentials obtained? There are several plausible answers to this question and no answer can be proved or shot down completely. Some researchers say that there was an active phishing campaign targeting Starbucks customers, others say that the phishing campaign was targeting a wider range of users who are not necessarily Starbucks customers. 

Starbucks claims that the reason for the account hacks is based on re-used credentials. In their statement they noted that, "….Unauthorized activity on their (a customer’s) online account is primarily caused when criminals obtain reused names and passwords from other sites and attempt to apply that information to Starbucks."  The implication here is that customers are ultimately responsible for the loss of their data, because they re-used old passwords rather than creating new passwords per account. 

While this may be partially true, any corporation that sustains an attack that results in a loss of customer data still bears some of the blame, especially when that company isn’t careful with customer data in the first place. Last year the Starbucks mobile application was caught storing usernames, passwords and location data in clear text on the device. This data could have been taken by anyone with access to the device, remotely on devices which have been running a jail-broken operating system, or harvested quietly by data-theft Trojans for future use.  

Although the situation is still unclear, it’s feasible that the credentials stolen back then were used in this current attack on users. Starbucks could theoretically go back and check if the hacked accounts existed last year during the previous breach and perhaps see if the two attacks were actually linked. 

1. Secure application data: During development of the app, Starbucks should have validated that Secure Data Storage is enforced. This is one of the basic requirements covered by the OWASP Top 10 for mobile and PCs, and a great practice for app developers hoping to protect customers and themselves.

2. Two-factor authentication: After last year's breach, Starbucks should have enforced 2-step authentication for all customers who use the app for payments. Weak authentication is not acceptable on applications when so much is at stake. Starbucks’ claims of re-used passwords is another inducer to make use of 2-factor authentication techniques.

3. Proper data encryption: Data stored on the device should be encrypted properly. According to OWASP Mobile Top 10, the two ways that improperly encrypted data can manifest itself in a mobile app are that the app may utilize a flawed process and can be easily exploited, and that the app “may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary." We have not tested the Starbucks App encryption technique however this is a rule of thumb when creating mobile application that store sensitive data.

As with the PC world, mobile application developers should educate themselves so that they’re more aware of the risks they expose the application, the end user and the organization to when writing vulnerable or non-secure code. 

Developers are usually presented with a task that requires them to build functionality, however, rarely will the developer receive the tools to validate if the code written does not expose a known vulnerability. 

Static Code Analysis Solutions (supporting mobile code) might be the ideal method to detect these vulnerabilities at their earliest stage and resolve them with no overhead for the teams. Detecting a vulnerability during the development stage significantly reduces the TCO for any development shop by preventing data, credential or credit theft and also by helping preserve the public reputation of the company and avoid bad press about a security incident. 

Once the vulnerability is exposed in production, the effort in resolving the vulnerability can be tens of times more expensive than resolving the vulnerability at the development stage and the reputational damage has its own business impact.

A mobile secure code analysis solution should be able to support the top two mobile operating systems (iOS and Android) and optionally the Windows phone OS as well. The solution should allow coverage of the OWASP Mobile Top 10 plus additional security validation techniques to cover multiple scenarios which are unique to mobile and not addressed as a standard at this stage. 

Apple, for example, releases a Secure Development guideline document with each OS. It is important to validate that these guidelines are covered by the chosen static analysis solution. Android, iOS and Windows, expose many vulnerabilities which are unique to each platform and should be addressed separately. Of course, different coding language support should also be taken into consideration. 

Every day it seems we see new headlines describing the latest cyber-attack inflicting damage on companies like Starbucks, and ultimately their customers. While users of services like mobile applications must be vigilant in maintain their own cyber-security by using hard-to-guess passwords and other mechanisms, corporations, and the developers they employ to construct applications, must act responsibly in the way they handle consumer data and protect it. With great power (and data) comes great responsibility.