ChaosDB vulnerability and Azure Blob storage.

Probably by now you all have heard about CosmoDB vulnerability thru Jupyter notebooks, right?

If not here is a recap. From the security researchers at Wiz they found a hole from Jupyter-notebooks allowing a full access to CosmoDB databases.

“Rather, a series of flaws in a Cosmos DB feature created a loophole allowing any user to download, delete or manipulate a massive collection of commercial databases, as well as read/write access to the underlying architecture of Cosmos DB.

We named this vulnerability #ChaosDB. Exploiting it was trivial and required no other credentials.”

You can read their investigation from their website https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases

All tough this a really major thing for customers with CosmoDB’s, it was a great find from WIZ.IO and Microsoft reacted insanely quick to fix the hole.

“Microsoft’s Security Team deserves enormous credit for taking immediate action to address the problem. We rarely see security teams move so fast! They disabled the vulnerable notebook feature within 48 hours after we reported it. It’s still turned off for all customers pending a security redesign.”

So just rotate your keys are you are probably safe from now on. Just monitor the traffic in activity in our DB’s for malicious activities example with Azure Monitor to monitor control plane operations. https://docs.microsoft.com/en-us/azure/cosmos-db/audit-control-plane-logs

And implement security features https://docs.microsoft.com/en-us/azure/cosmos-db/database-security

And like WIZ.IO said “Nearly everything we do online these days runs through applications and databases in the cloud.”

That is true and with Azure Blob storage it’s the same. There is keys also for giving access, also Primary and a Secondary.

You don’t want these keys to publicly distributed.

You can store these keys in Azure KeyVault https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#use-azure-key-vault-to-manage-your-access-keys

And use Shared Key authorization for access the data

And also if you want you can use Shared Access Signature (SAS) https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview

to give time-based and role-based access to the storage. The following SAS roles can be used.

  • User delegation SAS
  • Service SAS
  • Account SAS

More info on docs.microsoft.com https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview

Blog storage contains what ever files you put out there. If the name of the storage account is too descriptive it will expose your files to the public more easily because there are bots scanning blobs for public access and if they notice something like invoices or company based info, they will act.

Checkpoint research teams found 8/2020 out that Clustered blob-storage is public by default.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168363

And Microsoft reacted on this posting recommendation on Azure website.

https://azure.microsoft.com/en-au/updates/choose-to-allow-or-disallow-blob-public-access-on-azure-storage-accounts/

Like MSFT stated, public access doesn’t give access to our data, but your container will be found relatively easy. And that will expose you to a target for them bad people.

CyberArk made a tool for assessing your access levels https://github.com/cyberark/blobhunter

It’s a Python script, so now it’s time to try out WSL in action if you haven’t done so already https://pbpython.com/wsl-python.html

WSL is just excellent, you can natively run two two kernels within our hardware, but in separately if you want or can connect to and from Linux and Windows shares. Maybe this a the next chapter for my blog.

Back to blobs, Microsoft has best practices (like they always do) for Blob storage https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations and in these recommendations there a mention about Defender for Storage, how many of you have heard about it?

You can enable it thru Azure Security Center.

And also from the Storage Accounts settings directly.

More information in MSFT Docs https://docs.microsoft.com/en-us/azure/storage/common/azure-defender-storage-configure

When You enable it, you can monitor the unlawful access within Azure Security Center or get alerts triggered based on rules.

https://docs.microsoft.com/en-us/azure/security-center/alerts-reference#alerts-azurestorage

Defender for Storage isn’t free but it could save our data and your day. For European customers and in Euros it’s it.

and on top of that one the Storage (with the setup below) itself with Azure pricing calculator makes this much.

So what is a transaction

All read and write access against the storage is a transaction, deleting files, adding, modifying.

Default block size is 4MB, so 4 * File size equals to the transactions amount that you have to consider when calculating running costs.

If you buy storage, lists your needs based on DR, usability and company policies and then estimate and add the protection to it. Because you don’t wan’y your organization to a part of these findings by CyberArk https://www.cyberark.com/resources/threat-research-blog/hunting-azure-blobs-exposes-millions-of-sensitive-files

In the Microsoft Evergreen service there is never a dull day, always something new is coming up.

Hopefully this was helpful for you all, Stay safe and vigilant.

Over and out,

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *