Misconfigurations are the bane of a developer’s existence and a not-so-secret joy for malicious actors. A recently discovered emerging malware campaign focuses on misconfigured servers to gain initial access, then uses traditional Linux attack techniques to deliver a cryptocurrency miner malware and maintain persistence after spawning a reverse shell.
The malware attack begins by exploiting misconfigurations across the following open-source and proprietary web-facing services:
- Apache Hadoop YARN
- Docker
- Confluence
- Redis
How Attackers Leverage Docker
The attack against Docker uses a common technique where the malicious actors:
- Send a Docker command request that spawns a new container
- Create a bind mount in the root directory to replicate the existing directory and files
With the ability to write files to the host, they can engage in a remote code execution (RCE) attack to connect with their Command and Control (C2). Using a Cron job to schedule an executable, the compromised container retrieves the first payload from the C2 server.
To improve their likelihood of success, the attackers also create a second Cron job that targets Python and the urllib2 library.
The Payloads and Persistence
The malware campaign uses new payloads, including four Golang binaries.
The initial payload is a shell script that:
- Defines the C2 domain storing additional payloads
- Checks for the chattr utility to rename it
- Installs the e2fsprogs package and renames it when no chattr utility exists
- Examines whether current user is root before moving on to second payload
The second payload is a longer script that:
- Prepares for additional compromise
- Engages in anti-forensics to evade detection
- Retrieves additional payloads
After gaining initial access, the payload scans a random network segment to identify the default Docker Engine API port, 2375. If the attackers receive successful responses to their HTTP GET requests, they collect these IP addresses to start the infection on a new vulnerable host.
For organizations using Docker containers, the Indicators of Compromise (IoCs) include the following files:
- cronb.sh
- ar.sh
- fkoths
- s.sh
- bioset
- d.sh
Best Practices for Securing Docker Containers
In Docker, the malware campaign relies on Docker container escape vulnerabilities. To mitigate risk, you should implement the following best practices.
Update Host and Docker
Since containers share the host’s kernel, any containers on the host become vulnerable. To mitigate risk, you should:
- Identify all hosts and Docker images
- Scan for vulnerable versions
- Apply security updates to both
Obfuscate the Docker Daemon Socket
The Docker socket is the primary entry point for the Docker API, meaning that anyone who has access to the socket has root access to the host. To protect the Docker socket, you should:
- Disable TCP for the Docker daemon socket to prevent exposing unencrypted and unauthenticated direct access to the Docker daemon
- Change any volumes, like -v /var/run/docker.sock://var/run/docker.sock, that you use to run the Docker image
- Change any volumes in the Docker compose file that are similar to “/var/run/docker.sock:/var/run/docker.sock”
Set a User
To prevent privilege escalation, you should set an unprivileged user across:
- Runtime: using -u option of docker run
- Build: use simple add user in Dockerfile
- Docker daemon: enable user namespace support
Limit Capabilities
You can harden Docker containers by:
- Dropping all capabilities with –cap-drop all
- Adding back some capabilities with –cap-add
- Not running containers with the –privileged flag
Understand Inter-Container Connectivity (icc)
Containers communicate using the docker0 bridged network. Creating custom Docker networks and specifying the attached containers limits communications without disabling it.
Use Linux Security Module
You should maintain the default security profile. No, seriously. This is one of the few “good” defaults to keep.
Integrate Container Scanning Tools
Incorporating a container scanning tool into your CI/CD pipelines enables you to engage in security checks like static code analysis. They can detect known vulnerabilities, secrets, and misconfigurations in container images to mitigate risk.
Use Default Daemon Logging Level
The default configuration is base logging level of info. If you review the configuration file /etc/docker/daemon.json, you should find that the log-file key is missing which means that the logging level is set to info.
Run in Rootless Mode
By running your Docker daemon and containers in rootless mode, you keep them as unprivileged users. Even if attackers break out of the container, they won’t have host root privileges so this limits the attack surface.
Qwiet AI: Integrating Docker Container Security into Development Processes
With preZero, you can scan all the containers that your applications use and correlate these results with the rest of your application scan. You can integrate the preZero platform into your current CI/CD pipelines, ticketing systems, and development tools. By building security directly into your current processes, our platform enables you to incorporate container security into your secure software development life cycle (SSDLC) processes while still ensuring that you get the speed you need to deliver software on time.
The Qwiet AI platform gives you visibility into the context around vulnerabilities so that you can effectively prioritize remediation actions based on whether attackers can exploit a weakness in your application and account for whether attackers are currently exploiting that vulnerability in the wild.
Take our preZero platform for a free spin or contact us today to see how Qwiet AI can help you build container security into your software development processes.
