本文原成于 2020 年末，缘起当时公司举办的针对内网系统的安全众测挖洞活动。本来我对内网实名论坛这种东西没什么兴趣，但在活动之前，有同事邀请在论坛内帮忙点赞刷人气，当时就发现了一些问题但没有深究。于是在活动期间深入研究一番，写了一篇 POC 提交了上去。

论坛在发状态的时候可以选择表情，这是一个很常见的功能。但该论坛里引用的表情图片竟然不是本地文件或者类似于微信的那种 [赞]转义代码，而是外部（新浪微博）的 URL，如 http://img.t.sinajs.cn/t4/appstyle/expression/ext/normal/86/2018new_quantou_thumb.png ，而且在发状态的时候，选中的表情以完整的 URL 写在 POST body 中。安全信条说永远都不要相信用户的任何输入，那这种用户能控制的图片 URL 是否可以搞点事情，如储存型 XSS 呢？

把图片的 <img src> 替换为非法地址，附上事件代码 on error=alert ，提交以后弹窗成功。

储存型 XSS 验证成功了，如果引入外部的 js 代码真正构造一个 “跨站” 脚本攻击，还可以做点什么事呢？构造一个调用发帖接口发送内容的 js，在中招人不知情的情况下再发一帖，内容依然是偷摸发帖代码，导致看中招人帖的观众再中招再发帖，如此往复，这就是 XSS 蠕虫了。

使用 Burpsuite 的 CSRF 模块验证了一下，结果发现发帖时需要校验 HTTP 头部的 x-token，验证失败。但是再一番探测之后又发现一个越权查询接口 /……/get/user/info/{用户名} ，把用户名作为参数，在不需要 sessionID 的情况下都可以查到该用户当前的 x-token！至此，一个 XSS 蠕虫攻击的所有要件都已齐备。

试想，攻击者先发一帖，埋入储存型 XSS，看帖的人加载了攻击者所埋的 js 脚本，该脚本通过越权接口查询当前登入用户的 x-token，加到到请求头中，调用发帖接口再发出含有 XSS payload 的帖子，如上所述导致看帖者再中招发帖，似病毒传染一般形成 XSS 蠕虫。

由于我的 javascript 代码水 (ji) 平 (hu) 有 (bu) 限 (hui)，况且也不能真的构造一个 js 蠕虫，那样影响实在太大，因此上述 POC 构思也仅仅是停留在当年的纸面上，随着论坛后来的升级改造，连土壤都不复存在。但给我的启示是，一两个漏洞看似危害不大，但是两个甚至更多的小漏洞的互相联合利用，将会带来危险程度呈指数级上升的严重危害。

红蓝对抗中蓝队的一些工作心得（一）

红蓝对抗中蓝队的一些工作心得（二）

为了运维监控的需要，一台安装了 CactiEZ 中文版的运维监控系统暴露在了公网供远程使用，在攻防演练中带来了不小的风波。

该 CactiEZ 是 php+Apache+MySQL 的系统，看下安装包里文件属性，创建时间也已有十多年，存在什么漏洞都不值得大惊小怪了。从内网 SSH 登到这台被打得体无完肤的主机，先看下 Apache 的访问日志 access_log ，果然发现了一大堆连接 webshell 的访问。到 web 目录去下查看，有一些创建时间不正常的可疑文件，还以 “.” 开头企图瞒天过 ls，但我查看文件用的是 Windows 下带映射 sftp 的 SSH 客户端 Bitvise Tunnelier，没有被晃到。这里发现了有些奇怪的关注点：

除了名为 .index1.php 开头的 webshell 外，web 目录下有两个文件 1.sh 和 1.sj 。

这里的 “sj” 明显是 “sh” 的键盘笔误，如果是事先准备好的文件传上来的，不大可能会出现这样的问题。再结合红队喜欢反弹 shell+内网穿透控制主机的习惯，那么我们怀疑是不是拿到了 bash 权限，然后写入的？

CactiEZ 大概是 Cacti 的本土汉化版，搜了一些 Cacti 系统漏洞的公开 poc，该 EZ 版都没有 poc 对应的模块，也没有利用成功。于是进入 web 界面排查，在该监控系统发送告警邮件的地方，发现了一个调用 Linux sendmail 命令的输入框，意为定位 sendmail 命令的路径，同时还有发送测试邮件的功能。虽然在此处填写 命令+参数 会提示找不到文件，但猜测也只是没匹配到文件名而已，“发送测试邮件” 照样会调用该文本框中的命令。这真是个危险的 feature 啊。如果我在框中填写 bash 的路径，不是可以直接起反弹 shell 了？在内网测试了一下，果然成功。

定位了问题，下面就是常规地封锁 accesslog 中的攻击 IP，清理各目录中留下的渗透工具，检查内网受损资产等等。

作为蓝队经验的最后一篇，还是得提一下不足之处，在演练期间，发生了好几次令人感到憋屈的事情，如：

1. 因为担心办公区环境终端被木马控制攻击主机区，而设置了严格的网络策略，导致红队依靠各种内网穿透工具在主机区横行无阻，蓝队却因各种内网策略访问受限；
2. 失陷主机因转手次数太多、时间太长等各种原因无人记得 SSH/Web 服务的密码，导致红队连得上主机，蓝队连不上。有的时候，比如已知某主机是通过 fscan 扫到 tomcat 弱密码打进去的，我们蓝队只能通过自己上传 webshell 拿权限，往 /etc/shadow 里新塞账户来获得 SSH 登入权。

这些事情都可以通过更完善的资产管理，以及主机部署统一运维 agent 下发命令等来解决。同时，堡垒机在内网也是比较有意义的。希望以后可以不再发生类似的事情。

最后，我们蓝队的老大提到，虽然游戏规则有所限制，但一些不正经的红队仍然会故意埋一些雷，以便在日后的类似演练中一举再突破，甚至高价兜售所埋的雷。那么蓝队还是得对于更高层次的、类似于 APT 的手段多加防备，如用木马替换系统命令，内核级 rootkit 等等。