浅谈轰炸漏洞攻防思路

最近做一些测试的时候遇到了挺多有意思短信轰炸的攻、防场景和思路，这里简单记录一下相关内容。

0x00 前期准备

在网站测试的过程中，常常在用户注册登录时出现手机号/邮箱注册，这里收集了较为流行的临时接收短信的网站，可用于测试。具体如下：

1. https://www.pdflibr.com/
2. http://www.z-sms.com/
3. https://www.receive-sms-online.info/
4. [随机推送] https://yunduanxin.net/
5. [国内] http://www.smszk.com/
6. [国外] http://receive-sms-online.com/
7. [国外] https://smsnumbersonline.com/
8. [国外] https://www.freeonlinephone.org/
9. [国外] https://sms-online.co/receive-free-sms

与此同时，写了个爬虫整理了上面涉及到的phone list，可作为黑名单进行反作弊建设：

https://gist.github.com/fr4nk404/1d8317a5f66ebe0933b8fade897497ff

0x01 常见问题

1. 简介

目前，商业网站的用户账号基本上是以手机号/邮箱注册登录，这样能够方便用户使用短信/邮箱验证码直接登入账户，在使用的过程中进行更好的账户管理。在以简易便捷为目的的基础上方便用户管理账号时也引入了安全风险，即短信炸弹/垃圾邮件等。

2. 一般功能

在应用手机号/邮箱和验证码作为用户登录凭证时，一般涉及到的网站功能点主要包括：

0x02 短信/邮件轰炸

1. 一般测试方法

在网站账户注册处，填写手机号/邮箱。使用Burp抓包发送到Repeater进行重放测试，返回结果为发送成功。

尝试测试是否设有频控，一般测试10~20次。若持续可接收验证码，则证明漏洞存在。

2. 删除Cookie

最近做测试的时候还遇到某网站在注册功能，响应头Session中存放了一个token，用户在前端触发具体操作时会根据该token生成另一个key，提交时后端再根据token和key验证是否合法来拦截短信轰炸。在这种情况下，每次触发接收验证码时，只需提前将cookie删除，即可绕过拦截。

3. 修改Cookie

在做安全防御时，一些网站在注册请求Cookie中存放一个固定值，当前端发送请求时，该值唯一校验一次。因此可通过在该请求Cookie中添加简单的数字后缀进行绕过[3]；

4. 设计缺陷

另外，最近遇到的一个情况是在某办公协作系统域名下的不同子域中，如在 www.A.com 域名下进行账户注册，注册成功随即默认登录（该处服务端已做了手机号的频率控制）。而在该域名 A.com 的另一个子域名 test.A.com 下没有注册功能，用户可用在 www.A.com 域名下注册的账号进行首次登录，并设置密码。而此时，在 test.A.com 中进行首次登录时验证码登录未做频控。此处场景利用主要用于企业统一账号登录的多平台设计一致性。

5. 其他相关问题

在漏洞挖掘的过程中，手机/邮箱账号登录验证还涉及到了一些如越权、逻辑缺陷其他问题，此处结合轰炸问题一起分享出来。

在登入网站账户后，一般带有修改绑定等功能。正常流程修改绑定流程如图：

（1）由于逻辑设计缺陷，攻击者可在未接收到服务端验证码时修改 服务端校验的返回包文为校验正确包文(如图流程)，从而绕过原手机号验证，越权进行账号重绑定；

（2）按照正常流程发送请求包，将提交新手机号并获取验证码过程(如图流程)单独拿出。有些服务因逻辑缺陷，未在之前的流程中添加校验正确的token，导致该请求包可以在登入账号的情况下无需校验原手机号，只需从发送提交新手机号验证码包文处开始流程即可。

同时，有些服务由于在修改绑定处默认认为账号登录安全，因此未进行短信轰炸的防御，从而可以在此处修改绑定 位置进行短信轰炸。

0x03 轰炸防御

1. 服务端限制同一手机号单位时间内的发送次数和时间间隔，如超过限制则根据业务需求进行相应时间的禁止限制；
2. 根据业务特点，设定手机验证码每天的最大发送量；
3. 对每一步的请求验证严格，要以上一步的结果为依据，同时应注意尽量避免攻击者可控，如在请求参数中随机假如一个key，并贯穿验证的始终；
4. 绑定图形校验码，将手机验证码和图形校验码进行绑定，防止恶意攻击；
5. 服务端返回给用户的验证相关内容避免在请求中独立展示，减少攻击者可控点，降低钓鱼风险。

0x04 小结

在以上问题分析过程中，从攻、防角度双向分析了一些短信轰炸/垃圾邮件可能出现的思路，可供参考~

转自先知社区