Unbounded consumption occurs when LLM APIs are not adequately rate-limited, throttled, or otherwise restricted in terms of resource use. This can involve excessive model inference requests, unbounded query sizes, or long-running processes that put undue strain on the server hosting the model, causing delays, outages, or even a complete loss of service.

When LLM APIs are not properly controlled, an attacker can abuse the system by sending high volumes of requests, large data queries, or complex tasks that drain resources. This issue can compound in multi-tenant systems where excessive consumption from one user or process affects others, leading to potential performance bottlenecks or system downtime.
Additionally, a Denial of Wallet (DoW) attack can occur when attackers exploit the cost-per-use model of cloud-based AI services by initiating a high volume of requests, which leads to unsustainable financial burdens on the provider. This can result in financial ruin for the provider, as the cost of processing excessive requests becomes unmanageable.

Example 1: A user submits a series of large text generation requests to an LLM API without any timeout, which allows requests to run without limits. This causes the system to process excessive data and exhausts available server resources.

import openai

# OpenAI GPT model setup
openai.api_key = "your-api-key"

def generate_large_response(prompt):
  response = openai.Completion.create(
      engine="text-davinci-003",
      prompt=prompt,
      max_tokens=1000
  )
  return response

# Submitting unbounded requests with high complexity and token count
prompt = "Generate an extensive article on AI."
response = generate_large_response(prompt)
print(response)

Example 2: A chat model is utilized without configuring a rate_limiter parameter while interacting with the LLM model.

from langchain_anthropic import ChatAnthropic
model = ChatAnthropic(
	model_name="claude-3-opus-20240229",
# not using rate_limiter
)

These examples demonstrate how unbounded API calls that lack a timeout can consume significant resources. Without restrictions on the execution time, the system can become overloaded. This can negatively affect the stability of the service and possibly result in resource exhaustion or denial-of-service risks.

The template does not forward audit logs to Amazon CloudWatch for monitoring. This can allow malicious behavior to go undetected and lead to delayed incident response.

By default, CloudWatch Log Groups retain logs indefinitely. An unset retention value indicates that organizational data handling policies have not been consulted in order to set appropriate configurations. This might result in unnecessary expenses for the organization to store and manage logging events.

An attacker can launch a Denial of Wallet (DoW) attack by persistently prompting spurious event-logging over an extended period of time, which can impact the organization financially.

Example 1: The following example shows an Ansible task that fails to define a retention policy.

- name: create a log_group in CloudWatchLogs
  community.aws.cloudwatchlogs_log_group:
    log_group_name: test-log-group
    tags: { "Name": "test-log-group", "Env" : "QA" }

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Server error messages can occur because of a misbehaving application, a misconfiguration, or a malicious value injected into the application. Error responses give attackers insight into how the application handles error conditions. The attacker can use this knowledge to remotely trigger errors that could potentially lead to denial of service conditions.
The attacker can use the details offered in the error message to gain further knowledge about the application logic and discover absolute paths to the filesystem. This information can help refine the attack payloads that target vulnerabilities such as file inclusion, command execution, SQL injection, and others.

By default, Amazon Redshift clusters do not capture audit logs. This can allow malicious behavior to go undetected and inhibit forensic analysis in the event of a breach.

Example 1: The following example template defines an Amazon Redshift cluster without audit logging.

  "Resources": {
    "RedshiftClusterTest": {
      "Properties": {
        "NodeType": "dc1.large",
        "Port": 5439,
        "VpcSecurityGroupIds": [
          "${RedshiftSecurityGroup}"
        ],
        "ClusterSubnetGroupName": "RedshiftClusterSubnetGroup",
        "ClusterType": "single-node"
        "MasterUserPassword": "MasterUserPassword",
        "MasterUsername": "MasterUsername",
        "DBName": "${DatabaseName}",
        "IamRoles": ["RawDataBucketAccessRole.Arn"],
        "PubliclyAccessible": true
      },
      "Type": "AWS::Redshift::Cluster"
    }

Systems protected by basic authentication offer attackers a potential weak link. Attackers can compromise passwords (especially weak ones) by brute-force, guessing, or social engineering.

Example 1: The following example shows a misconfigured Kubernetes service where Role-Based Access Control (RBAC) is disabled, leaving the system vulnerable:

resource example 'Microsoft.ContainerService/managedClusters@2024-09-02-preview' = {
    ...
    properties: {
        ...
        enableRBAC: false
    }
}

If the administrator fails to install a valid certificate, site visitors might come to expect the invalid certificate error message presented by the user agent alerting them about the hostname mismatch. An attacker can take advantage of this complacency and trick user into accepting an invalid certificate of their own. This sets the victim up for a man-in-the-middle attack.

DNSSEC prevents DNS spoofing by providing the ability to use digital signatures for DNS response validation. Any DNSSEC signing algorithm that uses SHA-1, however, is susceptible to an ever-growing risk of attack. SHA-1 is no longer considered a secure hash algorithm when used with digital signatures.

Example 1: The following example shows a Terraform configuration that enables the DNSSEC with the insecure signing algorithm rsasha1.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

GKE supports two cluster network modes: routes-based and VPC-native. VPC-native clusters use alias IP address ranges to route traffic from one Pod in a node to another Pod. This allows precise IP-based policies and firewall rules for Pods. In contrast, an entire node is the finest granularity level of control in routes-based clusters.

Example 1: The following example Terraform configuration does not enable a VPC-native cluster by setting networking_mode to ROUTES.

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

A servlet error message is the result of an unhandled exception in the application. It indicates that the application failed to handle unexpected user input.
Most serious attacks on a software system begin with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this operation can never fail" and "it doesn't matter if this operation fails". When a programmer fails to catch an exception that an operation might throw, they are operating under one of these assumptions.
An attacker can leverage the conditions that cause such errors to orchestrate attacks that will lead to unauthorized access to the system.

An unhandled SOAP exception can reveal information about the application that enables an attacker to orchestrate further attacks on the application. The error message can reveal fully qualified server paths, disclose the structure of server-side documents, or indicate avenues to gain unauthorized access to the system.
Just about every serious attack on a software system begins with the violation of a programmer's assumptions.
Two dubious assumptions that are easy to spot in code are "this operation can never fail" and "it doesn't matter if this operation fails". When a programmer fails to catch an exception that an operation may throw, they implicitly state that they are operating under one of these assumptions.

Systems protected by basic authentication offer attackers a potential weak link. Attackers can compromise passwords (especially weak ones) by brute-force, guessing, or social engineering.

Example 1: The following example shows a VM that allows SSH basic authentication.

resource example 'Microsoft.Compute/virtualMachines@2021-03-01' = {
    ...
    properties: {
        ...
        osProfile: {
            ...
            linuxConfiguration: {
                ...
                disablePasswordAuthentication: false
            }
        }
    }
}

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate