Following media reports that hackers who tampered with a software development tool from a company called Codecov used that program to gain restricted access to hundreds of networks belonging to the San Francisco firm’s customers, cybersecurity experts commented below.
<p><span lang=\"EN-US\">Whenever a third-party dependency or component is used by an organisation, there is some level of trust involved. At the base of every supply chain, there is also a ‘trust chain’ consisting of 3 layers: the system or software is not malicious, the vendor cares about security, and they know how to properly secure the solution they’re providing. <u></u><u></u></span></p> <p> </p> <p><span lang=\"EN-US\">While trust is obviously easier when organisations personally know and have an established relationship with the third party, this privilege rarely exists, making a ‘trust and verify’ approach paramount. This means that organisations trust, but take things a step further by verifying and validating. As malicious actors increasingly zero in on supply chain attacks, both third-party solutions providers and end users must make a more concentrated effort to move beyond a mindset of inherent security trust and shift to a ‘validation before implementation model.</span></p>
<p>This incident is yet another example of development tools being targeted by attackers to conduct attacks on infrastructure. This allows the attackers to potentially distribute malicious code in the future to a large number of users. Given the vast adoption of open source tools, the popularity and reputation of any particular tool also makes it an attractive target for attackers.</p> <p> </p> <p>The issue occurred due to an error in Codecov’s Docker image creation process that enabled the actors to extract sensitive credentials and modify the Bash Uploader script. Consequently, this allowed the actors to potentially exfiltrate sensitive information from Codecov customers’ continuous integration (CI) environments, such as environment variables containing keys, credentials, and tokens, outside of Codecov’s infrastructure. Armed with this data, there’s no shortage of malicious things an attacker could do to development environments that relied on the tool</p> <p> </p> <p>Codecov is an online platform for hosted code test reports and statistics with a customer base of over 29,000 companies and therefore the fallout from this could be huge. Users potentially affected by the attack should follow the advice issues by Codecov and to revoke all credentials, tokens, or keys located in CI processes and create new ones. Developers can determine what keys and tokens are stored in a CI environment by running the env command in the CI Pipeline. Anything sensitive should be considered compromised.</p>
<p>It is becoming more apparent that a proper Crown Jewels Analysis (CJA) approach is required to augment traditional threat intelligence methods to detect attacks and compromises of our systems. The hypothesis behind CJA works by modelling, that in the absence of any Tools, Techniques and Procedures (TTPs) of a threat actor, our most important assets, will behave differently. In the Codecov example, it would of been a change in the services used by the internal devices. In the Solarwinds example, it would of been the behaviour of compromised Solarwinds assets versus non-compromised assets displaying very different sets of activities.</p> <p> </p> <p>Getting the balance right between Threat IoC led detection and CJA led detection will be very important to maintain required levels of boardroom certainty in cyber risk.</p>
<p>The Codecov system breach is yet another example that highlights the need to verify and scan any 3rd party software artifacts introduced to enterprise networks or applications, especially as part of the build chain. Shell scripts, in particular, aren\’t being given enough attention and coverage from a security tooling perspective, making them more exploitable and useful for adversaries.</p>
<p>The parallels between this breach and what we saw with last year’s SolarWinds attack are obvious, and they both point to a worrying trend in cybersecurity. In both cases, we’re seeing attackers leverage weaknesses in supply chain security, and this dynamic means that while it is the vendor that is being initially breached, the impact of that breach is felt by that vendor’s customers.</p> <p> </p> <p>This is a powerful position for attackers to be in, enabling them to pick and choose from a wide number of targets while offering plenty of opportunities to exploit a customer’s trust in their vendors to evade detection.</p> <p> </p> <p>Attacks like this aren’t new, but with software being more interconnected than ever, I predict we’re going to start seeing these sorts of breaches more frequently. This means that code signing is more important than ever and that transparency around the storage and disposal of those code signing keys is going to be a vital step toward building trust in the channels we all use to distribute software.</p> <p> </p> <p>We need to collectively work to ensure that all organizations are given the tools and education required to validate the provenance of the software they use. The nature of these attacks means that mitigating them is going to require a concerted effort between all actors within a supply chain, and there’s still a lot of work to be done to make this sort of collaboration possible on a wide scale.</p>