作者:leveryd
原文链接:https://mp.weixin.qq.com/s/mnHGLZ_e3tWkxCL-DPAAvQ

背景

以前挖国内src时的一个套路:

通过"寻找管理后台 + 寻找api接口 + burp验证api接口"来找未授权api

找到未授权api后,根据api功能就能造成不同危害:

  • 比如利用"重置密码接口"来重置管理员密码,然后登陆后台
  • 比如利用"查数据接口"获取数据

个人觉得这个套路比较好用,原因在于:

  • 没有攻击payload,waf、nids等安全设备比较难检测(虽然可能按照访问404频率和比例等特征封禁)
  • "管理后台对外开放"和"api接口未授权访问",个人感觉这两个风险在企业里很难靠"技术手段"完全杜绝
  • 大部分检测工作可以用工具完成

也有不好的地方,在于:

  • 整个流程没有完全自动化,需要人工做重复性的事情,比如判断是否是管理后台

详细过程

  • 怎么找"管理后台"?

大概分三步:

  * 第一步筛出可能的管理后台地址
  * 第二步将首页截图保存成本地
  * 第三步人工浏览截图

第一步筛选管理后台地址的策略包括:

  * 域名中包含关键词,直接当作后台管理系统
  * 30x跳转地址包含关键词
  * 响应html中包含table标签(因为有可能后台管理首页就存在未授权访问,数据展示时会用到table标签)
  * 判断页面是否是vue框架写的(因为很多开发喜欢选择用vue来做管理系统)

脚本片段:https://gist.github.com/leveryd/334b719e253261ffd0abfd161e499ae7

  • 怎么找api接口?

从js文件文本中找,策略如下:

  * 将js代码中字符串常量提取出来
  * 字符串常量匹配 `/[\w\d\-./]+` 且不以 // 字符开头,认为是api路径
  * 字符串常量匹配 `[\w\d\-]+/[\w\d\-./]+` 且不以 / 字符开头,认为是api路径

脚本片段:https://gist.github.com/leveryd/465d19610d5fcf99199beb9284cd6f8c

这种方式不需要前端存在sourcemap泄漏。

当然如果前端有sourcemap信息就更好,这样可以利用 利用sourcemap还原前端项目-浏览器插件 这种工具还原前端项目,代码阅读性更好一些。接着对前端项目做代码审计,有可能在前端代码中看到 啥token、啥功能比较特殊的api接口(比如上传文件)。

  • 怎么使用burpsuite验证api接口?

将找到的api接口放到burpsuite批量验证,根据 响应状态码、响应长度、响应内容 来判断是否有未授权的api接口。

测试过程中可以变换请求方法:GET、POST、PUT

确认存在未授权接口后,再人工从前端js中找参数值利用。

成果

  • [评级高危-顺丰某系统后台API接口未做认证导致用户信息泄漏]
  • [评级高危-顺丰某系统未授权导致获取后台管理权限,可查看大量订单信息]
  • [评级高危-字节某业务线后端接口未授权访问]
  • [评级中危-腾讯广告后台接口未认证]
  • [评级低危-后台API接口存在未授权访问(可增删改数据)]

安全管理与技术

对于"管理后台对外开放"和"api接口未授权访问"这两类风险,在企业安全建设中是怎么防范的呢?

  • 怎么减少"管理后台对外"安全风险?

根据个人有限的经验来总结,管理上包括如下手段:

  * 公司发布安全红线:禁止后台开放到公网访问
  * 安全意识的宣导

技术上包括如下手段:

  * 统一认证登陆
  * 周期性对资产做扫描,识别"管理后台"
  * 从流量层面识别"管理后台"

业务上包括如下手段:

  * 后台访问白名单限制
  * 后台登陆多因素认证MFA(短信二次认证、rsa token等)

比如能看到的,滴滴很多后台管理业务都接入了统一认证登陆,对于我来说就比较难进一步测试。

不过上面的手段都并不一定管用,各种手段自身也有设计缺陷、安全漏洞等。

比如我前公司的统一认证平台 统一认证登陆 出现过一个设计上的漏洞。

正常的业务场景是:它支持钉钉登陆,员工在web页面输入邮箱后,钉钉app会收到一个确认登陆链接。员工点击确认链接后,web端就会验证通过,进入到后台系统。

有白帽子收集一些部分员工邮箱,就在web页面填收集到的邮箱。结果有部分员工点击了钉钉上收到的"确认登陆链接"消息,帮助"攻击者"进到了后台系统。

另外还听我同事给我分享的案例,他遇到某些有多因子认证的系统时,加x-forwarded-for请求头伪造内网ip就绕过去了,原因是面向内部的系统去掉了"多因子认证"。

至于安全意识的宣导、安全红线到底有多大作用,这感觉更不好衡量。

  • 怎么减少"api接口未授权访问"安全风险?

根据个人有限的经验来总结,技术上包括以下手段:

  * 依赖开发人员的代码安全质量
  * 零信任架构的实施

零信任应用的两个场景包括了 用户访问服务 和 服务之间互相访问 时的认证鉴权,而"用户登陆后台访问数据"恰好就是"用户访问服务"这个场景。

总结

验证了这个老套路在国内还是能挖到洞的。

站在攻击方的角度来看,现有每一步的安全策略可以优化,比如可以详细调研一下后台系统的分类,比如为什么开源的cms后台和前台经常是在一个域名下,而企业里的后台系统为什么经常是单独的访问方式?

整个流程或许也可以优化到完全依赖工具产出报警,就像 一种针对Webpack等前端打包工具构建的网站的自动化测试思路(附开源项目) 一样。虽然没有用过这个项目,但是看文章介绍感觉有不少实战上的细节和经验。


Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/1637/