.png)
GitHub announced last Friday that an internal investigation had discovered a breach: attackers had stolen OAuth user tokens issued to third-party vendors, Heroku and Travis-CI. These tokens were then used to download private data repositories from dozens of GitHub customers, including GitHub itself and npm, who had been using Heroku and Travis-CI-maintained OAuth applications.
Github researchers suspect that secrets harvested from these data stores could potentially be used to launch much wider supply chain attacks to gain access to additional infrastructure.
A day after the initial breach discovery, GitHub revoked tokens associated with GitHub and npm’s use of these compromised OAuth applications. GitHub also recommended to Heroku and Travis-CI that they conduct their own security investigations, revoke OAuth user tokens for the affected applications, and notify their users. GitHub customers, in turn, will be notified within 72 hours by GitHub via email with next steps to guide their own response.
While GitHub’s discovery of the breach was relatively quick, we still do not know when the attack took place. Even if the exploit was discovered on the same day of the initial breach, it still left customers potentially vulnerable during the days-long gap between initial discovery, customer notification, and full remediation. This lag-time provides ample opportunity for an attack of this type to metastasize and cause additional damage, pointing to the need of a more proactive defense.
If you haven’t done so yet, we recommend verifying that the following OAuth application are blocked in your GitHub organization and revoking any unknown or unvetted third-party vendor access:
- Heroku Dashboard (ID: 145909)
- Heroku Dashboard (ID: 628778)
- Heroku Dashboard – Preview (ID: 313468)
- Heroku Dashboard – Classic (ID: 363831)
- Travis CI (ID: 9216)
You can follow this guideline to review your OAuth access restriction policy and this guideline to review the OAuth tokens you authorized. In addition, it’s recommended to review the audit log, the user account security log for suspicious activity, installed GitHub Apps, and authorized Personal Access Tokens.
Feel free to contact us at info@valencesecurity.com for further assistance.
After doing this, the first step to secure your SaaS mesh from future supply chain breaches is for security teams to ensure they have proper inventory and monitoring of all non-human third-party integrations into critical SaaS applications like GitHub.
Valence Security can help provide this inventory through a free risk assessment of GitHub or any of several other business-critical SaaS applications. This assessment, which takes minutes, will uncover shadow GitHub Apps, third-party OAuth applications–as well as other third-party integrations connected to that SaaS application, terminated and inactive third-party vendors with valid access tokens to those SaaS applications, and suspicious and risky third-party integrations with high privilege access.
Ongoing use of Valence can help you continuously monitor the topology, configurations, and activities across your SaaS-to-SaaS supply chain to detect new connections, anomalous activities, data leakage, and over-provisioned privileges. In addition, it can extend zero trust principles to your SaaS-to-SaaS supply chain, enabling you to enforce policy controls such as least privilege access, workflow compliance, and revocation of compromised tokens.
This GitHub incident is just the latest in a string of recent attacks leveraging supply chain access to gain unauthorized access to critical business applications and data, and it certainly won’t be the last. You can depend on Valence to help cover your critical SaaS applications.
.jpg)
