XMRig miner started after shinyproxy installation

[hrbrmstr]

I didn't create the SO question but it belong here not there and I work in cybersecurity so can assist:

Unless someone proves otherwise, after installing ShinyProxy from ShinyProxy.io software, which is a well documented piece of software, the machine started a docker image that runs XMRig that takes 100% CPU usage and might be for bitcoin mining. Below some print-screens. If anyone with similar problem, please let us know.

From: https://stackoverflow.com/questions/45930045/xmrig-docker-using-100-cpu-after-testing-shiny-proxy-software-why

[hrbrmstr]

My first q to the SO OP was which release did they use.

[savon-noir]

Hello @hrbrmstr ,

first thing is to ensure that the docker daemon API is not reachable from the outside world. Lots of scans are being performed all days long to track down open docker daemon api service and launch docker instance from there.
Second, as this issue does not relate to a software issue but a suspected breach, I suggest we close this topic and start a thread via mail. You can reach OA security support at itsupport.at.openanalytics.eu

Could you send us a md5sum of the jar file deployed to the above mentioned e-mail?

[hrbrmstr]

Hopefully the OP chimes in. I just felt compelled to get the issue off of SO and into a place where folks cld poke at it.

And, aye, I'm a cybersecurity researcher http://sonar.labs.rapid7.com/ and wld bet some bitcoin that the issue is on the OP's system end and not ShinyProxy. I went through a decent chunk of the commits earlier and nothing seems to have snuck in here and it doesn't seem to rely on pwnd docker images. But I figured you'd know where to look faster & better.

I'll try to see if I can prod the OP into moving the convo over here.

You are to be commended for your quick response to this, btw. We rarely see that and it's a great example to the rest of the datasci community.

[barnumbirr]

Just chiming in:

[user@host]$ md5 shinyproxy-0.9.4_from_github_releases.jar
MD5 (shinyproxy-0.9.4_from_github_releases.jar) = ca4fe705cedc84601e8486ff0c70d646
[user@host]$ md5 shinyproxy-0.9.4_from_shinyproxy.io.jar
MD5 (shinyproxy-0.9.4_from_shinproxy.io.jar) = 5905b66dbf50f13de2883fe8d2614870

Download links on shinyproxy.io seem compromised.

[savon-noir]

Hello,

Thanks for the suggestions and input. We have internally checked this out with the devs. The .jar are coming from two separate builds. The one on shinyproxy.io is automatically pushed. We have, for now, a manual update on github. Although the source for the jar pushed on github and shinyproxy.io are the same, the "build exercices" are ran in separated environments. Therefore creating jar file with the same source code but different internal structures.

We are now running deeper integrity checks to give us better guarantee that the official repo has not been compromised. In a parallel track, the jar deployments will be also automated for github. We'll keep to issue open until then.

fyi, as a side node, there is a well-known issue in some shinyproxy deployments where the docker daemon is not appropriately protected. To protect a docker daemon the below security controls are mandatory:

• isolate docker host from public/untrusted network
• never bind the docker daemon API on 0.0.0.0, only on the loopback interface (127.0.0.1)
• should the docker api be exposed (in case of a swarm or cloud deployment), ensure to use TLS mutual authentication for enabling communication with the docker api. Its a more heavy setup as it would require a proper PKI or certificate management/creation solution but exposing the docker api should be avoided without appropriate protection.

I suspect that the original issue referenced in Stackoverflow has more to do with this.

Hope it helps!

[tverbeke]

@Mrsmn @hrbrmstr We are now certain that neither of these jar files contains malicious code. The MANIFEST files are different (due to the different build systems) and there are also some minor bytecode optimizations caused by different compiler versions (1.8.0_131 vs 1.8.0_77) on these different build systems.

[rugk]

For now what about providing SHA-256 hashes of the legitimate files? (Maybe also compare with downloaded files few days earlier.)

For the future:

• Consider signing release files?
• Reproducible builds?

[savon-noir]

@rugk thanks for the suggestions. Will be included in our efforts for improving shinyproxy's delivery consistency.

[joniarroba]

Guys, thanks for the support. I am new on Stack Overflow and GitHub so I don´t understand all slangs of cyber security. Anyways, if you need help or changes I have to do on the issues on theses platforms, just let me know, I go ahead and do it.
Joni Hoppen

[tverbeke]

No worries @joniarroba and thanks for your comments. The issue turned out to be independent from ShinyProxy, but it has a.o. been useful to extend the https://www.shinyproxy.io/security/ page, focusing in particular on security controls to protect a Docker host. Without such security, one can become victim of arbitrary containers being launched.

[tverbeke]

For the record: all jar files on Github are now identical to the jar files on https://www.shinyproxy.io/downloads/ and on both sites all jar files have corresponding .md5 with md5 sums.

[rugk]

Cough, cough… MD5 is fundamentally broken… So if you want to compare the files, use SHA-256.

[tverbeke]

For the latest release (1.0.0) we've introduced SHA-256 checksums - thanks for insisting.