Hacker News new | ask | show | jobs
by graystevens 3306 days ago
The recent update from Krebs gives some interesting details into how the attack took place, something we don't get to hear very often:

“Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it.”

Credit where credit is due, that's a pretty quick response time for data breaches, which are normally quoted as being discovered in an average of 30 or so days.

However the fact people's information can be decrypted from this breach is awful. Sounds a lot like the private key to decrypt this information was stored alongside the data in the database... whoops! That's like storing the clear text password. Let's hope the decrypted information contains strongly hashed passwords, but I'm not holding my breath.

3 comments

> Sounds a lot like the private key to decrypt this information was stored alongside the data in the database... whoops!

Not necessarily, even if this was done "properly" there is no guarantee that from the internal network there wasnt a separate exploit that the attacker could use to gain access to a different node which had the key in memory. With breakages like these you generally have to assume that anything that is theoretically possible has happened.

Eerily similar to the controversial Instagram bug last year:

Post: http://www.exfiltrated.com/research-Instagram-RCE.php

Discussion: https://news.ycombinator.com/item?id=10754194

Leak your cloud provider keys, leak everything. These should be kept under close scrutiny and locked down as much as possible.

Think about a single-sign-on service: by definition, the service would have the ability to generate/access tokens that would grant a user access to other applications. Therefore, a breach in any kind of SSO service would result in granting access to people's information -- no decryption needed!
That's true, but the SSO service itself can run on the users computer, so there is no need for the service to be able to decrypt the users data, only for it to be able to persist encrypted data.