A new security analysis of the 4 million container images hosted on the Docker Hub repository revealed that more than half contained at least one critical vulnerability. The review also identified thousands of images that contained malware or potentially harmful applications, highlighting the need for organizations to have strict policies and review processes in place for sourcing container images and third-party software components in general from public repositories.
Attacks that exploit the software supply chain are not new, but the growing popularity of DevOps, agile development and microservice-based software architecture powered by container technologies have fueled growth for public registries that host pre-made software components and images. In turn, this has led to attackers trying to exploit these relationships by publishing malicious code on these package repositories either directly or by compromising existing accounts.
According to the Sonatype report, Docker Hub saw the addition of 2.2 million container images over the past year and is on track to receive 96 billion image pull requests from developers this year.
Vulnerable Docker images
Container technologies like Docker brought major improvements to the speed with which companies can deploy and scale their applications. For example, pulling a pre-built Docker image containing an instance of MySQL from a public registry like Docker Hub to be used by an application takes seconds compared to manually installing and configuring the database server.
However, when using any third-party package in their own projects, organizations must always be aware of the risk of downloading and running outdated versions with known vulnerabilities. Docker containers are no different in this respect and in fact the risk is higher because they include full software stacks that have an OS layer and application layer and not a single package.
According to Sonatype’s analysis, at least 11% percent of open-source components consumed by developers have at least one known vulnerability, but this can vary significantly across programming languages and package repositories. For example, a 2019 analysis of the npm registry found that nearly 40% of hosted packages relied on code with known flaws.
When it comes to Docker images hosted on Docker Hub, the results of a full repository scan published today by threat analysis firm Prevasio revealed that 51% of all container images had critical vulnerabilities, 13% had vulnerabilities classified as high severity, and 4% had moderate flaws.
This shows that the risk of running outdated software as a result of images pulled from Docker Hub is high, but it can be reduced by choosing reliable publishers who keep their images up to date and by having policies in place that require vulnerability scanning and configuration analysis of Docker images at the time of deployment, as well as at regular intervals.
In September, Docker announced a partnership with security firm Snyk to integrate native vulnerability scanning capabilities on Docker Desktop and in Docker Hub. However, there is another risk associated with Docker images from third-party sources that’s harder to mitigate—images with malware or trojanized applications.
Malicious Docker images
All software repositories and app stores are targets for hackers interested in pushing malware to unsuspecting users and the success of these attacks depends on how closely these repositories are policed. During their analysis, researchers from Prevasio identified 6,433 images that were malicious or potentially harmful, representing 0.16% of the entire Docker Hub registry.
“If a company’s developer takes a shortcut by fetching a pre-built image, instead of composing a new image from scratch, there is a viable risk that such pre-built image might come pre-trojanised,” the Prevasio researchers warned. “If such image ends up in production, the attackers may potentially be able to access such containerized applications remotely via a backdoor.”
Cryptocurrency miners were the most common type of malware found in Docker images, accounting for 44% of the malicious images. Another 23% contained a Bitcoin wallet stealer in the form of a npm package called flatmap-stream, 20% contained various hacking tools such as post-exploitation frameworks that provide attackers with backdoors and 6.5% represented Windows malware.
“Our analysis of the malicious container images revealed a wide usage of cross-platform code, in particular GoLang, .NET Core and PowerShell Core,” the researchers said. “The portability of the cross-platform code is lucrative for the attackers as it increases ROI for their efforts. That is, malicious code they write does not have to be written multiple times for multiple platforms. It can be written once, and run everywhere, including Linux containers. As a result, a large number of offensive security frameworks and post-exploitation tools, such as Mimikatz or Caldera, can now be found in Linux Docker containers, facilitating the proliferation of well-evolved malicious Windows techniques into the world of Linux.”
Prevasio also found images with trojanized applications, for example backdoored versions of WordPress, the Apache Tomcat web application server or the Jenkins CI/CD tool. In some cases, container images included artifacts such as spam web pages that were likely a result of a malware infection on the computer that was used to generate them.
Offline scanning of container images with an anti-malware product might not be enough to catch such threats because attackers are increasingly using dynamic payloads. This means the malicious payload is downloaded and installed in the container when after the image is first deployed.
“Our analysis of malicious containers also shows that quite a few images contain a dynamic payload,” the researchers said. “That is, an image in its original form does not have a malicious binary. However, at runtime, it might be scripted to download a source of a coinminer, to then compile and execute it.”
Catching these requires dynamic analysis tools where the image is run and monitored inside a sandbox similar to those used to detect if Windows executables are malicious by analyzing their behavior at runtime.
Original article source was posted here