When security leaders ask developers to take a security-first mindset, it usually takes the form of how they code or set up related application infrastructure. But developers are becoming a conduit for cybercriminal attacks in far more than the traditional application security arenas.
Cyberattackers aren't just going after dev teams for access to the software security supply chain itself. While that carries significant risk, devs frequently have unmitigated access to privileged accounts — and developers' systems are often the least secured in an enterprise. Developers experiment with code in integrated development environments (IDE) that are tough to secure, they often have flexibility to download whatever applications they want on their systems, and their systems are often like Grand Central Station for access across the network.
These realities of modern software make developers the gift that keeps on giving to cybercriminals, who are increasingly finding ways to compromise developers' machines and their accounts. Compromising a development environment can help attackers achieve a range of objectives, including software supply chain attacks. But it could also be simply to do a smash-and-grab breach to steal sensitive data or credentials for easy sale on the black market, or lead to an attacker establishing persistence within a network.
A compromised developer is the common denominator in most of those schemes. And this is just one of many attack scenarios that involve that common denominator.
TrendMicro threat researchers said in an analysis last month that BlackCat ransomware used signed kernel drivers for evasion.The analysis showed that ransomware attacks can help comply with Microsoft code-signing requirements to give them more flexibility in their attacks. The attackers sought out leaked code-signing certificates from compromised environments and aimed to "obtain a new valid code-signing certificate by impersonating a legitimate entity and following Microsoft's process for getting the cross-signing certificate." A compromised developer is the common denominator in most of those schemes. And this is just one of many attack scenarios that involve that common denominator.
The SANS Institute at RSA Conference 2023 named "developers as target" as one of the top five most dangerous attacks. Johannes Ullrich, dean of research for SANS Technology Institute and founder of the group's Internet Storm Center, talked about the growing risk of attacks lodged specifically against developers in a follow-up analysis presented by SANS this week.
"We always talk about supply chain attacks and supply chain is often seen as something sort of fairly anonymous, kind of opaque. But what it really comes down to a lot is developers are now exposed to specific malware, to phishing attempts, and to social engineering that's specifically targeting them."
—Johannes Ullrich
Here's are five reasons why cyber attackers love developers — and what to do about it.
[ Get report: The State of Software Supply Chain Security (SSCS) 2024 | See the Webinar: State of SSCS ]
1. Devs operate privileged accounts
Developers necessarily have high levels of access to systems in order to get their jobs done, and attackers recognize that most organizations are still not very disciplined about how they control permissions and access to these privileged accounts. If attackers are able to compromise developer accounts, it becomes very easy for them to gain access to extremely sensitive systems and data.
Last year's breaches of LastPass offers a striking example of the lengths to which attackers will go to target developers due to the value of their account access. The LastPass adversary was likely seeking customer vault information stored by the company. They started with an attack against a developer's compromised endpoint that gave the criminals access to the company's development environment, and eventually the bad guys were able to steal some source code and technical details. From there, the attackers continued to do reconnaissance and research using that first trove of information to target a different DevOps engineer who had even more valuable access. That engineer was one of only four employees at LastPass with access to the company's corporate vault.
The attacker went after that engineer's home computer by exploiting a vulnerable instance of Plex, a media player, in order to install keylogger malware. By monitoring that, they were able to gain access to the LastPass corporate vault and steal a ton of valuable data, including customer vault back-up data.
2. Devs handle credentials and secrets in bulk
Not only do developers themselves have high levels of access to different systems, but they also handle tons of other credentials in bulk. Devs are like magnets for passwords, API keys, encryption keys, and a range of other secrets necessary for running software in production. Without some level of process management and automated controls to ensure they're properly managing secrets, it is all too easy for developers to leave credentials or secrets vaults expose to attackers who can use that information to completely own vast swaths of infrastructure and data.
Viktor Gazdag, managing security consultant for NCC Group, said the No. 1 CI/CD security best practice an organization can use to protect developers and their work is access hygiene and secrets management.
"If everything moves too fast, there is always a chance for overlooking a setting or drifting where there’s a well-defined setting or organization policy, but we need a temporary ease or temp solution to make it work. As the saying goes, 'the devil never sleeps.' Basic things like password policy, network segmentation, least privilege principal for identities, and updating will help prevent a lot of attacks."
—Viktor Gazdag
A complete secrets management strategy takes foresight, planning and practice so that it can include all of the elements necessary, which includes rotation, key management, auditing, reviewing, monitoring access and alerting based on the audit logs. "And not all CI/CD solutions have complete secret management support, so another tool or process might be required," Gazdag said
3. Devs use unvetted packages, extensions, and plugins
The best developers are tinkerers and are always experimenting with new tools and methods for their work. This means they're constantly running unknown and untrusted code on their systems. Attackers are aiming to take advantage of this, because duping a developer gives them a perfect avenue for getting malicious code executed within corporate environments — and on machines and in environments with high levels of network and system access. Whether it is the new set of AI tools for developers, such as GitHub CoPilot, developers use a range of plugins to get the exact functionality they want for what they're working on, Ullrich said. Those tools are increasingly seeded with malware.
"You may find that some of them aren't just implementing the functionality you're looking for, but they're also implementing some malicious code."
—Johannes Ullrich
The same thing goes for packages. Ullrich explained that even with governance and guardrails around the packages that actually go into the software they develop, developers are going to experiment with and execute code from unvetted packages on their local machines.
"Installing packages is what developers do. They have to install packages and they have to experiment with packages, so you cannot necessarily rely on them only using packages from some very limited set of pre-approved tools. They have to try out something new and see how it works for them, maybe even before they ask for it to be included in a particular set of approved libraries and packs you have."
—Johannes Ullrich
4. Dev tools and endpoint security don't play nicely together
One of the trickiest issues with protecting developers from phishing and social engineering attacks is that the typical endpoint security mechanisms that protect an average user's systems don't play as nicely on developer systems.
Developers tend to be plagued with false positives triggered by very normal development activity —such as executing certain types of code — that looks abnormal on any other machine.
"We have false positive issues. I had a problem with Crowdstrike. Whenever I grep in my bash history — which you often do as a developer — you trigger one of their alerts. As a developer, when you're seeing these alerts, you're somewhat more inclined to call it a false positive, which makes it of course more difficult to secure some of these developer workstations."
—Johannes Ullrich
5. Devs hold the keys to the supply chain kingdom
Attackers love targeting developers because at the end of the day devs hold the keys to the software supply chain kingdom. This is exactly why security researchers are increasingly seeing the prevalence rise in typosquatting attacks in code repositories as attackers seek to trick overwhelmed developers into accidentally using malicious components in their builds with names very similar to common components.
Last month ReversingLabs threat researchers uncovered an example of this technique when they discovered two malicious packages in npm that had a powerful remote access tool (RAT) hidden within them.
Typosquatting attacks hinge on developer inattention to small details in naming — “node” versus “nodejs” in one instance, ReversingLabs researcher Lucija Valentić said in the report.
"However, other details are easier to spot even for harried developers, including suspicious versioning, discrepancies in naming, smaller than expected downloads and dependencies and more."
—Lucija Valentić
