On 31st July 2018, Eric Holmes, a security researcher gained access to Homebrew’s GitHub repo easily (He documents his experience in an in-depth Medium post). Homebrew is a free and open-source software package management system with well-known packages like node, git, and many more. It simplifies the installation of software on macOS.
The Homebrew repository contains its recently elevated scopes. Eric gained access to git push on Homebrew/brew and Homebrew/homebrew-core. He was able to invade and make his first commit into Homebrew’s GitHub repo within 30 minutes.
Attack = Higher chances of obtaining user credentials
After getting an easy access to Homebrew’s GitHub repositories, Eric’s prime motive was to uncover user credentials of some of the members of Homebrew GitHub org. For this, he made use of an OSSINT tool by Michael Henriksen called gitrob, which easily automates the credential search. However, he could not find anything interesting.
Next, he explored Homebrew’s previously disclosed issues on https://hackerone.com/Homebrew, which led him to the observation that Homebrew runs a Jenkins instance that’s (intentionally) publicly exposed at https://jenkins.brew.sh.
With further invasion into the repo, Eric encountered that the builds in the “Homebrew Bottles” project were making authenticated pushes to the BrewTestBot/homebrew-core repo. This further led him to an exposed GitHub API token.
The token opened commit access to these core Homebrew repos:
- Homebrew/brew
- Homebrew/homebrew-core
- Homebrew/formulae.brew.sh
Eric stated in his post that, “If I were a malicious actor, I could have made a small, likely unnoticed change to the openssl formulae, placing a backdoor on any machine that installed it.”
Via such a backdoor, intruders could have gained access to private company networks that use Homebrew. This could further lead to data breach on a large scale.
Eric reported this issue to Homebrew developer, Mike McQuaid. Following which, he publicly disclosed the issue on the blog at https://brew.sh/2018/08/05/security-incident-disclosure/.
Within a few hours the credentials had been revoked, replaced and sanitised within Jenkins so they would not be revealed in future. Homebrew/brew and Homebrew/homebrew-core were updated so non-administrators on those repositories cannot push directly to master.
The Homebrew team worked with GitHub to audit and ensure that the given access token wasn’t used maliciously, and didn’t make any unexpected commits to the core Homebrew repos.
As an ethical hacker, Eric reported the vulnerabilities he found to the Homebrew team and did no harm to the repo itself. But, not all projects may have such happy endings.
How can one safeguard their systems from supply chain attacks?
The precautions which Eric Holmes took were credible. He informed the Homebrew developer. However, not every hacker has good intentions and it is one’s responsibility to make sure to keep a check on all the supply chains associated to an organization.
Keeping a check on all the libraries
One should not allow random libraries into the supply chain. This is because it is difficult to partition libraries with organization’s custom code, thus both run with the same privilege risking the company’s security. One should make sure to levy certain policies around the code the company wishes to allow. Only projects with high popularity, active committers, and evidence of process should be allowed.
Establishing guidelines
Each company should create guidelines for secure use of the libraries selected. For this, a prior definition of what the libraries are expected to be used for should be made. The developers should also be detailed in safely installing, configuring, and using each library within their code. Identification of dangerous methods and how to use them safely should also be taken care of.
A thorough vigilance within the inventory
Every organization should keep a check within their inventories to know what open source libraries they are using. They should also ensure to set up a notification system which keeps them abreast of which new vulnerabilities the applications and servers are affected.
Protection during runtime
Organizations should also make use of runtime application security protection (RASP) to prevent both known and unknown library vulnerabilities from being exploited. If in case they notice new vulnerabilities, the RASP infrastructure enables one to respond in minutes.
The software supply chain is the important part to create and deploy applications quickly. Hence, one should take complete care to avoid any misuse via this channel.
Read the detailed story of Homebrew’s attack escape on its blog post and Eric’s firsthand account of how he went about planning the attack and the motivation behind it on his medium post.
Read Next
DCLeaks and Guccifer 2.0: Hackers used social engineering to manipulate the 2016 U.S. elections
Twitter allegedly deleted 70 million fake accounts in an attempt to curb fake news
YouTube has a $25 million plan to counter fake news and misinformation
1- there are no “hack attacks” – hacking is about enjoying playful cleverness – vandalism is about cracking or attacking – there is something called “hacker ethics”, that says that no one should attack, destroy or steal something or someone – please stop spreading such confusion
2- github is now an obscure git host bought by an obscure “software” “company” – software libre projects should only disappear from there from their projects authors, and their authors remove everything and close their account (as i did exactly when i knew that disaster happened) – great that hosts like gitlab and bitbucket are around – github is just toxic for software libre projects
Hi,
Thanks for your insight. Here’s what I think,
1. There are hackers, ethical ones, and unethical ones, and the idea of the article is to spread awareness that unlike Eric, if an unethical one had gained access to homebrew, there might have altered the security formulae and would have a backdoor created on any machine that installed homebrew.
2. The Github-MS deal has touched a lot of nerves and I respect your decision to move from the platform. However, saying migrating from GitHub is the solution to prevent such supply chain attacks feels too simplistic. These kinds of attacks could happen on other platforms as well. The key concern I wished to raise in this article was that open source projects have vulnerabilities just as any kind of app may. The problem amplifies itself as there are many threads and human links on an open source project. The home-brew hacking incident highlights that open source communities need to think through security best practices and processes just as much they think through new features and enhancement proposals for their projects.