漏洞根源在于人——业务技巧篇

本文作者：i春秋签约作家——夏之冰雪

今年初写的一篇文章，漏洞根源在于人——知识深度篇 ，本来是写系列文章，因为各种个人原因一直推迟了。收拾好心情，重新出发吧！ 我们在安全检测、攻击的时候，会持续积累实战的业务经验，这些经验非常宝贵。不过，我们不能只局限在这样一个模式下： 已知的知识 + 实战 = 经验 这些经验并不足够丰满，我们需要跳出已知的安全知识点、打破常规的业务经验，往往需要向前多走一步，做额外的尝试，只有才能让自己在业务技巧上有更多的可能。本篇文章，我会列举一些案例和思路，与大家分享，希望大家在安全检测、攻击的时候，可以多一些尝试。 1. sql语句并不是只有注入点 一般情况下，我们会利用get、post参数，进行sql注入攻击，厂商采用的策略主要是： a. sql过滤 b. 类型判断 c. 预处理 有些业务在实现上直接使用了类型判断，比如查看新闻、查看商品、查看用户信息、分页等等，这些参数都可能做了数字判断。 比如阿里云的某个接口（近期已修复）： ​ 当我们传递非数字的时候，比如字母a，就会报错，告知类型不正确： 看上图，我们可以断定这个接口不存在sql注入，但是如果只局限在sql注入的业务经验上，我们可能什么也得不到。 跳出固有的攻击思路，即使是数字限制，其实依旧可以得到一些有用的信息： 由于代码层面只做了限制，但是并没有做正负数这种限制。当我传递一个负数如-11时，代码的检测语句判断正常，于是将-11传递给了mysql，而mysql的limit语句是分页功能，只能接受正整数。因此，抛出异常，阿里云的数据库表、sql语句、相对目录结构等信息，我们就这样得到了。 2. 业务检测不要只做一半 这是我在新人身上发现的问题，某款app需要做安全测试，我交给了一个新人做。由于他的经验较少，我都是在一个excel里面写好所有可能的攻击测试用例，让他照着excel挨个尝试寻找突破口。 其中的一个测试用例，如下图，这是这款app的一个活动页面，提供给用户一些福利，其中的两个福利是“每日签到”和“每周签到”。对这类业务，最显而易见的攻击就是突破次数限制，就拿“每日签到”来说，有可能接口没做限制，只是在app限制了，那攻击者就可以不断调用这个接口进行薅羊毛。 等新人把所有攻击结果给我的时候，他的攻击结论是此app无法薅羊毛。 而当我亲自测试的时候，我发现其实是可以薅羊毛的： 我的攻击账号得到了上万的额度，这是要花很多钱才能得到的。为什么会出现这个情况？并不是我比新人聪明，新人之所以没找到，是因为他进入了一个误区，他只测试了“每日礼包”发现没有漏洞，就没再测试“每周礼包”，误认为都没有漏洞。而我，并没有耍小聪明，把整个测试用例测全，发现“每周礼包”是可以突破时间限制的。 此漏洞，和app厂商确认，原因是工程师在做一周限制的时候，代码逻辑写的有问题。 A业务和B业务类似，如果A没有漏洞，那么B也没有漏洞。 如果我们被这个思路所束缚，虽然带来了效率的提升，但也失去了更多漏洞发现的可能。 3. 围绕userid展开围攻 网络安全中，数据泄露的危害程度是最大的，而用户数据泄露又是所有数据泄露中级别最高的。 在攻击中，用户数据的窃取往往是黑客的重点攻击目标。 也举几个例子： a. 某个人信息管理微信小程序 包括公司、姓名、头像、电话等多个维度的信息展示。 这类接口都是以userid为参数依据，可以直接遍历user_id获取数据。我们换个user_id，就能查看另一个人，仅作测试： b. 个人简历制作类程序 由于移动互联网的普及，大家在找工作的时候，已经开始使用电子简历。电子简历有其遍历性，可以快速的传递给面试公司，并可以灵活的传递、分享和转发。 那么，这个领域的各类产品，由于没有做好安全防护，也会存在userid遍历。 这类产品，并没有很好的对学生做好隐私保护： 调用接口也同样简单，只需要抓包，然后批量遍历user_id: c. 还有很多 除了简历、个人信息，还有发票管理、通讯录管理等等，甚至还有大姨妈这种记录个人生活习惯的业务产品，这些领域的业务，都有涉及各种数据。由于安全门槛不高，这些业务都可以围绕着userid进行展开，会发现可采集的价值数据信息很多。 总之，要多去思考、多去尝试，把攻击的业务范围扩大，把数据学会关联（比如手机号关联）。随着互联网的发展，会有越来越多的数据源可被挖掘或攻击，不要只停留传统的： 数据脱裤 ————》 社工库 而应该是： 全方位业务采集 ————》 围绕userid的获取 ————》 多维度数据筛选、业务间数据关联 ————》 社工库 4. 尝试绕过当前的限制 一切皆幻想，不要被表面的安全所震慑，有些防护看似牢不可破，这个时候可以通过业务延伸的途径绕过防护。 就跟古代打仗一样，主城墙看似攻不可破，我们能否攻击背后？我们能否让士兵扮演老百姓？我们能否假装是援军？我们能否夜间突袭？网络攻击虽然不能用这些招数，但是他们其实有很多相似点。 a. 声东击西 某款产品，号称几十天就斩获千万用户，经过测试，所有用户信息接口直接对外暴露、加密规则对外暴露，直接导致所有用户数据裸奔。 如上图所示，我们只要知道card_id和aid就能够获取一个用户的详细信息。aid看起来是个加密的数据，正常情况是不能遍历的，保证了安全性。这个时候，我们就不能只盯着这个接口了，毕竟aid很长很复杂，暴力破解也不是办法。这个时候，就需要围绕这个产品业务大量的抓包分析，结果发现他们提供了下面这个接口，传递任意uid即用户id，就可以获取card_id和aid。 这个案例说明的是，想要攻击a接口，有时候我会用b接口作为跳板，然后达到对a攻击的目的。 b. 借刀杀人 b案例和下面的c案例，这两个漏洞是真实案例，但由于漏洞涉敏，因此我虚构一个场景吧，这里假设以i春秋作为虚构的例子，方便理解。 i春秋功能非常丰富，提供了大量的api接口，网址如下： https://api.ichunqiu.com 其中有一个接口是修改密码的接口： https://api.ichunqiu.com/reset_password 比如当前用户，修改密码为"huaidan"，其中token就是这个用户登陆的秘钥，长度24位不可伪造，确保了其唯一性、安全性。接口调用如下：

curl -i '[url]https://api.ichunqiu.com/reset_password?token=55267d0f988a7cc4376222b2&new_password=huaidan'[/url]

这个接口无论怎么尝试，都会因为token的存在导致无法攻击成功，那么这个时候就需“尝试绕过当前的限制”。 经测试，发现i春秋有一款app，非常好用，appstore下载量全球第一，跑题了。。。 在使用i春秋app的过程中，发现了一个问题，这款app的网络请求中也使用了很多api.ichunqiu.com域名下的接口。app开发工程师为了方便，只要是在app下调用api接口，就会自动加上用户的token。 这里其实不难理解为什么自己的api接口会自动加上token，这样可以很方便的识别用户。有些app，对于自家网站的网页地址，也会自动加上token这种特征行为，这样可以很方便的进行用户行为统计，也能确保接口或者网页都是已登录状态操作。 那么，如果我能引导用户的手机，触发reset_password请求，岂不是也会自动加上token？那不就可以实施攻击了么！ 怎么诱导用户触发这个请求？我非常幸运地发现，这款app还有个im，也就是聊天功能。 “Hi 坏蛋，这里有大量的美女照片：https://api.ichunqiu.com/reset_password?new_password=huaidan” 当坏蛋在app收到消息后，铁定会去点击的，然后app自动在后面加上token，然后就没有然后了。。。 攻击原理图如下： 当然，这里也许有人要问，这个改密码链接这么明显，坏蛋肯定不会点。所以，真实例子中，我会生成一个短链，作为诱饵。 这个案例说明的是，即使在没有权限的情况下，依旧可以借助一些业务实现的机制，得到这一权限，如同借刀杀人。 c. 瞒天过海 接着b这个例子继续扩展。 i春秋给每一个用户提供了个性的话主页，为了方便传播自己的主页，专门做了一个二维码。可以把二维码分享到第三方平台上去，比如微博、微信，用户识别二维码后会跳转到对应的白帽子个人介绍页面。 我分析了这个二维码，实际地址如下： https://www.ichunqiu.com/view?profile_token=ae7ffef787ed78a7adc7772901 可以看到，profile_token这个参数用来识别用户的，并获取用户个人信息并展示主页。这个token会不会就是用户的登陆token？心血来潮，我把reset_password的token换成了这个：

1curl -i '[url]https://api.ichunqiu.com/reset_password?token=ae7ffef787ed78a7adc7772901&new_password=huaidan'[/url]

提示我token不合法，看来不对。我又第二波心血来潮，直接把token关键字也换成了profile_token:

1curl -i '[url]https://api.ichunqiu.com/reset_password?profile_token=ae7ffef787ed78a7adc7772901&new_password=huaidan'[/url] 修改密码成功！ 竟然通过二维码的用户标识，冒充了用户的登陆token，进行了高危权限的操作！就这样瞒天过海了。。。 写在最后，在做安全测试的时候，最多的、最好找的往往都是业务漏洞。之所以找不到，是因为我们覆盖的范围不够广，业务之间的关联性没有很好的把握。希望大家在对业务做测试的时候，多一些耐心，多动手把业务流程在纸上画出来，甚至编写攻击case，这样挖的洞自然也就多了。 昨天2017年12月7日，美团上热搜了，连续扣费三次订单失败，用户直接炸了。除了这一炸，还有白帽子提交了个非常吓人的漏洞，这里不方便透漏细节（可以理解为，黑客可以修改任意用户的订单支付价格，就知道多严重了）。我觉得，最大的原因在于公司快速发展下，不注重业务质量，最终业务安全势必要出问题的。所以，不论厂商还是白帽子，都不要忽视业务安全。