Skip to main content

Insecure Access Control

Fixing Insecure Access Control​

About Insecure Access Control

What is improper access control?​

Improper access control is a vulnerability that occurs when a system does not properly restrict or enforce access to resources, such as files, directories, network resources, or application functions.

Examples of improper access control vulnerabilities include:

  • Weak access controls: When access controls are weak or easily bypassed, attackers can gain access to sensitive resources or data by exploiting security weaknesses.
  • Insufficient authorization checks: When authorization checks are insufficient, it can allow unauthorized users to access sensitive data or resources, or to perform actions that they are not authorized to do.
  • Overly permissive access: When access controls are overly permissive, they can allow users to access resources or data that they do not need, increasing the risk of data breaches or other security incidents.

Check out these videos for a high-level explanation:

  • Missing function level access control

  • Missing object level access control

What is the impact of improper access control?​

Improper access control can lead to various security threats, such as:

  • Data breaches: Improper access control can allow attackers to access sensitive data, leading to data breaches, data loss, or unauthorized access to confidential information.
  • Unauthorized access to resources: Attackers can exploit improper access control to gain unauthorized access to resources, such as servers, databases, and applications.
  • Account takeover: Attackers can use improper access control to take over user accounts and gain access to sensitive data or resources.

How to prevent improper access control?​

Here are some measures that can help ensure proper access control:

  • Strong access controls: Implement strong access controls that restrict access to sensitive resources or data based on user roles and permissions.
  • Proper user authentication and authorization: Implement proper user authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
  • Input validation and sanitization: Validate and sanitize user input before using it to access internal objects or data. Use regular expressions or input filters to remove or encode any special characters that could be used to access sensitive data or resources.
  • Least privilege: Use the principle of least privilege to restrict access to resources to only what is necessary for each user role. This can help prevent attackers from gaining access to resources that they do not need to access.
  • Regular security audits: Regularly audit your system for security vulnerabilities, including improper access control vulnerabilities. Use automated tools and manual testing to identify potential issues and fix them before they can be exploited.

References​

Taxonomies​

Explanation & Prevention​

Training​

Default Security Groups With Unrestricted Traffic​

Check if the default security group does not restrict all inbound and outbound traffic. Security Groups set as default must be denied traffic.

Rule-specific references:

Option A: Remove Lax Security Groups​

A security group (amazon.aws.ec2_group) containing both of the below values should not exist:

  • rules array with an element that has a cidr_ip of 0.0.0.0/0 or a cidr_ipv6 of ::/0
  • With a matching rules_egress array with an element that has a cidr_ip of 0.0.0.0/0 or a cidr_ip of 0.0.0.0/0

EC2 Instance Using Default Security Group​

EC2 instances should not use default security group(s) (Security Group(s) with a name of "default").

Rule-specific references:

Option A: Remove any Default Security Groups​

  1. Remove any default security groups from the configuration
  2. Add non-default security groups if needed
  3. Test it
  4. Ship it 🚢 and relax 🌴

IAM Policy Grants AssumeRole Permission Across All Services​

IAM role should not allow all ("*") services or principals to assume it.

Rule-specific references:

Option A: Remove the All Specifier from the Principal​

iam_managed_policy.policy.Statement.Principal.AWS should not have a value of '*'.

  1. Remove the value '*' from any iam_managed_policy.policy.Statement.Principal.AWS or replace it with as few services as possible (ideally one)
  2. Test it
  3. Ship it 🚢 and relax 🌴

IAM Policy Grants Full Permissions​

IAM policies should not allow all ('*') in a statement action.

Rule-specific references:

Option A: Remove the All Specifier from the Resource Statement of the Policy​

iam_managed_policy.policy.Statement.Resource should not have a value of '*'.

  1. Remove the value '*' from any iam_managed_policy.policy.Statement.Resource or replace it with as few Amazon Resource Names (ARNs) as possible that have as limited scope as possible
  2. Test it
  3. Ship it 🚢 and relax 🌴

IAM Policies With Full Privileges​

IAM policies should not allow full administrative privileges (for all resources).

Rule-specific references:

Option A: Remove the All Specifier from the Action Statement of the Policy​

iam_managed_policy.policy.Statement.Action should not have a value of '*'.

  1. Remove the value '*' from any iam_managed_policy.policy.Statement.Action or replace it with as few actions as possible
  2. Test it
  3. Ship it 🚢 and relax 🌴

RDP Access Is Not Restricted​

Check if the Google compute firewall allows unrestricted RDP access (port 3389).

Option A: Remove Google Cloud Platform (GCP) Compute Firewall Rule Allowing Unrestricted RDP Ingress Traffic​

gcp_compute_firewall should not have an ingress rule with unrestricted source_ranges and with allowed array containing an object with ip_protocol of tcp combined with ports array containing 3389.

Rule-specific references:

  1. Make sure you do not have a similar configuration to the following, this leaves the RDP port open to all IP addresses:

    - name: create a firewall
      google.cloud.gcp_compute_firewall:
        name: test_object
        direction: INGRESS
        allowed:
        - ip_protocol: tcp
          ports:
          - '3389'
        source_ranges:
        - 0.0.0.0/0

  2. Instead, remove the open RDP port.
    RDP should not be used directly on the Internet or any network for that matter. If you need to use RDP, instead use it through a VPN or SSH tunnel:

    - name: create a firewall
      google.cloud.gcp_compute_firewall:
        name: test_object

  3. Test it

  4. Ship it 🚢 and relax 🌴

S3 Bucket ACL Allows Read to Any Authenticated User​

Misconfigured S3 buckets can leak private information to the entire internet or allow unauthorized data tampering/deletion.

Rule-specific references:

Option A: An S3 Bucket Should Not Have a Permission of Authenticated Read​

aws_s3.permission should not have a value of "authenticated-read".

  1. Remove or replace the value "authenticated-read" from any aws_s3.permission with a less permissive permission
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket Access to Any Principal​

S3 buckets should not be accessible to all ('*') users.

Rule-specific references:

Option A: Remove the All Specifier from the Principal​

s3_bucket.policy.Statement.Principal should not have a value of '*'.

  1. Remove the value '*' from any s3_bucket.policy.Statement.Principal or replace it with as few Principals as possible (ideally one)
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket Allows Delete Action From All Principals​

S3 Buckets must not allow Delete Action From All Principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/deletion.

Rule-specific references:

Option A: Remove the Delete Action from a Principal specifying All​

Where a Principal specifies 'All' the 'Delete' action should not be present.

  1. Remove any s3_bucket.policy.Statement.Action specifying "delete" where s3_bucket.policy.Statement.Principal has a value of '*'
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket Allows Get Action From All Principals​

S3 Buckets must not allow the 'Get' Action From 'All' Principals in order to prevent leaking private information to the entire internet or allow unauthorized data tampering/fetching.

Rule-specific references:

Option A: Remove the Get Action from a Principal specifying All​

Where a Principal specifies All the Get action should not be present.

  1. Remove any s3_bucket.policy.Statement.Action specifying "get" where s3_bucket.policy.Statement.Principal has a value of '*'
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket Allows List Action From All Principals​

S3 Buckets must not allow List Action From All Principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/listing.

Rule-specific references:

Option A: Remove the List Action from a Principal specifying All​

Where a Principal specifies All the List action should not be present.

  1. Remove any s3_bucket.policy.Statement.Action specifying "list" where s3_bucket.policy.Statement.Principal has a value of '*'
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket Allows Put Action From All Principals​

S3 Buckets must not allow Put Action From All Principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/putting.

Rule-specific references:

Option A: Remove the Put Action from a Principal specifying All​

Where a Principal specifies All the Put action should not be present.

  1. Remove any s3_bucket.policy.Statement.Action specifying "put" where s3_bucket.policy.Statement.Principal has a value of '*'
  2. Test it
  3. Ship it 🚢 and relax 🌴

S3 Bucket With All Permissions​

S3 Buckets must not have all permissions, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/deletion.

Rule-specific references:

Option A: Remove the Action All from a Policy Statement Where Effect is Allow​

Where the Effect is "Allow" the Action should not be All ("*").

  1. Remove or replace any s3_bucket.policy.statement.action specifying all ("*") where effect is "Allow"
  2. Test it
  3. Ship it 🚢 and relax 🌴

Security Group With Unrestricted Access To SSH​

SSH (TCP:22) should not be exposed to the world via AWS Security Group. There is very rarely a need for ranges of IP addresses to be able to access SSH port 22.

Rule-specific references:

Option A: Only specify single IP addresses or a very small range that can access SSH port 22​

All rules (ingress) of any given ec2_group should not have port 22 open to the world.

  1. Given a rule that is open to the world or wide range or IP addresses (cidr_ip and/or cidr_ipv6 with wide range): Change the CIDR to single IP addresses or very narrow range
  2. Test it
  3. Ship it 🚢 and relax 🌴

Sensitive Port Is Exposed To Entire Network​

This means that one or more of the following conditions is true:

  • cidr_blocks includes a value that ends with "/0" and the port range includes a sensitive port
  • or cidr_blocks includes a value that ends with "/0" and protocol is not "tcp" or "udp"

Rule-specific references:

Option A: Remove or modify rules that match one or more of the above conditions​

Remove the rules and/or disable the listening services

  1. Remove or disable any services such as Telnet or POP3
  2. Remove the rules that specify that ports such as 23 (Telnet) or port 110 (POP3) be open
  3. Todo
  4. Test it
  5. Ship it 🚢 and relax 🌴

SQLServer Ingress From Any IP​

Check if all IPs are allowed. An azure_rm_sqlfirewallrule should not have a start_ip_address with the value 0.0.0.0 combined with an end_ip_address of value 255.255.255.255.

Rule-specific references:

Option A: Reduce the range of allowed ingress IP addresses​

  1. Using the following parameters: start_ip_address and end_ip_address make the range as narrow as possible
  2. Consider adding several rules (azure_rm_sqlfirewallrule) if need be to target narrower rangers or single IP addresses
  3. Test it
  4. Ship it 🚢 and relax 🌴

Security Group Ingress Not Restricted​

AWS Security Group should restrict ingress access.

Rule-specific references:

Options A: Make sure the IP Address range of each Ingress rule is as narrow as possible​

For each ec2_group.rules (ingress) make sure the IP address range does not allow all IP addresses.

  1. For every rule, make sure the range of IP addresses is as narrow as possible. cidr_ip: 0.0.0.0/0, cidr_ipv6: ::/0 which specifies all addresses is not acceptable
  2. It's also good practice to constrain the number of open ports to only the ones that are actually needed. You can do this by having the range (from_port to to_port) as small as possible, or specifying the minimum ports required in the ports parameter
  3. Test it
  4. Ship it 🚢 and relax 🌴

Security Group is Not Configured​

Azure Virtual Network subnet must be configured with a Network Security Group, which means the attribute security_group must be defined and not empty.

Rule-specific references:

Options A: Make sure the IP Address range of each Ingress rule is as narrow as possible​

  1. Make sure the azure_rm_subnet has a security_group parameter that references an existing security group
  2. Test it
  3. Ship it 🚢 and relax 🌴

VM With Full Cloud Access​

A VM instance is configured to use the default service account with full access to all Cloud APIs.

Rule-specific references:

Option A: Remove Cloud Platform from Service Account Scopes for Google Cloud Platform (GCP) VMs​

service_accounts.scopes should not contain cloud-platform.

  1. Review the configuration of your GCP VM configuration
  2. If the service_accounts.scopes contains cloud-platform remove it
  3. Test it
  4. Ship it 🚢 and relax 🌴

HTTP Port Open​

The HTTP port (80) is open to the world in an AWS VPC Security Group. HTTPS which protects the integrity and confidentiality of transmitted data is the preferred option for HTTP traffic.

If you are transferring data of a sensitive nature then HTTPS should generally always be used. Sensitive data includes but is not limited to such items as:

  • Personally Identifiable Information
  • Login/authentication details
  • Passwords, secret keys
  • Credit card numbers

If you are not transferring any sensitive content, then besides concerns such as Search Engine Optimisation (SEO) and similar non-security related topics, Using HTTPS is less of an issue.

Rule-specific references:

Option A: Consider closing HTTP ingress port (80).​

All rules (ingress) of any given ec2_group should not have port 80 open to the world.

  1. Given a rule that is open to the world (cidr_ip: 0.0.0.0/0): Make sure that port 80 is not within the range specified by from_port - to_port or specified by ports. If it is remove it
  2. Test it
  3. Ship it 🚢 and relax 🌴

Remote Desktop Port Open​

The Remote Desktop port (3389) is open to the world in a Security Group. If you need to provide Remote Desktop communications to an EC2 instance consider doing so via a VPN or SSH tunnel.

Rule-specific references:

Option A: Close the Remote Desktop ingress port (3389).​

All rules (ingress) of any given ec2_group should not have port 3389 open to the world.

  1. Given a rule that is open to the world (cidr_ip: 0.0.0.0/0): Make sure that port 3389 is not within the range specified by from_port - to_port or specified by ports. If it is remove it
  2. If you need Remote Desktop access set-up a VPN or use SSH and limit the cidr_ip to as fewer IP addresses as possible
  3. Test it
  4. Ship it 🚢 and relax 🌴

SSH Access Is Not Restricted​

Check if Google Firewall allows SSH access (port 22) from the Internet (public CIDR block).

Rule-specific references:

Option A: Make sure Source IP address ranges allow the minimum number of hosts as possible​

  1. If port 22 is included in the list of gcp_compute_firewall.allowed.ports, make sure the CIDR gcp_compute_firewall.aource_ranges is as small as possible to block unauthorized actors getting to port 22
  2. Test it
  3. Ship it 🚢 and relax 🌴
Last updated on by Stefan Streichsbier