It’s been an absolute horror for me to watch the drama unfold after Ashley Madison’s hack. The website that encourages people to cheat on their spouses has been hacked and the data has been dumped into the public domain. It exposed private/intimate lives of lot of people and it could potentially have unimaginable consequences for the people involved.
The Toronto based company Avid Dating Life, the parent company of Ashley Madison, is being hit with $578 million class action law suit, that may very well drive it to the doors of bankruptcy. This is the worst nightmare of the software development team, who must be kicking themselves right now. There’s no greater shame for developers than to having their application breached and have it’s data exposed to the world.
People developing high profile public applications have one important job : To develop an application that follows the commonly agreed best practices of software development, offer highest level of security, to protect their users data from external threats without sacrificing user experience. The developers of AshleyMadison.com failed spectacularly at this. Not only did they have horrible security practices, which any competent hacker could exploit, they were also making money off of their customers by offering them phony features (like deleting their account from the system, if they paid $19) that simply weren’t implemented.
Shady business practices aside, as a developer who specializes in developing security based applications, I’m more interested in the technical aspects of their vulnerabilities.
- How exactly did the hackers break into the website?
- What kind of vulnerability did they exploit?
- Is it the incompetence of the Ashley Madison’s developers or is it the brilliance of the hackers from the Impact Team?
- What is the motive behind the attack?
It turns out, AM has pissed off a bunch of guys who were morally outraged with it’s behavior. It was relatively easy to break into the system and walk away with tera-bytes of data. There were no monitoring systems in place that alerted the admins. The hacking team was there in their systems for weeks ripping off data and nobody noticed. Here’s what they had to say : “For a company that built it’s business based on secrecy, it’s like they didn’t even try”. There were gaping holes in it’s security implementation and their admins committed a cardinal sin of using passwords that are easy to crack using brute force methods.
While it might take longer for us to know the full details of how exactly they attacked, the hackers from Impact Team shared some of the details with the Motherboard ( an online magazine ).
“We worked hard to make fully undetectable attack, then got in and found nothing to bypass… Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers”.
WTF, Really? “Pass1234” to VPN to root on all servers??? What exactly were they thinking? Didn’t they know they could have some pissed off customers who could try to attack? What about ‘Two Factor Authentication’? That was a disaster waiting to happen. As the folks at Ashley Madison stare at their inevitable law suites and potential bankruptcy, let’s take a look at some of the things they could’ve done that would’ve prevented this mess.
- Access to critical systems should never have ‘easy to remember’ passwords. Not even if it’s behind a firewall or in a Virtual Private Network. Always generate a strong password that’s very difficult to memorize. You can always using password managers and SSO applications to remember passwords for you.
- Always use https (ssl) for web traffic inside and outside the firewall.
- The access control system should automatically remove access to people who no longer require access (ex., ex employees)
- Have ‘Two Factor Authentication’ for all critical systems. It could done in a number of ways. Most common way is to have a dongle with OTP (one time password) that expires every 60 seconds.
- Logging into a network from internet should always ask for second factor authentication.
- Application should be checked for vulnerabilities like SQL Injection, Session Hijacking, etc.,
- Web applications should enforce HTTP Only and Secure Cookies.
- Applications need to mitigate XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery)
- Never expose sensitive data directly over the web.
- Your public facing website or API should never access the database or other data stores directly.
- Never store sensitive information in the cookies, memory or HTML storage.
While this is not an exhaustive list of things that needs to be addressed, it’s a good starting point. 99% of the attacks could be avoided if the applications follow the above mentioned security practices.
A little bit of due diligence from the users will also go a long way in protecting their privacy too. If you are going to be cheating on your spouse online, why use your real name and email?
