Business information leak - Azure - Azure

Need

Protection of customer data and prevention of unauthorized access

Context

1. Usage of Terraform for Infrastructure as Code (IaC)
2. Usage of AzureRM for managing Azure resources programmatically

Description

Insecure Code Example

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

1. Disable public access to the storage account
2. Implement access controls to restrict user access to sensitive data
3. Regularly rotate privileged credentials
4. Implement strong authentication mechanisms for user login

Secure Code Example

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

2023/09/18