Kdevtmpfsi - How to Find and Delete That Miner

kdevtmpfsi using the entire CPU

The solution mentioned here worked for us. You basically create the files the miner uses, without any rights, so the miner cannot create and use them.
https://github.com/docker-library/redis/issues/217

touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing

echo "everything is good here" > /tmp/kdevtmpfsi

echo "everything is good here" > /var/tmp/kinsing

touch /tmp/zzz

echo "everything is good here" > /tmp/zzz

chmod go-rwx /var/tmp

chmod 1777 /tmp

How to to trace malware orignation on ubuntu server and stop it

We also faced with this issue, please update first your GitLab to one of the versions:

13.10.3
13.9.6
13.8.8

After that clean crontab connected with git user and remove all the files owned by git user located in /tmp folder.

Now you can restart the server and it should be fine :)

Laravel login not working on production with white page showing request data


Debug.

I had the same issue for almost three days. It turned out to be a cryptocurrency miner script which later introduces a malware, 'kinsing'.

For anyone using laravel for an API, the 'symptom' for me was returning Content-Type header as text/html as opposed to application/json in the responses for all my post requests. This, like the login, would work okay for some time. Also all the responses returned success 200 status code irrespective of what I had in my codebase.

To confirm that this is indeed the same issue for you:

  • RUN: $ top // to check the CPU processes.

You'll notice a suspicious process named kdevtmpfsi or Kinsing using obnoxiously high amounts of CPU. Mine was at 400%.

You may have to check for a while as it sometimes disappears.
If you find the culprit the great, now you know the problem and might want to see issue thread .

Summary of what worked for me.

As suggested in the issue thread above, here's the solution that worked for me.

  1. Found all instances of the associated files.

    • find / -iname kdevtmpfsi
    • find / -iname kinsing
  2. Created and run a script to remove and replace all instances of the files, make them non-executable, and only allow root and one other user to edit them. (You can also run the commands directly in your terminal, from within the 'infected' container). On my server the files were in /var/tmp/kinsing /tmp/kinsing and /tmp/kdevtmpfsi.

     #!/bin/bash
    rm -rf /var/tmp/kinsing /tmp/kinsing /tmp/kdevtmpfsi && touch /tmp/kdevtmpfsi &&
    touch /var/tmp/kinsing && touch /tmp/kinsing
    echo "everything is good here" > /tmp/kdevtmpfsi
    echo "everything is good here" > /var/tmp/kinsing
    echo "everything is good here" > /tmp/kinsing
    chmod go-rwx /var/tmp
    chmod 1777 /tmp
    touch /etc/cron.allow
    echo "root" > /etc/cron.allow
    echo "{other uer}" >> /etc/cron.allow
    cat /tmp/kdevtmpfsi && cat /var/tmp/kinsing && cat /tmp/kinsing

remember to make the script executable if you go the script way


  1. Updated all my docker images. (Deleted old ones then pulled new ones). I want to assume you already know how to do this.

  2. Closed all my ports from the public and only exposed the webserver ports. To prevent future attacks. So the ports section of your laravel app service and db service would be something like this:

    laravel app service

    ports:
    - "127.0.0.1:8000:8000"
    - "127.0.0.1:9000:9000"

    db service

    ports:
    - "127.0.0.1:3306:3306"

    This basically binds the ports to connections only from the host since 127.0.0.1 is only accessible via your machine/server. Port mappings without the localhost binding map the ports to every interface on your machine/server. This is less than desirable if you have a public IP address, or your machine has an IP on a large network and is likely how the attackers accessed your server. Find more on port binding here.

Of course, this depends on the services you want publicly available. The point is not to give the public what they don't need.

Redis using 100% CPU after 6 hours of uptime

The process that is using all your resources is /tmp/kdevtmpfsi. A quick google search showed that it's mining malware. This means that not Redis nor your program has some kind of error. This comment on Github explains how to get rid of it.

question about sercurity flaw for malicious code aeR4Choc injection

Part of the solution has to do with updating your laravel

today I accidentally found my system infected due to a review made from a GoogleAds warning that my site had a virus

So you can see what it is about, look in your access log for the following line:

POST /_ignition/execute-solution

…and you will see that a few lines below you will have this other post:

POST /wJr2TTgX.php HTTP / 1.1 "200 43

To see the full explanation follow this link:

https://www.ambionics.io/blog/laravel-debug-rce

Edit: You can always edit the .env file of what you expose to the world and put it into production mode. The vulnerability only occurs in debug mode.



Related Topics



Leave a reply



Submit