The tx.origin global variable holds the address of the account from where a transaction originates.

If a smart contract, S1, receives a transaction from an account, A1, and then S1 calls another smart contract, S2, then inside S2, tx.origin contains the address of account, A1, used for calling S1. If the intent of tx.origin is to verify authorization of A1, then this authorization is bypassed.

Now, if an attacker can trick a user into sending a transaction into a malicious contract that them invokes the vulnerable contract where the user is authorized via tx.origin, then tx.origin will hold the address of the user account that initiated the transaction and authorization will be bypassed.

Example 1: The following code requires the owner of the contract (previously set in the constructor) to be the same as tx.origin before transferring funds to a provided address.

If an attacker is able to trick the owner of the contract into sending a transaction to a malicious contract which immediately calls the sendTo function in the vulnerable contract, then the condition within the require statement will be true and funds will be transferred to whatever address the attacker contract specified when calling sendTo.

function sendTo(address receiver, uint amount) public {
    require(tx.origin == owner);
    receiver.transfer(amount);
}

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

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.

Loose access configurations unnecessarily 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 (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following Ansible task defines an AWS Security Group that opens to the world (0.0.0.0/0) the TCP port 22, where an SSH server typically responds to incoming connection requests.

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

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.

IAM policies allowing unrestricted access to resources place an organization at risk. Poorly structured policies undermine the ability of an organization to control and manage changes to resources.

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example Ansible task defines a wildcard lambda principal.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

Amazon Redshift clusters are by default not publicly accessible.

Enabling public access to a cluster results in a wider attack surface for the organization.

Example 1: The following example shows an Ansible task that explicitly enables public access to an Amazon Redshift cluster by setting the publicly_accessible parameter to yes.

- name: example1
  community.aws.redshift:
    identifier: mycluster
    command: create
    db_name: mydb
    node_type: ds1.xlarge
    username: "{{ username }}"
    password: "{{ password }}"
    publicly_accessible: yes

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

A misconfiguration of public access to an S3 bucket is a leading cause of data breaches.

Although S3 buckets block public access by default, any authorized user can update bucket policies or access control lists (ACLs) to allow public access.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.

Amazon CloudFront Distribution can be misconfigured to allow unauthenticated or unencrypted communication, or use an outdated protocol. Such misconfigurations can cause compromise and allow an attacker, residing on a shared network, to snoop and tamper with data in transit.

Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.

Encryption at rest is not enabled. This exposes data to unauthorized access and potential theft.

Encryption at rest is not enabled. This exposes data to unauthorized access and potential theft.

By default, EBS volumes are not encrypted.
Example 1: The following example template exposes the data to potential theft and unauthorized access.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

An Amazon EC2 AMI that maps an unencrypted block device exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task creates an Amazon EC2 AMI and attaches a block device without data at rest encryption to the AMI because the encrypted parameter is set to false.

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

By default, an EFS file system is not encrypted. This exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task sets up an EFS file system without data at rest encryption because the encrypt parameter is set to no.

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]