The bootstrap process for Google’s cloud SQL Proxy CLI uses the “curl | bash” pattern and didn’t document a way to verify authenticity of the downloaded binaries. The vendor updated documentation with information on how to use checksums to verify the downloaded binaries.
2022-08-30: Initial report to the vendor 2022-08-30: Vendor acknowledged the report 2022-09-27: Vendor rejected the report as a security issue 2023-03-03: Vendor reported that a fix has been implemented 2023-03-19: Public disclosure
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).
[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.
We provide two examples of repositories containing hidden secrets that are only visible when cloning with the “–mirror” option. These can be found here:
gb_testrepo_reset – secret is retained after the git history is reset
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
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.
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:
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
Over the last few weeks, security teams everywhere have been busy patching Log4J vulnerabilities. In this article we want to talk about the three things you can tell your friends why this is way worse.
Ubiquity
This vulnerability impacts impacts Java applications and those can be found almost anywhere: enterprise, vendor applications, database drivers, Android phones and even the smartchip on the credit card in your wallet (Java Card). Additionally, majority of Java applications use log4j to handle logging, often involving user input. While your phone is probably not exploitable, the sheer number of places where log4j can be hiding makes this is hard to fix.
Severity
There are vulnerabilities that come out all the time, but few of them reach the highest possible level of severity: remote code execution (RCE) and this one hits that ticket. That means that every server running Java within your company becomes everyone’s computer – an attacker can run anything they want there and then use that as a springboard to tunnel in further.
Exploitability
There are many severe vulnerabilities out there that require specialized knowledge to exploit including speaking dead computer languages and building weird binaries during a full moon. With this one, you can begin the exploit by copy/pasting a tweet into a search bar combined with DNS.
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:
Delete a chat with a contact that had security code changes before.
Delete the contact from the device via the Android Contacts app.
Re-add contact to the device via the Android Contacts app.
Start a new chat in WhatsApp with that contact but do not send any messages.
Observe that security code changes are listed with dates in the chat.
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.
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
Substack had a open redirect vulnerability in their login flow which would have allowed an attacker to facilitate phishing attacks. The vendor has deployed a fix for this issue.
Vulnerability Details
Substack is an online platform that allows users to create and operate free and paid subscription newsletters. This platform had an open redirect vulnerability in its login flow which would redirect users to any sites after login completed. This could have been used by an attacker to facilitate phishing attacks targeting Substack users and steal their credentials.
The vulnerability was due to the fact that the “redirect parameter” in the login flow wasn’t been validated to make sure that the redirect only goes to a specific set of URLs. The attacker could specify their own redirect URL as follows:
Once a correct reporting channel was established, the issue was reported to the vendor and a fix was deployed limited the redirect parameter to Substack-specific URLs.
2021-07-08: Initial contact with the vendor, asking for a correct reporting channel 2021-07-09: Initial reply received, confirming communication channe again – no response from the vendor 2021-07-13: Pinged again – no response; pinged company co-founders on Twitter 2021-07-13: Communication with the vendor re-established, technical details sent 2021-07-23: Pinged for status, no response 2021-07-29: Vendor responded that a fix has been implemented 2021-07-29: Fix confirmed, vendor pinged for disclosure coordination – no response 2021-08-22: Public disclosure
Our talk titled “The Poisoned Diary: Supply Chain Attacks on Install Scripts” was accepted at this year’s @Appsec_Village @DEFCON 29.
UPDATE: It will take place on Sunday, August 8th, at 9:05 AM PST / 12:05 PM EDT. Details can be found here – Q&A will take place on DEFCON’s Discord server.
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:
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:
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):
Nightwatch Cybersecurity 
