Incorrect Default Permissions [CWE-276] — The Hacktivists

Incorrect Default Permissions weakness describes a case where software sets insecure permissions to objects on a system.

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

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

This weakness describes a case where software sets unintended permissions to directories, files or other objects during the installation process. As a result, a malicious user might be able to bypass intended security restrictions.

Most modern operating systems support access control lists (ACL) that are used to distinguish access rights for different users and groups. In modern operating systems a principal (e.g. process or threat acting on behalf of a user) acts upon objects.

Access to these objects (e.g. files, directories, registry keys, etc.) is crucial for security mechanisms implemented in different operating systems and can influence system behaviour depending on permissions imposed upon key components of the operating system.

1.1 Linux- / UNIX-based systems
❏ General permissions: Access permissions in Linux and UNIX-like systems are based on three user classes (user, group, and others) and three access modes (read, write, and execute).

Ownership rights for each directory and file are set by the chown(1) and chgrp(1) commands and are based on user and group identifiers.

The following table demonstrates differences between access modes for directories and files:

❏ Setuid/setgid bit: Setuid and setgid bits are accessed flags used to run applications with permissions of the executable’s owner or group respectively. Setuid/setgid bits are usually set for applications that need elevated privileges on the system, e.g. the ping command must send and listen for control packets on a network interface and thus needs elevated privileges, since the regular user is not allowed to do so.

In our case, the /bin/ping executable is owned by root. This means that having write-access to this executable might allow the execution of arbitrary code on the system with root privileges. That’s why it is very important to keep track of these files.

1.2 Windows-based systems
Support of access control lists starts with the NT family of Microsoft products and its NTFS file system. Before that only file attributes were used to distinguish access rights. All modern versions of Windows implement access control lists for directories, files, and registry keys. Proper system security depends on correct access rights.

Windows-based operating systems are equipped with a graphical user interface (GUI) and a command-line utility to manage access rights. The GUI is accessible via Windows Explorer:

The “icacls” command-line utility and its previous versions, such as “cacls” or “xcacls”, can also be used to view and modify access rights for users and groups. The following command displays permissions for the “C:\” drive:

C:\Users\Administrator>icacls C:
C: PC01\Administrator:(F)
NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
PC01\Administrator:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files 

Access rights to registry keys are managed by the regedit.exe utility. Since Windows-based operating systems depend on system registry, having insecure permissions on keys and hives might weaken system security and allow an attacker to gain unauthorized control over the system.

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

Usually, this weakness is locally exploitable. A malicious user might be able to gain access to sensitive information, tamper with sensitive data or compromise the vulnerable system entirely. If a setuid/setgid executable has world-writable permissions any local user can inject malicious content into it and execute arbitrary code with privileges of the file’s owner.

Basically, any application writable by an unintended actor poses a threat to system security and might be used to elevate privileges on the system, e.g. if such application was modified by a malicious and unprivileged user before being executed by a privileged one.

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

The following CAPEC patterns correspond to this weakness:

❏ CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
❏ CAPEC-19: Embedding Scripts within Scripts
❏ CAPEC-81: Web Logs Tampering
❏ CAPEC-127: Directory Indexing
❏ CAPEC-169: Footprinting

Incorrect permissions vulnerability is described in WASC Threat Classification as a weakness under
❏ WASC-17:(Improper Filesystem Permissions).

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

Software that changes access rights to objects during installation is potentially vulnerable to this weakness.

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

We will use the HTB23123 security advisory (CVE-2012–5697) as an example of this weakness. The vulnerability is introduced by the “btinstall” installation script that sets world-writable permissions for all files within the “/frameworkgui/” directory.

Let’s login into the system under the unprivileged guest account. To view files permissions we will execute the “ls –la” command, as demonstrated on the image below:

Now we will try to read the “config” file and then modify the agentpoll.pl script:

As a result of this vulnerability, any local user has full access to files within the “/frameworkgui/” directory.

6. Severity and CVSS Scoring
……………………………………..

Insecure default permissions are usually applied to locally installed applications, that’s why the primary access vector is the local system.

❏ Information disclosure
In case of potential information disclosure (e.g. software configuration, credentials, etc.) this weakness should be scored as:
3.3 [CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N] -Low severity.

❏ Data tampering
This weakness could be used to tamper with potentially sensitive information such as log files. If data can be modified or deleted, it should be scored as:
5.3 [CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L] -Medium severity.

❏ System access
If an attacker can modify a setuid binary or any other file that can be executed by another user or service on the system, privilege escalation is possible. In this case, this weakness should be scored as:
8.8 [CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H] -High severity.

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