R186. Use the principle of least privilege

Requirement

The principle of least privilege must be applied when creating new objects and roles, setting access permissions, and accessing other systems.

Description

Systems should usually have a set of roles with different levels of privilege for accessing resources. Users and applications should always have a role with the minimum level of privilege required to execute their functions. A violation of this may become a new vulnerability or leverage for causing a greater impact when exploiting other vulnerabilities.

References

  1. CAPEC-17: Using Malicious Files. An attack of this type exploits a system’s configuration that allows an attacker to either directly access an executable file, for example through shell access; or in a possible worst case allows an attacker to upload a file and then execute it.

  2. CAPEC-23: File Content Injection. An attack of this type exploits the host’s trust in executing remote content, including binary files. The files are poisoned with a malicious payload (targeting the file systems accessible by the target software) by the adversary and may be passed through standard channels such as via email, and standard web content like PDF and multimedia files.

  3. CAPEC-27: Leveraging Race Conditions via Symbolic Links. This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link.

  4. CAPEC-35: Leverage Executable Code in Non-Executable Files. An attack of this type exploits a system’s trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters.

  5. CAPEC-122: Privilege Abuse. An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

  6. CAPEC-153: Input Data Manipulation. An attacker exploits a weakness in input validation by controlling the format, structure, and composition of data to an input-processing interface. By supplying input of a non-standard or unexpected form an attacker can adversely impact the security of the target.

  7. CAPEC-176: Configuration/Environment Manipulation. An attacker manipulates files or settings external to a target application which affect the behavior of that application.

  8. CAPEC-233: Privilege Escalation. An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.

  9. CIS Controls. 4.7 Limit Access to Scripting Tools. Limit access to scripting tools (such as Microsoft® PowerShell and Python) to only administrative or development users with the need to access those capabilities.

  10. CWE-250: Execution with Unnecessary Privileges. The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

  11. CWE-269: Improper Privilege Management. The software does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

  12. CWE-272: Least Privilege Violation. The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

  13. CWE-276: Incorrect Default Permissions. The product, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.

  14. CWE-285: Improper Authorization. The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

  15. CWE-732: Incorrect Permission Assignment for Critical Resource. The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

  16. NIST 800-53 AC-6 The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.

  17. OWASP Top 10 A5:2017-Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.

  18. OWASP-ASVS v4.0.1 V1.2 Authentication Architectural Requirements.(1.2.1) Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.

  19. OWASP-ASVS v4.0.1 V1.4 Access Control Architectural Requirements.(1.4.3) Verify enforcement of the principle of least privilege in functions, data files, URLs, controllers, services, and other resources. This implies protection against spoofing and elevation of privilege.

  20. OWASP-ASVS v4.0.1 V4.1 General Access Control Design.(4.1.3) Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

  21. OWASP-ASVS v4.0.1 V4.1 General Access Control Design.(4.1.4) Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.

  22. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.2) Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.

  23. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.6) Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behavior into the application.

  24. PCI DSS v3.2.1 - Requirement 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials).

  25. PCI DSS v3.2.1 - Requirement 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary.

  26. PCI DSS v3.2.1 - Requirement 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users.

  27. PCI DSS v3.2.1 - Requirement 6.5.8 Address common coding vulnerabilities in software-development processes including improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

  28. PCI DSS v3.2.1 - Requirement 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.

  29. PCI DSS v3.2.1 - Appendix A1 A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.

  30. PCI DSS v3.2.1 - Appendix A1 A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy