攻防演练 | 记一次打穿某车企全过程
2023-7-24 23:24:54 Author: www.freebuf.com(查看原文) 阅读量:303 收藏

0x00 前言

本文介绍了笔者在某次攻防演练中,如何从外网渗透到某车企的内网的详细过程(为了保护敏感信息,所有数据都已经脱敏,有些截图也不完整,请见谅)。

这次网络攻防演练分为两个阶段一共十四天,前七天是私有资源阶段,后七天是公共资源池阶段。共有12支队伍参与比赛,我们公司全程只有两名选手参赛。由于公司从不提供一些辅助工具和人力资源,并且我俩近期连续参加了多场比赛,导致每次比赛后我俩都很内耗。

0x01 信息收集

裁判只给出了目标企业的名称,让我们自行寻找其他的信息,这是对我们资源差的队伍是一种考验。

幸运的是,笔者之前编写了一套信息收集的辅助脚本,现在可以派上大用场了。

首先,使用子公司收集脚本来搜索一级子公司。该脚本根据特定的条件和规则进行搜索,以获取与一级公司有50%的控股关系的子公司。然后,我们对这些一级子公司再次使用脚本进行搜索,以找到与它们有50%的控股关系的子公司。这个过程不断循环,直到没有符合条件的子公司为止,所以你看到下面最深达到了四级公司。
image
接下来,再用资产收集脚本对子公司收集脚本的ICP结果进行一系列的操作,该脚本包括子域名匹配、端口扫描、web路径搜索、服务识别等,最终结果会到了以下三个文件,其中ip文件可以交给灯塔去进行信息收集、url文件可以交给poc扫描器、详情文件可以在扫描poc的时候手工去寻找一些POC扫描器里面没有的漏洞(如弱口令,手动狗头)。
image

0x02 web打点

我先用poc扫描器(xray青春版,poc-bomber等开源作品)对资产收集的结果进行了一番扫描,结果没有发现一个可利用漏洞(人少公司也不提供些打点资源,怎么搞嘛,狗头保命)。没办法,只能老老实实手动地一个个分析哪些URL可能有惊喜了。在翻了一大堆无聊的页面后,我目光锁定在了一个url上,这url的title是XXConfluence
image
image
当发现这个网站使用的是Confluence时,我想很多师傅们都知道该怎么做了。我立刻检测它是否存在RCE,经过一番尝试后,发现这个版本确实存在RCE,并且确认了服务器的操作系统是Linux。

接下来就把shell反弹到服务器上,发现已经拿到了无限制的shell访问权限。马上做了一个远程控制马并上传到目标服务器。MSF上线后我就查了一下网卡,发现这个服务器有个172.32.0.30的网卡,接着上传代理工具。
image
image

0x03 内网信息收集

利用frp工具将内网暴露出来后,我们成功进入了172.32.0.0/24网段。接下来,我和队友开始了正式的内网信息收集工作。
image
image
按照常规的习惯,用fscan工具来扫一扫,看看能不能找到一些弱口令或者可利用的漏洞,让我们的攻击更加顺畅。可是,扫描结果让我失望了,32网段居然没有一个可以利用的漏洞点。我只好用fscan继续扫172.16到172.31的网段,希望能有所收获,但是又怕扫的太猛触发了一些报警,于是就小心翼翼的进行着。运气比较好,在扫172.16段的时候,发现了一个F5 BIG-IP文件上传漏洞。

为了验证这个漏洞是否真的存在,于是构造了一个URL来测试一下,结果发现可以成功执行和回显。我心里暗喜,这下有戏了!

https://172.16.0.11/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
image
接下来的步骤变得相对简单了,我将反弹shell的代码上传到F5服务器上,并通过本地的NC监听来执行。这样,我成功获取了F5服务器的反弹shell,并且发现它具有root权限,这意味着我们可以在这台服务器上做更多的信息收集了,拓宽攻击面。
image
image
image
为了进一步探索这台服务器的漏洞,分别测试了它是否能够无密钥登录其他服务器ssh、检查了历史命令记录和一些运行中的服务,但都没有找到有价值的信息。后来想到由于这台服务器上主要运行着java程序较多,使用了一条配置文件搜索命令,希望能从配置文件中发现一些突破点。

find / -name "*.properties" -o -name "*.yaml" > ret.txt

在仔细检索了多个文件后,我最终在一个叫做base_config.yaml的文件里发现了Redis和MySQL的密码。可是,当我尝试登录这些服务时,并没有找到任何敏感数据。而且最新的数据只更新到了2022年(此截图密码部分为笔者随机生成,不过与原密码长度相同)。
image
就在我思考是否应该停下来的时候,我突然灵光一现,想到既然Redis和MySQL的密码都是一样的,那么SSH的密码是否也是相同的呢?我立即使用Xshell工具尝试连接,令人惊喜的是,我居然成功连接了!接着,我开始思考是否其他服务器也会使用相同的密码,因为在内网中,很多管理员认为密码强度足够,所以会在其他服务上重复使用相同的密码。

在这里,将fscan扫描的172B段服务器的IP汇总到一个列表中,并使用爆破工具进行密码爆破。最终,我成功破解了47台服务器的密码。在使用Xshell手动登录时,我不得不承认,当资产数量较多时,手指会感到很累(手动狗头)。

以下是成功登录上的服务器image

0x04 突破逻辑隔离

我正在手动使用Xshell登录时,收到了来自队友的好消息。他尝试登录172.32.0.81时,发现该服务器存在多个网卡。
image
并且在历史命令中,我们找到了管理员在该服务器上添加了一条软路由,将流量转发到10.54.0.0/19网段
image
我们立即决定在172.32.0.81上搭建一个代理,以便能够访问到10.54.0.0/19网段的资源
image
前置工作做好后,然后使用fscan对10.54.0.0/19网段进行扫描,我们发现了一个MySQL数据库弱口令:

[+] mysql:10.54.15.233:3306:root [email protected]

在该数据库中,我们找到了一些敏感的数据,包括基础配置文件、车联网信息、车籍档案信息等。尤其是基础配置文件中,包含了各种服务账号和密码、nacos配置、云服务的secretId和secretKey等敏感数据。

0x05 云内网渗透

既然已经获取了云服务secretId、secretKey,那就利用CF这个云渗透神器进行进一步的探测,配置好AK后发现权限为管理员权限
image
随后创建子账户,接管控制台
在登录控制台时发现拥有64台云服务器、13个mysql云数据库、3TB的对象存储、17个vpc网络等信息
image
这64台服务器在cf里执行命令都是root权限
image
此外,神仙队友还从存储桶中找到了几万人的联系方式、家庭住址、驾驶证、身份证正反面照片、车牌号等高度敏感的信息。

这样一来,本次渗透也基本完成了,48台物理服务器加上64台云服务器以及大量配置文件数据、开发环境配置、大量客户敏感数据,分数已经远超上线分了。

0x06 总结

  1. 注意清理痕迹:在我和队友看到分数下来后就继续去渗透别的资产了,没有及时去跳板机上做清理痕迹,导致被溯源该单位成功复活,我们也相应地被扣了分数,损失惨重;

  2. 内网横向的时候一定提高速度,因为特别是有安全服务的win主机,一般报警都是有延迟性的,但是延迟性可能只有2小时、4小时、6小时等,所以一定要尽快地把资产梳理清楚,多获取路径分;

  3. 总结下本次攻击流程:
    外网Confluence应用RCE --> 内网F5应用RCE --> 从F5服务器配置文件中获取到数据库密码–>将数据库密码对ssh进行密码爆破 --> 爆破成功的服务器的历史记录中发现逻辑隔离10网段 --> 找到数据库弱口令 --> 从数据库的nacos配置中获取到云服务具有管理员权限的AK和SK --> 进入核心业务内网-->找到核心数据;

  4. 多尝试一下密码喷洒,可能会有意外的收获;

  5. 之后我会多利用社工钓鱼的技巧,去获取目标的敏感信息,因为现在通过传统的技术手段去攻击目标的漏洞已经不太容易了。


文章来源: https://www.freebuf.com/articles/web/372933.html
如有侵权请联系:admin#unsafe.sh