Thursday, July 17, 2014

Google's Project Zero

Google recently announced Project Zero, an initiative to “to significantly reduce the number of people harmed by targeted attacks“.  Project Zero is inverting the traditional bug bounty program and there are many positive elements to this new initiative. I'm a big proponent of bug bounty programs and worked with them closely at Mozilla (Mozilla created the first major bug bounty program for Firefox in 2004).

In addition to the positive elements I got a chance to also discuss some of the challenges Project Zero may face with Antone Gonsalves @antoneg at csoonline.com


Google bug-hunting Project Zero could face software developer troubles,
Antone Gonsalves | CSO | Jul 16, 2014



-Michael Coates - @_mwc

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
https://www.linkedin.com/today/post/article/20140417203003-8374308-avoiding-the-next-heartbleed

https://www.linkedin.com/today/post/article/20140417203003-8374308-avoiding-the-next-heartbleed




-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.

http://www.bloomberg.com/video/snapchat-data-breach-exposes-personal-info-9V9sSeFsSvWssezDGKnGQQ.html


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 http://lookup.gibsonsec.org/. 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 snapchatdb.info. 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 snapchatdb.info

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 security@snapchat.com. All companies should maintain security@<theircompany>.com



-Michael Coates - @_mwc