{"id":34,"date":"2022-02-11T12:29:57","date_gmt":"2022-02-11T12:29:57","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=34"},"modified":"2022-02-11T12:29:57","modified_gmt":"2022-02-11T12:29:57","slug":"gitbleed-finding-secrets-in-mirrored-git-repositories-cve-2022-24975","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=34","title":{"rendered":"GitBleed \u2013 Finding Secrets in Mirrored Git Repositories \u2013 CVE-2022-24975"},"content":{"rendered":"

Summary<\/h2>\n

Due to a discrepancy in Git behavior, partial parts of a source code repository are visible when making copies via the \u201cgit clone\u201d<\/a> command. There are additional parts of the repository that only become visible when using the \u201c\u2013mirror\u201d 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.<\/p>\n

Attackers and bug bounty hunters can use this discrepancy in Git behavior to find hidden secrets and other sensitive data in public repositories.<\/p>\n

Organizations can mitigate this by analyzing a fuller copy of their repositories using the \u201c\u2013mirror\u201d option and remove sensitive data using tools like BFG<\/a> or git-filter-repo<\/a> (which do a more thorough job).<\/p>\n

MITRE assigned CVE-2022-24975<\/a> to track this issue.<\/p>\n

[ADDED APRIL 2022: This bug is NOT the same as NotGitBleed<\/a> \u2013 see their website here]<\/em><\/strong><\/p>\n

[ADDED JULY 2024: A more in-depth article<\/a> on this issue from AquaSec]<\/strong><\/p>\n

Technical Details<\/h2>\n

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 \u201cgit clone\u201d<\/a> command. However, this command doesn\u2019t copy all of the data in the originating repository such as deleted branches and commits. On the other hand, there is a \u201c\u2013mirror\u201d 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 \u201c\u2013mirror\u201d command.<\/p>\n

[ADDED July 2024: More technical details are available in this blog post from AquaSec<\/a>]<\/strong><\/p>\n

We also tested forking in GitHub and GitLab, and in both systems forking uses the regular \u201cgit clone\u201d behind the scenes and not the \u201c\u2013mirror\u201d version. That means that repositories containing secrets in the mirrored portion will not propagate those secrets to their forks.<\/p>\n

MITRE assigned CVE-2022-24975<\/a> to track this issue.<\/p>\n

We provide two examples of repositories containing hidden secrets that are only visible when cloning with the \u201c\u2013mirror\u201d option. These can be found here:<\/p>\n

gb_testrepo_delete<\/a> \u2013 secret is retained after a branch is deleted<\/p>\n

gb_testrepo_reset<\/a> \u2013 secret is retained after the git history is reset<\/p>\n

If you try to clone the repository without the \u201c\u2013mirror\u201d option, and retrieve the secret, it will not work:<\/p>\n

And:<\/p>\n

If you try the same with the \u201c\u2013mirror\u201d option, you can now retrieve the secret (also note the larger number of objects retrieved):<\/p>\n

And:<\/p>\n

If you run gitleaks<\/a> on the cloned repositories, no secrets are found:<\/p>\n

\n<\/div>\n\n

However, running gitleaks<\/a> on the mirrored copies, finds the secrets stashed in deleted areas:<\/p>\n

\n<\/div>\n\n

Tooling<\/h2>\n

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<\/a> for figuring out the delta between cloned and mirrored copies of the same repository, and gitleaks<\/a> to scan for secrets.<\/p>\n

For examples on how to use these tools, please see sample scripts that we have published to GitHub<\/a>.<\/p>\n

Mitigations<\/h2>\n

Organizations can mitigate this by analyzing a larger part of their repositories using the \u201c\u2013mirror\u201d option and remove sensitive data using tools like BFG<\/a> or git-filter-repo<\/a>. Garbage collection and pruning in git is also recommended.<\/p>\n

Organizations should not analyze regular cloned copies (without the \u201c\u2013mirror\u201d 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 \u201cgit reset<\/a>\u201d command.<\/p>\n

Branding<\/h2>\n
\n<\/a><\/div>\n

There seems to be a recent trend to name vulnerabilities. While we think it\u2019s silly, why not go with the flow?<\/p>\n

Therefore we named this one \u201cGitBleed<\/strong>\u201c, since it leads to bleeding of secrets from repositories \u2013 with a mirrored logo<\/a> since it involves mirrored repositories.<\/p>\n

Changelog<\/h2>\n

2022-02-11: Initial publication<\/p>\n

2022-02-26: Added CVE reference<\/p>\n

2024-07-02: Added link to AquaSec<\/p>","protected":false},"excerpt":{"rendered":"

Summary Due to a discrepancy in Git behavior, partial parts of a source code repository are visible when making copies via the \u201cgit clone\u201d command. There are additional parts of the repository that only become visible when using the \u201c\u2013mirror\u201d option. This can lead to secrets being exposed via git repositories when not removed properly, […]<\/p>\n","protected":false},"author":0,"featured_media":35,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/34"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=34"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/34\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/35"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}