假设你是一台公网服务器,无数人会给你发来URL,要求你进行内容加载。那么在这海量请求中,会有不怀好意的人发送内网URL,要求你进行加载,这其中的风险难以言喻。
因此,一些聪明的开发人员为了防止这种情况,就发明了各种各样的代码。
以上就是DNS重绑定所要解决的问题!
先让我们逐行分析代码。
以上就是最原始的整体流程。
而在我使用https://lock.cmpxchg8b.com/rebinder.html时,发现它的功能并不能满足我的需求。它只能在2个IP之间随机变化,我往往需要发送多个请求才能得到我想要的结果。为此我特意制造了属于自己的工具。
在某次测试时,我偶然发现了一个服务,可以主动发送JSON请求(可以自定义报头等字段)。
当我将url设置为某些内网ip时(比如127.0.0.1),它就会返回如下结果:The request was blocked。
我试了几个普通绕过方法后,发现并没有效果。于是我便想起我和我的朋友Jan Masarik所参与的一次CTF竞赛中遇到的一道和DNS重绑定有关的题目。详细信息如下:https://ctftime.org/writeup/13005。
这个CTF题是由ELB创作的,我非常感谢他带给我的灵感!
我使用了writeup中的技巧,将谷歌网站的IP解析为127.0.0.1。在利用burp发送了100个请求后,我终于看到了想要的结果!
此时,虽然我成功找到了一个SSRF漏洞,但并不知道接下去该做什么……我以前都只是面对CTF——你拿到flag,一切就结束了。但实际情况并非如此。
在几个小时毫无头绪后,我向Jan Masarik发出了求助。我告诉他,目标貌似和亚马逊服务有关,于是他发送给我一些ip地址——169.254.169.254。他告诉我这是AWS元数据的ip地址,如果我能获取其中的数据,基本上就控制了整个AWS。于是我立刻开始了行动,并很快得到了AWS的key。
不幸的是,那些都是没用的key,我几乎不能用它们做任何事……。
实际上,我只能读写一些存储桶,但这没有任何用处,而那些托管在前端的存储桶都是不可写的。在接下来的几个小时里我试着提升权限以及尝试一些其他操作,但其实能做的并不多。
于是我决定把这个漏洞上报,并持续观察测试,看是否能得到一个RCE。
我没有收到公司的任何回复,也许我应该把这个漏洞说的更严重一点……,不过这样我有了更多的时间进行测试。
当我向127.0.0.1:22发出请求时,服务器返回bad response: SSH-2.0-OpenSSH_someversion :D,我试图通过暴力破解得到ssh的root登录密码,但很可惜失败了。
接下来我开始遍历这台机器上的其他端口。
很快我又发现了一个Monit管理界面,由于它存在一个缓冲区漏洞,所以我可以读取到一些内存信息甚至直接关闭整个实例!
最后我把这个新发现也上报了!
在等待了一个月后,他们终于修好了漏洞,并给了我一笔赏金,生活还在继续。
回顾整个流程,我觉得在利用DNS这方面缺少一个强悍的界面和日志,于是开始使用Flask api,通过SQL和redis连接到特殊配置的DNS服务器。
你可以点击这里查看代码,以及一个现成的可使用的网站——你可以注册,创建新绑定规则,用它来破解某些东西,查看日志等等。是的,这个网站只使用了http协议,我恨自己,我太懒了,不想去安装https。
具体来说,它的作用是:
如果你有一些空闲时间,欢迎看看我的https://github.com/makuga01/dnsFookup。如果有人能添加一些功能或前端,我会很感激的。
若你想和我联系,可以直接在推特上找到我。
本文由白帽汇整理并翻译,不代表白帽汇任何观点和立场
来源:https://nosec.org/home/detail/3185.html
原文:https://geleta.eu/2019/my-first-ssrf-using-dns-rebinfing/
白帽汇从事信息安全,专注于安全大数据、企业威胁情报。
公司产品:FOFA-网络空间安全搜索引擎、FOEYE-网络空间检索系统、NOSEC-安全讯息平台。
为您提供:网络空间测绘、企业资产收集、企业威胁情报、应急响应服务