How to Detect Cloud Storage Misconfigurations to Protect Valuable Data

Originally published by CrowdStrike.

Written by Ciaran O'Brien and Matt Johnston, CrowdStrike.

Cloud storage misconfigurations continue to become more prevalent and problematic for organizations as they expand their cloud infrastructure, driving the importance of technologies such as cloud security posture management (CSPM) as crucial tools for protectors everywhere.

Consider the recently reported public exposure of data associated with some Microsoft customers and prospects. The data leak was publicly reported Oct. 19, 2022, by Microsoft and SOCRadar, whose security researchers discovered the leak and reported it to Microsoft on Sept. 24. Microsoft reconfigured the storage bucket, identified as Azure Blob Storage, “within several hours” of being notified, making it “no longer publicly accessible,” SOCRadar reported.

According to Microsoft, “The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability” and there was “no indication customer accounts or systems were compromised.”

As organizations continue to adopt such cloud data storage services and expand their cloud infrastructure, the risk of misconfigurations is poised to grow — potentially leaving valuable resources exposed to threat actors. Here, we dive into this issue and what can help.

Cloud Storage Misconfigurations

Cloud-based data storage is a favorite target of threat actors who seek organizations’ valuable data to achieve their goals, whether they include espionage — an attempt to gather data about the target for use in future attacks — or monetary gain. While cloud service providers (CSPs) offer services to enable scalable data storage solutions and integrations with other services, the risk of exposing data to unauthorized parties through misconfiguration remains high.

Azure Blob Storage is one example of such storage services which can, if desired, integrate with SQLServer by acting as a backup destination for databases. The service provides a number of configuration settings to increase the security posture of storage Blobs. As the recent report by SOCRadar suggests, organizations using these services would do well to ensure these configurations are consistently monitored and enforced in their environments. This can be difficult to achieve, however, particularly as environments scale and you begin adding complexity through integrations such as SQLServer backup, as in this reported instance.

Read on to learn some best practices. First, we’ll overview the risk that misconfiguration poses to organizations.

How a Threat Actor Could Exploit Misconfigurations

Here, we describe a potential attack scenario involving the following components, all of which were factors in the recent scenario SOCRadar reported:

1. Misconfigured, publicly accessible Azure bucket
2. SQL servers backed up in said Azure bucket which contain unencrypted data at rest
3. Additional Azure buckets accessed with information retrieved from SQL server backups

The following steps outline how a threat actor might exploit such a situation for malicious gain. It’s important to note this is a generalized and hypothetical scenario.

1. Recon:

The first step in an attack exploiting these weaknesses is understanding the different levels of public accessibility. In the case of Azure Storage Blobs, anonymous public accessibility permissions can be granted at the container or the blob access level.

The container access level allows an anonymous client to make requests to containers enumerating the blobs they contain as well as to individual blobs, accessing their content or metadata. A threat actor only needs to know a storage account name and a container name to enumerate content within these blob storages.

In contrast, the blob access level only allows requests to individual blobs for their content meaning a threat actor also needs to know the name of individual blobs ahead of time to access them.

At this point a threat actor would likely perform some general reconnaissance on the target with the goal of defining wordlists containing likely names of storage accounts, containers and blobs. To discover targets of opportunity, threat actors might scan public DNS records to find active storage accounts, based on common naming conventions used for domains, such as <storage_account_name>.blob.core.windows.net.

2. Enumeration:

The second step is enumeration. Though this can be achieved by simply visiting the blob URLs directly in the Azure portal, we will walk through a programmatic method as enumeration is often scripted.

In a case where the access level is set to container, a threat actor can iterate through a wordlist of storage account names and container names making GET requests to the list blobs API that Microsoft provides for Azure.

curl 
“https://{storage_account_name}.blob.core.windows.net/{container_name}?restype=container&comp=list”

This request with the comp=list query parameter returns XML data that can be parsed to retrieve a list of Blobs within the container.

<?xml version="1.0" encoding="utf-8"?>
<EnumerationResults ContainerName="https://{storage_account_name}.blob.core.windows.net/{container_name}">
 <Blobs>
  <Blob>
   <Name>backup1.bak</Name>
   <Url>https://{storage_account_name}.blob.core.windows.net/{container_name}/backup1.bak</Url>
   <Properties>
    <Last-Modified>Mon, 31 Oct 2022 20:17:14 GMT</Last-Modified>
    <Etag>0x8DABB7CE67F8660</Etag>
    <Content-Length>15</Content-Length>
    <Content-Type>text/plain</Content-Type>
    <Content-Encoding />
    <Content-Language />
    <Content-MD5>4ZwSg8klsyBmhf9SKs/j5g==</Content-MD5>
    <Cache-Control />
    <BlobType>BlockBlob</BlobType>
    <LeaseStatus>unlocked</LeaseStatus>
   </Properties>
  </Blob>
  <Blob>
   <Name>backup2.bak</Name>
   <Url>https://{storage_account_name}.blob.core.windows.net/{container_name}/backup2.bak</Url>
   <Properties>
    <Last-Modified>Wed, 02 Nov 2022 17:21:08 GMT</Last-Modified>
    <Etag>0x8DABCF6A1682309</Etag>
    <Content-Length>0</Content-Length>
    <Content-Type>text/plain</Content-Type>
    <Content-Encoding />
    <Content-Language />
    <Content-MD5>1B2M2Y8AsgTpgAmY7PhCfg==</Content-MD5>
    <Cache-Control />
    <BlobType>BlockBlob</BlobType>
    <LeaseStatus>unlocked</LeaseStatus>
   </Properties>
  </Blob>
 </Blobs>
 <NextMarker />
</EnumerationResults>

On the other hand, if the access level is blob, a threat actor would need a third wordlist containing possible blob names. They could then iterate through all three wordlists making HEAD requests to the get blob properties API.

curl 
-I “https://{storage_account_name}.blob.core.windows.net/{container_name}/{blob_name}”

If the blob exists, this endpoint returns a status code of 200 and some HTTP headers containing blob metadata.

HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/plain
Content-MD5: 1B2M2Y8AsgTpgAmY7PhCfg==
Last-Modified: Wed, 02 Nov 2022 14:14:03 GMT
ETag: 0x8DABCDC7EC99D24
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 22ce96f8-901e-0029-50c8-eede8a000000
x-ms-version: 2009-09-19
x-ms-lease-status: unlocked
x-ms-blob-type: BlockBlob
Date: Wed, 02 Nov 2022 14:35:38 GMT

If the blob doesn’t exist a status code of 404 is returned with the message “The specified blob does not exist.”

HTTP/1.1 404 The specified blob does not exist.
Transfer-Encoding: chunked
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: eb2b2339-801e-00a3-6ac8-ee853b000000
x-ms-version: 2009-09-19
Date: Wed, 02 Nov 2022 14:35:43 GMT

While more cumbersome, a threat actor could enumerate existing blobs by making these requests and recording those that return status codes of 200.

3. Data Exfiltration:

Once the publicly accessible blobs are discovered and enumerated, they can be downloaded and their contents inspected via get blob requests.

curl 
“https://{storage_account_name}.blob.core.windows.net/{container_name}/{blob_name}”

The response body of this request will contain the contents of the blob.

4. Further Enumeration and Exfiltration:

In this reported case the downloaded blobs contained unencrypted SQL Server backups. Database backups often contain sensitive information; if they are unencrypted, all it would take for the threat actor to access their data is the use of SQL statements to read and retrieve the stored information just as an authorized administrator or data owner would. Upon inspection of the backups, fields are discovered referencing further publicly accessible Azure Blob Storages that were unknown to the threat actor. At this point, the threat actor can repeat the enumeration and exfiltration of these newly discovered Azure Blobs which might contain further sensitive information.

Best Practices for Configuring Azure Blob Storage

As a baseline for protection, we recommend implementing the following essential controls when using Azure Blob Storage services:

• Apply access control lists (ACLs) to restrict access to files or directories in storage to certain security principals (users, groups or application service principals)
• Apply storage networking firewalls to restrict access to only authorized IP spaces or virtual networks (never allow access from the entire public Internet unless that fits your intended use)
• Apply authorization methods to restrict access to only authorized users or services, and refrain from enabling anonymous access unless that fits your intended use
  • Shared access signatures can often fill the need for temporary anonymous access in a more secure way
• Leverage encryption at rest and in transit to secure the data from unauthorized view

Note: Because threat actors who gain access to user accounts that can manage these settings may modify them to create exposures they can leverage externally, We also recommend you:

• Leverage Azure storage role based access control (RBAC) to restrict unauthorized users from changing configurations
• Continuously monitor the configuration state of these protections to ensure they remain intact

In its investigation, SOCRadar discovered additional publicly accessible Azure Blobs by analyzing some unencrypted SQLServer backups found in the initial blob. To prevent this from happening, we recommend not only ensuring your Azure Blob Storage configuration is secure but also securing the configuration of any services that interact with Azure Blob. As unencrypted SQLServer backups were relevant in this case we recommend the following:

• Apply transparent data encryption for SQL databases to encrypt data at rest within SQL databases, transaction log files, and associated SQL database backups

Conclusion

Threat actors have proven to show a continued interest in gaining access to the information stored by cloud services. By leveraging security standards and monitoring solutions like those described above, protectors of this data can work to ensure it remains secure, to stop the breach from happening.