Analysis on Docker Hub malicious images: Attacks through public container images
1–10 of 25 posts
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#2Does every “registry” or “hub” have to repeat the same mistakes? It’s not like the same didn’t happened on pypi, npm, crates, and who knows how many others.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#3With Docker, how well is the host protected from malicious images?
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#4With Docker, how well is the host protected from malicious images?
The host should be protected in regards to code execution (Assuming theirs no escape).
The big issues come in the fact that you may pass in proprietary/confidential files, for example Code, which is now at risk of being leaked and the company faces extortion. Or you have a network configuration where the malware can pivot onto another server and now your whole environment is exposed to risk.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#5Honestly, this seems like little. We should be wary of the source we try to pull, but given how easy it is to upload something malicious you’d expect thousands of images of this kind. Maybe DockerHub is already detecting and deleting these packages?
Or why aren’t more people interested in this?
Not sure, but maybe injecting into commonly used libraries via subdependencies is seen as a more effective method, getting more focus. Would be interesting to have a broader analysis of malicious artifacts!
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#6Given that these malicious images seem esoteric (only a few hundred downloads), is this even a threat? Most companies have private mirrors that protect against such attacks.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#7The segmentation into attack vectors is interesting. But images from individuals on something like DockerHub have always been untrusted. I expected to read here about recent compromised official DockerHub library images.
I don't see how that threat is new or now more pressing than ever. How would you even count something like `docker pull vesnpsexga/joomla` as typosquatting vs. `docker pull joomla`? It's not even close.
Users should limit there container runtime/podman/docker access to docker.io/library or use a pull-thru caching feature of their own registry to bring in stuff from hand-selected places in public registries like docker.io or quay.io to environments behind the firewall.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#8this is all trending to a point where the number available libraries for an ecosystem will be seen as a liability rather than an asset.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#9Does every “registry” or “hub” have to repeat the same mistakes? It’s not like the same didn’t happened on pypi, npm, crates, and who knows how many others.
these all inherently trust the code submitted to them. scanning tools cost a lot of money, but even the best scanning tools can't begin to detect malicious activity, because malicious activity often looks exactly like legitimate activity.
Re: Analysis on Docker Hub malicious images: Attacks through public container images
#10Does every “registry” or “hub” have to repeat the same mistakes? It’s not like the same didn’t happened on pypi, npm, crates, and who knows how many others.
these all inherently trust the code submitted to them. scanning tools cost a lot of money, but even the best scanning tools can't begin to detect malicious activity, because malicious activity often looks exactly like legitimate activity.
While no automated tool can accurately catch all malware, I'm building Packj [1] to provide objective security insights into software artifacts. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out spawning of shell, use of SSH keys, mismatch of GitHub code vs packaged code (provenance), etc.