Slack announced its GitHub code repositories had been breached over the new year holiday weekend. The incident involved threat actors gaining access to Slack’s externally hosted GitHub repositories via a “limited” number of stolen Slack employee tokens. Further investigations revealed that the threat actors downloaded private code repositories (so far, no evidence that customer data was compromised).
The spike in API key exploits, such as the Slack attack, repeatedly proves that organizations must protect their API keys as vigorously as they protect usernames and passwords. We have listed below six practical tips to help you minimize your attack surface and avoid similar attacks.
A spike in attacks targeting GitHub account
The Slack exploit joins a chain of attacks targeting GitHub code repositories over the past 12 months, in which attackers take advantage of improperly secured API keys and OAuth tokens to penetrate organizations’ GitHub repositories. One recent high-profile example occurred in April 2022, where attackers used stolen OAuth app tokens issued to Heroku and Travis-CI to breach dozens of GitHub customer accounts through authorized Heroku or Travis CI OAuth app integrations.
What’s more, the current attack against Slack was published merely days after another similar attack on CircleCI was brought to attention. The CircleCI breach exposed its customers to supply chain attacks, in which attackers may use keys and secrets stolen from the CircleCI environment to penetrate their GitHub repositories. In response, CircleCI has urged its customers to detect all connections of GitHub repositories with CircleCI and rotate all secrets, including API, SSH and deploy keys.
Access tokens put you at risk, even if used internally
The attack on Slack is slightly different from the above examples. Upon investigation, it was revealed that attackers first managed to penetrate Slack’s environment and find the necessary access tokens to the company’s GitHub repositories, allowing them to steal some of Slack’s code.
Some keys, such as PAT (Personal Access Token) keys, are frequently generated without proper governance of the security or IT teams. For instance, a developer wants to test a new solution so he generates a token or provides an existing token to an additional service. These tokens usually have forever access, with a high level of permissions. In most cases, they are “set and forget” tokens used once for a test and then left open and connected to the GitHub repository. Examples like this are more common than not. A recent study by the Astrix research team found that GitHub environments among organizations of over 1,000 employees have thousands of connections to internal and third-party services and that the majority are shadow connections, connected with API keys, PAT, Webhooks, and even SSH keys (in comparison to only dozens of integrations to GitHub apps). In addition, every week, anywhere from 20-30 new personal access tokens are generated.
These numbers explain why attackers increasingly abuse these open-ended GitHub connections to compromise companies’ code, customers’ code, and other sensitive data.
The spike in API key exploits, such as the Slack attack, repeatedly proves that organizations must protect their API keys as vigorously as they protect usernames and passwords. Leaking or breaching an API key can have more fatal consequences than a username and password login, since logins are often protected by two-factor authentication, whereas API keys are not.
Six tips to reduce your Git platform attack surface
Discovering all the access tokens and understanding their permissions and the exposure they inflict might be a tedious and time-consuming task since they are usually created by DevOps, Dev, and IT teams without any governance or proper vetting process and documentation. Furthermore, this type of monitoring should be conducted on an ongoing basis since, over time, these connections, whether through OAuth token, PAT, API keys or service accounts, may change their usage purposes, and level of permissions.
There are some best practices organizations can follow to reduce their exposure to such threats:
- Educate users to keep their tokens outside of their local machines (in a secret manager, for example).
- Set a short expiration time for tokens.
- Rotate tokens periodically.
- Avoid highly privileged tokens with a wide array of access types (metadata, code, administration), and use dedicated tokens instead where possible.
- Regularly identify and revoke unused tokens (read the following paragraph to learn how Astrix Security Platform can help).
- For GitHub users, replace classic PATs with new fine-grained PATs and restrict them to a specific repository where possible.
How Astrix can help
The Astrix Security Platform provides a consolidated, comprehensive view of all the internal and third-party integrations with your GitHub environment (repositories, workflows, and configurations), as well as all access keys in use and the level of access and permissions granted to each one. Our platform automatically identifies and allows rapid mitigation of risky connections related to suspicious third-party integrations, anomalous behavior (like suspicious source IPs), overly permissive integrations, redundant applications, and insecure tokens.
Contact us to meet with Astrix security experts for a complimentary scan of your Git environment to discover and remediate all risky shadow connections.
