xmrig injection

[VAVASIN]

Description

The container contains a script that launches xmrig miner
Files: check.sh xmr-go.sh

When it starts, it puts all server processors at 100%

Files

[cameronconradt]

I have had this same issue show up on my device. I stopped it by removing the file from /tmp and restarting the docker.

Currently running v2.31.2 according to TrueNas

[xX-MrN0b0dy-Xx]

I've been running 8 instances of File Browser on a Synology NAS for a couple of months now, never had this problem (currently on 2.31.1, amd64 arch). But I had a friend that told me that someone hacked into his instance and installed an xmring. He thought it was due to a network misconfig that exposed the container to the internet without auth layer...
But it rather seems that someone working on this project is trying to "make some extra" on us...

I strongly suggest you to report this IMMEDIATELY to filebrowser@googlegroups.com as stated here, in order to understand who did this cryptojacking and if the malicious dev also did something worse like accessing the users instances...

[Cecchellone]

Unfortunately, I had the same issue about a month and a half ago.
I thought it was my fault because I had left the default network access open for (literally) just a few seconds before I changed the Docker Compose.
Seeing this issue both reassures me and worries me about the application...

In my case, I had exposed a single Docker volume with the :ro attribute, so I wasn’t expecting any damage. However, I later realized they managed to place (and run) that executable inside the “generic” volume space of the container. My only mistake might have been not exposing the volume as the root of the files shown by Filebrowser, but as a subfolder.

I believe the only reason this could happen is due to the possibility of running commands from within Filebrowser.
The only solution I see is to add SSO compatibility and/or a read-only mode application-wise, for testing purposes.

---

But I had a friend that told me that someone hacked into his instance and installed an xmring....

Hi @xX-MrN0b0dy-Xx 🩵

[rwinkhart]

I just found xmrig running on my server under the user I made for filebrowser. I am not using a container, it is installed natively and I compiled it myself. Something is very wrong here.

Edit: xmrig is tied to the filebrowser process. It dies when I kill filebrowser.

Migrating to Filestash or Nextcloud. The lack of response to this week-old issue kind of kills my trust in this project.

[xX-MrN0b0dy-Xx]

Yes, I'm about to migrate to another project like Zipline too... But I really like File Browser for how lite and "mobile-friendly" it is.
Just to understand, has OP or anyone affected by the problem reported it suing their official channel as stated here?

(I know is new year, but the slow response to something critical like this is killing my trust too...)

[rwinkhart]

Yes, I'm about to migrate to another project like Zipline too... But I really like File Browser for how lite and "mobile-friendly" it is. Just to understand, has OP or anyone affected by the problem reported it suing their official channel as stated here?

(I know is new year, but the slow response to something critical like this is killing my trust too...)

Yes, I reported it by emailing the linked Google group. That was only two days ago, though, as that's when the issue hit me.

Thanks for the Zipline mention, it looks really neat. I might have to check it out. Since most alternatives do a little more than I need, I migrated to gossa in the meantime.

[denyago]

The Virustotal report is concerning. Can anyone explain it?
https://www.virustotal.com/gui/file/9b07af59202ba99bc684889a0c8f6a8bb7e2c9f00eb4e7200c7bb20b64f23c7a/behavior

[9001]

The Virustotal report is concerning. Can anyone explain it? https://www.virustotal.com/gui/file/9b07af59202ba99bc684889a0c8f6a8bb7e2c9f00eb4e7200c7bb20b64f23c7a/behavior

nothing in that report looks concerning to me; what makes you think so?

---

But it rather seems that someone working on this project is trying to "make some extra" on us...

I doubt that this is the case. This is probably just a 0day that somebody found and is taking advantage of.

---

Those of you who hit this issue, can you share some details of your setup? Currently we don't have much to go on. Some rough ideas:

• Did you expose your instance directly to the internet, or through a reverse-proxy?
  • in case you used a reverse-proxy, then which one? and how was it configured?
• Did you have multiple accounts defined? What were their permissions? Did they all have strong passwords?
• Did you keep any logs which could help point in the right direction?
• Did you enable or disable any particular filebrowser features?

My main suspicion is filebrowser's feature for executing commands, but that is just a vague guess as I am unfamiliar with filebrowser, and much less its code.

I am also curious why @xX-MrN0b0dy-Xx has not been hit; is your service also accessible from the internet over IPv4?

---

finally, for those of you looking for alternatives, I am maintaining a list of similar software which may help.

[rwinkhart]

The Virustotal report is concerning. Can anyone explain it? https://www.virustotal.com/gui/file/9b07af59202ba99bc684889a0c8f6a8bb7e2c9f00eb4e7200c7bb20b64f23c7a/behavior

nothing in that report looks concerning to me; what makes you think so?

But it rather seems that someone working on this project is trying to "make some extra" on us...

I doubt that this is the case. This is probably just a 0day that somebody found and is taking advantage of.

Those of you who hit this issue, can you share some details of your setup? Currently we don't have much to go on. Some rough ideas:

• Did you expose your instance directly to the internet, or through a reverse-proxy?

  • in case you used a reverse-proxy, then which one? and how was it configured?

• Did you have multiple accounts defined? What were their permissions? Did they all have strong passwords?

• Did you keep any logs which could help point in the right direction?

• Did you enable or disable any particular filebrowser features?

My main suspicion is filebrowser's feature for executing commands, but that is just a vague guess as I am unfamiliar with filebrowser, and much less its code.

I am also curious why @xX-MrN0b0dy-Xx has not been hit; is your service also accessible from the internet over IPv4?

finally, for those of you looking for alternatives, I am maintaining a list of similar software which may help.

Mine was exposed to the internet through IPv4 only via Caddy as a reverse proxy. My caddyfile was pretty minimal, only specifying tls1.3, logging, and of course a reverse_proxy directive. Only one account was defined and it had a strong password. Through my logs, I was able to confirm I had no logins from unknown IPs. I was using Filebrowser in a stock configuration, but I had it running natively (no container) under its own dedicated user (which let me know pretty quickly what program was responsible for the crypto miner). I saved all of the files it downloaded to /tmp in case they need to be analyzed.

Also I considered Copyparty, lol. Only ended up using something else because I couldn't read the compressed data in the distributed Python file, even with vim -b, for whatever reason.

[9001]

rwinkhart, did you have access-logging enabled in Caddy? If so, have you been able to correlate any of the requests to when the miner was dropped? This would be useful since it could indicate which http endpoint was used. If we are lucky, the attacker forgot to fake the last-modified timestamps of the files in /tmp, which should make it feasible to correlate by timestamp. Or perhaps you have something like netdata running, which would log when the sudden spike in cpu usage occurred?

I'd be amazed if the files it dropped in /tmp would indicate anything about the initial entrypoint, but you never know...

Also I considered Copyparty, lol. Only ended up using something else because I couldn't read the compressed data in the distributed Python file, even with vim -b, for whatever reason.

Hehe, that's as good a reason as any 😁 I'll quickly mention that you can install it through pip install copyparty instead (possibly/preferably in a venv) and then run it with python3 -m copyparty -- not as practical, but the pypi package is just a plain zip-file, so definitely looks less shady 👍

[rwinkhart]

The access logs don't show anything out of the ordinary. I use fail2ban, so duplicate 401s within 10 minutes result in a permanent IP ban, and I don't have any attempted logins that didn't immediately get IP-banned (and very few that got banned at all).

As far as timestamps go, the last modified unfortunately appears to match around the time I found the files (Jan 1st @ 2PM EST). I did tar them, though, so they should be accurate to when I found them. I do not have logging to determine exactly when my usage spiked, unfortunately.

[denyago]

nothing in that report looks concerning to me; what makes you think so?

Some IDS rules hit. Yes, can be a false positive, but why?

Network activity from here - https://www.virustotal.com/gui/file/9b07af59202ba99bc684889a0c8f6a8bb7e2c9f00eb4e7200c7bb20b64f23c7a/relations

Some IPs are related to other detected threats.

[xX-MrN0b0dy-Xx]

The Virustotal report is concerning. Can anyone explain it? https://www.virustotal.com/gui/file/9b07af59202ba99bc684889a0c8f6a8bb7e2c9f00eb4e7200c7bb20b64f23c7a/behavior

nothing in that report looks concerning to me; what makes you think so?

But it rather seems that someone working on this project is trying to "make some extra" on us...

I doubt that this is the case. This is probably just a 0day that somebody found and is taking advantage of.

Those of you who hit this issue, can you share some details of your setup? Currently we don't have much to go on. Some rough ideas:

• Did you expose your instance directly to the internet, or through a reverse-proxy?

  • in case you used a reverse-proxy, then which one? and how was it configured?

• Did you have multiple accounts defined? What were their permissions? Did they all have strong passwords?

• Did you keep any logs which could help point in the right direction?

• Did you enable or disable any particular filebrowser features?

My main suspicion is filebrowser's feature for executing commands, but that is just a vague guess as I am unfamiliar with filebrowser, and much less its code.

I am also curious why @xX-MrN0b0dy-Xx has not been hit; is your service also accessible from the internet over IPv4?

finally, for those of you looking for alternatives, I am maintaining a list of similar software which may help.

I had 8 containers in the same compose running filebrowser v2.31.1 with an uptime of more than 2 months. 8 containers because, given that filebrowser has no ACL, I provided file access to different volumes of my server to my family and a couple of friends thanks to bind mounts and user: directive (can user: this be what protected me? dunno, pretty noob with docker)

Some info:

• Compose were running on a Synology DS920p with DSM7.2.2 (low end x86-64 hardware)
• The container that served my files was the only one running only with an admin account. All the others had the admin user and then a non admin one without the posibility to run commands.
• All the users had paranoid passwords with: at least lenght 64, at least 10 numbers and at least 15 special chars.
• All the containers were exposed to the internet behind a Reverse Proxy with Nginx, each one with a reserved sub-domain and each one had its own access.log and error.log.
• Last but not least these log were fed to a fail2ban jail that detected 401s.

I stopped the containers when I randomly saw this issue, but when I checked:

• Containers and file access logs didn't show any strange behavior and I never had any xmrig, strange files or performance peaks, despite the 2 months and a half uptime
• fail2ban had few (less than 10) failed logins but when I asked around, turned out they were all genuine myspelled password.
• nginx logs didn't show anything strange

The only "particular" thing of my configuration is that I have several fail2ban jails for common bots and urls that on a daily basis tries stupid code injection, tries to retrieve info from my network or remote code execution (eg. Censys, A-Little-Client, LuCI and other stuff that tries to hack old OpenWRT systems).

[Cecchellone]

Here I am.

The Setup

Hey everyone, here's the deal. I was running FileBrowser in a Docker container on two different machines:

• A super low-end x64 box(first-gen Intel Core i3 👴🏼) with Ubuntu Server.
• A Raspberry Pi 5 (ARMv7) also with Ubuntu Server.
  Now, the xmrig miner issue only showed up on the x64 machine. This machine lives outside my home network, specifically at my grandma's house ❤️.

To keep things somewhat secure:

• I set up a WireGuard connection to the machine, routing critical stuff like SSH (port 22) through WireGuard only.
• FileBrowser was reverse proxied via NGINX to the external network, using a dynamic IP and DDNS.
• Later, I added an Authentik Proxy Provider to NGINX (not FileBrowser's built-in auth), but honestly, I have no clue if the xmrig miner snuck in before or after that extra layer
• I was the only one accessing FileBrowser, so no multiple instances nor multiple accounts.

Where I Screwed Up

The container had one volume mounted:

/data/torrents:/srv/torrents:ro

The idea was to make this read-only, just so I could grab my torrents remotely. Sounds good, right? Well, I made a huge mistake.
Instead of mounting the volume directly on /srv, the container still had /srv exposed as writable.

When I checked, I found the xmrig binaries happily running in /srv. My guess? Someone dropped the binaries there and ran them because FileBrowser defaulted to an rw filesystem on that path.

What I Did About It

Unfortunately, I hadn’t had time to set up Fail2Ban or any decent logging system on this new-ish machine. When I realized how bad the situation was, I decided to just nuke it and start from scratch with Debian after a threat suggestion from @xX-MrN0b0dy-Xx .

For Reference

Here’s a simplified version of the Docker Compose file I was using:

services:
  app:
    # Transmission config

  browser:
    image: filebrowser/filebrowser
    restart: unless-stopped
    environment:
      FB_BASEURL: "/browser"
    #  FB_AUTH_METHOD: proxy
    #  FB_AUTH_HEADER: "X-authentik-username"
    ports:
      - 8084:80
    volumes:
      - /data/torrents:/srv:ro
      - ./config.json:/.filebrowser.json
      - ./filebrowser.db:/database.db

P.S. I never was able to setup correclty the proxy auth method, any suggestion with Authentik?

And Nginx configuration:

upstream transmission {
    server <redacted>;
}

upstream filebrowser {
    server <redacted>;
}

# Upgrade WebSocket if requested, otherwise use keepalive
map $http_upgrade $connection_upgrade_keepalive {
    default upgrade;
    ''      '';
}

server {
    # SSL and VHost configuration
    listen                  443 ssl http2;
    server_name             <redacted>;

    include /etc/nginx/ssl/<redacted>.conf;

    # Increase buffer size for large headers
    # This is needed only if you get 'upstream sent too big header while reading response
    # header from upstream' error when trying to access an application protected by goauthentik
    proxy_buffers 8 16k;
    proxy_buffer_size 32k;

    location / {
        # Put your proxy_pass to your application here, and all the other statements you'll need
        location / {
            proxy_pass http://transmission;
            proxy_pass_header X-Transmission-Session-Id;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        # Support for websocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade_keepalive;

        ##############################
        # authentik-specific config
        ##############################
        auth_request     /outpost.goauthentik.io/auth/nginx;
        error_page       401 = @goauthentik_proxy_signin;
        auth_request_set $auth_cookie $upstream_http_set_cookie;
        add_header       Set-Cookie $auth_cookie;

        # translate headers from the outposts back to the actual upstream
        auth_request_set $authentik_username $upstream_http_x_authentik_username;
        auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
        auth_request_set $authentik_email $upstream_http_x_authentik_email;
        auth_request_set $authentik_name $upstream_http_x_authentik_name;
        auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

        proxy_set_header X-authentik-username $authentik_username;
        proxy_set_header X-authentik-groups $authentik_groups;
        proxy_set_header X-authentik-email $authentik_email;
        proxy_set_header X-authentik-name $authentik_name;
        proxy_set_header X-authentik-uid $authentik_uid;

        # Location for Filebrowser
        location /browser {
            proxy_pass http://filebrowser;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

    # Other authentik configurations...
}

Let me know if I can help you with anything else!
I might even be able to recover a snapshot of that machine, but even if I manage to do so, I doubt I’d be able to retrieve any meaningful logs from it.

[9001]

nothing in that report looks concerning to me; what makes you think so?

Some IDS rules hit. Yes, can be a false positive, but why? [...]
Some IPs are related to other detected threats. [...]

regarding the virustotal scan, the suspicious connections are false positives; they do not originate from filebrowser --

Expand this section if you want the detailed virustotal explanation

virustotal's network tracing is systemwide across the entire VM that is performing the scan, and not limited to the uploaded file to be scanned, as indicated by these entries in the report:

TCP 151.101.1.91:443 (extensions.gnome.org)
TCP 151.101.2.49:443 (cdn.fwupd.org)
TCP 89.187.183.12:443 (odrs.gnome.org) 

it's safe to assume that none of these connections are actually originating from filebrowser; they're from other processes on the VM that was performing the scan. For example, extensions.gnome.org is probably gnomeshell. The reason they choose to do analysis this way is in order to catch malicious activity done through ipc indirections (dbus and such), but that is not what's going on in this case.

if we force virustotal to rescan the filebrowser binary (by appending a single byte of garbage), we get completely different results, which supports this explanation: https://www.virustotal.com/gui/file/c98a6a0a72a0163fc86be6286b4fd85b521cf8a0249d8b61da5526bd8d1853b3/behavior

virustotal is a great and valuable tool, but must be interpreted with care. For example, most/all python programs which are compiled to a windows exe will look something like this -- all of these are false positives, and obvious/easy to explain when you know what's going on, but they definitely look scary at a quick glance.