Improper Access Control [CWE-284] — The Hacktivists

Improper Access Control weakness describes a failure in the AAA security model.

Table of Content
1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring

1. Description
………………………………

Access control is a security process that controls the usage of specific resources within predefined criteria and is a part of the AAA (Authentication, Authorization, Accounting) security model.

All modern systems use certain access control models to manage their security. Access control models can be grouped into three main classes: Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role-Based Access Control (RBAC).

❏ Mandatory Access Control (MAC): MAC is an access control model implemented in many modern operating systems such as SELinux (since kernel 2.6), FreeBSD (since 5.0), SUSE Linux, Ubuntu, Microsoft Windows (starting with Vista), etc.

In MAC a security policy administrator controls the overall security policy. Users do not have the ability to override the defined policy set and e.g. grant access to otherwise restricted objects.

This policy is based on mandated regulations determined by a central authority.

❏ Discretionary Access Control (DAC): The DAC access control model is based on the identity of the requestor and defined access rules that determine allowed actions.

Access decisions are typically based on provided credentials and are subject to manipulation within specified bounds.

In most DAC model implementations the owner of the object can modify its permissions and transfer ownership to other subjects.

❏ Role-Based Access Control (RBAC): Role-based policies control access to objects depending on the roles that user have within the system and on rules that define access permissions for users in the given role.

Discretionary and role-based policies usually contain an administrative policy that defines an administrative account for access control management.

The Improper Access Control weakness describes a case where software fails to restrict access to an object properly.

A malicious user can compromise the security of the software and perform certain unauthorized actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.

Two major behaviours can potentially introduce access control weaknesses:

❏ Specification: Some permissions, privileges or ownerships, which are initially intended for certain users or processes, can indeed be applied to other users or processes (e.g. placing a file with the secured key into a word-readable directory, or assigning capabilities of a privileged account to a guest user).

❏ Enforcement: the security mechanism contains errors that prevent proper enforcement of the specified access control requirements (e.g. allowing the user to specify his own access controls or allowing incorrect access control lists to produce insecure settings). This problem occurs within the application that does not correctly enforce or inherits the intended security policy.

The following PHP code can be used as an example of the improper access control weakness:

<?php
// Improper Access Control [CWE-284] vulnerable code example
// © HTB Research
define ("ACCESS_DENIED",false);
if ($_SERVER["REQUEST_METHOD"]=="GET"):
 ACCESS_DENIED=true;
 if(CUser->IsAuthorized()):
 ACCESS_DENIED=false;
 else:
 ACCESS_DENIED=true;
 endif;
endif;
if (ACCESS_DENIED):
 echo "You don't have permission to access this file.";
else:
 ShowPrivilegedContent();
endif;
?>

In the above code, the ACCESS_DENIED constant is erroneously declared as false. An attacker might be able to send an HTTP POST request to the script, bypass the authorization checks intended for the HTTP GET method, and gain access to the output of the ShowPrivilegedContent() function.

2. Potential impact
………………………………

This weakness allows an attacker to bypass intended security restrictions and perform a variety of actions depending on the source of error and functionality of the application.

An attacker might be able to perform certain actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.

3. Attack patterns
………………………………

There is only one CAPEC pattern that is related to this weakness:

❏ CAPEC-19: Embedding Scripts within Scripts

This weakness is not described as an attack technique in the WASC Threat Classification database.

4. Affected software
………………………………

Any software intended to handle access controls is potentially vulnerable to this weakness.

5. Severity and CVSS Scoring
……………………………………..

This vulnerability could be scored differently depending on the application’s design, its functionality and potential security impact.

In case an attacker gets full control over the application or can read, modify and delete data, it should be scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] — Critical severity.

Credits: https://www.immuniweb.com/