近期在进行短信轰炸的漏洞排查专项，所以对当下的短信轰炸进行排查的案例以及对排查方案进行总结。
1. burp
2. Ehole
1、空格绕过的短信轰炸案例分享
2、短信轰炸的排查方案示例
3、修复方案
01 前言背景
近期短信轰炸专项排查时，访问到某业务系统时，尝试重复放包，该系统存在短信轰炸的防护逻辑。
但是在进行横向轰炸测试时，意外发现该系统可用多个手机号循环重复进行短信验证码获取，可短时间内触发多条短信。
后续发现已有对短信轰炸绕过方式的总结文章：
(https://www.cnblogs.com/backlion/p/17294082.html)
参考其中手法，进行绕过尝试，发现空格绕过对该类短信轰炸的防护手段有较好的绕过验证效果。
问询业务方在该处实现的功能逻辑，梳理后存在以下问题：
1、先对用户传递的手机号字符串进行是否重复发送的比对逻辑，再对该字符串进行11位数字字符的规范处理。该逻辑导致相同手机号在增添空格字符后，被记为不同的手机号。
2、为防止轰炸，对已发送短信的手机号采用了短队列存储，新请求验证码的手机号，会将最早记录的手机号挤出队列。
主要为问题1存在的逻辑漏洞，可进行空格绕过。
02 排查方案
对于公网资产，先进行可能存在短信轰炸页面的收集，可利用指纹框架判断工具，如ehole等对常见关键字(注册、找回等)进行筛选检索。
Ehole: https://github.com/EdgeSecurityTeam/EHole
此处给出ehole可用的指纹文件示例
{"fingerprint": [{"cms": "找回密码","method": "keyword","location": "body","keyword": ["找回"]}, {"cms": "忘记密码","method": "keyword","location": "body","keyword": ["忘记"]}, {"cms": "注册","method": "keyword","location": "body","keyword": ["注册"]}, {"cms": "一键登入","method": "keyword","location": "body","keyword": ["一键登入"]}, {"cms": "忘记密码","method": "keyword","location": "body","keyword": ["forget"]}, {"cms": "手机","method": "keyword","location": "body","keyword": ["手机"]}, {"cms": "验证码登入","method": "keyword","location": "body","keyword": ["验证码登入"]}, {"cms": "密码重置","method": "keyword","location": "body","keyword": ["reset"]}, {"cms": "密码重置","method": "keyword","location": "body","keyword": ["重置"]}, {"cms": "短信快捷登入","method": "keyword","location": "body","keyword": ["快捷"]}, {"cms": "短信登入","method": "keyword","location": "body","keyword": ["短信"]}, {"cms": "短信便捷登入","method": "keyword","location": "body","keyword": ["便捷"]}]}
之后对筛选出的资产清单进行人工判断，确定是否存在短信轰炸问题。
当电话号码传参不存在传递字符串长度的限制，且未对含非数字字符的输入进行过滤时，可尝试输入空格字符(" ","%20","+")，测试其对短信发送接口的影响。
也可以直接使用相关插件，如SMS_Bomb_Fuzzer
（https://github.com/yuziiiiiiiiii/SMS_Bomb_Fuzzer）
之后根据收到的短信验证码情况，来判断短信轰炸的防护状况。
03 修复方案
1、后端严格校验输入的手机号格式并对短信发送频率做限制，只允许输入11位数字，过滤所有特殊字符。
2、对近期发送过短信验证码的校验，对提取后的手机号进行记录匹配，而非用户直接传递的字符串。
3、短信发送前增添完备的图形验证码校验。
原文始发于微信公众号（安全驾驶舱）：【web安全】短信轰炸排查思路分享
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论