You are falling for this hack. Here is how you can help prevent it.

Too many users in web3 are running malicious code on their machines by accident and losing access to their private keys, we explore how docker containers can help.

What a great thumbnail

‍Thank you to The Red Guild for inspiring this post. This article was originally posted here.

Picture any one of these scenarios.

• You roll up to a CodeHawks competitive audit, clone the git repo and type forge test.
• You’re excited to be interviewing for a massive pay job, and you clone the git repo and run npm install.
• You’ve been working on a project for a while and realize some of your packages are outdated, so you update them with npm update, forge install, or mox install.

Well, guess what? If you didn’t take the proper precautions, you’ve just been hacked.

In this blog post, we’ll explore how isolated development environments, particularly using Docker containers, can significantly reduce your risk of falling victim to these kinds of threats.‍

You can watch a video on this here.

The reality of cyber attacks

According to Chainalysis, private key leaks were the most popular attacks in 2024.‍

Data from Chainalysis

There are many ways private key leaks can happen, but for developers and security researchers, the easiest way for such an attack to happen is by running unvetted code. In all three scenarios we gave above (all three also happened in 2024), they all had this issue in common.

Running your code on your host machine gives that code access to your entire machine.‍‍

This is the issue.

One of these private key attacks was a supply chain attack, where the @solana/web3.js package had malware injected into it. When you updated your packages to the malicious version, it would look through your entire machine for potential private keys, connect to the blockchain, and then send your crypto to another wallet!

You can read more about the attack here.

This would have been as simple as running npm update and npm run, and you'd be finished! So, as developers and security experts, we can help protect ourselves by running our code in an isolated development environment.‍

Protecting yourself with isolated environments

While it’s impossible to eliminate all risks in software development, there are a few tools we can use to mitigate potential issues:

• Virtual Machines (VMs)
• Docker Containers
• Physical devices specific for running potentially dangerous code

At Cyfrin, we are big fans of Docker containers, as they are lightweight and developer-friendly environments that most developers should be able to set up without interrupting their flow.

What are docker containers?‍

Docker containers are portable environments that encapsulate your application’s code along with all its dependencies. This means you can run your application in a controlled setting without affecting your host machine. Let’s break down how Docker works:

• Isolation: Each container runs in its own isolated environment, which prevents malicious scripts from accessing your host system.‍
• Controlled access: You can specify which resources a container can access, allowing for a more secure development process. You can specify what you want to give it access to, including filesystems, networking, tools/scripts, libraries, and packages.
• Easy cleanup: If a container is compromised, you can simply delete it without affecting your main system.

Wow, cool lightboard

You can think of a docker container as being a self-contained machine inside of your machine.‍

Web3 dev containers repo

To help developers set up a project that has most of the tools they need already installed, we’ve created the web3-dev-containers repo. It helps users set up an isolated environment.

View the quickstart to get set up with a VSCode-based docker container (called a dev container) so you can run your scripts with an extra layer of safety! This repo will:

1. Spin up a docker container with foundry or moccasin libraries already installed
2. Either all inside your VSCode, or in a raw docker container
3. Make it easy to enter and exit your dev containers so you can be more secure but also developer-friendly

For security researchers:

You should always run client code in a developer container! There have been many attacks where a client asks an auditor to audit some code, and they put malicious code into the audit repo, hacking the auditor’s machine.

AIs like Claude and ChatGPT are really good at docker containers. Give them the repo files as context and ask them questions about what’s going on in the files!‍

Best practices for using docker containers

While Docker helps isolate your development environment, it’s essential to follow best practices to maximize security:

• Use trusted images: Always pull images from reputable sources to avoid incorporating malicious code.
• In our repo, we use a Linux docker image from Microsoft to help set up our containerized environment to resemble an official Linux instance.
• Run as a non-root user: Configure your containers to run as non-root users to limit potential damage from any exploited vulnerabilities.
• In our repo, we create a new user called VSCode.
• Limit container privileges: Be cautious about the permissions you grant to containers, ensuring they have only what they need to function.
• We only download specific packages, like foundry, aderyn, and slither.
• Regularly update your images: Keep your Docker images up to date with the latest security patches and updates.‍

Understanding security implications

Though running applications in isolated environments significantly reduces risk, it’s crucial to remain aware of potential security implications. For example:

• If you mount your local file system to a container, only grant access to necessary files. Malicious scripts could exploit this access if not properly restricted.
• In our repo, we go over both mounted and unmounted options.
• Be mindful of network access. If a container has network privileges, it could be used for malicious purposes, such as launching attacks or stealing data.
• There could always be a docker escape hack we don’t know about, where a malicious script can exit docker! This would be an insane hack, but it could be possible!

It’s important to understand the potential security concerns, as no solution will ever be 100% foolproof.‍

Conclusion

In summary, the key to minimizing your risk of cyber attacks lies in understanding the threats and implementing security practices. By utilizing Docker containers and following best practices, you can create isolated development environments that protect your sensitive information and reduce the likelihood of falling victim to malicious attacks.

Stay safe out there, and remember, while no system is entirely foolproof, informed practices can significantly enhance your security posture!

For further reading on protecting your development environment, check out resources from the Red Guild blog and the GitHub repository for web3 Dev containers.

Originally published at https://www.cyfrin.io.