Docker and the Umami v2 Vulnerability: An Anatomy of an Open Door

The Accidental Exposure: The Trap of Port 3000

In the world of self-hosting, using Docker greatly facilitates the deployment of tools like Umami for web statistics. However, a classic beginner's mistake (or haste) is to map the application port directly to the public interface of the machine. By using a rule like 3000:3000 in your configuration file, you're asking Docker to open this port on all network interfaces, including the internet.

Attackers use automated scanning tools like Shodan or Censys to spot these exposed services. An Umami instance with its port open in this way becomes an immediate target. Once access is gained, the attacker can exploit the service's weaknesses to inject commands and gain control of the container, and potentially the underlying Linux host.

The Critical Umami v2 Flaw

Beyond mere network exposure, the Umami v2 application suffered from critical documented vulnerabilities, notably injection and authentication bypass issues (as discussed on the Umami GitHub). These flaws allow a remote attacker to execute arbitrary code on the server without even needing a valid account. This is the ideal entry point for a botnet.

The flaw often exploits a lack of validation of user input or environment variables during application initialization. In the case of Umami v2, a well-formatted malicious request can force the Node.js server to execute a shell script, thus launching the infection chain that leads to the deployment of cryptocurrency mining tools without the owner's knowledge.

The Malicious Script and Cryptominer Infection

The attack follows a well-known pattern of cryptomining botnets. The first stage involves downloading a discreet shell script, often disguised under an innocuous filename like .win.txt or cron.sh in the /tmp directory. This folder is favored by hackers because it's almost always writable for all system users, including those with restricted privileges.

This script has several missions: to disable local firewalls, remove any rival miners already installed by other groups, and finally download the final payload. In this scenario, it's a miner named javae, an optimized binary to exploit the machine's CPU (Central Processing Unit) at 100%. This malware uses the Stratum protocol to communicate with mining pools like pool.hashvault.pro, draining your resources for the attacker's benefit.

Securing Docker: Best Practices

To avoid this situation from happening again, the golden rule is to never expose an application port directly to the internet. You must force Docker to listen only on the local loopback interface (localhost). Thus, only an internal service like a reverse proxy can communicate with your application, filtering malicious requests along the way.

# Bad practice
ports:
  - "3000:3000"

# Good practice (Listen only locally)
ports:
  - "127.0.0.1:3000:3000"

In addition to this configuration, installing a firewall like UFW on the host and using a reverse proxy (Nginx Proxy Manager, Traefik, or Caddy) allows you to add an essential layer of protection. These tools not only manage SSL/TLS encryption but also enable you to add basic authentication or IP whitelisting before accessing the Umami interface.

Conclusion and Resources

The incident is an excellent cybersecurity lesson. Removing the infected container is the first step, but cleaning up temporary directories and checking for the absence of persistent SSH keys or suspicious cron jobs are just as crucial. A compromised machine should be treated with utmost suspicion, as attackers often leave backdoors.

I might have lost some CPU cycles, but somewhere in the world (North Korea ), a hacker could have bought a coffee, and for not securing my port 3000, I inadvertently contributed to the international economy.

Always keep your Docker images up to date to benefit from the latest security patches and monitor your resource consumption via tools like htop to detect any unusual behavior. To deepen your knowledge on securing containerized environments, you can consult the Docker Documentation or the guides from the OWASP.