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

• OWASP Top 10 - A01 Broken Access Control
• CWE-284: Improper Access Control
• CWE-285: Improper Authorization

Explanation & Prevention

• OWASP: Broken Access Control
• OWASP: Authorization Testing
• OWASP: ASVS - V4 Access Control
• OWASP: Proactive Controls - C7 Enforce Access Controls
• OWASP: Authorization Cheat Sheet

Related CVEs

• CVE Details: CWE-284
• CVE Details: CWE-285

Training

• Secure Code Warrior: Improper Access Control
• Secure Code Warrior: Missing Function Level Access Control
• Secure Code Warrior: Missing Object Level Access Control

Insecure SecurityContext Settings

This category refers to SecurityContext settings that are insecure at the pod or container level.

Rule-specific references:

• Configure securityContext for containers
• SecurityContext.Capabilities.Drop

Option A: Run containers as non-root users

Force the running image to run as a non-root user to ensure least privilege.

1. Go through the issues that GuardRails identified

2. Look for code like this:

   apiVersion: v1  
   kind: Pod  
   metadata:  
     name: security-best-practice
   spec:  
     containers:  
     # specification of the pod’s containers  
     # ...  
     securityContext:  
       runAsNonRoot: false
     # it is also possible for runAsNonRoot to not be set.

3. Replace the line containing runAsNonRoot: false with:

   spec:  
     containers:
     # specification of the pod’s containers  
     # ...  
     securityContext:  
       runAsNonRoot: true

4. Test it

5. Ship it 🚢 and relax 🌴

Option B: Don't run containers in privileged mode

Privileged containers can allow almost completely unrestricted host access.

1. Go through the issues that GuardRails identified

2. Look for code like this:

   apiVersion: v1  
   kind: Pod  
   metadata:  
     name: security-best-practice
   spec:  
     containers:  
     # specification of the pod’s containers  
     # ...  
     securityContext:  
       privileged: true

3. Replace the line containing privileged: false with:

   spec:  
     containers:
     # specification of the pod’s containers  
     # ...  
     securityContext:  
       privileged: false

4. Test it

5. Ship it 🚢 and relax 🌴

Option C: Don't add SYS_ADMIN capabilities

Capabilities permit certain named root actions without giving full root access. They are a more fine-grained permissions model, and all capabilities should be dropped from a pod, with only those required added back.

There are a large number of capabilities, with CAP_SYS_ADMIN bounding most. Never enable this capability - it’s equivalent to root and should always be avoided.

1. Go through the issues that GuardRails identified

2. Look for code like this:

   apiVersion: v1  
   kind: Pod  
   metadata:
     name: sys-admin-capabilities
   spec:
     containers:
     # specification of the pod’s containers
     # ...
     securityContext:
       capabilities:
         drop:
           - all
         add:
           - SYS_ADMIN

3. Remove the SYS_ADMIN capabilities

4. Test it

5. Ship it 🚢 and relax 🌴

Option D: Disable allowPrivilegeEscalation

Gates whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation. This defaults to allowed to not break setuid binaries. Setting it to false ensures that no child process of a container can gain more privileges than its parent.

1. Go through the issues that GuardRails identified

2. Look for container definitions with allowPrivilegeEscalation being set to true

   apiVersion: v1
   kind: Pod  
   metadata:
     name: drop-capabilities
   spec:
     containers:
     # specification of the pod’s containers
     # ...
     securityContext:
       allowPrivilegeEscalation: true

3. Change it to allowPrivilegeEscalation: false

4. Test it

5. Ship it 🚢 and relax 🌴

Option E: Reduce kernel capabilities

Reducing kernel capabilities available to a container limits its attack surface. It's recommended to drop all capabilities and only add the ones specifically needed.

1. Go through the issues that GuardRails identified

2. Look for container definitions without a capabilities definition in the securityContext

3. Drop all capabilities and only add the ones needed

   apiVersion: v1
   kind: Pod  
   metadata:
     name: drop-capabilities
   spec:
     containers:
     # specification of the pod’s containers
     # ...
     securityContext:
       capabilities:
         drop:
           - all
         add: ["NET_ADMIN", "SYS_TIME"]

   Or better yet:

   apiVersion: v1
   kind: Pod  
   metadata:
     name: drop-capabilities
   spec:
     containers:
     # specification of the pod’s containers
     # ...
     securityContext:
       capabilities:
         drop:
           - all
         add: ["NET_BIND_SERVICE"]

4. Test it

5. Ship it 🚢 and relax 🌴

Option F: Run as high-UID user

Run as a high-UID user to avoid conflicts with the host's user table. While this is not a high-risk issue it is recommended to set a UID higher than 10000.

1. Go through the issues that GuardRails identified

2. Look for container definitions like this:

   apiVersion: v1
   kind: Pod  
   metadata:
     name: run-as-user
   spec:
     containers:
     # specification of the pod’s containers
     # ...
     securityContext:
       runAsUser: 1000

3. Change the value to a number higher than 10000

4. Test it

5. Ship it 🚢 and relax 🌴

Fixing Insecure Spec Settings

This category refers to Spec settings that are insecure.

Option A: Disable HostPID

Sharing the host's PID namespace allows visibility of processes on the host, potentially leaking information such as environment variables and configuration.

1. Go through the issues that GuardRails identified

2. Look for spec definitions like this:

   apiVersion: v1
   kind: Pod  
   metadata:
     name: run-as-user
   spec:
     hostPID: true

3. Change the value of hostPID to false

4. Test it

5. Ship it 🚢 and relax 🌴

No Drop Capabilities for Containers

Please refer to the applicable sub-section under Terraform.

Not Limited Capabilities For Pod Security Policy

Rule-specific references:

• Define Capabilities with Pod Security Policy
• Holistic Info-Sec for Web Developers - Capabilities Risks, Countermeasures

Option A: Define requiredDropCapabilities

Usually, the best approach when it comes to the set of capabilities that pods can run with is to remove them until something in your application stops working, or start with no capabilities and only add the ones you need. The fewer Linux capabilities you run with the fewer privileges and access the containers within the given pod have to the host's kernel.

At the Pod Security Policy level:

1. Add as many capabilities to requiredDropCapabilities of your Pod Security Policy as possible, or even add ALL
2. Test your application
3. If everything is still working try adding more capabilities to requiredDropCapabilities
4. Test your application, if something has stopped working, remove the capability you just added to requiredDropCapabilities
5. Test your application
6. If everything is still working, ship it 🚢 and relax 🌴