-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
[BUG] Monero miner spawned inside linuxserver/firefox instance #54
Comments
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid. |
Sounds like you had your Firefox container compromised, I would check to make sure you haven't got it exposed without any authentication. |
Any access to the containers webui also gives access to xterm that's spawned by startvm>openbox, which is why we inquire about if this has been directly exposed to the internet. |
It happened on a server that's completely isolated from the Internet in terms of inbound connections. No outbound firewall rules were in place however. I manage the server using a VPN to which it and I both connect. |
Nothing else runs on the server - no other containers and only the VPN service. Also, only port 3000 was forwarded into the container as shown in the docker run command sample above. In other words, it's not possible that the xterm connection originated from outside of the container. The infection seems to have originated within the container. |
All our code is public, if you really think we've packaged xmrig into our container, that's a bold claim. |
Agreed. Until we find out what spawned the process we don't know who or what spawned it. Nevertheless, the container is a closed environment, except for webvnc port 3000, so the infection (xterm connection) originated from within the container. No plugins or browser add-ons were added. The container was simply started, and used to access a few sites to test connectivity, and then left idle. I'll spin up a new instance of the container, this time without --rm and I'll add a rolling pcap on the host machine to see if I can reproduce the situation and collect more info if/when it happens again. I'll also check the firefox sqlite history database to look for clues. In the meantime, others with the container up and running may want to check for xmrig running and ongoing load averages of 1.0+ |
All of our code, including the builder logs are public: You can find the baseimage codes and build logs by browsing those two as well. I assure you there is no xmrig process in there. You're not the first person to experience rogue processes in docker containers. You most likely got hacked in some way (could even be a separate machine on your network), and the bot/hacker scanned your machines for any processes and containers it could inject stuff into. You might be using a vpn to access your stuff, but the problem is, you're trusting your lan environment. Once that's breached, it's game over. I'd recommend securing your machines and services on the lan as well. That's a common reason for implementing zero trust. As a start, you can put your services behind Authelia/Authentik with 2fa, and not map the docker ports on the host directly. Have your reverse proxy (ie. SWAG) connect to the services over the docker network. |
I understand your suggestions about checking for a lan breach but again there is no way in or out of the container from the LAN (local LAN or the server's LAN) except for port 3000 (xvnc). No ports or protocols are open to the Internet, only the VPN, which connects to my vpn server with myself and that server as the only clients. I don't mean to belabor this point, I just want to make sure you don't dismiss this report by assuming that the network was not secured. I'll do my best to help find the source of the infection. The xmrig binary was dropped into /tmp at 05:05 UTC from an unknown source, likely via xterm as the initial point of entry. Smells like a scheduled task that executed at that time. I noticed node.js is part of the container, so there is a long list of packages therein that could be infected. Note that after restarting the container (new, clean process tree shown below), it didn't spawn an xterm yet or by default. Also comparing this process tree to the infected process tree above it's noteworthy that xterm was spawned by openbox.
|
Did you check the client machines? |
xterm is launched by right clicking on the desktop. |
I didn't assume your network was insecure. I suggested it as a potential entry point. You said your container directly exposes port 3000 on the lan. That port allows a user to access a terminal running in the Firefox container. The only assumption I'm making is that the image we publish does not contain any cryptomining processes. I linked you all of our sources. Feel free to go through them. All we're asking is for you not to make any unsubstantiated claims about our images containing xmrig. Just because you have an xmrig process starting up inside your container, it does not mean we shipped it. There are many other ways it can get in there. |
I found the error, it was user error in the iptables firewall configuration. Port 3000 was indeed being exposed at times to the Internet. Apologies for the confusion, and thanks for your patience. |
Is there an existing issue for this?
Current Behavior
XMRIG, a crypto currency miner, was maliciously spawned by the linuxserver Firefox image. It ran at 100% CPU until terminated. Prior to termination, I backed up the container filesystem for forensic analysis.
The Monero miner spawned after the container had been up and idle for a week or two (note the dates associated with the process listing below for timeline of events).
The pkill and killall binaries had been replaced with bash scripts that prevent the termination of the xmrig process, highlighting the fact that xmrig is intended to run maliciously.
Below is the pool config associated with the xmrig instance that was running.
This is a process listing. Notice how it shows xmrig being spawned by the xterm process, which was spawned by the startwm.sh script.
Expected Behavior
Expected Firefox image to be clean, free of malware, including rogue crypto miners.
Steps To Reproduce
Replace :latest with the tag associated with image ID e57be1fc05b6.
Then let the container sit idle for 3 weeks. At some point the xmrig miner may spawn as it did for me.
Environment
CPU architecture
x86-64
Docker creation
The text was updated successfully, but these errors were encountered: