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

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

Insecure Bootstrap Process in Oracle Cloud CLI

Summary

The bootstrap process for Oracle Cloud CLI using the “curl | bash” pattern was insecure since there was no way to verify authenticity of the downloaded binaries. The vendor is now publishing checksums that can be used to verify the downloaded binaries.

Vulnerability Details

As part of our ongoing research into supply chain attacks, we have been analyzing bash installer scripts using the “curl | basj” pattern. Oracle provides such script used to install the CLI command for interaction with Oracle Cloud. However, there was no way to check whether the files that the script downloads are legitimate, which could potentially open the end-user to supply chain attacks. The installer is run as follows:

bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

Vendor Response

The vendor started publishing SHA-256 checksums for the CLI.

References

Vendor reference # S1456147

Vendor security advisory: Jan 2022

Timeline

2021-04-21: Initial report to the vendor
2021-04-21: Vendor acknowledged the report
2021-05-04: Vendor communicated that a fix is pending
2021-12-28: Vendor reported that a fix has been implemented and credit will be provided in an advisory
2022-01-18: Vendor advisory published
2022-02-06: Public disclosure

WhatsApp for Android Retains Deleted Contacts Locally

Summary

WhatApp for Android retains contact info locally after contacts get deleted. This would allow an attacker with physical access to the device to check if the WhatsApp user had interactions with specific contacts, even though they have been deleted.

Vulnerability Details

When a contact is deleted on WhatsApp, their information about security code changes is retained (while the chat content is not). The only way to get rid of that is to select “Clear Chat” for the contact before deleting it. Even deleting the chat itself doesn’t do it unless the “Clear Chat” operation is done first. The “security code change notifications” option must be enabled in order for this to work.

Someone getting access to the user’s device can figure out whether they ever chatted with specific contacts, even if those contacts and their chats are no longer on the device. This is a privacy issue – especially for people like journalists and those living in dangerous countries.

Since WhatsApp uses Android’s contact app for contact information but supports chats with numbers that aren’t contacts, our theory is that the application retains information about security code changes even for contacts no longer on the device. There seems to be a discrepancy between how the “Clear chat” option and “Delete Chat” options are implemented in the application, with the first option deleting security notification data.

To reproduce:

  1. Delete a chat with a contact that had security code changes before.
  2. Delete the contact from the device via the Android Contacts app.
  3. Re-add contact to the device via the Android Contacts app.
  4. Start a new chat in WhatsApp with that contact but do not send any messages.
  5. Observe that security code changes are listed with dates in the chat.
  6. Select “Clear Chat” to remove the security code changes, and repeat sterps 1-4. Observe that the security code changes no longer appear.

Tested on WhatsApp for Android, app version 2.21.20.20, running on Android 12.

Vendor Response

We haven’t retested on a more recent version but our recommendation to users is to use the “Clear Chat” option in order to prevent this.

The vendor will not be fixing this issue, here is their response:

As part of the attack scenario you describe getting access to a person’s WhatsApp account to obtain private data, as you mention yourself, people do have a way to remove these messages from their account, if a bad actor gets access to their WhatsApp account prior to that person deleting that information then they will be able to view this information. As such, we are closing this report.

References

CWE: CWE-212 – Improper Removal of Sensitive Information Before Storage or Transfer

Facebook # 10102482597361835

Timeline

2021-10-24: Initial report sent to the vendor, report ID assigned
2021-10-27: Vendor asks for more info, additional info and screenshots sent
2021-11-03: Vendor sent interim status report, still investigating
2021-11-09: Vendor rejects the vulnerability and closes the report
2021-12-30: Public disclosure

Firebase CLI Installer Making Calls to Google Analytics

Firebase is a mobile and web application development platform provided by Google. One of the tools available for the platform is the Firebase CLI tool (GitHub repo) which helps developers interact with the platform from command line. An automatic install script is offered among other options, which allows installation of the CLI tool via the “curl | bash” pattern as follows:

curl -sL https://firebase.tools | bash

As part of our ongoing research into supply chain attacks, we have been looking into bash installer scripts that make calls to external systems. First, there is no way to verify that the installer is legit, However, to our surprise, we also found that this script makes calls to Google Analytics as part of the installation process. There is no sensitive data being collected but Google may still be collecting IP addresses of users installing the CLI. The source code for the installer script can be found here:

https://firebase.tools/

While this can be disabled, the documentation to do so is hard to find and is embedded within the installer script itself. We hope that Google will make this documentation more clear in the future. In any case, here is the documentation:

The actual code that makes these calls can be found here:

And here are all the analytics events triggered within the script:

send_analytics_event start
...
send_analytics_event uninstall_npm
...
send_analytics_event uninstall
...
send_analytics_event already_installed
...
send_analytics_event upgrade
...
send_analytics_event "missing_platform_$UNAME"
...
send_analytics_event failure
...
send_analytics_event missing_path
...
send_analytics_event success

New Tools for Addressing Supply Chain Attacks

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):

Security of Homebrew Bootstrap Process

As part of our ongoing research into supply chain attacks, we have been looking into the overall security of various OSS projects. Homebrew is one such project – providing Linux packages for MacOS. The current bootstrap process is retrieving the bootstrap shell script directly from GitHub and piping it into bash without verification as follows:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

We had a discussion with the project maintainers around the security of this approach, and while it is not great security-wise, it is somewhat safer than hosting the script on an intermediate web server (like codecov.io), since changes will be noticed within a GitHub repo fairly quickly (similar to what happened with PHP).

Details of the discussion can be found here:

https://hackerone.com/reports/1166535

Supply Chain Attacks via GitHub.com Releases

Summary

Release functionality on GitHub.com allows modification of assets within a release by any project collaborator. This can occur after the release is published, and without notification or audit logging accessible in the UI to either the project owners or the public. However, some audit information may be available via the GitHub APIs. An attacker can compromise a collaborator’s account and use it to modify releases without the knowledge of project owners or the public, thus resulting in supply chain attacks against the users of the project.

This issue was reported to the vendor – their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details. GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

Background

GitHub.com is a widely used tool for software development offering source code management (SCM) and other tools. It is used for hosting and distribution by many open source projects (OSS). The release functionality within GitHub.com offers a way to publish packaged software iterations as releases. These include a compressed snapshot of the source within the project as a .ZIP and .TAR.GZ file, as well as as additional binary assets. This functionality is a common way for open source projects to distribute their releases.

Vulnerability Details

The release functionality on GitHub.com allows modification of assets within a release by any project collaborator, after the initial release is published. An attacker can use this gap to modify releases without the knowledge of project owners by compromising an account of any project collaborator, thus resulting in supply chain attacks against those using the project. The following specific issues facilitate this:

  • Release assets can be modified after initial publication – except for the source code snapshots
  • Any project collaborator can modify a release – there are no fine-grained controls to allow code access and not release access.
  • There is no notification or indication within the UI that a release was modified – to either the project owners or other collaborators, or the public. However, some data is exposed via API.
  • A “verified” flag is displayed if the Git commit was verified – but this only applies to the source code snapshot and not the other release assets

The releases API provided by GitHub does expose additional information about release assets, which could potentially be used to see if a release was modified. This information includes the username of the uploader and the timestamp when the upload took place. This can be compared to the main release metadata. An example of using APIs for checking releases can be found at our release_auditor project.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Example of a release (see here):

Example of API response exposing asset data:

Steps to Replicate

The following steps can be used to replicate this issue:

  1. Alice creates a public repository on GitHub.com, and adds some code including a shell script “test.sh”.
  2. Alice invites Bob as a collaborator on this repository.
  3. Alice publishes a release including the shell script “test.sh” as a separate asset.
  4. Bob accesses the release, and modifies the “test.sh” script within the release.
  5. When viewing the release via GitHub.com UI, there is no indication the script was modified. Downloading the script shows that it is different from what Alice published.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Vendor Response and Mitigation

The issue was reported to the vendor via their bounty program. Their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details.

GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

An example of using APIs to check releases can be found in our release_auditor project.

References

Example repository: https://github.com/nightwatchcyber/gh_release_test
GitHub.com docs: here, here and here
HackerOne report # 1167780
release_auditor: see here

Credits

Advisory written by Y. Shafranovich

Timeline

2021-04-18: Initial report submitted to the vendor
2021-04-20: Automated response received
2021-04-21: Vendor response received, intended behavior
2021-04-21: Request to disclose sent
2021-04-23: Vendor ok with disclosure
2021-04-25: Public disclosure – added a link to the OSS project

Local Denial of Service in Nissan Leaf EV (2018) Head Unit Display (CVE-2021-1000008)

Summary

The head unit display in the Nissan Leaf electric vehicle (EV) has a local denial of service vulnerability that can be used to lock up the screen. Once locked, the car remains drivable but the display can no longer be used (even if the car is turned off and on). The only way to unlock the screen is by removing and re-inserting the SD card containing the mapping data.

This was tested on the 2018 SV model of the Nissan Leaf, other Leaf models/trims and other Nissan models with similar SOS functionality may also be affected.

This issue has been reported to the vendor (Nissan), NHTSA and ICS-CERT. Since the vulnerability is low risk there is minimal impact on end users. The vendor has confirmed the issue, but no patch is currently available.

Details

The Nissan Leaf is an electric car which contains a head unit with a touch screen interface in the middle of the dashboard. This panel is used for entertainment and navigation functions such as playing music/radio, navigation and interface with cell phone operating systems such as Android Auto and Apple Play. This panel (#3) is separate from the meters and gauges screen (#2) used to display information regarding the operation of the vehicle itself (as seen below – from the owner’s manual):

panel

Additionally, the Nissan Leaf just like many other Nissan models includes an SOS button located on the roof of the car above the passenger seat and is intended to summon help in case of an emergency. This button is paired with the Nissan app and can be seen below (screenshots from Nissan’s video and manual):

Screen Shot 2020-02-11 at 11.44.23 PMScreen Shot 2020-02-11 at 11.45.58 PM

The display has a denial of service vulnerability that can be used to lock up the screen. Once locked, the car remains drivable but the display can no longer be used (even if the car is turned off and on). The only way to unlock the screen is by removing and re-inserting the SD card containing the mapping data. The vulnerability seems to be the result of interaction between the SOS functionality and the rest of the software operating the head unit.

To replicate:

  1. The car being tested needs to be paired with the Nissan mobile app, and have the NissanConnect subscription enabled.
  2. Turn on the car, verify that NissanConnect with SOS functionality is enabled by checking that the little light on the SOS button is lit.
  3. Press the SOS button to trigger an emergency call.
  4. Immediately, press and hold the SOS button to cancel the call while turning off the car.
  5. The SOS call will lock the head unit, and will stay that way until the SD card is removed and re-inserted which reboots the display panel.

This was tested on the 2018 SV model of the Nissan Leaf, other Leaf models/trims and other Nissan models with similar SOS functionality may also be affected. If a NissanConnect subscription is not enabled on a particular vehicle, then it is probably not vulnerable because the SOS functionality is disabled.

Vendor Response and Mitigation

This issue has been reported to the vendor (Nissan), NHTSA and ICS-CERT. Once the report was routed to the correct team, the vendor responded quickly and confirmed the issue. Since the vulnerability is low risk there is minimal impact on end users. No patch is currently available.

A CVE will not be issued for this vulnerability by MITRE since MITRE doesn’t “assign CVE IDs for Local Denial of Service”. A CVE was issued by the Distributed Weakness Filing (DWF) project instead.

References

CVE (DWF): CVE-2021-1000008

ICS-CERT ticket # ICS-VU-984522
NHTSA case # 11308645
Nissan Information Security (IS) Case # 233758
Nissan Leaf (2018) manual: see here

Credits

The original discoverer of this issue is a minor and their full name cannot be disclosed for privacy reasons.

Timeline

2019-09-24: Initial report to the vendor
2020-01-01: Second report to the vendor, automated reply received
2020-01-27: Follow-up email sent to the vendor, no response
2020-01-28: Initial report to ICS-CERT
2020-02-08: Follow-up communication with ICS-CERT
2020-02-11: Draft advisory sent to both the vendor and ICS-CERT
2020-02-12: Reported to NHTSA
2020-02-12: CVE requested from MITRE
2020-02-16: CVE response received from MITRE
2020-02-16: Response from the vendor received (initial reports were misrouted)
2020-02 through 2021-03: Multiple phone and email communications with the vendor
2021-03-14: Public disclosure

2021-04-08: CVE assigned via DWF