BrowserStack attack post-mortem

You what? You said hashed passwords and email addresses were taken for 5K users. What does "wholly intact" mean?

> All user passwords are salted, and encrypted with the powerful bcrypt algorithm, which creates an irreversible hash which cannot be cracked. However, as an added precaution, we suggest that users change their BrowserStack account passwords.

Those 5K passwords are compromised. It isn't an "added precaution" it is a mandatory requirement. The whole point of bcrypt is to buy you time to change your password, they have misunderstood that and think bcrypt is "unbreakable" so people don't need to change passwords. That's super ignorant.

I would expire all 5K users (or ALL users) passwords immediately and send them recovery emails.

Ouch! This is why you must practice the principle of least privilege when provisioning access keys, especially ones that can control your entire infrastructure.

> He was then able to run an instance inside our AWS account using these credentials, and mount one of our backup disks.

Good security practices are like an onion ... it's got many layers and will most likely make you cry.

This is why you should be encrypting your backups. The backup program doesn't even need to be able to read the backups it creates, it only needs to to be able to write them (i.e. the public half of the key).

If you're thinking, "Why does that matter? It can already read the plain-text data it's backing up!" then you're not thinking about history or multiple servers. Each may be able to read the current state of its own file system, but if they only have the public half, they can't read the historical state or each other's backups. The damage would be limited to a single server and only what's live on it at that moment.

> We were able to verify the actions of the hacker using AWS CloudTrail, which confirmed that no other services were compromised, no other machines were booted, and our AMIs and other data stores were not copied.

CloudTrail is awesome and if you're on AWS you really should enable it. It costs peanuts compared to what it provides. In cases like this, where the attacker takes over your entire infrastructure, it may be the only log you have of what happened.

I appreciate that they're trying to communicate the strength of bcrypt, but this is more than a bit hyperbolic.

> He began to copy one of our tables, which contained partial user information, including email IDs, hashed passwords, and last tested URL. His copy operation locked the database table, which raised alerts on our monitoring system.

How does a copy operation lock a database table? Because you set thresholds on the number of reads? I find it a little surprising that such a knowledgeable hacker would make such a rookie mistake. Can someone clarify?

I doubt they have the hackers real IP. The hacker was almost certainly using a proxy right? Even if they have an IP address of the hacker, what is the likelihood of tracking it down to a physical person?