☰

VPS 被用于比特币挖矿。如何识别漏洞？

tag-icon • tag-icon apache-2.2 vps hacking
VPS 被用于比特币挖矿。如何识别漏洞？

我运行的用于托管一些基本网站的 ubuntu VPS 似乎已经遭受了 apache 攻击以进行比特币挖掘。

在我的 apache error.log 中我看到以下内容。

[Sun Dec 15 06:27:58 2013] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with
Suhosin-Patch configured -- resuming normal operations
[Sun Dec 15 06:27:58 2013] [info] Server built: Jul 12 2013 13:38:21
[Sun Dec 15 06:27:58 2013] [debug] prefork.c(1023): AcceptMutex: sysvsem (default: sysvsem
[Sun Dec 15 09:14:16 2013] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 18 total children
curl: try 'curl --help' or 'curl --manual' for more information
./tmp.sh: 1: ./tmp.sh: ^M: not found
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
^M  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0^M100  165k  100  165k    0     0   402k      0 --:--:-- --:--:-- --:--:--  460k
./tmp.sh: 2: ./tmp.sh: ^M: not found
./tmp.sh: 3: ./tmp.sh: ^M: not found
./tmp.sh: 4: ./tmp.sh: ^M: not found
./tmp.sh: 5: ./tmp.sh: ^M: not found
./tmp.sh: 6: ./tmp.sh: ^M: not found
[2013-12-15 10:06:35] Starting Stratum on stratum+tcp://mine.pool-x.eu
[2013-12-15 10:06:35] 1 miner threads started, using 'scrypt' algorithm.
[2013-12-15 10:06:36] Stratum detected new block
[2013-12-15 10:11:05] Stratum detected new block
[2013-12-15 10:12:46] Stratum detected new block
[2013-12-15 10:13:15] Stratum detected new block

计划是重建我的 VPS，但首先我想确切了解这是如何发生的，而且我遇到了一些死胡同。以下是我注意到/尝试过的一些事情：

  1. 我可以重启我的 VPS，但挖矿似乎要几个小时后才能重新开始。这是 CRON 作业吗？（它似乎每天上午 10 点左右重新启动）。

    • 这是在 CRON 作业上启动的吗？似乎在 crontab 中找不到任何东西，但我有其他地方可以检查吗？
    • 他们是否拥有我的 VPS 的 IP 地址并利用我的服务器漏洞？我该如何检测，错误和访问日志尚无定论。

  2. 看起来不是一个 WordPress 漏洞

  3. 我已经设置了 lastcomm，对于 www-data 用户，我看到以下内容 - 这显然是正在发生的攻击。我如何才能获得有关正在发生和正在运行的事情的更多信息？

    $sudo lastcomm www 数据 在此处输入图片描述

  4. apache2 和 httpd 进程有什么区别？

    在此处输入图片描述

  5. 我现在注意到以下访问日志条目，但从未与挖掘重新启动的时间一致：

    177.10.216.85 - - [15/Dec/2013:14:19:01 +0000] “POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C$

  6. 我还对该进程运行了 pwdx，它只返回了以下内容

    4529：/

    而 MySQL 进程返回以下内容。

    2298：/var/lib/mysql

更新：

我不认为这是 plesk 漏洞，因为 apache 返回的是 404（正确吗？！）我现在非常确定这只是一个隐藏的 CRON 作业或类似的东西。甚至可能是一个隐藏的进程。他们最初是如何进入的，我真的不确定！

46.137.41.30 - - [26/Dec/2013:13:25:26 +0000] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 493 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"

答案1

您是否尝试过解码访问日志中的那个奇怪的字符串？

粘贴此字符串：

%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C$

在此站点中：

http://www.url-encode-decode.com

对解码后的 ASCII 文本进行快速谷歌搜索表明，这是一个Plesk 漏洞正在被利用。

http://about-threats.trendmicro.com/RelatedThreats.aspx?language=au&name=The+Perils+of+the+Plesk+Zero-Day+Exploit

答案2

你可能没有遇到和我一样的问题，但是我的 VPS 被利用了 JBoss 漏洞，他们安装了一个 web shell（pwn.jsp），然后使用它下载了一些 perl 后门 shell。

我只是想说要警惕攻击者可能留下的其他后门。我发现我的 JBoss 管理控制台目录中有一个名字奇怪的 WAR 文件，部署后攻击者可以在我的 JBoss 安装中部署他选择的任何应用程序

我在另一个帖子中有更多详细信息stackoverflow 帖子和更多内容请参阅博客文章

答案3

cron 作业定义将以文本文件的形式位于以下任何可能的位置：

  • /etc/cron.d/
  • /etc/cron.daily/
  • /etc/cron.hourly/
  • /etc/cron.monthly/
  • /etc/cron.weekly/
  • /var/spool/cron/crontabs

前 5 个是基于系统的 cron 文件夹，通常都在根级别运行，最后一个是包含每个用户 cron 的目录（例如，当您运行crontab -e或crontab -l它将从该目录加载时，每个创建了 cron 作业的用户帐户都会在此文件夹中有一个文件

看看那里，可能会有一个 cron 任务，以以下 cron 定义开始

6 10,22 * * * ....

相关内容