Skip to content

Commit

Permalink
risks 2-4
Browse files Browse the repository at this point in the history
  • Loading branch information
omer-cider committed Mar 15, 2022
1 parent 953d2a5 commit c7f40e8
Show file tree
Hide file tree
Showing 5 changed files with 223 additions and 3 deletions.
Binary file added Images/dppe.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Images/ippe.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
67 changes: 66 additions & 1 deletion Risks/CICD-SEC-02-Inadequate-Identity-And-Access-Management.md
Original file line number Diff line number Diff line change
@@ -1 +1,66 @@
# CICD-SEC-2: Inadequate Identity and Access Management
# CICD-SEC-2: Inadequate Identity and Access Management
## Definition


Inadequate Identity and Access Management risks stem from the difficulties in managing the vast amount of identities spread across the different systems in the engineering ecosystem, from source control to deployment. The existence of poorly managed identities - both human and programmatic accounts - increases the potential and the extent of damage of their compromise.


## Description

Software delivery processes consist of multiple systems connected together with the aim of moving code and artifacts from development to production. Each system provides multiple methods of access and integration (username & password, personal access token, marketplace application, oauth applications, plugins, SSH keys). The different types of accounts and method of access can potentially have their own unique provisioning method, set of security policies and authorization model. This complexity creates challenges in managing the different identities throughout the entire identity lifecycle and ensuring their permissions are aligned with the principle of least privilege.

Furthermore, in a typical environment, the average user account of an SCM or CI is highly permissive, as these systems have not traditionally been a major focus area for security teams. These identities are mostly used by engineers that require the flexibility to be able to create major changes in code and infrastructure.

Some of the major concerns and challenges around identity and access management within the CI/CD ecosystem include:



* **Overly permissive identities** - Maintaining the principle of least privilege for both applicative and humac accounts. For example, in SCMs - Ensuring each human and applicative identity has been granted only the permissions required and only against the actual repositories it needs to access is not trivial.
* **Stale identities** - Employees/Systems that are not active and/or no longer require access but have not had their human and programmatic account against all CI/CD systems deprovisioned.
* **Local identities** - Systems which do not have their access federated with a centralized IDP, creating identities that are managed locally within the system in question. Local accounts create challenges in enforcing consistent security policies (e.g. password policy, lockout policy, MFA) as well as properly deprovisioning access across all systems (for example, when an employee leaves the organization).
* **External identities** -
* <span style="text-decoration:underline;">Employees registered with an email address from a domain not owned or managed by the organization</span> - In this scenario, the security of these accounts is highly dependent on the security of the external accounts they are assigned to. Since these accounts are not managed by the organization, they are not necessarily compliant with the organization's security policy.
* <span style="text-decoration:underline;">External collaborators</span> - Once access is granted to external collaborators to a system, the security level of the system is derived from the level of the external collaborator’s work environment, outside of the organization’s control.
* **Self-registered identities** - In systems where self-registration is allowed, it is often the case that a valid domain address is the only prerequisite for self-registration and access to CI/CD systems. Usage of default/base set of permissions to a system which is anything different than “none” significantly expands the potential attack surface.
* **Shared identities** - Identities shared between human users / applications / both humans and applications increase the footprint of their credentials as well as create challenges having to do with accountability in case of a potential investigation.


## Impact

The existence of hundreds (or sometimes thousands) of identities - both human and programmatic - across the CI/CD ecosystem, paired with a lack of strong identity and access management practices and common usage of overly permissive accounts, leads to a state where compromising nearly any user account on any system, could grant powerful capabilities to the environment, and could serve as a segway into the production environment.


## Recommendations



* Conduct a continuous analysis and mapping of all identities across all systems within the engineering ecosystem. For each identity, map the identity provider, level of permissions granted and level of permissions actually used. Ensure all methods of programmatic access are covered within the analysis.
* Remove permissions not necessary for the ongoing work of each identity across the different systems in the environment.
* Determine an acceptable period for disabling/removing stale accounts and disable/remove any identity which has surpassed the predetermined period of inactivity.
* Avoid creating local user accounts. Instead, create and manage identities using a centralized organization component (IdP). Whenever local user accounts are in use, ensure that accounts which no longer require access are disabled/removed and that security policies around all existing accounts match the organization’s policies.
* Continuously map all external collaborators and ensure their identities are aligned with the principle of least privilege. Whenever possible, grant permissions with a predetermined expiry date - for both human and programmatic accounts - and disable their account once the work is done.
* Prevent employees from using their personal email addresses, or any address which belongs to a domain not owned and managed by the organization, against the SCM, CI, or any other CI/CD platform. Continuously monitor for non-domain addresses across the different systems and remove non-compliant users.
* Refrain from allowing users to self-register to systems, and grant permission on an as-needed basis.
* Refrain from granting base permissions in a system to all users, and to large groups where user accounts are automatically assigned to.
* Avoid using shared accounts. Create dedicated accounts for each specific context, and grant the exact set of permissions required for the context in question.


## References



1. The Stack Overflow TeamCity build server compromise - The attacker was able to escalate their privileges in the environment due to the fact the newly registered accounts were assigned administrative privileges upon access to the system.

[https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/](https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/)

2. Mercedes Benz source code leaked after a self-maintained internet-facing GitLab server was available for access by self-registration.

[https://www.zdnet.com/article/mercedes-benz-onboard-logic-unit-olu-source-code-leaks-online/](https://www.zdnet.com/article/mercedes-benz-onboard-logic-unit-olu-source-code-leaks-online/)

3. A self-managed GitLab server of the New York state government was exposed to the internet, allowing anyone to self-register and log in to the system, which stored sensitive secrets.

[https://techcrunch.com/2021/06/24/an-internal-code-repo-used-by-new-york-states-it-office-was-exposed-online/](https://techcrunch.com/2021/06/24/an-internal-code-repo-used-by-new-york-states-it-office-was-exposed-online/)

4. Malware added to the Gentoo Linux distribution source code, after the GitHub account password of a project maintainer was compromised.

[https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident_Reports/2018-06-28_Github](https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident_Reports/2018-06-28_Github)
80 changes: 79 additions & 1 deletion Risks/CICD-SEC-03-Dependency-Chain-Abuse.md
Original file line number Diff line number Diff line change
@@ -1 +1,79 @@
# CICD-SEC-3: Dependency Chain Abuse
# CICD-SEC-3: Dependency Chain Abuse
## Definition


Dependency chain abuse risks refer to an attacker’s ability to abuse flaws relating to how engineering workstations and build environments fetch code dependencies. Dependency chain abuse results in a malicious package inadvertently being fetched and executed locally when pulled.


## Description


Managing dependencies and external packages used by self written code is becoming increasingly complex given the total number of systems involved in the process across all development contexts in an organization. Packages are oftentimes fetched using a dedicated client per programming language, typically from a combination of self-managed package repositories (e.g. Jfrog Artifactory) and language specific SaaS repositories (for example - Node.js has npm and the npm registry, Python’s pip uses PyPI, and Ruby’s gems uses RubyGems).

Many organizations go to great lengths to detect usage of packages with known vulnerabilities and conduct static analysis of both self-written and 3rd party code. However, in the context of using dependencies, there is an equally important set of controls required to secure the dependency ecosystem - involving securing the process defining how dependencies are pulled. Inadequate configurations may cause an unsuspecting engineer, or worse - the build system, to download a malicious package instead of the package that was intended to be pulled. In many cases, the package is not only downloaded, but also immediately executed after download, due to pre-install scripts and similar processes which are designed to run a package’s code immediately after the package is pulled.

The main attack vectors in this context are:



* <span style="text-decoration:underline;">Dependency confusion</span> - Publication of malicious packages in public repositories with the same name as internal package names, in an attempt to trick clients into downloading the malicious package rather than the private one.
* <span style="text-decoration:underline;">Dependency hijacking</span> - Obtaining control of the account of a package maintainer on the public repository, in order to upload a new, malicious version of a widely used package, with the intent of compromising unsuspecting clients who pull the latest version of the package.
* <span style="text-decoration:underline;">Typosquatting</span> - Publication of malicious packages with similar names to those of popular packages in the hope that a developer will misspell a package name and unintentionally fetch the typosquatted package.
* <span style="text-decoration:underline;">Brandjacking</span> - Publication of malicious packages in a manner that is consistent with the naming convention or other characteristics of a specific brand’s package, in an attempt to get unsuspecting developers to fetch these packages due to falsely associating them with the trusted brand.


## Impact

The objective of adversaries which upload packages to public package repositories using one of the aforementioned techniques is to execute malicious code on a host pulling the package. This could either be a developer’s workstation, or a build server pulling the package.

Once the malicious code is running, it can be leveraged for credentials theft and lateral movement within the environment it is executed in.

Another potential scenario is for the attacker’s malicious code to make its way to production environments from the build server. In many cases the malicious package would continue to also maintain the original, safe functionality the user was expecting, resulting in a lower probability of discovery.


## Recommendations

There is a wide range of mitigation methods which are specific to the configuration of the different language-specific clients and the way internal proxies and external package repositories are used.

That said, all recommended controls share the same guiding principles -



* Any client pulling code packages should not be allowed to fetch packages directly from the internet or untrusted sources. Instead, the following controls should be implemented:
* Whenever 3rd party packages are pulled from an external repository, ensure all packages are pulled through an internal proxy rather than directly from the internet. This allows deploying additional security controls at the proxy layer, as well as providing investigative capabilities around packages pulled - in case of a security incident.
* Where applicable, disallow pulling of packages directly from external repositories. Configure all clients to pull packages from internal repositories, containing pre-vetted packages, and establish a mechanism to verify and enforce this client configuration.
* Enable checksum verification and signature verification for pulled packages.
* Avoid configuring clients to pull the latest version of a package. Prefer configuring a pre-vetted version or version ranges. Use the framework specific techniques to continuously “lock” the package version required in your organization to a stable and secure version.
* Scopes:
* Ensure all private packages are registered under the organization’s scope.
* Ensure all code referencing a private package uses the package’s scope.
* Ensure clients are forced to fetch packages that are under your organization’s scope solely from your internal registry.
* When installation scripts are being executed as part of the package installation, ensure that a separate context exists for those scripts, which does not have access to secrets and other sensitive resources available in other stages in the build process.
* Ensure that internal projects always contain configuration files of package managers (for example .npmrc in NPM) within the code repository of the project, to override any insecure configuration potentially existing on a client fetching the package.
* Avoid publishing names of internal projects in public repositories.
* As a general rule, given the amount of package managers and configurations in use simultaneously, complete prevention of 3rd party chain abuse is far from trivial. It is therefore recommended to ensure that an appropriate level of focus is placed around detection, monitoring and mitigation to ensure that in case of an incident, it is identified as quickly as possible and has the minimal amount of potential damage. In this context, all relevant systems should be hardened properly according to the guidelines under the “CICD-SEC-7: Insecure System Configuration” risk.


## References



1. Dependency Confusion, by [Alex Birsan](https://twitter.com/alxbrsn). An attack vector that tricks package managers and proxies into fetching a malicious package from a public repository instead of the intended package of the same name from an internal repository.

[https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)

2. Amazon, Zillow, Lyft, and Slack NodeJS apps targeted by threat actors using the Dependency Confusion vulnerability.

[https://www.bleepingcomputer.com/news/security/malicious-npm-packages-target-amazon-slack-with-new-dependency-attacks/](https://www.bleepingcomputer.com/news/security/malicious-npm-packages-target-amazon-slack-with-new-dependency-attacks/)

3. The _ua-parser-js_ NPM library, with 9 million downloads a week, was hijacked to launch cryptominers and steal credentials.

[https://github.com/advisories/GHSA-pjwm-rvh2-c87w](https://github.com/advisories/GHSA-pjwm-rvh2-c87w)

4. The _coa_ NPM library, with 9 million downloads a week, was hijacked to steal credentials.

[https://github.com/advisories/GHSA-73qr-pfmq-6rp8](https://github.com/advisories/GHSA-73qr-pfmq-6rp8)

5. The _rc_ NPM library, with 14 million downloads a week, was hijacked to steal credentials.

[https://github.com/advisories/GHSA-g2q5-5433-rhrf](https://github.com/advisories/GHSA-g2q5-5433-rhrf)
Loading

0 comments on commit c7f40e8

Please sign in to comment.