自己浸透测验(主要是Web方向)有几年了,现在算是大佬级别。回想起学习缝隙发掘的进程,除了看一些经典书本外,最想看的便是大牛们挖缝隙的具体进程,比方如何寻觅方针,从哪里下手,遇到问题怎么处理。可是,网上介绍常识的多,叙说进程的少(也或许是我的搜索姿态不对……)。除了在乌云上有几个大神有时会共享一些具体的挖洞思路外,大部分人仍是“有图有真相,一图胜千言”。关于老司机来说,瞄一眼就知道是怎么回事了,但关于新手来说,往往是一头雾水。因而,自己共享一下最近的一次挖洞进程,希望可以抛砖引玉,咱们积极共享自己的挖洞经历。
PS:作为一个有操守的白帽子,本文重在共享思路与进程,细节处仍是要打码处理,究竟不是来提交缝隙的。
寻觅方针
这次是针对我常用的一个手机APP(下文简称:某APP)进行缝隙发掘,说起来选择某APP作为方针也是挺偶然的。因为我主要是搞Web浸透测验的,并没有挖过手机APP的缝隙。有一天,在看他人共享Burp Suite的运用技巧的文章时,发现通过Burp还可以进行手机APP抓包(究竟Too young……)。光说不练假把式,仍是要自己着手操练一番。先把Burp设置一下,在Proxy中Options下的Proxy Listeners中,点击Edit,把Bind to address设置为All interfaces。 内容来自 uwa
然后手机和电脑处于同一局域网中,给手机设置代理服务器,IP为电脑的IP地址,端口为Burp中的设置的端口,默以为8080。这时分,就可以用Burp抓取手机的恳求包了。
山重水复
这时分我就打开某APP,履行常见的操作,Burp中就记录了大量的HTTP数据报文。然后,便是对Burp中截获的报文进行剖析了。没多久,一个恳求就引起了我的注意。这是一条GET恳求,恳求的URL是相似下面这种格局:
直觉告诉我,这儿很有或许会有越权缝隙。所以,我用浏览器打开这个URL,公然直接就看到了用户数据。换个id再试一下,把id加1,成果也是相同的,都爆出用户数据了。因而,到这儿现已确定某APP存在越权缝隙。 asthis.net
确定这个越权缝隙存在后,略微平复一下心情,然后就发现这个缝隙形成的后果并不严重。因为这儿通过帐号越权检查到的用户数据中,并没有包含一些比较敏感的数据,比方姓名、手机号、身份证等。简单地说,便是可以越权检查到他人的数据,可是“他人”是谁并不知道,这样来说看到数据仅仅一堆无意义的数字罢了。只钓到一条小鱼有点不甘心,所以就持续挖,应该还有其他的缝隙存在。
持续检查Burp捕获的报文,这次要点检查登录进程中提交的恳求和回来的响应,想从这儿下手深入发掘一番。登录的报文如下,可以看到,只有一个POST参数params,其值通过了URL编码。
把params的值解码之后,发现是json格局的一串数据,基本内容如下: copyright UWA
其间,让人感兴趣的便是userId字段和body字段了,目测应该别离对应登录的用户名和暗码。然后我用相同的用户名和不同的暗码、不同的用户名和同样的暗码别离登录、抓包,然后解码比照发现,相同的用户名对应的userId值相同,相同的暗码对应的body值也相同,这就证明了我的推测。进一步剖析发现,userId和body的值都是十六进制的数字串,userId的长度为32位(这儿指32个十六进制字符,下同),body的长度为128位。这就说明userId和body的值都通过了加密处理。关于userId,我首要想到是不是通过了MD5?不过通过核算用户名的MD5和userId并不相等,也便是说,即便是MD5也加了salt。
剖析到这儿,暂时没方法持续深入了。那就先放一放,剖析一下登录进程中回来的数据包,下图是登录成功之后回来的数据包。 本文来自如斯
一看回来的数据包直接傻眼了,明显是通过加密的。不过,这儿仍是要注意一下回来的数据包长度,因为我故意输入过错的暗码进行登录时(如下图所示),回来的数据包长度竟然相差无及!并且也能看到,有许多相同的字符。很显然,这儿有很大的或许是有问题的。
山穷水尽
到目前为止,虽然现已把登录进程中的恳求报文结构都剖析清楚了,可是因为报文中的要害数据都进行了加密处理,所以到现在简直仍然是一筹莫展。事实上我在这儿卡了两天,也没什么好的方法,乃至还想到过剖析一下他人帐号登录进程中的数据包然后破解出暗码的主意。不过细心一想就觉得这个主意太不现实,又不是暗码学专家,仅仅通过几条密文就想破解加密进程,这怎么或许成功!虽然主意有点荒唐,可是还真给我带来了创意:既然某APP发送的报文和回来的报文都是加密的,那必定是在某APP中进行了加密和解密的操作,那么如果可以剖析一下某APP的源码,应该就可以搞清楚其间的加解密进程。那么问题来了,哪里能得到某APP的源码呢? 内容来自 uwa
思来想去,最方便、最有或许的方法便是将某APP进行反编译得到源码。ios版的我就不想了,究竟也没搞过ios开发,直接去逆向必定是不现实的。可是安卓版的仍是有搞头的,因为之前看过他人进行APK逆向的文章,也写过Java代码。说干就干,网上搜一搜安卓逆向教程一大堆,究竟咱仅仅想剖析源代码,并不是要搞脱壳破解,入门级的教程就可以满足要求,这儿就不多说了。总归,将某APP反编译之后,发现代码进行了混淆,可是并不影响剖析,略微费点劲罢了。通过剖析,公然有收成。
首要,发现加解密运用了AES算法,并且加解密所用的密钥是16位的。
持续剖析发现,开发人员竟然把密钥“简直”硬编码在代码中!密钥一共16位,前面几位是网站域名,再加上devId的前几位,凑够16位便是密钥。而devId在登录的恳求包中是以明文出现的,这样一来,相当于加密算法和密钥咱们都得到了。 asthis.net
到目前为止,剖析的进程基本上就现已结束了,是时分写代码验证一下剖析成果了。用Python写了AES加解密的代码,将userId和body进行解密之后发现,userId公然便是登录的用户名,而body的值则是如下json格局的字符串:
很明显,password的值也通过了加密,这儿有或许便是核算了MD5,不过有或许加了salt。持续剖析源代码,找到了对暗码进行处理的进程,公然是加了salt的MD5!并且,salt也是硬编码……
UWA
拿自己的暗码进行验证,证明了上述剖析。
意外惊喜
到现在为止,现已可以假造数据包进行模仿登录进程了。事实上,我开始的主意也是想假造数据包模仿登录进行暴力破解的。不过,在进行暴破之前,仍是先把回来的响应报文解密看看。按照之前的剖析,回来的报文必定是有问题的。
将响应报文解密之后,公然带来了更大的惊喜!前边现已说到,登录成功回来的数据包长度和失利时回来的数据包长度很接近,解密之后发现,何止是长度接近,内容也有九成是相同的!当然,这都不是要点,要点是不论登录是否成功,都回来了用户的实在数据,包含姓名、手机号、身份证号以及正确暗码的哈希值,暗码彻底便是形同虚设。不枉费我一番心思,总算钓到大鱼!
总结
缝隙发掘的进程基本上结束了,之后提交缝隙的进程我就不废话了。整个进程写起来有点像流水账,可是却把我发掘缝隙的进程和思路写清楚了,总结起来便是: 本文来自如斯
多看多想多着手实践,有事没事多抓包剖析
Web方面的挖洞思路和软件逆向相结合,带来意想不到的惊喜
不要总想着暴力破解,那是没有方法的方法
最终,希望此文可以抛砖引玉,咱们都能把自己的挖洞思路共享出来。挖缝隙有时分确实需要一点创意,多学习一下他人的挖洞思路,必定可以对自己有所启示。