Business
Improve your risk posture with attack surface management
Security that enables business outcomes
Gain visibility and meet business needs with security
Connect with confidence from anywhere, on any device
Secure users and key operations throughout your environment
Move faster than your adversaries with powerful purpose-built XDR, attack surface risk management, and zero trust capabilities
Maximize effectiveness with proactive risk reduction and managed services
Understand your attack surface, assess your risk in real time, and adjust policies across network, workloads, and devices from a single console
Drive business value with measurable cybersecurity outcomes
See more, act faster
Evolve your security to mitigate threats quickly and effectively
Ensure code runs only as intended
Gain visibility and control with security designed for cloud environments
Protect patient data, devices, and networks while meeting regulations
Protecting your factory environments – from traditional devices to state-of-the-art infrastructures
ICS/OT Security for the oil and gas utility industry
ICS/OT Security for the electric utility
Stop threats with comprehensive, set-it-and-forget-it protection
Bridge threat protection and cyber risk management
Stop breaches before they happen
Stop adversaries faster with a broader perspective and better context to hunt, detect, investigate, and respond to threats from a single platform
The most trusted cloud security platform for developers, security teams, and businesses
Cloud asset discovery, vulnerability prioritization, Cloud Security Posture Management, and Attack Surface Management all in one
Extend visibility to the cloud and streamline SOC investigations
Secure your data center, cloud, and containers without compromising performance by leveraging a cloud security platform with CNAPP capabilities
Simplify security for your cloud-native applications with advanced container image scanning, policy-based admission control, and container runtime protection
Security for cloud file/object storage services leveraging cloud-native application architectures
Defend the endpoint through every stage of an attack
Stop adversaries faster with a broader perspective and better context to hunt, detect, investigate, and respond to threats from a single platform
Optimized prevention, detection, and response for endpoints, servers, and cloud workloads
On-premises and cloud protection against malware, malicious applications, and other mobile threats
Expand the power of XDR with network detection and response
Stop adversaries faster with a broader perspective and better context to hunt, detect, investigate, and respond to threats from a single platform
Protect against known, unknown, and undisclosed vulnerabilities in your network
Detect and respond to targeted attacks moving inbound, outbound, and laterally
Redefine trust and secure digital transformation with continuous risk assessments
Stop phishing, malware, ransomware, fraud, and targeted attacks from infiltrating your enterprise
Learn about solutions for ICS / OT security.
Stop adversaries faster with a broader perspective and better context to hunt, detect, investigate, and respond to threats from a single platform
Keep ahead of the latest threats and protect your critical data with ongoing threat prevention and analysis
Augment security teams with 24/7/365 managed detection, response, and support
Augment threat detection with expertly managed detection and response (MDR) for email, endpoints, servers, cloud workloads, and networks
Our trusted experts are on call whether you're experiencing a breach or looking to proactively improve your IR plans
Stop breaches with the best response and detection technology on the market and reduce clients’ downtime and claim costs
Grow your business and protect your customers with the best-in-class complete, multilayered security
Deliver modern security operations services with our industry-leading XDR
Partner with a leading expert in cybersecurity, leverage proven solutions designed for MSPs
Add market-leading security to your cloud service offerings – no matter which platform you use
Increase revenue with industry-leading security
Discover the possibilities
We work with the best to help you optimize performance and value
Understanding ChatGPT's potential for misuse via malware creation
Learn more >
How threat actors leverage file-sharing to harvest credentials
Learn more >
Understanding how stolen data is acquired and sold
Protect your organization >
Content has been added to your Folio
Cloud
In this proof of concept, we look into one of several attack vectors that can be abused to attack the supply chain: targeting the developer. With a focus on the local integrated developer environment (IDE), this proof considers the execution of malicious build scripts via injecting commands when the project or build is incorrectly “trusted”.
By: David Fiser Read time: ( words)
Save to Folio
In 2021, we published an entry identifying the weak parts of the supply chain security. In the face of the surge in documented attacks, the entry gave a summarized overview of how malicious actors found gaps to abuse and take advantage of for possible gains and disruptions.
In this entry, we focus on one specific part of the supply chain: the developers themselves. To find a suitable attack model focusing on the developer, we must first understand who is considered the developer (and therefore the target), their workflow, and their daily tools. We also set the focus on how developers and their respective tools can be abused to compromise the supply chain, and how understanding these threat scenarios allows developers and the organizations to decide which tradeoffs to make to protect their projects and themselves.
Who is “The Developer”?
We can use a dictionary definition, stating a developer is a person that develops computer software. In our understanding, a person who writes code. This includes popular programming or scripting languages like Java, JavaScript, TypeScript, Go, Python, C/C++, and many other languages, including infrastructure or container deployment definitions such as Dockerfiles, Kubernetes, Terraform HCLs, and many others. From that description alone, the definition covers various parts of the IT industry, including every person writing code and security researchers, among many others.
Although the workflow itself may vary from developer to developer and from company to company, it will most likely fall into one of the following categories depending on how the developer is using the integrated developer environments (IDE):
As the developer definition covers multiple professions, some workflows could exclude some items from the list. For example, research purpose proof of concept would more likely not set up a whole CI/CD pipeline. However, most workflows will include usage of an IDE for the development. In this entry, we focus on local IDEs, as we also discussed specific platforms in our previous entries on the security risks of online coding platforms.
A Use Case of a Local IDE
When using the local IDE, one of the use cases is when the developer pulls the code to their local computer. This code is further compiled into binary format for it to be executed. There is an implicit trust in the code written by previous contributors because most developers assume that the codebase is likely not “dirty” since it works as intended. This trust is not only carried to and in the source code itself, but also in the build scripts, libraries, dependencies, and other project files when included. That brings us to the first threat scenario: injecting malicious actions into the project files or build scripts.
As developers, do we read the build scripts after pulling remote code prior to their execution?
We tested various popular IDEs and programming languages by injecting malicious build commands to the build scripts or project files if and when applicable. These are the results of version of IDEs we tested:
When we consider the generic threat model, we also must include every non-controlled input. This includes the source code, its files, and including its pre- and post-build scripts and IDE extensions, if applicable. We previously wrote about the danger of possible malicious IDE extensions in one of our 2020 articles.
We defined the following scenarios for each of the IDEs to validate our threat model:
Using Visual Studio Code
Starting with Visual Studio Code version 1.57 (released May 2021), the code editor introduced the concept of Workspace Trust. This feature helps developers safely browse and edit code regardless of the source or authors by preventing code execution from untrusted files and repositories. This is probably due to the increasing number of third party extension vulnerabilities at the time, which — when abused — could allow remote code execution (RCE) when opening an untrusted file. The concept is straightforward: it does not allow any (build/debug) task or some extension features to operate unless the workspace is trusted. This shifts the responsibility to the developer and prompts them to trust or not trust the downloaded code.
The thing to emphasize here is to not blindly trust every workspace.
What should the developer look for and consider as suspicious signs that the code should not be trusted? Among other instances, signs that should raise red flags among developers are:
Prior to executing the IDE tasks, one should verify the .vscode/tasks.json file, especially when downloaded from an unknown source, by auditing the file within the project directory for suspicious or malicious commands.
A malicious command can be hidden under the tasks.json file and masquerade as a build command. When a developer tries to build the previously blindly trusted project above, the developer machine will execute the remote code, which can be malicious. The attacker could also make the payload stealthier by hiding the malicious command between regular build commands. This will raise less suspicion with the developer.
In our simulation, we put a script on a remote server via Pastebin. This is a method abused by some threat actors to deliver their malicious payloads into infected machines. The benefit of this technique for cybercriminals is that the payload can be changed remotely. For instance, the payload can be changed for something harmless after a successful infection.
Using Visual Studio
Visual Studio, the proprietary IDE from Microsoft for .NET and C++ developments, does not have the Workspace Trust feature. As a result, the developer should be extra careful when loading non-trusted project files and executing builds. A malicious pre- or post-build task could be injected into the file, causing unwanted execution from the start of the build.
Using Other IDEs
In the case of Eclipse IDE, the injection of build commands is still possible. Hence, the files differ. At first, a build command of ExternalToolBuilder has to be specified inside the .project file, referencing another file present inside the .externalToolBuilders folder where the actual execution command is defined. By chaining multiple build commands together, we can achieve the same multiple command execution as in the case of Visual Studio Code.
As the project file injection with external build tool is applicable within the scope of the base IDE, it is applicable only for languages where actual code is compiled into a binary file. This includes Java and C/C++, but excludes languages like PHP as no build is performed.
NetBeans IDE is mainly used for Java development, although it also supports PHP, HTML5, JavaScript, or C/C++ developments via a third party extension. Java development projects can leverage Maven, Gradle, or Ant as their dependency management and build automation tool. As such, the project and build definitions may be different. However, all these tools support the execution of third party processes as pre- or post-build actions. In this scenario, an attacker could inject malicious code and hope that the developer will not notice and execute unwillingly.
In the case of Ant, the injection can be done inside the nbproject/build-impl.xml file by adding the following code snippet into one of the suitable targets tags:
<exec executable=”{command to execute}”>
<arg value={argument}/>
</exec>
When the developer uses Maven as the build tool, the same objective could be achieved by altering the pom.xml inside the project folder. This time, the org.codehaus.mojo plugin is used inside the build tag. The syntax used is like the one used with Ant.
In the case of Gradle, a Groovy language script is used for the build definition located inside the app/build.gradle file, and calling the execute() function on a string inside the task of choice will trigger a code execution.
Even though the Open Project dialog has an option for a “Trust Project Build Script”, its functionality is only valid for Gradle projects. When unchecked, it prevents Gradle script priming and, thus, code execution is possible while loading the project as a fix of CVE-2020-11986. Nonetheless, when the user decides to execute the build manually, no further dialogs are shown and the build is considered trusted.
IntelliJ IDEA is another IDE used for Java, Kotlin, Groovy, and other Java Virtual Machine-(JVM) based languages’ development. It also supports Ant building scripts. Loading a project that contains an Ant build script triggers a dialog warning that it might execute potentially malicious code, and advises to use safe mode if it is not coming from a trusted source. When a developer tries to perform a build in safe mode, the IDE warns the user that the action can be done only in trusted mode.
PyCharm is an IDE used for Python development. Python scripts are not usually compiled prior to its execution. However, a developer could still specify a custom Run/Debug configuration, allowing to execute a third party binary before the actual script execution. This might be used for script data input preparation.
The action is referenced inside the project. However, the actual executable specification is stored on a different place, more specifically at ~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml. As we can see, the file is stored inside the user home directory, protecting it against our threat model scenario as it would require local file system modifications.
Conclusion
We evaluated all the identified IDEs with a threat scenario of executing malicious build scripts. We proved that it is possible to inject malicious commands into these build scripts. As described above, some IDEs explicitly warn the developer on the possibility of malicious actions, and unless the project configuration marks them as explicitly trusted it won’t be allowed to perform the task. On the other hand, some IDEs use the assumption that when the developer opens a project or copies it into his workspace, it is automatically trusted and will not require any further action.
No matter what IDE we use, there will be always a tradeoff between security and usability. Developers should not blindly trust every open-source project found on the internet. Prior to any execution of build actions, developers should at least know about the possibility that they can be targeted and review the build scripts.
We would also like to emphasize that the described threat scenario is not limited to local IDEs only, but the fact that security importance lies within the used workflow and workspace trust itself — regardless of the situation/s if the developer executed the actual build/compilation inside a container or VM powering online IDE. Once the workspace is marked trusted and the build script is modified, it could trigger unwanted code execution within the environment and access rights available to the IDE. To mitigate the risk of supply chain compromise using the described threat scenario, here are some best practices developers can keep in mind:
David Fiser
Threat Researcher
Try our services free for 30 days
Select a country / region
Privacy | Legal | Accessibility | Site map
Copyright ©2023 Trend Micro Incorporated. All rights reserved