从一个验证漏洞到一键签到脚本

  • A+
所属分类:技术文 文章 未分类

一次在疫情闲的没事干的经历

网络安全的重要性

首先按本次来讲,这个一键签到脚本是开发人员遗留下的漏洞。我为什么要这样讲呢?因为按常理来说获取个人信息的api,有着十分强大的安全锁,不管是从时间戳,登录凭证或者cookie来说都是几重验证同时进行的。而i健康这个平台在建桥所有的程序(应该说是服务)里面是安全性最差的一个了。不过这也怪不得他们,这个项目需要快速上线,短短几天时间能做出一个这样子的程序已经十分优秀了。

接下来让我们看看发现的经过。

从API验证缺失来讲一键签到

我们首先位于mids.gench.edu.cn处登录,获得到了位于.gench.edu.cn域下的cookie——iPlanetDirectoryPro的值。这个值十分关键,适用于所有建桥服务下的跳转验证身份。具体如下图

从一个验证漏洞到一键签到脚本

其次我们来到i健康,点开进行跳转,拦截到api/login/student处,如下图所示

从一个验证漏洞到一键签到脚本

这时你会发现,验证时有个timestamp,并且验证身份是以gench_hq_user和iplanet进行验证。

这个时候我们就需要进行参数调试,看看哪个是不必要的可以跳过的参数,最后我们会发现很神奇,这个api甚至时间戳都不用验证并且只需要iplanet值就可以获得我们的个人信息。厉不厉害,这个洞我在最后会提到一句如何进行利用。

返回的json如下图

从一个验证漏洞到一键签到脚本
我这里显示乱码只是url编码异常,实际上是中文

再来看看后面一个api,当我们进行到签到步骤时,我们会看到如下组成的post数据以及地址。如下图

从一个验证漏洞到一键签到脚本

最后我们和上一个api一样进行验证,会发现这次不需要iplanet的cookie值进行验证,只需要gen_hq_user了,而根据我换号和多次实验,发现这个值永恒不变。

接下来就是聪明的朋友想得到的了,那我只要一直定点定时重复发送这个数据包不就能全自动打卡了吗?

叮咚!The answer is YES!

以上就是一键签到的原理

一笔带过渣码

花了一晚上写的成品,主要目录如下以及利用的Java的爬虫jsoup进行数据登记和操作

从一个验证漏洞到一键签到脚本
源码目录

主要说明:

  • Main.java ——函数主入口以及判断是否第一次使用
  • getinfo.java——通过iplanetDXXXPRO的cookie值获得需要自动填入的个人信息,相关api为login/student。
  • sign.java ——见到主要功能入口,提供两个函数,一个是第一次使用,从上一个接口中返回的数据进行post登记并以txt方式把数据留存在本地方便下次调用,另一个是调用之前的参数直接进行post登记
  • jiexi.java——主要是获得jsession和loginticket值进行换号和登录Mids后台操作相关。jsession在这边起到换号正常使用的功能,loginticket是登录学校后台中表单的hidden项,使用爬虫取出后跟随get一起发送至后台验证,此项不可缺少。
  • psotlogin.java ——字面意思,登陆学校后台的函数。
  • Spider.java —第一版demo所使用的爬虫函数,爬出loginticket隐藏参数,现已弃用

总体而言是这个思路,具体代码我就不解释了。如果有要合作做出完整版的可以找我。

另外一说的是程序中要求输入的密码是RSA加密过的,一开始写这个的时候卡在这边,没有相关经验我只好从登录源码中提取并且自行调试,最后写了加密器.html这个东西进行手动密码加密了。

再来讲讲以上两个api验证漏洞的危害

第一点

从studentlogin这个api来看,缺乏timestamp这个验证值,我是没有想通为什么在从浏览器发出的请求中是带有这个值的但是调试去掉竟然不会拒绝,匪夷所思。

这个api可以获得身份证,名字,学号,住址,手机号。这些信息非同小可。竟然不用双重验证就能利用,不太行。

从重来讲这个漏洞的利用,常见的web渗透有sql注入,上传验证缺失,XSS,CSRF等。就我们学校的防火墙YXlink来讲,虽然上一年在防火墙界貌似并没有什么出色的表现但是还是处于二流偏向一流的水准,对于Webshell的传出以及sql注入和特殊字段转码和拦截方面绝对不差,所以我们可以先排除注入,反射性xss以及Webshell的选项。最后可能的就是存储型XSS攻击以及csrf攻击。

分类讨论

存储型XSS一般需要留言框等地方,学校最出色的就是有BB这套闭源系统,到处是留言框以及上传,最适合此类的漏洞,在适当的编码下通过防火墙注入这个长期没有更新的系统我认为难度不是很大,就是苦于这套系统没有人使用,老师不发起讨论等,无法做到测试。

CSRF难度稍大,原理为用户打开A站,然后在B站点开了恶意链接,然后向A站发起请求,例如赚钱等进行利用。一般性来说单个评价最多为低危漏洞,中小厂甚至不会为这种漏洞评级。并且现在许多网站跨域措施较为完善。在建桥,利用恶意表单向i健康发起请求并向其他后端发送请求得到的json是可以做到的。更何况学校有一堆12年的站放在那里没人维护,我觉得只要构建并且弄一个足够吸引人的噱头就能做到。

除开这两点也没有其他可以讲的了,还有就是虽然有防火墙,但我不觉得写i健康的人胆子大到会把patch和delete以及其他操作同时开放吧,但是他们的确这么做了。

第二点

这个就是获取到假的值,只要知道固定的gench_hq_user就可以恶作剧,假设甲未感染,但是乙通过某个方式知道了他的gench_hq_user,那么他就可以帮这个人登记为已经感染。这种玩笑可不好笑。

这个每日登记Api我能想到的也没有什么可以利用的地方。没多少意思。

在最后写一笔,如果你参透了以上的内容你完全可以只用postman定时任务就能完成每日签到。所以还等什么,赶紧来看懂吧。

噫hihihihihihihihi.jpg

avatar

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: