文章来源:先知社区(Fr4nk)
原文地址:https://xz.aliyun.com/t/5432
在网站测试的过程中,常常在用户注册登录时出现手机号/邮箱注册,这里收集了较为流行的临时接收短信的网站,可用于测试。具体如下:
https://www.pdflibr.com/
http://www.z-sms.com/
https://www.receive-sms-online.info/
[随机推送] https://yunduanxin.net/
[国内] http://www.smszk.com/
[国外] http://receive-sms-online.com/
[国外] https://smsnumbersonline.com/
[国外] https://www.freeonlinephone.org/
[国外] https://sms-online.co/receive-free-sms
与此同时,写了个爬虫整理了上面涉及到的phone list,可作为黑名单进行反作弊建设:
https://gist.github.com/fr4nk404/1d8317a5f66ebe0933b8fade897497ff
目前,商业网站的用户账号基本上是以手机号/邮箱注册登录,这样能够方便用户使用短信/邮箱验证码直接登入账户,在使用的过程中进行更好的账户管理。在以简易便捷为目的的基础上方便用户管理账号时也引入了安全风险,即短信炸弹/垃圾邮件等。
从企业的角度上看,短信的发送需要向运营商交付一些费用。尽管企业短信费用比个人用户低廉,但是一旦被恶意利用发送大量短信后,将会造成较大的直接经济、信息和名誉损失。
从用户的角度上看,大量垃圾短信的发送将会直接造成信息骚扰。而当大量网站被恶意利用者掌握时,针对指定号码的黑名单防护将失去效用,从而造成个人骚扰。
从攻击者的角度上看,可以将前期收集到包含该漏洞的网站集成到攻击工具中,对指定用户、企业域名邮箱用户进行短信轰炸、个人骚扰等。
从进一步漏洞利用角度看,可通过注册接口测试账号是否注册过,结合社工库可进行撞库等;若发送的信息内容在发送信息的请求包中,攻击者也可自定义发送内容,从而造成进一步的钓鱼利用等。
在应用手机号/邮箱和验证码作为用户登录凭证时,一般涉及到的网站功能点主要包括:
账号注册
首次设置密码时用户身份校验
账号登录(可选验证码方式)
重置密码
绑定手机/邮箱
修改绑定手机/邮箱
免费试用/活动领取/独特功能/反馈处
待补充...
在网站账户注册处,填写手机号/邮箱。使用Burp抓包发送到Repeater进行重放测试,返回结果为发送成功。
尝试测试是否设有频控,一般测试10~20次。若持续可接收验证码,则证明漏洞存在。
最近做测试的时候还遇到某网站在注册功能,响应头Session中存放了一个token,用户在前端触发具体操作时会根据该token生成另一个key,提交时后端再根据token和key验证是否合法来拦截短信轰炸。在这种情况下,每次触发接收验证码时,只需提前将cookie删除,即可绕过拦截
3. 修改Cookie
在做安全防御时,一些网站在注册请求Cookie中存放一个固定值,当前端发送请求时,该值唯一校验一次。因此可通过在该请求Cookie中添加简单的数字后缀进行绕过[3];
另外,最近遇到的一个情况是在某办公协作系统域名下的不同子域中,如在 www.A.com
域名下进行账户注册,注册成功随即默认登录(该处服务端已做了手机号的频率控制)。而在该域名 A.com
的另一个子域名 test.A.com
下没有注册功能,用户可用在 www.A.com
域名下注册的账号进行首次登录,并设置密码。而此时,在 test.A.com
中进行首次登录时验证码登录未做频控。此处场景利用主要用于企业统一账号登录的多平台设计一致性。
在漏洞挖掘的过程中,手机/邮箱账号登录验证还涉及到了一些如越权、逻辑缺陷其他问题,此处结合轰炸问题一起分享出来。
修改绑定
在登入网站账户后,一般带有修改绑定等功能。正常流程修改绑定流程如图:
(1)由于逻辑设计缺陷,攻击者可在未接收到服务端验证码时修改 服务端校验的返回包文为校验正确包文
(如图流程),从而绕过原手机号验证,越权进行账号重绑定;
(2)按照正常流程发送请求包,将提交新手机号并获取验证码过程
(如图流程)单独拿出。有些服务因逻辑缺陷,未在之前的流程中添加校验正确的token,导致该请求包可以在登入账号的情况下无需校验原手机号,只需从发送提交新手机号验证码包文
处开始流程即可。
同时,有些服务由于在修改绑定处默认认为账号登录安全,因此未进行短信轰炸的防御,从而可以在此处修改绑定
位置进行短信轰炸。
服务端限制同一手机号单位时间内的发送次数和时间间隔,如超过限制则根据业务需求进行相应时间的禁止限制;
根据业务特点,设定手机验证码每天的最大发送量;
对每一步的请求验证严格,要以上一步的结果为依据,同时应注意尽量避免攻击者可控,如在请求参数中随机假如一个key,并贯穿验证的始终;
绑定图形校验码,将手机验证码和图形校验码进行绑定,防止恶意攻击;
服务端返回给用户的验证相关内容避免在请求中独立展示,减少攻击者可控点,降低钓鱼风险。
如有侵权,请联系删除
推荐阅读