Overview
On June 16, 2022, GitHub sent a message to its customers disclosing a bug in GitHub Apps that existed for a 5-day timeframe between February 25 and March 2, 2022 – and which could have been abused to grant excessive permissions to malicious third-party applications
The disclosed bug is the latest example of how third-party integrations can expand organizations’ attack surface by jeopardizing core systems including (but certainly not limited to) GitHub.
The post below shares our current understanding of the GitHub App bug and its implications for GitHub clients security posture. We also share practical mitigation strategies security teams can follow to ensure their organization’s GitHub account hasn’t been compromised.
About the GitHub Apps bug and its implications
According to a GitHub disclosure from June 16, 2022, a bug detected in GitHub Apps allowed privileged escalation from read permission to its equivalent write permission between February 25 and March 3, 2022.
Exploiting this bug would have required:
a) a malicious or compromised GitHub app installed on your organization’s GitHub account before or during that 5-day window
b) a malicious actor familiar with this vulnerability.
Even though GitHub closed the bug in March 3rd 2022, there are several use cases in which a malicious actor could have abused this bug (within this 5-day timeframe) to obtain persistent access and leave long-term effects on your organization’s Github account.
For example, they could have gained long-term access to your company source code by adding a new webhook that leaks the code to an external server, or by adding a rogue user to your organization’s GitHub account. Moreover, a malicious actor could have abused this “elevated permission” bug to inject malicious code to your private repositories.
Remediation guide: immediate steps to secure your GitHub account
We recommend you follow the following steps to verify your Github account hasn’t been compromised:
- Review the GitHub Audit Log (this is possible through the UI) for the relevant dates reported by GitHub within the “vulnerable” 5-day timeframe (February 25 – March 3, 2022), with special attention to the above action types:
- Creating or modifying webhooks: [hook.create, hook.config_changed, hook.events_changed]
- Adding members: [org.add_member, org.invite_member]
- Code editing: [pull_request.merge], especially by non-human actors
- Note any irregular or suspicious activity (and reach out if you have concerns)
Lesson learned: Zero Trust approach for third-party integrations
The GitHub apps vulnerability is yet another example of why organizations should adopt a Zero Trust approach when it comes to app-to-app connectivity, especially when it comes to third-party integrations – ensuring least privileged programmable access where:
- Only critical/required services have access to the organization’s core systems
- Every service has the minimal required access and permissions to perform its job
With the proliferation of third-party services connected to core engineering systems like GitHub, it can be challenging for organizations to minimize their third-party integration attack surface. This is mainly because it requires security teams to monitor and audit not just the applications – but reviewing all app-to-app connections and credentials (OAuth apps, webhooks, tokens, …), along with exposure scoring and ongoing monitoring.
How we can help
Astrix helps security teams control the risks of over-privileged and shadow integrations. With agentless, one-click deployment, Astrix enables security teams to instantly see through the fog of connections and detect redundant, misconfigured, and malicious third-party exposure to their critical systems.
Click here to learn more about ensuring your GitHub is securely connected to cloud services.
