GitHub’s bug bounty program is now a mature component of how we improve product security. We're excited to highlight some achievements (and interesting vulnerabilities)!
Security is core to GitHub’s mission and our Product Security Engineering team is focused on continuously driving improvements to how GitHub develops secure software. One key component of GitHub’s security development lifecycle is our partnership with security researchers and the bug bounty community through the GitHub Security Bug Bounty Program. Launched in 2014, this program and our researchers have amplified our ability to ship secure products beyond what we could have achieved as an independent team at GitHub. Now in its seventh year, GitHub’s bug bounty program is a mature and reliable component of how GitHub continuously improves the security of our products.
In this post, we’re excited to highlight the achievements of the seventh year of our bug bounty program, detail some interesting vulnerabilities we’ve mitigated through the program, look forward to the upcoming year, and invite the community to participate in our ever-growing bounty program.
2020 was our busiest year yet. From February 2020 to February 2021, we handled a higher volume of submissions than any previous year. We’re proud that we’ve kept our time to first reply, triage, and payout for submissions within our aggressive standards as the program has grown. Some highlights from the past year include:
Each submission to our bug bounty program is a chance to make GitHub, our products, the developer community, and our customers more secure, and we’re thrilled with the ongoing collaboration to make GitHub better for everyone with the help of your skills. If you’re interested in participating, visit our website for details of the program’s scope, rules, and rewards.
The creativity and depth of technical talent that we see in submissions to our bounty program continues to impress us. As an example, here’s a closer look at one of the most interesting submissions we received in 2020.
It’s rare to see an open redirect vulnerability carry significant impact or risk to an application. In isolation, open redirects are typically only useful as a stepping stone for social engineering attacks. However, William Bowling (@vakzz) was able to show how an open redirect vulnerability on GitHub.com could be used to compromise the OAuth flow of Gist users.
William found that a method used across a number of controllers on GitHub.com supplied unsafe and user-controlled arguments to Ruby on Rails’ url_for routing method to generate links and redirect locations. By providing a JavaScript protocol handler, cross-site scripting would have been possible, but since GitHub.com has a strong Content Security Policy, the risk of potential XSS was mitigated. However, this generated URL was used as a redirect location and it could be used to redirect users to a location of an attacker’s choice. While the risk is fairly low, this vulnerability could be used to facilitate social engineering attacks by providing a link to GitHub.com that would end up redirecting to an attacker-directed site.
William was able to take the impact of this bug one step further given the prevalence of the vulnerable method across our request handlers. By utilizing this redirect in combination with the OAuth flow that GitHub.com performs to authenticate to GitHub Gist, he was able to redirect the user after a successful OAuth authentication so that the user’s OAuth code would be leaked to a location determined by the attacker. This would have allowed the attacker to log into GitHub Gist for any user they could trick into following their malicious link.
Internally at GitHub we have helper methods, safe_url_for and safe_redirect_to, to prevent these types of vulnerabilities by filtering out untrusted redirect locations, protocols and other risky arguments. To mitigate the open redirect vulnerability, we refactored the vulnerable code to use these safe variants and prevent the user-control of certain arguments to url_for. Additionally, we added a check to our continuous static analysis tooling to detect when url_for is added to new code with user-controlled arguments. By putting these safeguards in place to capture this type of vulnerability, we moved towards eliminating this class of vulnerabilities as a whole across our codebase.
We awarded $10,000 for this submission and we appreciate William’s persistence in continuing to dig in order to demonstrate the impact an open redirect can have when chained with other functionality. You can read more about this vulnerability on William’s blog.
As discussed in last year’s bug bounty anniversary post, in 2020 GitHub became a CVE Number Authority (CNA) with MITRE and we began issuing CVEs for vulnerabilities in GitHub Enterprise Server. Being a CNA allows us to clearly and consistently communicate to customers the issues that are fixed in our products, allowing customers to properly identify outdated GitHub Enterprise Server instances and prioritize upgrades. Additionally, any vulnerability we issue for GitHub Enterprise Server from a bug bounty submission is credited to the researcher in the CVE, allowing us to further recognize those researchers that participate in our program.
To support this process, we formalized our internal workflows for CVE issuance. We created automation that ties into how we track vulnerabilities internally as GitHub issues and standardized the steps to ensure consistent and clear details in our CVEs:
Greg Ose CVEProject/cvelist repository.In the past year, we have continued to refine this workflow and tooling and have published three CVEs for GitHub Enterprise Server. So far in 2021, this workflow has continued to prove successful and has allowed us to quickly complete the CVE process for seven additional advisories. The more CVEs and details we can provide on fixes to our products, the more easily we can communicate the priority of upgrades to our GitHub Enterprise Server customers.
In 2020, we continued our work on private bug bounty programs for beta and other pre-release products in addition to our public bounty program. Private bounty programs help us identify issues earlier in the software development lifecycle for new products and features so that we can more easily roll out architecture and design changes that would be challenging later in development.
One private bug bounty program in 2020 focused on visibility restrictions for GitHub Pages. Historically, when a GitHub Page was published, it was made public to the internet. With this new feature, users have the ability to restrict access to only GitHub users who have access to the underlying repository. This is a great feature that gives you the ability to create internal documentation sites or portals, but it also required complex architectural changes to how GitHub Pages was implemented. This complexity didn’t come without risk, and the Product Security Engineering team worked with our engineers to design the authentication process for GitHub Pages and validate its implementation through internal security testing and code review.
For additional assurance, we also included this feature as a target for a private bug bounty program. We granted our private bug bounty researchers early access to the feature while it was under development in May 2020. Two researchers, Robert Chen (@notdeghost) and Philip Papurt (@ginkoid), were able to identify cross-site scripting and a handful of other vulnerabilities that could be combined to bypass the visibility setting on a GitHub Page! We rewarded these researchers $35,000 not only for the vulnerabilities they identified but also for successfully completing the capture the flag challenge we set up as part of the bounty. We were able to fix the identified issues before this feature launched and also implement architectural hardening to ensure this offering is more resilient to similar vulnerabilities in the future.
In 2020, we also gave our private bug bounty researchers an early look at GitHub Enterprise Server 2.22. This was the first GitHub Enterprise Server release to utilize a new container-based architecture and was the first release to add GitHub Actions, Packages, and GitHub Advanced Security code scanning as beta features. With all of these new features, plus a new architecture, we wanted to add this extra step of review to our security development lifecycle.
This year, we’re continuing to focus on expanding our private program to provide early assurance of new features and product offerings. In June, we launched a new private bounty for Codespaces. Codespaces provides a complete development environment in the cloud which comes with a unique architecture and a unique set of security considerations. The private bug bounty allows us to bring in researchers to help us validate our internal work designing and implementing this service in a secure way. We’re grateful to the participants currently engaged in this private program.
2021 has seen significant investment and growth across GitHub’s security program. In June, we created a new internal team dedicated to the execution and growth of our bug bounty program. If you’re a participant in our program, expect to see some new faces on the other side of your submissions! This team will help further accelerate and refine our triage and response process as well as expand into new initiatives such as live hacking events and additional private bug bounty programs.
As we celebrate the anniversary of the bug bounty program, we would like to extend another thank you to all the researchers who have participated in the program—we look forward to the year ahead! As part of our continued investment in GitHub’s security, we’re expanding the Product Security Engineering team and the broader GitHub security organization. If the work we do in our bug bounty program and throughout our development lifecycle to secure our products and services is interesting to you, check out our open roles at https://github.com/about/careers!
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
