对某大型企业的一次web漏洞挖掘过程

  • A+

注:本文相关漏洞均已报告 SRC 并完成修复

前言

近几年工作转型,已经很久没挖过漏洞,突然想检验一下自己当前是否还有挖洞能力。因此本次以挖到某个大型厂商一个中危级别以上漏洞作为目标,最终挖到了一个低危 (存储 xss ) + 一个高危 (任意文件读取) ,完成了本次目标。同时将整个过程较完整的思路记录下来,供大家参考。

前期思路

该企业有着多年的自身安全建设及 SRC 运营,如果以渗透测试的思路拿机器权限绝非易事(渗透测试思路请参考此前发到乌云 drops 的一篇文章
渗透中寻找突破口的那些事),且常见的反射 xss,sql 注入等问题估计早已被内部扫描器、自身及外部安全人员挖的差不多,我就以逻辑类漏洞作为主要挖掘方向。

寻找目标

既然要寻找逻辑类漏洞,首先要寻找功能比较复杂的站点,通过搜索引擎搜索
site:xxx.com
发现这么一个站点

1.png

通过域名 git.xxx.com 可初步判断为是一个类似 gitlab 的代码托管平台,此类平台一般会涉及到用户管理、文件管理、项目管理等功能,可测试的种类多样,因此将目标定在这个系统上,深入测试每一个功能,直到挖到中危以上漏洞完成目标。

测试过程

登录系统后可看到左侧功能菜单如下

2系统首页.png

可以看到功能还是比较丰富的,需要注意的一点是测试全程开启抓包工具,我这里使用的是 fiddler,目的是可以抓取一些接口地址进行测试,以及方便改包重放。
我们顺着提示,先初始化 git 账号,设置用户名时随便输入了 test,提示用户名已存在,这里一定是调用了接口查询后端数据库或缓存,返回 fiddler 看到如下请求

2判断用户名接口包数据.png

此时我们可以做一个基本的 sql 注入测试,此处属于字符型,一般我会直接在后面加单引号,因为在数据库查询中,如果引号带入的话会触发语法错误而造成页面的异常响应,我们通过页面响应是否异常即可初步判断是否存在 sql 注入,结果如下

2判断用户名接口sql注入测试结果.png

通过文案提示可发现后端对用户名格式做了判断,这里的返回结果,除了sql 注入外,xss 需要的引号,尖括号也无法带入,因此用户名的 xss 测试也省了,不过这也是符合预期的,如果这样就挖到漏洞,我估计一定是他们自身的扫描器挂了。后面对于大多数的接口测试思路基本如此,不做赘述。
来到"项目"功能,先创建项目,做如下填写

新建项目测试.png

这里简单说明下,前面的 aaaaa、bbbbb 主要是方便对返回结果搜索来定位过滤情况,不同的功能用不同字母主要是为区分不同功能点的过滤情况,">用来判断目标系统对敏感字符的过滤情况,标签作为大部分白名单标签可观察目标系统是否支持白名单标签
提交后出现如下提示

项目路径内容检测未通过.png

这里一般分为前端判断与后端判断两种情况
1. 前端判断的话我们可以通过改包重放来绕过限制
2. 后端判断可以忽略对相关功能点测试

我这里看到了对应的请求包,所以可判断本处为后端判断,所以只进行描述字段的相关测试,提交请求后返回结果如下

2项目描述发现img标签可用.png

这里我发现一个比较可喜的现象,那就是虽然过滤了尖括号,但是 img 标签被正常解析,说明此处支持白名单,在接下来我又分别做了一些测试,结果如下
|测试payload|返回结果|说明情况|
|-|-|-|
|<img src=1 onerror1=alert(1)>|<img src="HRay2/aaaa/1">|对onerror属性过滤|
|<img src=1 aaa=1>|<img src="HRay2/aaaa/1">|对属性的过滤非黑名单而是白名单|
|<img/src=1/onerror=alert(1)>|<img/src=1/onerror=alert(1)>|以 / 分隔属性会直接转义尖括号|
|<bbbbbb>|空|非白名单标签过滤为空|
|<bb<bbb>bbbb>|<bbbbbb>|执行对非白名单标签过滤后会转义尖括号|
|<img src=javascript:xxxxx>|<img>|白名单属性内依然有过滤|
|<img src=javas<aaaa>cript:xxxxx>|<img src=javascript:xxxxx>|执行对非白名单标签过滤后转义尖括号动作无视黑白标签|
|<img src=jAvascript:xxxxx>|<img>|过滤无视大小写|
|<img src=aaaa:xxxxx>|<img>|非基于黑名单的过滤|
这里的输出点我们需要依赖尖括号,且目前看来只能使用白名单标签 + 白名单属性,暂时无法利用,所以我们继续看其他功能点。
经过一些类似测试后,我们来到了项目组功能,在项目组的描述文件功能处又遇到了与刚才相同的过滤,不过这个时候我比刚才多做了一个尝试

输入处测试白名单属性内测试情况.png

目的是想深入看一下白名单属性内的过滤情况,结果如下

发现白名单属性内无过滤.png

我们输入的内容被完整的输入,说明白名单属性内,对尖括号是没有做过滤的。
在 html中 ,有些标签是可以优先闭合的,比如下面这段代码
<html>
<title>
<a href="1</title><script>alert(1)</script>"></a>
</html>

这段代码在实际解析中会把<a href="1作为<title>标签中的部分,从而完成无双引号的闭合。
本处无法在上面插入有效的title标签,理论上不可利用,但是当我直接测试如下 payload 时

title成功闭合.png

奇迹出现了

成功逃逸.png

经过后端的逻辑处理后插入的 script 标签竟然直接跳出了 a 标签,到了这里大家可能以为把 script 标签内容改为 alert(1) 就解除了,实时并非如此,我发现 script 标签内的符号都会被 url 编码处理,比如

url编码1.png

我们通过插入
aaaaaa<a href="1<title><script>aa`[email protected]#$%^&*()-+=_[]{}| /?</script>"> 来测试符号的 url 编码情况,结果如下

符号url编码测试结果.png

开始想通过<script src=xxx.js>的方法实现,且该站点本身就提供写文件的功能,可以天然绕过同源限制,不过被浏览器拦截

2浏览器拦截.png

查了一下,大概是因为这里写入的 js 以 raw 格式查看返回的是 text 格式,与 script 标签内要求的 javascript 类型不符导致,查找无 url 编码符号的 payload
最后找到这么一个
aaaaaa<a href="1<title><iframe/src=data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=>">
成功完成弹窗

2成功弹窗.png

不过后来这个被评为低危,因为 poc 是在 data:text 下执行的,无法获取用户信息,后来我又找到这么一段 poc
aaaaaa<a href="1<title><script>throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337]+a[13]</script>">

2script弹窗.png

说明:后面读了测试规范,发现官网其实是严禁弹窗测试的,希望大家后面注意,尽量使用 console.log 来做测试

不过这样停止总觉得有点勉强,那就继续再挖一下看看吧。
因为 xss 的价值比较低,所以后面的测试着重去找一些偏逻辑、水平权限或者敏感接口类的问题,以下思路为测试后没成功,但是我觉得对 web 安全测试来说还是需要关注的点。

  1. 我们随便打开一个页面的时候,查看网页源代码,会发现有这么一段内容

猜测存在user_id参数.png

这里面包含一个 id,并且通过这段内容以及观察其他一些参数的格式,估计可能会存在一个参数名为 user_id 的隐藏参数,之前发现过这么一个例子,就是站点本身的一系列操作都是解析 session 内容来获取用户对应身份进行操作,但是当你主动去传递一个类似 user_id 这么一个参数时,程序会去执行传递的 user_id 对应用户的操作,这就导致了水平权限的问题,这种问题的成因有可能是早期程序逻辑就是根据传参的 userid 去执行操作,后期改成 session,但只是去掉了默认的参数传递,并没有完全从后端去掉这部分逻辑。

  1. 在 cookie 中存在这么一个字段

2cookie中身份字段.png

熟悉的小伙伴可能一眼就能认出这是一段 base64 的密文
这段密文解密后的内容格式为
Username:毫秒级时间戳:32位md5
其中 md5 没有解密成功,不多做猜测,前面讲到程序一般从 session 获取用户身份信息执行对应操作,当然也可能是从 cookie 中某个字段去取值,所以可尝试将 username 部分替换为其他用户信息(这里替换为自己小号用户名),替换后使用 base64 加密并替换对应字段内容,同时也可以尝试将用户名后面加单引号,用来测试一些隐藏的 sql 注入

  1. 测试过程中抓到这么一个接口
    https://git.xxx.com/search/autocomplete/users/1xxxx.json

    2获取用户基本信息接口.png

看起来可以获取一些基本信息,中间的 users 这里,有可能会存在一些类似的隐藏接口可以获取一些敏感信息,比如把 users 换成 tokens 等

经过一系列失败的测试后,我看到了一个让我眼前一亮的功能,在我们使用客户端提交 commit 的时候,可以选择调用一个 bash 脚本来检查 commit 描述是否符合特定规范,比如必须要使用 --bug=xxx 类似的格式(由于很多图都是提交报告后补截的,这个功能在我报告后很快就下掉了,所以此处只能靠文字描述)。开始想着此处可能要出 rce ,不过这个 bash 脚本是官方写死的,无法更改。最后在查看 fiddler 时被我抓到了一个读脚本内容的接口

2读文件接口.png

本能的尝试读取 /etc/passwd

2读取passwd文件.png

哈哈,运气不错,抓到了一个文件读取,并且是 root 权限,从 root 的 history 文件里读到了 log 文件路径

2读取roothistory.png

到这里足以证明危害,所以马上报告给了官方 src,响应也很快,周末的时候也可以及时完成止损,下掉了对应功能,这个漏洞被官方评定为高危级别,因此本次测试目标达成,至此告一段落。

后记

刚开始工作的时候,有幸跟 0x557 的 la0wang 在一起工作,当时做项目感觉老王总是能用很短的时间挖到可以 getshell 的漏洞,并且很多漏洞并没不复杂,自己也能看懂,就是挖不到,当时感觉是运气不好,随着工作年头的增加逐渐明白那是因为常年的积累,对各种系统、各种程序的逻辑了解的足够深刻,了解哪里容易出现问题才做到的。漏洞本身源于对外部可控因素的过滤或校验不严格,我们需要通过不断积累各种知识来深入理解哪些是我们可控的,可控的因素会带入到哪里,可能经过哪些地方,才能更多的挖掘到别人挖不到的漏洞。人工测试过程中,我们要多去思考程序可能的逻辑是怎样的,而不应该机械化的看到 id=xx 这种就加个单引号,看到输入框就往里加标签,这样人的效率自然拼不过机器。所以本文尽可能比较完整的描述了整个测试的思考流程,希望可以给大家带来参考价值。最后打个小广告,C轮融资的互联网企业,招一枚渗透测试工程师,大家可以把简历发送至[email protected] 感谢大家的阅读。

相关推荐: Spring 自动绑定漏洞

Spring 自动绑定漏洞 0x01:自动绑定 自动绑定功能在很多框架中都有实现,主要功能是允许软件框架自动将HTTP请求中的参数绑定到程序变量或对象中以便于开发者访问。 而自动绑定漏洞的漏洞点在于,攻击者可能将额外的HTTP请求参数绑定到一个对象上,使用这种…