Security Risks in Online Coding Platforms
As DevOps gained traction and cloud computing usage grew, you can now also code online. Convenient, yes, but are online IDEs secure? To answer this, we will focus on two popular cloud-based IDEs: AWS Cloud9 and Visual Studio Online.
Threat Modeling for Online Coding Platforms
Before cloud integrated development environments (IDEs) became an option, you, i.e., the developer, typically need to download and/or install everything you need onto your own workstations. However, as DevOps gained traction and cloud computing usage grew, you can now also code online. Convenient, yes, but are online IDEs secure? To answer this, we will focus on two popular cloud-based IDEs: AWS Cloud9 and Visual Studio Online.
The difference between local and cloud-based coding platforms is where the bulk of the environment resides. In cloud IDEs, the environment is a virtual machine instance inside your cloud provider. In terms of security, this means you are delegating trust to the cloud provider but you are responsible for preventing the opening of “backdoors” or the introduction of misconfiguration issues to the VM. In the case of using your own device with AWS Cloud9, you are responsible for configuring the device securely.
Figure 3. Working in Visual Studio Online
Linked devices/VMs are not always secure
The question is what is running on the backend. As we described, an SSH-linked device is necessary in order to use these online coding platforms. In the case of Visual Studio Online (still in preview mode as of this writing), we can find a Visual Studio (VS) Code server running on the machine.
Figure 4. Example of vscode-remote inside linked VM
The code server itself is a Node.js application which your browser will connect to. You can also download the whole ~/.vscode-remote folder and run the server inside your local environment.
Notably, you, as the owner of the linked device, have permission to promote yourself to root and install or configure whatever you think you will need. You also have, by default, both Docker and Git preinstalled.
In the case of AWS-hosted Cloud9, the situation is a little more complicated. The backend necessary for platform communication is located inside the linked device while the frontend remains hosted on a different location. But like in VS, you can also promote yourself to root.
This brings us to our first security concern: How secure or private are linked devices/VMs? The linked device contains confidential information — access tokens, application configurations, source code, etc. Needless to say, they should be protected against unauthorized access.
Figure 6. Example of platform confidential information
By default, the platform is secured by the provider. However, you should keep in mind that, together with your root access availability, you are also responsible for preventing misconfiguration issues, especially when using third-party plugins. AWS does not provide plugin support for plugins not developed by them.
There are possible misconfigurations you might make that can lead to security issues, for example, if you set your IDE to be accessible from outside, either intentionally for ease of sharing, or unintentionally. In addition, it is not common for access tokens to be stored in encrypted token vaults; a lot of them can be viewed via plaintext configuration files. Without additional security measures, your access tokens can end up exposed to outsiders.
Once unauthorized access is acquired by cybercriminals, they can compromise your code (an example would be the supply chain attack against a software company that modified software updates with malware) for their own gain.
Browsers can introduce malicious extensions or vulnerabilities
The next security concern is the browser itself. As online coding platforms are accessed from web browsers, you should be very careful when accessing these sites from public, non-domain, shared or unprotected computers.
Malicious browser extensions are a well-known phenomenon. While an untrusted computer possibly infected with malware presents an obvious risk, we also experimentally confirmed via a PoC (proof of concept) that it is possible for an attacker to steal code using a malicious web browser extension.
Figure 7. Example of data sent by the malicious browser extension PoC
Code extensions and plugins can also contain malware
The main advantage of Visual Studio Online and, generally, the VS Code platform, is the number of extensions available. This in itself, however, is yet another possible attack surface.
Let’s imagine a malicious VS Code extension — a useful-looking extension with an embedded backdoor. The lack of permission checking (like disk access, network access, process access, etc.) for extensions during installation or use becomes a security problem. The extent of security checks during extension publishing is limited to having a valid publisherId and a few image-related restrictions. So basically, you have to trust the extension developer entirely.
For demonstration purposes, we created a customized malicious extension PoC containing a reverse shell functionality.
Figure 8. Our malicious VS Code extension description
When installing a VS Code platform extension, you have two options: (1) find it inside the VS Code extension marketplace or (2) install it from a .vsix file.
Figure 9. Example of our malicious VS Code extension description
When developing VS Code extensions, there are some limitations. However, there are no limits or concerns about extensions spawning a new process.
Knowing this, we confirmed that it is possible to execute a reverse shell when the malicious extension is installed and the environment is loaded. A scenario like this gives an attacker full remote code execution (RCE) capability with root permissions under a linked VM. It should be noted that when a developer closes the VS Online webpage, the connection will be terminated.
Figure 10. Spawned reverse shell inside Visual Studio Online platform
Experience showed us that even if the main or core software code is secure, community- or third-party-developed plugins can introduce vulnerabilities that can break the overall security of the software.
No software application is error-free
A recent vulnerability affecting the Visual Studio Live Share extension, which is also available for VS Code, shows that we can expect to see another vulnerability affecting online coding platforms in the near future.
Securing cloud IDEs is a must for DevOps
Threat modeling allows us to understand the different factors at play that can affect the overall security of a computing environment. Cloud IDEs should be no different from other software, if not more critical to secure. Here are some recommendations for each of the security issues we raised:
- For linked device security — Install trustworthy software. Keep that software updated. Don’t indiscriminately open ports to the internet.
- For browsers — Work inside trusted and secured environments. Try to avoid using shared computers. Install browser extensions from trusted vendors only.
- For VS Code extensions — Avoid installing extensions from unknown sources or authors.
- For vulnerabilities in general — Make sure your environment is updated to the most recent version.
Likewise, Trend Micro helps DevOps teams to build securely, ship fast, and run anywhere. The Trend Micro™️ Hybrid Cloud Security solution provides powerful, streamlined, and automated security within the organization’s DevOps pipeline and delivers multiple XGen™️ threat defense techniques for protecting runtime physical, virtual, and cloud workloads.