By default, you can use SSH keys stored in project metadata to access all Compute Engine instances in a project. This greatly expands the attack surface accessible to any compromised SSH key and violates the least privilege principle.

Example 1: The following example shows a Terraform configuration that permits project-wide SSH logins by setting block-project-ssh-keys to false in the metadata argument.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    block-project-ssh-keys = false
    ...
  }
  ...
}

Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

By default, the serial port of a Compute Engine instance is disabled for console access. Enabling serial console access can allow attackers to connect to the Compute Engine instance from any IP address because the serial port does not support IP-based access restrictions.

Example 1: The following Terraform configuration permits interactive serial console access by setting serial-port-enable to true in the metadata argument.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    serial-port-enable = true
    ...
  }
  ...
}

By default, the certificate-based authentication is disabled on new clusters that run GKE version 1.12 and later. With certificate-based authentication, a user presents a certificate that the Kubernetes API server verifies with the specified certificate authority. However, there is no way to revoke the certificate when the user leaves or loses the credentials. This makes the certificate-based authentication unsuitable for end users.

Example 1: The following example Terraform configuration enables GKE client certificate-based authentication by setting issue_client_certificate to true in the master_auth block.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    client_certificate_config {
      issue_client_certificate = true
      ...
    }
    ...
  }
...
}

By default, CloudTrail log file validation is disabled, which prevents investigators from confirming that there has been no external tampering with CloudTrail log files.

This enables an attacker with the necessary privileges to perform harmful configuration changes and hide them by modifying the CloudTrail logs.

Example 1: The following Ansible task sets up a CloudTrail configuration without log file integrity validation because the enable_log_file_validation parameter is missing.

- name: create a single region cloudtrail
  community.aws.cloudtrail:
    s3_bucket_name: mylogbucket
    s3_key_prefix: cloudtrail
    region: us-west-2

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following service provider configuration tells WebSphere to accept unsigned inbound timestamps:

<com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" >
...
        <securityRequestConsumerServiceConfig xmi:id="SecurityRequestConsumerServiceConfig_1211399165585">
          <addTimestamp xmi:id="AddTimestamp_1212094497592"/>
...
</com.ibm.etools.webservice.wsext:WsExtension>

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following service provider configuration tells WebSphere to send an unsigned timestamp:

<com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" >
...
  <securityResponseGeneratorServiceConfig xmi:id="SecurityResponseGeneratorServiceConfig_1211568020342">
    <addTimestamp xmi:id="AddTimestamp_1211568020342"/>
...
</com.ibm.etools.webservice.wsext:WsExtension>

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following client configuration tells WebSphere to accept unsigned timestamps:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityResponseConsumerServiceConfig xmi:id="SecurityResponseConsumerServiceConfig_1212093287097">
            <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
            ...
</com.ibm.etools.webservice.wscext:WsClientExtension>

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following client configuration tells WebSphere to send unsigned timestamps:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityRequestGeneratorServiceConfig xmi:id="SecurityRequestGeneratorServiceConfig_1212078169562">
          <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
          ...
</com.ibm.etools.webservice.wscext:WsClientExtension>

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel. The <transportSender> tag should not specify http, because communication with this URL will not be encrypted.

When a timestamp expires, any security semantics sent with the timestamp should expire as well. Therefore, timestamps without an expiration could allow security semantics (such as UsernameToken credentials) to remain valid indefinitely.

When a timestamp expires, any security semantics sent with the timestamp should expire as well. Therefore, timestamps without an expiration could allow security semantics (such as UsernameToken credentials) to remain valid indefinitely.

Azure Data Factory linked services can be configured to connect to various data stores. The sslMode property, when set to 0 (disable), 1 (allow), or 2 (prefer), does not fully enforce a secure SSL/TLS connection. This can leave data transfers vulnerable to interception or downgrade attacks.

Example 1: The following example shows a misconfigured linked service using sslMode set to 0 (disabled). The same risk applies if sslMode is 1 or 2:

resource example 'Microsoft.DataFactory/factories/linkedservices@2024-09-02-preview' = {
    ...
    properties: {
        typeProperties: {
            sslMode: 0
        }
    }
}

Azure Front Door is a global, scalable entry point for managing web traffic. Allowing unencrypted HTTP traffic exposes sensitive data to potential interception. It is crucial to ensure that only secure HTTPS traffic is accepted.

Example 1: The following example shows a misconfigured Front Door service that accepts HTTP traffic, which is insecure:

resource example 'Microsoft.Network/frontDoors@2024-09-02-preview' = {
    ...
    properties: {
        routingRules: [
            {
                properties: {
                    acceptedProtocols: ['Http', 'Https']
                }
            }
        ]
    }
}

Disabling SSL for hostname bindings exposes web traffic to potential interception, making sensitive information vulnerable to attackers. In an ideal configuration, enable SSL to secure the connection between the client and the web application.

Example 1: The following example shows a misconfigured hostname binding where SSL is disabled:

resource example 'Microsoft.Web/sites/hostNameBindings@2024-09-02-preview' = {
    ...
    properties: {
        sslState: 'Disabled'
    }
}

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, the https_only setting is set to yes enforcing secure transfer for an Azure storage account. However, this setting can be explicitly disabled.

Disabling secure transfer exposes the stored data to unauthorized access, potential theft, and tampering.

Example 1: The following Ansible task shows a storage account that does not enforce secure transfer.

- name: create a storage account
  azure_rm_storageaccount:
    resource_group: testResGroup
    name: sa0001
    type: Standard_GRS
    https_only: no

Application Gateways are typically used for managing web traffic, including SSL termination. Exposing traffic on port 80 without encryption can leave sensitive data vulnerable to interception, making the system susceptible to attacks.

Example 1: The following example shows a misconfigured Application Gateway that allows unencrypted HTTP traffic on port 80:

resource example 'Microsoft.Network/applicationGateways@2024-09-02-preview' = {
    ...
    properties: {
        frontendPorts: [
            {
                port: 80
            }
        ]
    }
}

Data Box Edge devices are used for offline data transfer to Azure, often handling sensitive data. Disabling SSL exposes data transfers to potential interception, compromising confidentiality and integrity.

Example 1: The following example shows a misconfigured Data Box Edge device configuration where SSL is disabled by setting the sslStatus property to DISABLED:

resource example 'Microsoft.DataBoxEdge/dataBoxEdgeDevices@2024-09-02-preview' = {
    ...
    properties: {
        sslStatus: 'Disabled'
    }
}

Machine Learning services often handle sensitive data and computations. Disabling SSL means that communication between clients and the service is not encrypted, leaving it vulnerable to interception and unauthorized access.

Example 1: The following example shows a misconfigured Machine Learning service where SSL is disabled by setting the sslEnabled property to false:

resource example 'Microsoft.MachineLearningServices/workspaces/services@2024-09-02-preview' = {
    ...
    properties: {
        sslEnabled: false
    }
}

When configuring Azure VMware Solution (AVS) private clouds, it's critical to enable SSL for LDAP connections to protect sensitive information. Disabling SSL such as setting the ssl property to DISABLED, can expose directory credentials and data to potential interception or man-in-the-middle attacks.

Example 1: The following example shows a misconfigured private cloud resource where ssl is disabled:

resource example 'Microsoft.AVS/privateClouds@2024-09-02-preview' = {
    ...
    properties: {
        identitySources: [
            {
                ssl: 'Disabled'
            }
        ]
    }
}