别被加密迷惑!短信轰炸的“华点”在哪?
常规操作是啥?手机号加密,然后逆向解密,发送验证码,服务器生成标识值,再用这标识值发回去...听起来是不是像绕口令?但问题的关键是:这套流程真的安全吗?
抽丝剥茧:挖掘短信轰炸漏洞的“三板斧”
第一板斧:解密?不,是“扒”加密方式!
与其说是“逆向”,不如说是“扒”。一层层扒开加密的外衣,找到加密方式和密钥。就像图片里展示的,通过断点调试,揪出幕后黑手:AES-ECB加密
,密钥是U0Xg55zo9-TglUjxvBG_Dac_2NAsAyQc
。等等,这密钥...真的安全吗?
试着用它加密手机号,如果成功了,恭喜你,拿到了“入场券”。但别高兴太早,这只是万里长征第一步。
第二板斧:mfaid的“乾坤大挪移”?
抓包!抓包!抓包!重要的事情说三遍。当你发送验证码时,注意观察数据包,你会发现一个神秘的mfaid
值。
这个mfaid
就像一个“通行证”,告诉服务器:“我要发短信啦!” 但这玩意儿只能用一次,用完就失效,服务器会给你一个新的。
POST /prod-api/xxxr/xxx/send-sms HTTP/1.1 Host: xxxx Cookie: xxxxxx Content-Length: 65 Sec-Ch-Ua-Platform: “Windows” Sec-Ch-Ua: “Microsoft Edge”;v=”131”, “Chromium”;v=”131”, “Not_A Brand”;v=”24” Sec-Ch-Ua-Mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0 Accept: application/json, text/plain, */* Content-Type: application/json;charset=UTF-8 Istoken: false Accept-Certificate: 81111559-124c-408e-b436-a86ff5f3d95e Origin: xxxxxxx Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: xxxxxxx Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 Priority: u=1, i Connection: keep-alive {“phoneNumber”:”手机号加密”,”mfaId”:”TMAxxxxxUupr”}
HTTP请求头里塞满了各种信息,但最关键的还是phoneNumber
和mfaId
。
第三板斧:无限刷新的mfaid,轰炸的“永动机”?
漏洞的根源在于,服务器竟然允许我们用旧的mfaid
换新的mfaid
! 这就像一个死循环,你用A换B,再用B换C,然后用C换D... 只要你有足够的耐心,就能无限刷新mfaid
,然后...Duang!短信轰炸!
漏洞的“阿喀琉斯之踵”:次数限制去哪了?
最致命的是,这里竟然没有对手机号的发送次数做限制! 这简直是给攻击者开了绿灯,让他们可以肆无忌惮地利用mfaid
进行无限发送。
声明: 本文仅用于技术探讨,严禁用于非法用途。任何未经授权的渗透行为都将承担法律责任。请务必遵守法律法规,保护网络安全。
黑客/
原文始发于微信公众号(龙哥网络安全):网络安全炼金术:短信轰炸漏洞,从逆向到无限可能?
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论