Skip to main content

Business information leak - Azure

Need​

Protection of customer data and prevention of unauthorized access

Context​

  • Usage of Terraform for Infrastructure as Code (IaC)
  • Usage of AzureRM for managing Azure resources programmatically

Description​

Non compliant code​

provider "azurerm" {
  version = "=2.40.0"
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_storage_account" "example" {
  name                     = "examplestoracc"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  
  allow_blob_public_access = true
}

The above Terraform code creates an Azure resource group and a storage account within that group. The issue lies in the allow_blob_public_access attribute of the azurerm_storage_account resource. This attribute is set to true, which means that the blobs within this storage account are accessible to the public.

The allow_blob_public_access attribute controls whether or not public read access is allowed for the blobs in this storage account. If this is set to true, then anyone with the URL of the blob can access it.

This is a serious vulnerability because it could potentially allow unauthorized users to access sensitive business information stored in the blobs. This is especially dangerous if the storage account contains information from multiple customers, as the access would not be limited to a single customer's data.

This vulnerability could be exploited by malicious users who are aware of the public access setting and have the blob URLs. They could access the blobs, read the data, and potentially use it for malicious purposes.

Steps​

  • Disable public access to the storage account
  • Implement access controls to restrict user access to sensitive data
  • Regularly rotate privileged credentials
  • Implement strong authentication mechanisms for user login

Compliant code​

provider "azurerm" {
  version = "=2.40.0"
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_storage_account" "example" {
  name                     = "examplestoracc"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  
  allow_blob_public_access = false

  network_rules {
    default_action             = "Deny"
    virtual_network_subnet_ids = [azurerm_subnet.example.id]
    ip_rules                   = ["100.0.0.1"]
  }
}

resource "azurerm_virtual_network" "example" {
  name                = "example-network"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "example" {
  name                 = "example-subnet"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefix       = "10.0.1.0/24"
}

The updated code includes several changes to address the vulnerability:

  1. allow_blob_public_access is set to false to disable public access to the storage account. This ensures that the data stored in the account is not accessible to the public.

  2. A network_rules block is added to the azurerm_storage_account resource. This block includes a default_action of "Deny", which means that all requests are denied by default. Only the requests that match the rules specified in the ip_rules and virtual_network_subnet_ids are allowed. This is a form of access control that restricts user access to sensitive data.

  3. A azurerm_virtual_network and azurerm_subnet resources are created. The virtual_network_subnet_ids in the network_rules block includes the ID of this subnet. This means that only the requests from this subnet are allowed.

Please note that this is a basic example and you might need to adjust the ip_rules and virtual_network_subnet_ids according to your needs. Also, remember to regularly rotate privileged credentials and implement strong authentication mechanisms for user login to further enhance the security.

References​

Last updated on