Modification of Security Tool Configuration

ID

sectool_config_modification

Severity

high

Resource

Security Tool Configuration

Description

Security tools (named "AppSec scanners" here for short) are often invoked in CI/CD systems to automate detection of security issues like vulnerabilities, secret leaks, unsafe configurations and the like.

Bad actors are interested in bypassing AppSec scanners to avoid detection of malicious changes in software.

But in fact the CI/CD systems are often highly privileged, and for deployment they have access to sensitive systems, including source code, component registries and production assets. This motivates bad actors to find ways for running unauthorized code on the CI/CD pipelines. With ingenuity combined with a permissive configuration, tjey can get an AppSec scanner to execute unintended code, making the tool the vector for the attack.

Impact

Attackers can provide add or change a configuration file for bypassing detection (disabling the tool or certain parts of it). By configuring "custom detectors" they may include expressions or code scripts that are run when the AppSec scanner runs in the pipeline, sort of Remote Code Execution (RCE).

Targeting the configuration of the security tool, attackers may run code for malware injection, code tampering, starting a reverse shell, or exfiltration of environment variables, CI/CD secrets or source code.

Some tools automatically use default configuration files when available in the analysis directory. For this reason, the configuration files for AppSec scanners should be changed following a controlled process, typically with a review by a team member different from the commit author.

Example

For illustrative purposes, imagine the popular open source security tool Checkov. A .checkov.yaml file is used by default, to configure the tool, including which detectors to include/exclude, and the location of custom detectors that could be coded in Python.

An attacker that adds an unexpected .checkov.yaml or modify an existing one can both disable all detectors, or configure a directory where malicious python code could be placed:

# This is for bypassing the tool: do not show errors
# by using a single non-existing check

soft-fail: true
check:
  - CHECK_DOES_NOT_EXIST

# And this is for running arbitrary python code in custom detectors
# placed in the directory included in the malicious commit:

external-checks-dir:
  - innocent-looking-dir-but-you-are-pawned

Mitigation / Fix

Configuration files for security tools are deemed critical. Additions or modifications on such files should pass specific checks, to ensure the changes do not bypass the tool’s detectors or include custom detectors aimed at executing uninteded code. This could be achieved in several ways, like:

  • Ensuring a Pull Request review is required.

  • Ensuring Pull Request checks were passed.

  • Ensuring that commits are signed.

  • Ensuring that the commit author belongs to a specific group.

By default, the validation for the change requires pr_reviewed OR (commit_signed AND author_is_admin).

Configuration

The detector has the following properties:

  • fileMatchers, which matches the several files analyzed by this detector.

    • fileTypes is used to specify the file types analyzed by this detector.

    • fileRegex is used to specify the path regular expression for these files to be matched.

    • enabled, which is true by default, is used to enable or disable a particular file matcher, while keeping the others enabled.

  • changeTypesToConsider, listing which change types to be considered, one or more characters from:

    • A for added files

    • M for modified files

    • D for deleted files

    • C for copied files

    • R for renamed files

    • T for changes in the file type/mode

    • * for any change.

Multiple values can be encoded, like AM for additions / modifications, or AMD for additions / modifications / deletions. The default is M to consider modifications only.

  • nonTrivialChangeChecker, which is a comma separated list of checkers used to discard trivial modifications. Available checkers are:

    • empty: Used for discarding changes involving empty lines or spaces.

    • comments: Used for discarding changes involving comments.

  • changeValidationChecker, which is a declarative expression used to define the validation checkers to be applied on each critical modification.
    Basically, it’s a logical expression between checker IDs with the AND & OR operators. Parenthesis can also be used to create groups of expressions.
    Available checkers are:

    • commit_signed: Checks that commit signature passed the verification (Not available for Azure Devops nor Bitbucket Cloud).

    • author_is_admin: Checks that commit author is an admin (Not available for GitLab).

    • author_in_group: Checks that commit author belong to a group. In example, by using author_in_group(sec_crew, other-random-group) we would be checking if the commit author belongs to sec_crew OR to other-random-group (Not available for GitLab).

    • pr_reviewed: Checks that the commit was reviewed in a Pull Request.

    • pr_reviewed_by_group: Checks that the commit was reviewed in a Pull Request by a reviewer from a specific group (or groups).

    • pr_reviewed_by_admin: Checks that the commit was reviewed in a Pull Request by an administrator.

    • pr_status_checks_passed: Checks if the given commit has passed the Pull Request checks.

Both nonTrivialChangeChecker and changeValidationChecker are used for the purpose of discarding False Positives, when changes do not require attention, or when they were properly reviewed/ authored.