没有资源的攻防演练靠什么做救命稻草?(对抗篇)

作者:Sender  来源:wavecn.com  发布日期:2023-07-23  最后修改日期:2023-07-23

一个人的蓝队......真是无奈。

article banner

笔者:国际认证信息系统审计师、软考系统分析师

一句话:尽一切可能限制攻击队获得操作系统管理员权限。

攻防演练是人和人的对抗,攻心为上

攻防演练的时间是有限的,只要攻击队发现被拖住了,就会去寻找下一个更加容易得分的目标。

说起来容易,做起来难。因为实际情况太多太复杂了。所以本篇先说一下这次攻防演练的对抗防御过程。

一、源起

这次攻防演练,本打算躺平放弃了(见我之前发的:缺乏资源如何应对网络安全攻防演练?),但到了发现被入侵那一刻,斗心就上来了。心想:

“老子哪有那么容易让你们得手”

于是和攻击队打了一个上午的拉锯战,最后成功守住了靶标系统,迫使攻击队转移攻击其他单位的靶标系统。

验证了自己宝刀未老(可以猜猜号主年龄,当然猜中也没奖)。

剧透:其它单位靶标系统不堪一击,成为攻击队的送分题。

实际上,攻击队在前一晚已经上传了 WebShell,但由于各种原因和实施了的关键措施:用非特权账户运行中间件,我才有机会在第二天早上拉锯和反制。所以这就是本文标题的源头,妥妥的救命稻草。

二、过程

言归正传。攻击队在前一晚就已经发掘到了一个弱口令的测试账户。至于这个弱口令账户哪里来的......事后查了是这个应用系统在初始安装时就自动创建的,没人用的,这真是个巨坑啊。

随后,攻击队找到了这个应用系统的一处任意文件上传漏洞,上传了 JSP 的 WebShell,开始进行试探,什么 whoami ifconfig 之类的命令运行一通,获取主机和网络信息。

但是,这个应用系统是以普通用户运行的 Tomcat 中间件,系统 CentOS 7的补丁持续更新,并且开启了 SELinux,所以在攻击队前一晚的尝试中,并未能找到有效的提权办法获得 root 权限,反而在日志机留下大量的操作失败记录。

由于已经提前报备了每天23点后操作系统定时关端口然后做备份,到点了,定时任务启动,端口关闭,WebShell 不可用,攻击队只能被迫去睡觉(不是)。

所以这种定时关端口的措施也确实有作用,减少暴露攻击面确实是颠扑不破的真理。

(也因为我这没有也不可能有24小时值守啊)

然后第二天,早于攻击队上班也起了作用。当然我还先慢悠悠地磨豆,煮咖啡,冲调,然后一边喝一边常态化启动 Thunderbird 收服务器的 Logwatch 邮件......好家伙,有料!

(好像有人问豆子哪里的,答案是某鹿,某东有售。顺带吐槽某品牌奶越来越稀,只是不耐受人群没得选)

logwatch mail

邮件显示,用于运行 Tomcat 的锁定用户正在尝试用 root 身份执行特权命令!

(收服务器 Logwatch 邮件这个操作相当 Old School ,我这实时监控手段是不足的,需要补,不过穷啊)

这不就是有 WebShell 了吗!斗心登时就上来了,老虎头上叮虱子是吧,干!

首先检查有无被新创建文件,方法很简单:

find -newermt '2023-07-11 00:00:00' ! -newermt '2023-07-12 23:59:59'

发现上传了两个用时间戳做文件名的JSP文件,其中一个还复制到了WEB根目录下面并改名为 error.jsp 想躲起来,但文件的创建时间已经深深地出卖了你

(这两个文件是 WebShell 的先导落地,作用是伪装为PNG文件响应远程传入和结果传出,实现下一步无文件木马的注入运行)

立马改掉文件名不给运行,例如:

mv error.jsp error.jsp_disabled_by_wavecn

但不删除。因为要预备写防守报告拿分时作为证据。

接下来,快速登录多开N个 Putty 窗口,同时:查看系统日志、查看服务器上的 tomcat 日志、检查内存有无异常进程。虽然都是很简单的操作,作为科普还是写一下。

系统日志用 tail 持续观察新输出,之前的日志通过日志机看就好:

tail -f /var/log/messages

Tomcat 日志是关键。需要往前追溯,用 less:

less /opt/tomcat/logs/debug_

同步检查内存进程:

ps aux | grep tomcat

所以上一篇文章里面说的多屏幕排布窗口还是很有用的,虽然内容基本就是调侃:没有资源的情况下如何熬过攻防演练?

只是,Tomcat 日志进不了日志机独立保存。这其实是个管理漏洞,以后还要考虑把 Tomcat 日志如何转移保存到日志机,或者另一台服务器。

居然 ps 操作显示已经有异常的 java 进程在运行了:

[root@server ~]# ps aux | grep tomcat
tomcat      86487  0.0  0.0 113280  1220 ?        S    11:34   0:00 sh -c cd "/home/tomcat/.java";./java -p iLTi6kGVLnn+rXRGFq86gz/qaXafjwGot2dAwZAonky4u1wqTtA4O17BR8UsdmV6 2>&1
tomcat      86489  0.2  0.0 715572 11236 ?        Sl   11:34   0:03 ./java -p iLTi6kGVLnn+rXRGFq86gz/qaXafjwGot2dAwZAonky4u1wqTtA4O17BR8UsdmV6

不放截图是为了精简内容。话说我手头这破应用系统何德何能需要劳烦到出动无文件木马......确实已经是主流手段了。

不管那么多直接杀掉就好。

kill -9 进程号

右边在杀进程,左边查 Tomcat 日志,重点是按上传的 WebShell 文件的时间开始往前看,找出攻击者用的是哪个系统用户,通过什么系统功能实现上传 WebShell 的。

(看日志确实靠经验,也靠对这个信息系统的熟悉程度)

tomcat log

按目录关键字,在日志里面找到了相关的系统用户ID和攻击队的IP地址。马上用信息系统的管理员禁用被攻击队利用的系统用户账号。

(我还在数据库的用户表里面查询确认了图片中的账号名“01”,然后才用应用系统管理员禁用了这个账号)

Tomcat 日志里面记录了攻击队上传的经过BASE64编码的无文件木马代码,有空会翻出来再看看具体是啥。

然后急 Call 系统的开发商,开发商居然说,啊,那个漏洞还未修补吗,然后反手发来一个补丁。

(囧)

一看补丁适用的应用系统版本,凉了,不是我这个版本,是较新的版本。

(大囧)

好吧,尽管试试。一番备份和替换,重启 Tomcat......系统能登陆但功能界面都出不来。

(预料中的囧)

只能回退了。

回退完,重启服务,攻击队也几乎同时就换了另一个真实用户账号(又是弱密码!)登录了,重新上传了 WebShell,且又启动了无文件木马的 java 进程。

(这是明知对面有人还继续吗,但你对面那个可是 root 用户哦,你提不了权就没有赢面的哦)

继续 kill -9 杀进程,同时把 WebShell 上传的目标目录设置为 root 所有,且目录属性为000,谁都别想写。

chown chmod 这些命令太常用,实在是懒得在这里做格式了。

disable upload dest dir

想想还不够,Tomcat 日志既然写得这么清楚,URI和参数都有:

uri and param

于是去WAF设置自定义规则,按URI和参数进行拦截:

waf custom rule

应用规则:

waf custom rule applied

再然后,继续排查禁用可能被攻击队控制的其它弱密码账户,果然还是有人用弱密码一直不改的(这系统开新账号统一初始弱密码,厂家从不改这个奇葩设计,也是巨坑),重启 Tomcat 服务确保账户不能用。

平静下来了。攻击队应该也知道了,另一边的人还是有两把刷子的。

然后就开始听到其它单位在喊救命了。

于是,各种截图,写防守报告,上传演练管理平台,经裁判组评审,拿到60分的加分。

其实防守报告多写一些内容或者能拿多点分,但后来想,一个人的防守,算了,不搞那么累,还不如看看自己的桌面墙纸:

my desktop

三、结论

整个过程,关键就是在于攻击队的 WebShell 不是以 root 用户身份运行,无法控制主机。然后就是其它措施的共同作用,比如勤奋地打好补丁使得操作系统没有可利用的提权漏洞。如此多管齐下,实现拖住了攻击队的步伐,最终就能相对从容地把攻击队送去别家。

进一步地,可以对这个专用系统账号进一步设限制,禁止执行特权命令之类,总之从严就还有很多功课需要补。

另一个大前提,是作为管理员对这系统的熟悉和了解程度。我是不会说我之前对这系统做了多少铺垫,包括自己换 Tomcat 漏洞版本,大改jsp代码适配 Tomcat 的变化,自己改 jsp 里面的漏洞,用数据库触发器调整系统功能逻辑和绕过BUG等等。

所以我是早就问开发商拿了数据字典的,一个人的蓝队,DBA也是我。

就差反编译修改代码后再编译来实现功能修补了。

只是弱密码排查、测试账户封禁始终都还是有遗漏,这点自己都觉得比较失败。

下一篇再具体讲讲这救命稻草相关的实现。

题图来自Pixabay公共图片库

本栏目相关
  •  2024-02-22 开源杀毒软件 ClamAV 1.3.0 新版释出,支持解析检查 Microsoft OneNote 附件
  •  2022-05-11 CIS-CAT 配置评估工具介绍及操作实践
  •  2022-03-16 Windows 系统安全基线及软件工具介绍
  •  2022-08-28 网络攻防中的色彩象征
  •  2022-03-11 安装RHEL/CentOS时如何选择配置安全策略?
  •  2022-03-17 详细了解微软安全合规工具包(SCT)
  •  2022-03-25 从甲方角度介绍“CIS互联网安全中心”
  •  2023-01-06 MSSQL数据库自动备份和自动复制转移备份
  •  2022-03-28 如何应用CIS互联网安全中心发布的《CIS关键安全控制措施集》之一:总览
  • 微信订阅号二维码

    本页网址二维码: