Tools

GitBleed – Finding Secrets in Mirrored Git Repositories – CVE-2022-24975

nightwatchcyber Research, Tools , , ,

Summary

Due to a discrepancy in Git behavior, partial parts of a source code repository are visible when making copies via the “git clone” command. There are additional parts of the repository that only become visible when using the “–mirror” option. This can lead to secrets being exposed via git repositories when not removed properly, and a false sense of security when repositories are scanned for secrets against a cloned, non-mirrored copy.

Attackers and bug bounty hunters can use this discrepancy in Git behavior to find hidden secrets and other sensitive data in public repositories.

Organizations can mitigate this by analyzing a fuller copy of their repositories using the “–mirror” option and remove sensitive data using tools like BFG or git-filter-repo (which do a more thorough job).

MITRE assigned CVE-2022-24975 to track this issue.

[ADDED APRIL 2022: This bug is NOT the same as NotGitBleed – see their website here]

Technical Details

Git is a popular open source tool used for version control of source code. When users make a copy of a local or remote git repository, they use the “git clone” command. However, this command doesn’t copy all of the data in the originating repository such as deleted branches and commits. On the other hand, there is a “–mirror” option which copies more parts of the repository. The discrepancy between the two behaviors can lead to secrets and other sensitive data lingering in the original repository. Additionally, existing tools for secrets detection often operate on cloned repositories and do not detect secrets in the mirror portion of the repository unless cloned via the “–mirror” command.

We also tested forking in GitHub and GitLab, and in both systems forking uses the regular “git clone” behind the scenes and not the “–mirror” version. That means that repositories containing secrets in the mirrored portion will not propagate those secrets to their forks.

MITRE assigned CVE-2022-24975 to track this issue.

We provide two examples of repositories containing hidden secrets that are only visible when cloning with the “–mirror” option. These can be found here:

If you try to clone the repository without the “–mirror” option, and retrieve the secret, it will not work:

And:

If you try the same with the “–mirror” option, you can now retrieve the secret (also note the larger number of objects retrieved):

And:

If you run gitleaks on the cloned repositories, no secrets are found:

However, running gitleaks on the mirrored copies, finds the secrets stashed in deleted areas:

Tooling

There are plenty of existing tools out there that can manipulate git repositories, scan them for secrets and remove specific commits. During our research, we used git for checking out repositories, git-filter-repo for figuring out the delta between cloned and mirrored copies of the same repository, and gitleaks to scan for secrets.

For examples on how to use these tools, please see sample scripts that we have published to GitHub.

Mitigations

Organizations can mitigate this by analyzing a larger part of their repositories using the “–mirror” option and remove sensitive data using tools like BFG or git-filter-repo. Garbage collection and pruning in git is also recommended.

Organizations should not analyze regular cloned copies (without the “–mirror” option) since that may provide a false sense of security, and should not rely on methods of removing secrets such as deleting a branch or rewinding history via the “git reset” command.

Branding

logo

There seems to be a recent trend to name vulnerabilities. While we think it’s silly, why not go with the flow?

Therefore we named this one “GitBleed“, since it leads to bleeding of secrets from repositories – with a mirrored logo since it involves mirrored repositories.

Changelog

2022-02-11: Initial publication

2022-02-26: Added CVE reference

New Tools for Addressing Supply Chain Attacks

nightwatchcyber Research, Tools

In the recent codecov.io security incident, an attacker modified a shell script used by a common software development tool for code coverage. This modification did not take place at the original source code repository where it would have been visible to others, but after the code was packaged and placed on the web server from which it was served.

Prompted by this incident, we are now releasing new tools that provide information and detection of similar attacks against other projects. The scope is limited to attacks that modify the released code and do not touch the original source code. The following tools are now available:

  • dont_curl_and_bash – a list of projects that are installed directly off the Internet via a “curl | bash” manner along with possible mitigations
  • icetrust – a tool that can be used to verify a downloaded artifact such as a shell script before it is executed via methods such as checksums and PGP signatures
  • release_auditor – a tool that can be used to check if a GitHub release was modified after initial publication (see our earlier blog post for additional information)

Additionally, we are also providing two examples of how a continuous monitoring dashboard can be setup to detect such attacks by project maintainers. The following are available (screenshots below):

New Tool – airflowscan – A security checklist and static analysis tool for Apache Airflow

nightwatchcyber Tools

We just release a new set of tools. The intent of this project is provide a basic security checklist for hardening Apache Airflow installations, and a static analysis tool that can be used to analyze the Airflow configuration file for insecure settings. More information can be found at GitHub:

https://github.com/nightwatchcybersecurity/airflowscan