Introduction
For attackers targeting technology businesses, the goal is often stealing intellectual property and other data, which can either be sold for profit or used for other purposes. This makes developers a targeted role. A key reason to target developers is that they often have administrator privileges across various systems, especially Git repositories. It’s common for Git repositories to hold important data and in many cases, secrets that can be used to access other critical infrastructure environments of the organization.
This is the second post in our series on the history of supply chain attacks. In this post, we will focus on the importance of monitoring the access to source code management systems, identifying abnormal activity, and steps to reduce such risks.
Sawfish Phishing Campaign
In April of 2020, GitHub repositories were targeted once again, but in this case, the Sawfish attack was initiated via a clever phishing tactic targeting developers.
The phishing campaign lured targeted GitHub users to domains that look similar to legitimate GitHub instances at first glance but were actually clever fakes. Examples for such domains are git-hub.co, sso-github.com, and corp-github.com. Other domains misspell the ‘i’ in GitHub with an ‘l’, like glthub.info. The attackers also tried domains that look like those owned by other tech companies, such as aws-update.net and slack-app.net.
The attackers used several techniques to hide the real link destination, including URL shorteners. They also use redirects, on compromised sites that had legitimate-looking URLs, to trick victims into browsing to the attackers’ malicious sites.
The phishing emails often claimed their victims’ accounts, or the repositories within them, had been compromised, or other potentially unauthorized activity had been detected.
Another example would be:
Once the targeted user entered his login into the phishing site, the attacker could steal the account. As evidence of its sophisticated nature, the Sawfish attack was designed to work even when users had TOTP-based two-factor authentication by relaying the TOTP codes to the attacker and user in real-time. (However, accounts protected by Hardware security keys are not vulnerable to this attack).
With unrestricted access to the developer’s account, the attackers could then download the contents of private repositories, typically owned by the organizations they work for, containing valuable source code.
Furthermore, the attackers could even use GitHub OAuth tokens to access the victim’s accounts after passwords had been changed because the OAuth tokens authorized access for a predefined period regardless of password updates. Alternatively, they could create a GitHub personal access token, which allows the user to access their GitHub account using the Security Assertion Markup Language (SAML). This is an open authentication standard often used for single sign-on (SSO) access. Setting up an SSH certificate to access a logged-in account is also trivial. If the victim of a phishing attack didn’t review their SSH certs, the attacker could continue accessing the account covertly for a long time.
Why Sawfish is Such an Important Supply Chain Attack
While any phishing attack is a problem, getting access to a GitHub user’s private repository means access to the source code AND keys to access online applications and SSH keys, along with login credentials for other online services. This can be more harmful if the user has access to sensitive assets within the organization. Not only is Sawfish an attack through an organization’s software supply chain, given the nature of the access that it provides in code repositories, attacks like it could be used to turn its victims into vectors for new supply chain attacks.
Reducing Your Vulnerability to Sawfish Style Supply Chain Attacks
To protect your organization from Sawfish-style attacks we recommend considering the following mitigation steps in your source control management systems.
- Monitor clones and forks of the repositories, and try to identify any suspicious activities, such as:
- Has the forked repository remained private or is now public?
- Has the forked / cloned repository included sensitive information or secrets?
- Has the forked / cloned repository been downloaded as a .zip file?
- Harden your authentication policies:
- Software MFA is a good first step, but consider using hardware security keys for maximum security.
- Consider using a browser-integrated password manager to provide a degree of phishing protection by autofilling or recognizing only a legitimate domain for which you have previously saved a password.
- Determine what additional access an attacker could obtain with valid repository credentials:
- Consider enforcing least privilege policies to reduce the scope of access – Ensure that source code and infrastructure-as-code repos are in different security teams.
- Consider enforcing IaC best practices policies to ensure key assets, such as S3 buckets or RDS DB, are not publicly exposed.
- Consider signing code commits and peer reviews code before merging to make it harder for attackers to insert code into the master branch.
How Cycode Can Help
Crises are a time for the community to come together. As such, Cycode is offering a free code repository security assessment to any organization that is looking to harden their development infrastructure. Alternatively, if there is some other way we can help your organization, please get in touch with us.
