4 ms·
It looks more like they had all the jupyter notebooks for all customers sitting side by side, and each notebook had a master key for the related DB. ...but due
by wokwokwok 5y ago
It looks more like they had all the jupyter notebooks for all customers sitting side by side, and each notebook had a master key for the related DB.
...but due to a poor deployment strategy, the instances were not sandboxed from each other.
(and yes, you would be correct in thinking that was a catastrophic failure; it's like having a folder with a directory per customer and a master access key in each folder, and WOOOPS, didn't realize people might look at ../Amazon/master_key.txt
It's pretty hard to brush this one off; it's a colossal screw up)
- shirt 5y agoYou got it :)
- onionisafruit 5y agoSeveral people had to have thought it was a good idea to add the jupyter notebook service with the primary keys to every cosmosdb instance even though a tiny portion of customers would ever even look at it. Yet it’s still fine to add that extra attack surface. I’ve seen some azure documentation that stresses you should never ever use your primary keys in a deployed service. Yet they do it willy nilly.
- scns 5y agoInsecure by default by opt-in security and a "should never" allready guarantees that it will happen IMHO.
- stonepresto 5y agoThey seemed to be sandboxed to some extent, the researchers mention a privesc which could either be user -> root and then accessing other users accounts, or it could be a sandbox escape through the hypervisor to the host and a pivot from there. Regardless, shouldn’t be possible. You see the former with a lot of “online Python interpreter” sites.
- tyingq 5y agoIt read somewhat like there was a separate DB with everyone's credentials in it and some api call to get your own credentials...with an unintended way to change the parameters from cred_get("me") to cred_get("arbitrary_account").