Ashley “100% discreet” Madison’s security, before its breach, was as flimsy as tissue paper, according to a new report.
A joint investigation by Canada’s Privacy Commissioner and the Australian Information Commissioner has found that the security fails leading up to the July 2015 breach and subsequent online dumps of user data and related extortion attempts included these:
- A fictitious trustmark icon on its home page to reassure users.
- Storage of encryption keys in regular text files that were easy to spot.
- Sending passwords in plaintext in emails.
- Inadequate authentication for employees accessing systems remotely.
- Storing a “shared secret” (a common passphrase used by all VPN users) for how to access systems remotely on the company’s Google drive, meaning it was available to anyone, anywhere, who could access an employee’s drive on any device.
A recap: sometime last year, attackers stole some 36 million user accounts from Ashley Madison, a site for cheaters run by Avid Life Media (ALM, which recently rebranded itself as Ruby Corp.).
After the breach was discovered in July 2015, the attackers went on to publish a 10GB dump of user details. Then, they followed up with a 20GB dump.
The investigation into Toronto-based ALM’s practices focused on four key areas: information security, retention and deletion of user accounts, accuracy of email addresses, and transparency with users.
The investigators found that ALM’s network protections did in fact include encryption on all web communications between the company and its users.
However, the encryption keys were stored as visible, plainly identifiable text on ALM’s systems, leaving any encrypted information at risk of being disclosed.
As far as those so-called trustmarks go, the investigators found that at the time of the breach, the Ashley Madison homepage included various stamps that suggested a high level of security, including a medal icon labelled “trusted security award.”
That mark was completely fabricated and self-bestowed, ALM officials later admitted before removing it. The Privacy Commissioner of Canada, Daniel Therrien, said in a statement that this means Ashley Madison’s users never properly gave consent:
The company’s use of a fictitious security trustmark meant individuals’ consent was improperly obtained.
The report, which was released this week, found that ALM violated privacy laws in both Canada and Australia.
ALM’s storage of passwords in plaintext in emails and files is a bit of a surprise: originally it was thought that Avid stored passwords correctly, as in, not at all.
Rather, the company supposedly only kept hashes created by passing users’ passwords through a key derivation function (in this case bcrypt).
That part is true, according to the report. Passwords were hashed using bcrypt, with the exception of some legacy passwords that were hashed using an older algorithm.
In sum, Ashley Madison dropped the ball on some pretty basic stuff.
Marc Dautlich, an information law expert at Pinsent Masons, had this to say to the BBC:
Ashley Madison’s shortcomings were generally avoidable through relatively straightforward measures. And the cost of the consequences which it has now incurred are far greater than the cost of prevention would have been.
Both the Canadian and Australian commissioners issued a number of recommendations aimed at helping Avid get into compliance with privacy laws.
What’s more, they published takeaways that all organizations can use.
Those recommendations are worth a look. The commissioners cover everything from multifactor authentication, the importance of documented security policies and procedures, and how inadvisable it is to pull your own security certificate out of thin air.
We’re assigning a Sophos Naked Security Registered Trademarked Copyrighted-in-our-own-minds “Amen!!!” to that!
LonerVamp
Just glancing through the Information Security section of those findings, this reads no different than most organizations of ALMs apparent size or revenue base, and of those even larger. Few real policies, some misunderstandings about security value, poor practices on individual user/admin level here and there, lacking detection. Other than that fake security seal on the site, nothing seems out of the ordinary, sadly.
Knowing nothing more than what I read in those sections, I sort of feel bad for that very new Director of Security (DoS) they had apparently recently hired. Breach discovered July 2015, DoS hired “mid/early 2015,” and the breach having been around for several months prior to being discovered. It’s unfortunate that DoS was replaced subsequently by a CISO. Even the findings made mention that detection mechanisms likely wouldn’t have worked based on how the attacker had gotten in. (Or maybe not; maybe they were awful, but it seems to me he/she had almost no time to make meaningful change.)
The only questions it leaves for me was how someone was able to spoof a Toronto IP address to get into the VPN. Wouldn’t the packets return back to that fake IP address rather than the proxy the attacker used? I’d also question whether these findings themselves truly indicate a sophisticated, targeted attack or not (i.e. opportunistic). Probably would need to know more about how the victim employee was targeted.