Dropbox HelloSign应用中SSRF漏洞导致的AWS私钥泄露

探星者

已于 2022-06-17 08:37:03 修改

阅读量385

点赞数

分类专栏： Hackerone漏洞启示录文章标签： web安全安全

于 2022-06-16 22:13:03 首次发布

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg2OTY2NjMwMw==&mid=2247483686&idx=1&sn=ae69dc311134f1266b9166a374805568&chksm=ce98ddb6f9ef54a01e51a1d43e837db578efaa3dde80dca0e4f923bb801b07185f945f0b346b&token=1250468541&lang=zh_CN#rd

版权

Hackerone漏洞启示录专栏收录该内容

3 篇文章 0 订阅

订阅专栏

赏金$4913的HelloSign SSRF漏洞

报告原始地址：Server Side Request Forgery (SSRF) at app.hellosign.com leads to AWS private keys disclosure

漏洞报告时间为2020年7月14日由sayaanalam提交针对Dropbox的漏洞赏金为$4913

漏洞利用链

以下为安全研究员漏洞挖掘过程的经历分享：

由于Dropbox有较高的赏金和较短的响应时间，因此我选择了它作为漏洞挖掘目标，并尝试针对HelloSign进行我的赏金狩猎。我发现它有这样一个功能，可以从Dropbox、GDrive、BOX、OneDrive和EverNote中导入文档。此时，SSRF已经浮现在我的脑海中，于是我开始测试Dropbox的导入功能，并观察到了如下请求

我尝试改变file_reference参数值为burp collaborator的URL（相当于回显服务器地址，Burp自带的一个功能模块），但是返回了404错误，我觉得这应该已经存在SSRF保护，于是我把我的电脑关了😫

但是第二天，我又改变了我的想法，我再次尝试深入挖掘并测试了OneDrive的导入功能，并看到了这样一个请求:-

GET /attachment/externalFile?service_type=O&file_reference=MYONEDRIVEFILELINKHERE&file_name=FILENAME.ANYTHING&c=0.8261955039214062 HTTP/1.1
Host: app.hellosign.com
Connection: close
Accept: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
X-CSRF-Token: 
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: REDACTED
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,hi;q=0.7
Cookie:REDACTED

你可以看到在上面这一请求当中有一个请求参数service_type，其值为O代表OneDrive，与之前那个请求中的D参数值不同，我重新将file_reference参数值更改为我的burp collaborator的URL，这次非常幸运成功收到了ping回显

之后HelloSign生成了一个PDF包含了collaborator的页面内容，这可太令我开心了😍

接下来我开始尝试获取设备的本地信息，首先我通过whatismyipaddress查询他们所使用的云服务信息，发现他们所使用的是AWS/EC2。于是我尝试利用http://169.254.169.254/latest/来获取信息，但却返回了404 Not Found响应

显然请求没有通过，我又试了下http://127.0.0.1，还是返回一样的内容

再次emo😫，不过我试图通过Hackerone上的Hacktivity来寻找方法并找到了这份珍贵的报告HackerOne，它使用了303重定向来绕过SSRF保护

我立刻在我的服务器上部署了这一段代码

<?php header('Location: http://169.254.169.254/latest/meta-data/', TRUE, 303); ?>

再次使用这一服务器重定向链接进行尝试，并最终获得了了AWS实例（的元数据）内容 😍😍😍

现在的我可太兴奋了，因为在世界上最棒的漏洞赏金程序之一上发现了完整的SSRF read漏洞，使得我能够从AWS元数据中检索一切，如access_keys，token等。

我立刻提交了漏洞报告并在三小时后收到了回复，安全团队让我检查下是否存在RCE漏洞。我利用access key和token尝试执行实例重启指令，但是失败了并提示该角色没有足够的权限来执行命令（看来暂时没有发现有效的RCE漏洞）

但我还是非常高兴，因为发现了这一漏洞并最终获得$4913赏金😙

漏洞报告解读

SSRF（Server-Side Request Forgery，服务器端请求伪造）具体是什么意思，简单地说就是伪造以服务器的身份来发送一个请求。平常我们通过浏览器上网时，通常是浏览器发出HTTP请求，然后服务器返回数据，在这种情况下所返回的数据往往是受到后台代码限制的。SSRF漏洞就是利用可控参数，更改请求者为服务器本身从而达到窃取数据的目的。结合这一案例具体点说，就是原先file_reference参数的值应该为某一需要导入文件的具体地址，但是攻击者将其更改为服务器本身的URL链接，以此成功返回了其内部数据（这就导致了SSRF漏洞的存在，后台代码应该对这一参数值进行验证并作出限制）。而获取的这些数据中所包含的access_keys，token等内容，就相当于我们登录账户时的用户口令，虽然这一服务器存在比较好的权限分离机制使得RCE（Remote code execution，远程代码执行）攻击失效，但利用这些认证凭据仍然可以完成一些权限范围内的敏感操作。