安全矩阵

 找回密码
 立即注册
搜索
查看: 395|回复: 0

浅谈在数据包被加密和签名保护时的渗透方式

[复制链接]

179

主题

179

帖子

630

积分

高级会员

Rank: 4

积分
630
发表于 2023-3-23 18:38:52 | 显示全部楼层 |阅读模式
本帖最后由 adopi 于 2023-3-23 18:38 编辑

原文链接:浅谈在数据包被加密和签名保护时的渗透方式
场景
在金融银行类安全测试中,经常见到数据包加密、签名保护,这种业务不能直接进行有效的安全测试,修改数据包参数会重放失败,爬虫见到密文也是懵逼





测试套路
对于这种业务,不管是手工还是借助工具,需要先还原加密算法(或者签名保护算法)。知道了加密逻辑后,就可以开发burp插件完成明文状态下的安全测试,最后借助密文数据天然过waf的优势结合Xray等漏扫工具完成半自动的安全测试(逻辑漏洞还得需要手工测)。笔者通过几个案例介绍这类业务的通用测试流程:常见加密算法分析流程、burp插件开发、联动Xray半自动化挖洞。
所以案例只是案例,读者不要纠结于这些案例中的加密算法,因为加密有很多组合形式。主要是通过本文介绍这类业务的通用测试方法,降低安全测试的人力成本

案例
常见签名的生成算法:sign = MD5( sort( 业务参数+时间戳+其他参数) ),拼接业务参数+时间戳+其他参数,对字符串排序,计算字符串MD5作为sign。客户端和服务端使用相同的算法生成sign,服务端接收到请求后,先计算一次sign,如果业务参数、时间戳、其他参数中有一个被修改过,得到的sign就与客户端发送过来sign不一致,签名校验就会失败,不再处理请求

签名校验
1、不修改数据包,重放请求,此时可以正常响应



2、然后修改参数icon_type的值为11,再次重放,此时会提示"message":"sign invalid",请求中的api_sign是签名的值,需要知道api_sign是怎么计算出来的



3、用url参数作为关键字搜索,在js中定位api_sign,设置断点


4、刷新网页,停在了断点位置,单步步入进入函数内部,可以看到加入了两个参数app_key、app_pwd,然后单步往下走,参数c的值此时为device_id=069c8db0-af49-11ed-9a08-3b99f11ff116×tamp=1676725825997&session_token=G2de7f3ab78910b46ad8c07d6e25c627&app_key=f6aefd6691f04573bdf9e044137372bc,也就是所有url参数


5、继续单步走,进行了一次排序,c的值为app_key=f6aefd6691f04573bdf9e044137372bc&device_id=069c8db0-af49-11ed-9a08-3b99f11ff116&session_token=G2de7f3ab78910b46ad8c07d6e25c627×tamp=1676725825997


6、之后就是拼接字符串,app_key+"Oic"+app_pwd+"QeeeS99u3d"+c+app_key+app_pwd



7、得到的字符串为:
f6aefd6691f04573bdf9e044137372bcOic72e78efefe6b4577a1f7afbca56b6e28993c06ea4bb84cde8dd70e582dbc76cbQeeeS99u3dapp_key=f6aefd6691f04573bdf9e044137372bc&device_id=069c8db0-af49-11ed-9a08-3b99f11ff116&session_token=G2de7f3ab78910b46ad8c07d6e25c627×tamp=1676725825997f6aefd6691f04573bdf9e044137372bc72e78efefe6b4577a1f7afbca56b6e28993c06ea4bb84cde8dd70e582dbc76cb

8、最后获取这个字符串的MD5,就是签名api_sign的值



9、还原了api_sign的计算方式,就可以开发burp插件自动更新签名校验的参数api_sign

用burp插件自动更新签名
burp插件的接口开发知识不再单独介绍了,否则篇幅会太冗长,在文中数据包加解密和签名保护绕过这块,没有涉及到太多复杂的开发知识。插件的学习可以参考官方文档和官方的代码demo,代码量不算多https://portswigger.net/burp/extender/api/index.html

首先在processHttpMessage中,检查uri参数,移除原来参数api_sign


根据修改后的uri参数,使用已还原的api_sign生成算法得到新的api_sign



此时修改参数,重放请求后,插件会自动更新url中api_sign的值(ps:下面这两个截图是笔者随意找的测试站点,url参数也是自己加的,读者根据上下文理解意思即可)




在控制台查看更新的api_sign,此时修改请求参数做安全测试就不再受签名保护限制了



数据包分段加密
一个H5应用,在微信可以正常访问,放到浏览器访问限制



修改一下User-Agent,修改为安卓或ios手机的UserAgent,再刷新页面后能正常访问



随便输入一个卡号后先抓个包看看



数据包都做了加密


任意修改一个密文字符,把第一个字符c改成1,服务端不能正常处理密文



直接发明文包不行,明文会被当成密文去解密


使用数据包的参数encryptData定位加密代码位置,展开js文件,搜索关键字;单击{}格式化js,方便阅读



单步步入调试进入pten函数,参数e是默认DES密钥



查看setMd5的入参,可以debug一行一行看



也可以将方法代码放到控制台查看



可以看到第一部分MD5的构造是原始参数json+DES密钥e,拼接后做MD5



setDES这部分是ECB模式,Pkcs7填充的DES加密,密钥是e



参数n是rsa加密DES密钥得到的密文,是一个固定值。最后返回MD5+splitStr+DES加密后参数+splitStr+rsa加密的DES密钥


splitStr是一个分割字符,用于将不同加密加密方式得到的密文分割开,服务端收到密文后,按splitStr分割密文,再逐段解密


拿到控制台看看是什么字符图片

也就是数据包中见到的\u001d图片


验证一下:解密中间部分的密文, 得到原始参数的json



ptde函数用于解密返回包的密文






单步步入getDESModeEBC函数,使用密钥e进行DES解密,没有其他处理





在线解密验证下



得到结论:
请求包的加密:MD5(原始参数+DES密钥)+”\u001d”+DES(原始参数) +”\u001d”+RSA(DES密钥)
返回包的解密:直接用DES密钥解密即可

分段解密
用正则获取两个\u001d中间的密文,


解密后在burp控制台打印,看看能不能正常解密



明文请求的body则加密后重新封包



这时候使用明文发包没问题了



使用IMessageEditorTab在burp中增加一个控件,用于获取解密后的完整请求包,在IMessageEditorTab中填入header和解密后的原始参数



先判断是否请求中包含参数encryptData



包含则说明是密文包,再启用控件,解密密文



点击“参数明文”控件,获取到了解密后的完整请求包,对明文参数进行安全测试,重放后插件会自动完成密文构造



对于变化的密钥,可以提供一个ui界面,在输入框设置密钥,rsa等动态变化的值



最后需要把返回包的密文也处理掉,由于在burp插件开发中返回包没有参数的概念,只能通过偏移获取body,解密后,用明文替换密文,再用IMessageEditorTab展示解密后的数据包



此时原始响应还是密文,因为客户端需要解密这个密文,IMessageEditorTab中明文只是展示作用,辅助安全测试,不会返回给客户端



encryptData中的密文被替换为明文展示,之后的安全测试就完全是明文了



自动BypassWAF 联动Xray
这也是数据包加密给安全测试人员的彩蛋吧,数据包加密有一个好处:天然对waf等态势感知设备免疫,自带绕过属性:
明文的payload会被waf识别



如果直接扫描原始请求,会触发WAF拦截



加密后waf没法再识别,如果还原了加密算法,也就间接的绕过了waf(但是,除了前置的waf,应用程序自身也会对参数做合法性校验)


控制台打印加密的payload



于是可以结合漏扫工具做半自动的安全测试(逻辑漏洞还是需要手工测试),示意图如下


1、burpA中联动Xray





2、开启联动Xray的开关



3、这个开关用于控制是否对明文请求包做加密,在联动Xray时,需要给Xray明文包,所以开启后从burpA重放的明文请求包不做加密,直接给Xray去做payload构造



4、设置Xray的代理



5、burpB作为Xray的代理


6、将插件代码拷贝一份,打包为另一个插件,作为联动Xray的专用插件。其他代码不用动,只修改BurpExtender.java中processHttpMessage方法代码:只处理经过Proxy的http流量,做两件事:加密请求body,解密响应body


7、启动Xray监听127.0.0.1:7777, 在burpA的Repeater中重放明文请求包


8、Xrays收到burpA的明文请求,在明文包构造payload,开始扫描,从Xray日志可以看到,未触发WAF


9、burpB收到Xray的明文请求,加密请求中明文中包含payload的body再发给服务端,扫描器能正常工



10、查看控制台打印的密文body:



11、burpB解密响应的密文body后返回给Xray,从状态码和返回包可以看到未触发WAF拦截,Xray再根据明文响应包内容判断是否存在漏洞



原文于:https://xz.aliyun.com/t/12295
原文作者:1615078760777882


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|安全矩阵

GMT+8, 2024-3-29 20:09 , Processed in 0.012752 second(s), 19 queries .

Powered by Discuz! X4.0

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表