The key concept is weak authorization controls which may allow unauthorized users to access and manipulate sensitive security configurations, leading to information disclosure and privilege escalation.

Scenario: Dinis’s Unauthorized Access to Security Configurations

Envision a scenario where Dinis, exploiting weak authorization mechanisms, gains access to sensitive security configuration information or access control lists (ACLs). This vulnerability arises from:

1. Inadequate Protection of Security Settings: Essential security configurations and ACLs are not sufficiently safeguarded against unauthorized access.
2. Lack of Robust Authorization Checks: The system fails to rigorously verify user permissions for accessing these critical settings.

Example

Dinis discovers that a network management tool in an organization does not adequately restrict access to its security configuration settings and ACLs. Although he is a regular user, the tool’s weak authorization checks allow him to view and potentially alter these configurations. By accessing the ACLs, Dinis manipulates the permissions, granting himself higher access rights and enabling further exploitation of the system.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Information Disclosure and potentially Elevation of Privilege.

Elevation of Privilege (EoP) occurs when an attacker gains access to capabilities or resources beyond their intended permissions. Dinis, a regular user, can access security configurations and ACLs, which are normally restricted and sensitive, meaning that there is a Information Disclosure. In the case that he can modify them, he can grant himself higher privileges, escalating his access. The core issue is unauthorized access to sensitive security controls, potentially enabling privilege escalation.

What can go wrong?

Such vulnerabilities can lead to unauthorized alterations in security settings, potential system breaches, and the compromise of network integrity. This can manifest in various forms, including but not limited to:

• Weak authentication mechanisms for accessing security configurations
• Lack of monitoring and logging for access to security settings
• Access to security configurations by non-privileged users
• Exploitation of vulnerabilities in security management tools to gain unauthorized access
• Inadequate access controls on security configurations, allowing unauthorized users to view or modify critical settings
• Exposure of sensitive information in security configurations, such as encryption keys or credentials, to unauthorized users
• Unauthorized changes to ACLs can lead to privilege escalation and further exploitation of the system

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

1. Implement stringent authorization controls to restrict access to security configurations and ACLs, ensuring only authorized personnel can view or modify them.
2. Employ role-based access control (RBAC) to clearly define and enforce access permissions based on user roles.
3. Restrict access to security-relevant configuration to only appropriate authorized users.
4. Ensure the application is designed taking into account client-side security features that browsers using the application must support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms) and have implemented measures in case these features are not supported or are bypassed by an attacker like blocking access or warning the user.
5. Make sure the application ensures that function-level access is restricted to consumers with explicit permissions.
6. Implement authorization rules at a trusted service layer and don't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.
7. Configure the authorization server to only assign the required permissions to each user or service, following the principle of least privilege.
8. Communications between backend application components, including local or operating system services, APIs, middleware, and data layers, should be performed with accounts assigned the least necessary privileges.
9. Ensure that failed authorization attempts are logged and monitored to detect potential abuse or misconfigurations in access controls.
10. Consider implementing multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis when evaluating access to administrative interfaces or critical functions.
11. Regularly audit and monitor access to these settings to detect and respond to any unauthorized attempts.
12. Verify that access to secrets and sensitive configuration data is properly protected and only accessible to authorized users or services.
13. Ensure that access to security configurations and ACLs is not exposed through APIs or interfaces that are accessible to unauthorized users.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.