有时候，乙方不能感受甲方的痛；
有的漏洞，乙方不会碰到甲方的场景；
不是因为技术不够强，只是由于缺少对业务足够深入的理解。
在漏洞回归的时候，也会发现新的隐患；
一条短短的验证码，可能酿成一场事故；
业务安全之另类隐患，希望和大家分享鲜有人说的点点滴滴。
1、系统登录处暴力破解
1.1 回归验证
某业务系统在修复安全问题，并进行部分功能调整后进行安全提测，内容如下：
接收到提测邮件后，安全测试人员首先对已知漏洞在测试环境进行验证。使用burp对登录接口进行枚举验证：
当发现可枚举问题还未修复完善时，立即停止了爆破并打回相关漏洞。
1.2 短信炸弹
一切都是常规操作，不过不久之后，有不少用户反馈收到上述业务系统发出的短信验证码。不幸的是正好命中一位公司高管，据其描述最近总收到测试环境的验证码且有多条，一声令下要求追溯发信源头，并将收到短信验证码一事定级为安全事故。由此，信息安全组便成了肇事者，身背故障分。
1.3 事故分析
登录接口设计存在缺陷：
输入用户名和密码，若验证成功则对该用户发送短信验证码
测试环境使用生产数据：
为了方便测试，开发将其他数据库的真实手机号等信息同步至相关测试数据库，导致大量真实用户收到测试环境短信验证码
提测缺失重大变更信息：
开发未同步用户的密码，系统新增的同步用户统一被设置初始弱密码，且登录接口有重大变更，未在提测信息汇总进行描述
1.4 经验教训
从安全的角度出发，在此次事件有点冤。但事已至此，吃一堑需要长一智，在痛苦的经历中学习提高，关于对业务可能造成高风险危害的操作尽量少做或不做：
漏洞扫描、漏洞利用等高危操作，尽量做到事先告知业务方
安全测试前先评估影响范围，尽量确保对业务和用户无影响
安全测试时尽可能主动了解业务形态及功能变更等多种情况
2、密码找回处暗藏危机
2.1 缺陷挖掘
某系统在密码找回处，可以通过工号或手机号进行找回。
当输入存在的工号或已注册手机号时，response返回手机号：
当输入存在的工号或已注册手机号时，系统自动发送四位数字短信验证码：
看到这里，很多人都会想到任意用户密码重置漏洞的场景：
通过第一步可以枚举出已经注册的用户，
从第二步获知纯数字的四位验证码很容易爆破，
此时还需要看看该接口是否可以枚举：
虽然用户名和密码加密，但该接口还是可以进行枚举。使用一些小技巧不难加密用户名和密码，所以该系统此处功能存在严重漏洞，且已经有利用成功的案例：
2.2 漏洞修复
面对有图有真相的任意用户密码重置漏洞，开发立即响应进入漏洞修复阶段，对用户名密码验证频率和次数进行了限制，降低了漏洞带来的风险。
2.3 暗藏危机
在回归验证时，原漏洞在和产品的沟通下，算是基本修复。
然而事情往往没这么简单，静下心来分析发现了更加隐蔽的安全隐患：
可发短信至任意用户(包括领导)，同上一个场景一样，又是只有甲方才能深刻体会到的风险。
2.4 深刻体悟
业务方面的安全隐患，可能不仅仅是由于业务逻辑造成，其他不规范的操作也起到一定的助攻成分。
业务相关的漏洞修复，推动改起来甚至比web漏洞更加难，因为产品要考虑友好度和便捷性。不过也可以找到其他次之的修复方案，在安全和业务之间找到平衡点，让安全真正的为业务保驾护航。
原文发布于微信公众号 – 我的安全视界观（CANI_Security）
来源：freebuf.com 2018-08-19 21:43:19 by: 阿尔法之梦
请登录后发表评论
注册