网络安全炼金术：短信轰炸漏洞，从逆向到无限可能？

别被加密迷惑！短信轰炸的“华点”在哪？

常规操作是啥？手机号加密，然后逆向解密，发送验证码，服务器生成标识值，再用这标识值发回去...听起来是不是像绕口令？但问题的关键是：这套流程真的安全吗？

抽丝剥茧：挖掘短信轰炸漏洞的“三板斧”

第一板斧：解密？不，是“扒”加密方式！

与其说是“逆向”，不如说是“扒”。一层层扒开加密的外衣，找到加密方式和密钥。就像图片里展示的，通过断点调试，揪出幕后黑手：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进行无限发送。

声明： 本文仅用于技术探讨，严禁用于非法用途。任何未经授权的渗透行为都将承担法律责任。请务必遵守法律法规，保护网络安全。