freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

挖洞经验 | 教你查看老板工资
2022-03-23 16:13:02

*郑重声明:本文所提供信息仅供学习研究或自查使用,切勿用于非法用途,由于传播,利用此文所提供的信息而造成的任何直接或间接的后果和损失,均由使用者本人负责,本文作者不承担任何责任。


0x01 背景

(故事纯属虚构,如有雷同纯属雷同。)


作为一个网络安全一年级学生,平时喜欢养生,某天下班后企微突然弹了个上线前测试任务的通知,看任务描述是供应商开发的工作台小程序,已通过第三方安全测试,再仔细一看是薪资查询系统。

1647964203_6239f02b76536b4831bdc.jpg!small?1647964203854


功能非常简单,一个登录口几个查询接口。账号密码输入、查看、退出,提交无漏洞报告,一气呵成。

1647964282_6239f07a3d529f36bc49d.jpg!small?1647964282811


《危.jpg》

1647964336_6239f0b0825e9905e4f65.png!small?1647964336898


0x02 重开

并非迫于领导淫威,只为不断提升自己,早日实现财富自由,做一个吃喝不愁的five,重新梳理下思路。

1647964389_6239f0e580b646ea9849c.png!small


开搞

1、敏感信息泄露:无果

2、工具检测:无果

3、登录框

win10系统代理127.1:8080启动,burp启动,打开登录页面,开始渗透。

1647964407_6239f0f7b506c60f53e76.png!small?1647964408164

  • 弱口令爆破放弃(图像识别不会)

  • 有账号锁定机制、模糊登录提示,该有的都有。

  • 无短信登录机制,图形验证码一定次数后出现,未发现绕过。

  • 明文传输

先从http登录请求开始分析,username passwd关键参数加了密,这个长度目测RSA加密算法明文传输都不给?再看一波登录认证流程,前几步看起来用的企微的一套流程,一顿操作后,也没啥思路,最后获取的session看着也不是jwt,看来从登录流程搞不到产出勒。。

1647964438_6239f116620a2c4b9a4e0.png!small?1647964438874


4、访问控制

  • 越权访问

登陆进来,一顿点点点。

1647964452_6239f1246bff9e5e79561.png!small


”获取PS数据成功“,这就是关键请求了,但和登录一样,不仅请求加密,响应也加了密,目测这里也是RSA算法

再看一眼请求参数,猜测action是查询类型,而params是时间等筛选条件??凭借我屈指可数的肾透经验,这里有点奇怪,action没加密,params却加密了, 这样的做法有点做贼心虚的意思。

1647964471_6239f137ab80072b010dd.png!small?1647964472154


如果猜想正确,岂不是可以查老板薪资,要验证猜想(经典的加密越权),需要三步:

1647964497_6239f1512ea61f28a88ed.jpg!small?1647964497551



第一步:必须得拿到一个params明文。

思路1、企微小程序可在浏览器中打开:如果没配置拒绝用户在浏览器中打开小程序,我就有机会通过前端断点调试的方式拿到params明文格式。

思路2、双向RSA加密公用一对公私钥:响应数据虽然是密文,但页面总是要给用户展示信息的,所以前端必然会有解密操作,那私钥一定会出现在前端。

思路3、硬刚:在混淆的js代码中逆向分析params参数,难度高,且费时费力(我不会)。

第二步:params明文数据中存在用户唯一标识uid,且唯一标识uid存在规律。uid可能是姓名、简单数字或者登录用户名等,这种我就可以猜到老板的uid

第三步: 服务端仅使用uid而非session字段来进行身份鉴别。这样通过伪造老板的uid进行身份鉴别,就可以拿到工资信息。


思路1:企微小程序可以在浏览器中打开。

选择在浏览器中打开。

1647964526_6239f16e9a1bbfae23f85.png!small?1647964527212


直接跳到了企微统一回显页面,GG

1647964531_6239f173bb6ba05da2f4e.png!small?1647964532123

思路2:双向RSA加密公用一对公私钥。

右键js 直接搜索关键字setPrivateKey|PrivateKey|setPublicKey|PublicKey等关键字,搜了一圈,只找到了1010行PublicKey,没搜到私钥,整个流程也没看见有密钥之类的接口,柑橘很奇怪,不禁陷入了沉思。。。

1647964540_6239f17c74b280b2b85d1.png!small?1647964540981


这里有个tip,思路1跳转前,浏览器会先加载目标的js等静态资源文件,然后才会进行页面权限校验的跳转。这种情况下用burp代理开启拦截一步步放行,可以把页面卡在跳转前,方便使用Chrome F12分析js代码,但大概率页面不能正常显示。

1647964551_6239f187c7f14f99fe059.png!small?1647964552225


思路3、在混淆的js代码中逆向分析params参数

一顿操作猛然虎(逆不动),一看时间两点三十五,狗命要紧。

1647964559_6239f18fc33accf792751.jpg!small?1647964560207

0x03 峰回路转

躺在床上,留下了没有技术的眼泪,明明近在咫尺,却远在天边,心中满是不甘。

1647964572_6239f19caa5dddd98db6e.png!small?1647964573581


第二天上班 ,准备再挣扎一下,已无退路可言,稳住心态,重新分析流程,接着回想昨天柑橘不对的地方,先不说有没有共用一对公私钥,单是响应密文的解密私钥也愣是没看见。


手没有感情的点着鼠标,眼睛继续关注着burp的历史请求,突然再看见这个“关键查询请求”的时候,感觉密文有点眼熟,再用burp比对昨天Reperter留下的查询请求,那不能说俩params密文毫无关系,只能说一摸一样 (●'◡'●)

1647964594_6239f1b2437149bd0a7f3.png!small?1647964594736


RSA加密时用了随机数,密文那不能相同呀。

1647964599_6239f1b71c7e8a3a7a7da.png!small?1647964599718


真相只有一个,这就不是RSA!!难怪一直找不到PrivateKey。再次找到js,输入熟悉的关键字enc.Utf8.parse验证猜想,一口老血吐了出来,这波呀,这波是降维打击,密钥到手。

1647964603_6239f1bbd8c6337eaca68.png!small?1647964604479


掏出之前写的python脚本,AES-128-ECB-Pkcs7,用密钥解密params,明文里第一个参数就是uid,这时 我感觉已经稳了。

params=Z0YzJz/VqeJ5EB**************************************b1RQ/NEcGZsOXLw==

1647964609_6239f1c1369cbec8273e0.png!small?1647964609619


响应密文同样用的是AES加密算法。nKnG45TzMzBstdw5P/EAU46EVWhOpkKNA/haj*************************

1647964612_6239f1c4c25417966b964.png!small?1647964613363


第三步验证就比较简单了,只需篡改成老板的uid--> 生成伪造密文 --> 最后发送伪造的密文,观察到响应密文和之前不一样。

1647964631_6239f1d776160dec387b0.png!small?1647964631888


解密密文,高危漏洞到手 ψ(`∇´)ψ

1647964640_6239f1e013d31b3c37674.png!small?1647964640496

1647964652_6239f1ec603d5a48378bf.gif!small?1647964664967


4、访问控制

  • 未授权访问:最后用burp -> Authz撸一遍未授权,无果,结束。

测完结束,重写报告提交给开发团队修复,修复建议:身份鉴别应使用session,不要用uid、不要用uid、不要用uid


开心之余又有些担心,准备着喝完茶去送外卖了。

1647964667_6239f1fb270f63ad792a3.jpg!small?1647964667639


然后...

1647964678_6239f20639bd858cd45cc.png!small?1647964678623


0x04 总结

整体来说运气不错,如果真是RSA的话第一步就是知识盲区了,后面验证越权第二三步也没有障碍,回顾一下这个越权漏洞的发现过程:

1、被迫重开。

2、登录发现使用了RSA加密算法,潜意识判断内部用的也是RSA,寻找params明文未果,不甘心的睡觉。

3、再挣扎一下,回顾疑点,最终发现内部关键字段用的其实是AES算法,从而实现降维打击。

4、二三步畅通无阻,js中发现AES密钥 --> 解出params明文 --> 篡改uid伪造身份 --> 发送伪造密文通过身份鉴别 --> 解密服务端响应的密文 --> 最终拿到数据。


经验可以给我们敏锐的“直觉”,但也会带来 “思维惯性”,也是这次最大的阻力,值得反思一下。关注下这类被加密隐藏的越权问题,或许会有惊喜,最后祝你们多多挖洞。


本文作者:, 转载请注明来自FreeBuf.COM

# 渗透测试 # web安全 # 挖洞经验
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
评论 按热度排序

登录/注册后在FreeBuf发布内容哦

相关推荐
\
  • 0 文章数
  • 0 评论数
  • 0 关注者
文章目录
登录 / 注册后在FreeBuf发布内容哦