About Azure Blob Containers

Azure blob is a Microsoft object service optimized for storing large amounts of unstructured data. Data is stored inside blobs grouped into containers that, in turn, are tied to a user’s storage account. 

There are three types of blobs:

• Block blobs store data in the form of blocks. They’re ideal for storing text and binary data. The maximum size of a block blob can be 190.7 tebibytes (TiB).
• Append blobs are also a collection of blocks, but are fine-tuned for frequent append operations. These are typically used for writing and maintaining logs. 

• Page blobs are composed of 512-byte pages and can store up to 8 TiB of data. Page blobs are optimized for fast read/write operations.

Blobs provide an efficient way to host and serve data over HTTP/HTTPS. Blob objects can be accessed using Azure PowerShell, Azure CLI, Azure Storage REST API, or a client library (available in .NET, Java, Go, PHP, Node.js, Ruby, and Python).

To start uploading blobs, you first need to create a container to house them. You can think of a container as a folder on your file system, with blobs being actual files. A container can be created directly from the Azure portal using a storage account.

Cloud Risk Description

Any client can read data in a blob container configured for public access. Avoid this unless expressly needed; make sure you don’t select Allow public access when creating a blob container. Such incorrect configuration could allow malicious actors to anonymously access the container blobs without requiring a shared access signature. For more information, view the Microsoft Azure documentation on this topic.

How Orca Helps

Orca can detect when a blob public access setting allows anonymous read access, and alerts on this issue (see screenshot).

Orca further detects sensitive data at risk across both the workload and control plane, pinpointing the exact location and providing masked data samples for quick remediation. It also leverages context such as location and accessibility of assets containing the data.

Related Risks

• Default network access rule for storage accounts is not set to deny: Access to a storage account can be granted to traffic from specific Azure virtual networks as well as public IP address ranges. Not restricting default network access can leave an avenue for attackers to potentially gain access to sensitive data.
• Azure storage account without private endpoint and firewall configured: When a storage account is configured as Public, attackers can potentially access sensitive information contained within. In general, the option should be set to Private unless absolutely necessary to do otherwise.

Recommended Mitigation Strategies

• 

  For all storage accounts, ensure that Configuration ➤ Blob public access is set to disabled.

• 

  Ensure Public access level is set to Private for all containers.

• 

  Regularly audit for any storage accounts or containers that allow public access.

• 

  Use shared access signature tokens to provide restricted access to blob containers.

Useful Links

• Naming and Referencing Containers, Blobs, and Metadata: https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata
• Create a storage account: https://docs.microsoft.com/en-us/azure/storage/common/storage-account-create
• Quickstart: Upload, download, and list blobs with the Azure portal: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-portal
• Overview of Azure page blobs: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-pageblob-overview?tabs=dotnet
• Scalability and performance targets for Blob storage: https://docs.microsoft.com/en-us/azure/storage/blobs/scalability-targets
• Tutorial: Upload and analyze a file with Azure Functions and Blob Storage: https://docs.microsoft.com/en-us/azure/storage/blobs/blob-upload-function-trigger?tabs=azure-portal
• Data protection overview: https://docs.microsoft.com/en-us/azure/storage/blobs/data-protection-overview