Thursday, April 17, 2014

Avoiding The Next Heartbleed - LinkedIn Publish

Avoiding The Next Heartbleed
How should companies learn from Heartbleed to be better prepared for the next major security event?

Full story

-Michael Coates - @_mwc

Wednesday, April 16, 2014

Discussing Heartbleed

There's plenty of information out there about Heartbleed. I posted a high level analysis on the Shape blog and there's also an OWASP page up on the topic.

Over the past week I had the opportunity to speak with several organizations about the vulnerability, what is at stake and how organizations should be defending their applications and users.


-Michael Coates - @_mwc

Tuesday, March 25, 2014

OWASP AppSec Keynote - Security in an Interconnected and Complex World of Software

Last week I delivered the closing keynote at the OWASP AppSec Apac conference held in Tokyo, Japan. Riotaro Okada, Sen Ueno, Robert Dracea and the entire OWASP Japan chapter put the amazing conference together.

The slides are posted and a video recording should be available soon.

-Michael Coates - @_mwc

Thursday, January 2, 2014

Snapchat Hacked - Aware of Vulnerability for 4 Months

Snapchat has been hacked and 4.6 million usernames and phone numbers have been exposed. I spoke with Emily Chang on Bloomberg West about the compromise and the risk to users.

As a result of the flaw all of Snapchat's users, reportedly around 8 million, are at risk. You can see if your data is part of the 4.6 millions already compromised by entering your username here Even though the last 2 digits of the phone number are omitted the full phone numbers have been breached.

Timeline of Events
  • 8/28/2013 - GibsonSecurity discloses potential security vulnerabilities to Snapchat and ZDnet covers the story too
  • 12/24/2013 - GibsonSecurity provides full disclosure of the vulnerability and proof of concept for Find_Friends and bulk account creation attacks. Per GibsonSecurity this is in response to receiving little communication from Snapchat and no traction in resolving the security vulnerabilities in over 4 months
  • 12/27/2013 - Snapchat issues a blogpost acknowledging the potential weaknesses and describes the issue as theoretical. They also assure customers that they've added additional controls to prevent such an attack.
  • 1/1/2014 - An unknown 3rd party unrelated to GibsonSecurity exploits the vulnerability, obtains data on 4.6 million users and provides the data publicly at The last 2 digits of the phone number are obscured.
The Vulnerability
Snapchat's API is not supposed to be publicly used but that doesn't stop anyone from reverse engineering the protocol to determine how it works and how to initiate various actions. GibsonSecurity, a self reported group of "poor students, with no stable source of income" from Australia, did just that.

By design, Snapchat provides a feature for users to locate friends by their phone number. Using the API it was trivial for GibsonSec to leverage automation to initiate numerous requests to this feature. Since phone numbers follow a predictable pattern XXX YYY ZZZZ, the automation simply iterated through each number until the response indicated the number matched a valid user account. When a match was hit the associated Snapchat username was returned for the provided phone number.

Screenshot from

Why didn't Snapchat fix this?
Excellent question. Snapchat either didn't understand the issue, put too much faith in their defensive solutions, or deprioritized the issue to focus on feature development. At this point Snapchat has said very little about the issue. Unfortunately startups are increasingly targeted by attackers as they quickly amass a large amount of user data. Although the company may be strapped for engineers, they must realize that once they have valuable data (user data, credit card info, etc) they will be a target.

Rate Limiting and IP Blocking
The minimum defensive control is rate limiting and IP blocking of malicious activity. Unfortunately even these controls quickly fail when the attack is distributed across a botnet. In those situations you must automatically determine human activity from bot activity. While captures are one approach, they are hugely disruptive to users and provide declining defensive value against malicious bots.

Working with Security Researchers
As someone who has worked with the security research community for many years at Mozilla and OWASP there is a lot for Snapchat to learn here.
  1. Acknoweldge the security researchers and thank them for providing the security information. It's unclear what response Snapchat provided, but from GibsonSec's comments it appears there was little communication.
  2. Keep communication lines open with the researchers. Copy them into the bug and provide regular updates on progress. Also ask them if they'd like to take another look at your proposed defensive solution.
  3. Work to fix the issue quickly. There are always competing priorities, but if protecting user data is not extremely high on your list, then you should reevaluate whether users should trust you at all.
  4. Don't publicly downplay a reported security issue as "theoretical". At this point you are inviting someone to prove you wrong - often without the benefit of responsible disclosure.
  5. Provide the public with honest and frequent updates. Forthright communication goes a long way. A good incident response and communication plan can keep a bad situation from getting worse. A bad plan; however, can be a catalyst for negative press in addition to the issue at hand.
The security community can be a wonderful group of talented researchers. In many cases they are working out of intellectual curiosity and want to help companies when they've found flaws. However, dismissing those efforts or pushing them to the back burner can have devastating effects.

In the end, if you are asking users to trust their data with your company then make sure to hold up your end of the bargain - take security seriously and prioritize efforts whenever a security concern arises.

*** Update ***
Snapchat has recently issued a blogpost indicating they plan to allow users to opt-out of the find friends feature, provided they've validated ownership of their phone number. An opt-out approach is unfortunate since users will be vulnerable and exposed by default.

Snapchat also more clearly documented the method for security researchers to contact them at All companies should maintain security@<theircompany>.com

-Michael Coates - @_mwc

Monday, December 30, 2013

The Target breach, Encrypted PINs, and Customer Safety

On Friday I sat down with Jon Erlichman on Bloomberg West to discuss the recent Target breach, what we know, and what risks face consumers.
Timeline of events & what we know
Encryption of PINs
On Friday, December 27th Target revealed that the encrypted PINs had been compromised. The press release includes a few important statements:
  1. Target doesn't have the decryption key - "Target does not have access to nor does it store the encryption key within our system. The PIN information is encrypted within Target’s systems and can only be decrypted when it is received by our external, independent payment processor."
  2. Triple DES encryption - "PIN is encrypted at the keypad with what is known as Triple DES"
  3. Target claims customers are safe - "We remain confident that PIN numbers are safe and secure" and "debit card accounts have not been compromised due to the encrypted PIN numbers being taken" 
Are customers safe?
I'm not surprised to see Target attempting to calm customers' fears with their statements about the security of the PINs. However, I'm not convinced I'd support their optimism of safety.  Triple-DES encryption, when used correctly, does provide strong encryption and it would be infeasible to brute force the encryption key. However, even in an ideal use case there are several weaknesses to Triple DES that could impact the effective strength.

What could go wrong with Triple DES?
But, when used incorrectly Triple DES may only provide the illusion of security for these PINs. Here are two scenarios that could put PIN data immediately at risk:
In these situations the encrypted output would be the same if the input (i.e. the PIN) is the same. This allows attackers to perform analysis of the encrypted PIN data and compare the results with frequency analysis of PIN selection to make reasonable guesses about which encrypted value matches to what original PIN. In other words, if the most common encrypted value is "51 91 ca 27 be 68 c2 21" then there's a really good chance the original PIN for those users is 1234.

Other indications of concern
Another reason to be cautious about the safety of breached users is the actions taken by Chase. In the height of the Christmas season Chase bank changed limits for all impacted customers. This may be a cautionary move by Chase with memories of the 2009 RBS WorldPay attack that resulted in the loss of $9 million in a matter of hours. However, such a decision made in the prime spending hours of Christmas must have been thoroughly discussed and had supporting information justifying their concerns.

Lastly, we don't know what other information will be uncovered during the investigation, or worse, won't be uncovered because the investigation can't detect it. Target themselves initially reported that PINs were safe and unaffected only to later find out, as their investigation continued, that the encrypted values were stolen.

Advice to Customers
My advice for customers involved is to proactively request new debit cards. Credit card fraud can be easily reversed but debit card fraud can result in inaccessibility to lost funds for a period of time during the dispute.

-Michael Coates - @_mwc