Monday, November 18, 2013

Let's Chat at OWASP AppSecUSA

I'll be at OWASP AppSecUSA this week and am looking forward to all the great talks and activities. I'd also enjoy the opportunity to setup time to meet with others interested in security, web development, or just catching up.

Let's setup a time - Please send me an email at michael.coates@owasp.org or message me on twitter (@_mwc).

First drink is on me.




-Michael Coates - @_mwc

How Third Party Password Breaches Put Your Website at Risk

Every website compromise and password breach puts your website at risk even if your business is completely unrelated to the compromised site.

Which major website was compromised this week? How many user details and passwords were stolen?

Over the past few weeks the news was littered with stories of Adobe's compromise of millions of user records, MacRumors theft of 860,000 username and passwords and the compromise of numerous user passwords at Vbulletin.com.





Attackers Data Mine Compromised Passwords

Every time a major password breach occurs the compromised emails addresses and passwords are available for hackers or criminal enterprises to download and analyze. Unfortunately, the breached companies often improperly protect their passwords and as a result it is easy for hackers to obtain the original password for each user. Attackers will collect and store these compromised credentials and then use this information to take over the user's account anywhere else on the web where the user has reused the username and password.

Account Take Over is Distributed and Automated via Botnets

Armed with millions of email addresses and passwords from the breached website, attackers use these credentials to programmatically attempt to login to websites all over the web. This activity is not conducted by a single individual sitting at their computer and manually entering usernames and passwords. Instead criminal enterprises will leverage scripts, automation, and botnets to distribute the attack across many computers all around the world. This automation allows the attacker to cover their tracks by initiating the login attempts from real machines all over the world.

This type of attack is known as credential stuffing also called account takeover 

A real world example - How Facebook Is Protecting Their Users

Facebook was not compromised in any of these recent attacks; however, as a large target and an organization that is accurately aware of the risk of third party breaches, their security group took immediate action. Facebook mined the compromised data from the adobe breach to identify Facebook accounts that were potentially at risk. Facebook enabled additional security controls for any account within the adobe breach that used the same password on Facebook.


What You Can Do - Comparing Compromised Passwords with Your Web Applications Users Info

Here's how to check if users the password information within a data breach may put your users at risk. Note: This may not be realistic for an organization to perform due to the technical requirements and resources needed.
  1. Obtain the compromised user data - Download a data dump of the compromised information. This may take some searching but the information is available online.
  2. Determine the passwords associated with user email addresses - This step is straight password cracking. The work required will depend upon on the original method used by the website to protect their passwords. Unfortunately, in many cases the passwords are poorly protected with either encryption or a weak hash such as md5. The current best practice for password storage is bcrypt or PBKDF2. Read here to find out how sophos analyzed the adobe breach.
  3. Test Your User Passwords - Next we need to compare the compromised data with your web application's usernames and passwords. Important, this step does not require you to view the passwords of your users. Instead, we'll simulate the login process in your application to validate if the compromised password from the breached website matches the user in your web application. Here are the steps:
    1. Compare the usernames within the breached data (from step 1) with usernames in your web application. Note any matches. These are the accounts we want to test in your application.
    2. Work with your development team to identify the authentication routine for your web application. This will include a step where the password provided by the user is hashed and then compared against your data store of usernames and hashed passwords
    3. Build a script to perform the hash and database comparison. The purpose of using a script is to avoid having to manually interact with your website UX for each test.
    4. Take the list of impacted usersnames (from step 3.1) and their actual passwords (from step 2) and run them through the script (from step 3.3). If a login is successful then we've identified a reused password that is at risk.
  4. Protect your users - For any matches in step 3.4 you'll want to immediately take action to protect their account. This can include locking their account, forcing a password reset, or whatever actions are typically taken by your organization in the event of account takeover.
What You Can Do - Securely Store Your Passwords
Ensure you protect password data in your application by using an appropriate hashing algorithm. Approaches such as encryption, md5 hashing or any sort of home made manipulation are not sufficient. Instead you should use scrypt, bcrypt or PBKDF2. More information on password storage can be found at the OWASP Password Storage Cheat Sheet.



-Michael Coates - @_mwc

Friday, November 15, 2013

Support OWASP Outreach - Just a few moments today really helps



OWASP is a worldwide nonprofit organization with a mission of making application security visible for all. In short, we're trying to make the world a better place by providing free security resources and communities.

If OWASP has helped you or your organization please consider supporting our nonprofit. Here are a few ways to help:

  • Support our ThunderCloud outreach effort for AppSecUSA. This is totally free. 
    • If we reach 100 supporters ThunderCloud will send a single message via the supporters chosen option (facebook, twitter, etc). That's it and we can potentially reach 50k+ people. However, if we don't reach the minimum supports we get nothing.
    • https://www.thunderclap.it/projects/6403-hackers-hit-time-square-nyc
  • Attend OWASP AppSecUSA. The event is next week in NYC and will be the most concentrated group of application security professionals in the world. There is an amazing lineup of speakers and events
  • Support your local OWASP chapter. We have chapters in over 100 countries around the world. Find your local OWASP chapter here.
  • Consider supporting the OWASP foundation. We offer all of our resources, including owasp.org, for free. We'll  be able to continue offering these great items as a result of our supporters.



-Michael Coates - @_mwc

Tuesday, November 12, 2013

DevBeat - Developer First Security Integrating Security into Development

I presented to a great developer crowd today at VentureBeat's DevBeat conference in San Francisco. Here are the slides and a few pictures from the event.







-Michael Coates - @_mwc

Monday, November 11, 2013

Virtual Security Training Lab - Setup Instructions


Below are the setup instructions to configure a virtual security training lab that runs within an isolated virtual machine. Using this lab you can perform hands on security testing that leverage a variety of prominent application security flaws including those mentioned in the OWASP Top 10.

The lab requires the following software (all free):







-Michael Coates - @_mwc