某金融src的一次较复杂攻击链进入后台

2024-08-29 17:29   日本  

1.前言

本文大体完成于去年,是由某金融SRC的案例修改而来,由于涉及一些敏感信息,所以部分细节略有修改。整个案例还是很有意思的,从一个页面到另一个页面,从一个JS到另一个JS。

2.目录FUZZJS接口分析

首先本文的攻击场景是一个登录框

看到这,很多师傅应该会很开心,看起来没有验证码,那不是妥妥的喷洒+爆破拿下吗?但实际上并不是,密码错一次就会出验证码

好吧,有验证码又如何呢,我用验证码识别插件操作一下不就行了?

实际上不行,测试之后发现,这里这个接口有密码错误次数进行限制,并且验证码+错误次数限制都没法绕过去,所以在这个接口爆破喷洒肯定行不通了。

那么还有什么办法呢?这时候就可以开始想想分析JS找接口了,但是不行啊,这里没有webpack,而且这里的JS文件都是这种的:

有经验的师傅应该知道,这种JS文件找不到什么接口的,所以JS分析这条路也断了,那接下来只能去目录FUZZ了呗。

天无绝人之路,目录FUZZ发现这个站点存在目录遍历的问题

而在众多目录中,我发现了一个与众不同的目录

在该目录中,有一个wechat目录,当我访问这个目录,会重定向到一个页面

看似一片空白,但在这之下,我看到了熟悉的webpack

那么接下来就是分析了

3.JS分析再到JS分析

webpack,那找到接口的可能性大大提升了,在这里,我提取出了六七百条接口

但是令人震撼的是,这些接口居然全部鉴权,一个能用的都没有

所幸,这其中有一些前端的web界面,我们还是可以访问到的,虽然这些界面上的功能我们也一个都用不了

好吧,那么此时要怎么破局呢,我对这些新页面又细心研究了一波,发现其中有相当一部分是有一些新的JS文件的,比如:

有新的JS文件,意味着可能有新的接口,有新的接口就可能有新希望,我统计了一下存在新JS文件的页面,并且对其中的JS文件进行了分析,然后找到了一些新的接口,而在其中,我终于发现了少量未鉴权的接口

其实说实话,这两个接口我一开始只测试了/API/rfid/GetAssets,因为另一个带login,我以为和登录口那个登录点一样,有验证码,那就没有测试的必要,但是GetAssets接口的参数怎么都FUZZ不出来,最后我极不情愿的去研究这个Login接口了。

在研究它之前,我特地去看了看登录界面的接口是怎么样的,然后我惊讶的发现,他们从接口路径来看实际上是完全不同的

也就是说我那个新的登录接口,或许并不像登陆界面的接口一样这么严格。我对这个新登录接口进行参数FUZZ,很简单地发现了它的参数

这里说个趣事,实际上这个点是有验证码参数的,但是不加也没事,于是就这么简单的被我绕过了。

然后就是愉快的密码喷洒环节了。

4.虚惊一场的密码喷洒到进入后台

密码喷洒非常简单,非常顺利,固定密码为123456,喷洒出了大量用户,其中不乏部门管理员

正当我兴致勃勃拿着弱口令去登录时,却发现一个都登不上

是的,在另一个接口登录成功,但在这个接口却不行,这时我都欲哭无泪了。那还能咋办呢?这时候我开始认真分析起了两个接口地返回包:

如下是登陆界面接口的返回包:

如下是fuzz出的新登录接口的返回包

注意观察我们是不是少了点什么?没错,两个接口实际上是极其相似的,唯一的区别只在于,登录页面的那个接口,多了一个返回值,也就是issuccess,那如果我们替换返回包,并且在其中也加入这个返回值呢?

成功登录后台!

5.结语

本文主要是作为一个引子,引出以后可能发布的JS分析系列,JS分析的各种姿势还是非常重要的,在不同场景下,都有哪些方法、工具、思路去获取js文件,比如登录点场景、后台场景、SSO场景、Webpack场景、目录以及JS文件FUZZ场景、小程序解包场景等等。以及我们拿到JS文件之后,其中可能有什么与安全有关的重要信息、我们要如何提取这些信息,这些都是很有意思的知识点,如果只用findsomething或者packerfuzzer之类的工具,是绝对无法应对上述的各种情况的,无疑会错过一个亿,在长期挖掘各家企业src的经历中,笔者也是总结了大量特殊场景下的JS获取以及分析思路,后续也会整理成一个系列的文章发布出来,欢迎师傅们关注。


HW专项行动小组
大师!教我打攻防
 最新文章