3 ms·

How can CosmosDB's architecture and design make it possible to have a read-write key that works on all customers' databases? Yikes!

• buitreVirtual 5y ago
  I think each database has its own key, but all keys were accessible via Jupiter Notebook.
• zeusk 5y ago
  because there isn't. There's a vulnerability in some jupyter notebook implementation allowing them access to unrelated notebooks which hold read/write keys to database they're connected to.
• 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 ago
    You got it :)
  • onionisafruit 5y ago
    Several 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 ago
      Insecure by default by opt-in security and a "should never" allready guarantees that it will happen IMHO.
  • stonepresto 5y ago
    They 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 ago
      It 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").
• dharmab 5y ago
  When I was working with Azure Queue Service years ago, the way for my service to get delegated read-only access to a queue was: 1. My service's users would have to grant my service permission to read all access keys for the queue 2. My service would look through the access keys and try to find one matching some conditions (specific provided name and read-only) 3. If it couldn't find a limited one (which it would not in pretty much every real case due to the defaults) it would grab any read/write key and use that (Later, we used Managed Identity when that became available, which avoids the song-and-dance but also has performance issues with very large scale sets. Out of the frying pan...) I'm wondering if Jupyter had similar ability to read the primary r/w key for every database that had it enabled.