2 things come to my mind why I am I posting this here:
I could imagine that there are devs (maybe even at Storj) using Lastpass, maybe even customers to organize their Storj account or bucket credentials.
I wonder if - if Lastpass would have used Storj as cloud service - such an incident could have been avoided or had somehow a lesser impact (In the past I had suggested, if password managers would be interesting clients given the Storj DCS architecture. ) or if ideas can be obtained from that incident, what features Storj could implement that such a breach could be less severe.
I am still using KeePass and haven’t found the time to upgrade to Bitwarden. Has someone a docker-compose file for Bitwarden that I can just copy and paste?
Unrelated to Storj, but unfortunately there is no other convenient alternatives in corporate use cases (centralized password management for distributed teams) without implementing some custom tools and spending time and resources to support it.
Bitwarden offers hosted solutions as well for businesses. LastPass has been going down the drain ever since they got acquired by logmein. Would definitely recommend switching to bitwarden even if you don’t choose to self host. Keeper also has solutions for corporate.
Alerting and logging was enabled during these events, but did not immediately indicate the anomalous behavior that became clearer in retrospect during the investigation. Specifically, the threat actor was able to leverage valid credentials stolen from a senior DevOps engineer to access a shared cloud-storage environment, which initially made it difficult for investigators to differentiate between threat actor activity and ongoing legitimate activity. Ultimately AWS GuardDuty Alerts informed us of anomalous behavior as the threat actor attempted to use Cloud Identity and Access Management (IAM) roles to perform unauthorized activity.
To access the cloud-based storage resources – notably S3 buckets which are protected with either AWS S3-SSE encryption, AWS S3-KMS encryption, or AWS S3-SSE-C encryption – the threat actor needed to obtain AWS Access Keys and the LastPass-generated decryption keys. The encrypted cloud-based storage services house backups of LastPass customer and encrypted vault data.
No, and I didn’t say that. But it is very interesting to learn, where Lastpass data is/was stored. In the past I had already suggested, to target those password managers as customers:
I still think it would be a nice fit.
But as always, there is a lot to learn from such an attack. For example it has now been mentioned, what 3rd party software was exploited:
According to a person briefed on a private report from LastPass who spoke on the condition of anonymity, the media software package that was exploited on the employee’s home computer was Plex.
The article mentions the logging capabilities that made it possible to detect anomalous behavior. I don’t know how that works on AWS but of course I am asking myself if something similar exists for Storj DCS.
And maybe such an incident is also a good time to ask how well the Storj satellites are secured against such an attack? It seems that an attacker could cause a lot of harm, if he gains unauthorized access to the satellites. And the question how well they are protected and secured against a similar attack, might be even something potential customers would ask themselves, before putting data on Storj DCS.
So there is a lot around this Lastpass incident, that can be interesting for Storj as well.