异常情形的301重定向导致AWS安全凭证泄露

最新推荐文章于 2024-08-13 11:32:42 发布

代码狙击者

最新推荐文章于 2024-08-13 11:32:42 发布

阅读量1.6k

点赞数 1

分类专栏：漏洞挖掘案例文章标签： 301 Redirect SSRF AWS

漏洞挖掘案例专栏收录该内容

5 篇文章 1 订阅

订阅专栏

异常情形的301重定向导致AWS安全凭证泄露

大家好，
本文记录了我最近渗透的一段经历，也是我漏洞奖金之旅中遇到的最奇葩有趣的重定向漏洞了，利用它我可以访问印度顶尖金融公司的AWS EC2凭证信息。接下来介绍我如何从一个不寻常的重定向发现远程文件包含漏洞（RFI），再把它提升为服务端请求伪造漏洞（SSRF）并最终获取AWS EC2的凭证。

最近我一直在研究ASP.NET应用的路由原理——每条URL是如何被路由到正确的应用逻辑或功能中去的。ASP.NET的核心MVC使用路由中间件来匹配传入的URL请求并将它们映射到动作。很多时候由于错误的路由逻辑和不合适的代码框架，配置错误的路由将产生一些非预期的行为。为了更好地理解这一点，可以读下这篇文章。

在这里插入图片描述

在测试全印度最大的金融公司时，我发现应用是ASP.NET写的，并且运行在Windows IIS/10.0之上，可以从响应头中看出——

在这里插入图片描述

为了理解应用的路由规则，我在原始URL（https://redacted.com/）后面添加了些无用数据——https://redacted.com/xyxyz，按理说会返回404 Not Found。但情形有所不同，我又用“我的账户”功能试了试——https://redacted.com/myaccount/xyyyz，同样我得到了一个301重定向并被路由到请求发起的页面，即https://redacted.com/myaccount。现在，我在后面添加任何HTTP协议的URL——https://redacted.com/myaccount/http://evilzone.org，页面内容都变成了重定向后的页面，但URL维持原状（https://redacted.com/myaccount/http://evilzone.org），这表明服务端加载了页面，很可能将请求原样发送给了upstream服务器，背后的代码逻辑大概是这样——

对于像/myaccount这样的URL，应用执行myaccount.MyProfile动作；对于包含http或https协议的URL，比如/myaccount/^(http|https)://(.*)，接受并转发给upstream服务器；如果URL没有匹配以上规则，应用同样执行myaccount.MyProfile动作。

这些代码看上去像是临时环境下的测试代码，本不该出现在生产环境，但可能被开发者不小心遗留了下来，并且错误地配置了upstream代理规则。

现在为了调试和观察HTTP请求，我用了款类似Burp Collaborator的工具Requestbin。然后发送了请求https://redacted.com/myaccount/https://en1sxi232vmus.x.pipedream.net/，并得到了以下响应头——
在这里插入图片描述

如图x-forwarded-for头中有两个IP，这很奇怪，我用whois查了一下，发现第一个IP是我路由器的IP，另一个是redacted.com（也是upstream代理服务器）的IP。现在可以确定我之前发现的重定向是服务端重定向，而非客户端重定向。既然它是服务端重定向，那它很可能构成SSRF（服务端请求伪造）攻击。服务端的upstream代理可能是这样的——

# server context, here the victim.com is the value which is passed #by MVC action.
location /myaccount/* {
    proxy_set_header HOST $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for, $client_ip ;

    proxy_pass http://victim.com/;
}

. . .

我开始测试SSRF并访问本地主机上的不同端口来检测开放端口https://redacted.com/myaccount/http://127.0.0.1:80，返回200状态码时意味着端口开放（很明显有应用在该端口运行）。当我请求别的端口，比如21时https://redacted.com/myaccount/http://127.0.0.1:21，它返回——

在这里插入图片描述

状态码000，不是200说明端口可能已关闭或被防火墙过滤。这其实便是SSRF最简单的一种利用方式——内部服务端口探测。

现在，进一步观察响应头（X-Amz-Cf-Id以及关键字cloudfront）发现应用部署在AWS上——

在这里插入图片描述

所以无需浪费时间，我直接请求API访问AWS实例的元数据（http://169.254.169.254/latest/meta-data），完整的URL是——https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data，得到如下响应——

在这里插入图片描述

更进一步，我调用API来访问ssh公钥https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key并成功得到了它——

在这里插入图片描述

这样，我便有了个SSRF漏洞，可以用它扫描内网端口、访问EC2元数据，现在用它读取AWS安全凭证——

该凭证用来向亚马逊EC2架构的其余组件标识某一实例，我必须向AWS实例元数据的安全凭证API发起请求，最终的URL是（https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance），如我所料，终于可以控制它了——

在这里插入图片描述

但是EC2实例绑定的IAM角色似乎权限有限，因此该漏洞被认定为低危。以上便是这起由异常的重定向漏洞导致AWS账户凭证泄露的全部内容。这个例子很好地说明了一段未被审查的脆弱代码和一些误配置规则造成的致命漏洞。值得开发者、厂商吸取的教训是——不要在没有同事审查代码的情况下提交代码到生产环境，很可能会不小心把测试代码push到生产环境，要记得检查手动编写的代理/路由规则。

感谢阅读！

原文链接：https://medium.com/@logicbomb_1/the-unusual-case-of-open-redirection-to-aws-security-credentials-compromise-59acc312f02b