SSRF攻击文档翻译

Part1 基础知识

Hello world!
我将在本文向您介绍服务器端请求伪造(SSRF)的概念,它是客户端请求伪造(CSRF)的表兄弟,QWQ,在开始之前,我只是简单的介绍一下这个概念的基础知识,以便于下一篇中引入更多高级的技术。我还必须赞扬NicolasGrégoire(Hack in ParisHackfest)和Orange Tsai(DEFCON),他们在很大程度上激发了本系列的内容,并以某种方式激发了我对这种技术的兴趣。我已经提供了一个SSRF模拟环境供您自己测试。文中所有的例子也是用这个环境来模拟。
那么服务器端请求伪造到底是什么?就是让服务器去请求你通常请求不到的东西,比如内网资产。这不是不可能,因为Web服务器通常可以访问比外部代理更多的资源,因为本地网络周边的信任级别很可能高于直接来自Internet的信任级别,证明了defense in-depth方法的局限性。
深度防御是一种信息保障(IA)概念,其中在整个信息技术(IT)系统中放置多层安全控制。 其目的是在安全控制失败或利用漏洞的情况下提供多余的保障,该漏洞可以涵盖系统生命周期期间的人员,程序,技术和物理安全方面。

SSRF攻击并不是一个新鲜的事物,但趋势正在增多并暴露原始攻击面。从现在来说,我们
将假设有一个全新的Web应用程序,它已经变得非常流行,现在已经开始实现诸如REST API和定制WebHooks等整洁的功能。

当然,你希望你的用户能够在发布之前测试他们的WebHook处理程序。在这种情况下,你需要给他们一个很好的调试接口:

因此,如果您的用户在https://yourhandler.io/events上监听REST API ,客户将收到测试事件并收到一些调试信息,例如来自其服务器的响应内容和状态代码。

如果我们处于攻击者的位置,我们现在有一台服务器愿意以我们的名义向任意位置发送HTTP请求,并向我们提供它得到的响应!问题是,它不能确保我们输入的URL实际上是外部 Internet地址。如果不是事件处理程序,我们输入类似http://127.0.0.1:8080的内容怎么办?那么,我们现在在主机上有一个端口扫描器,超出了防火墙或安全组,并且即使这些服务只在本地主机上侦听!当然,我们也可以尝试扫描流行的10.0.0.0/8子网中的本地地址。但是,我们怎么才能知道易受攻击主机的实际子网?

那么,让我说一下WHOIS的一个请求,告诉您易受攻击的Web应用程序的公有IP地址是AWS基础架构的一部分,为什么不尝试去询问AWS元数据服务

我们现在知道我们Web应用程序的VPC地址空间。元数据服务可以提供非常有用的信息,但是如果我们不限制在Web上呢?让我们记住一个URL的结构:

scheme://user:pass@host:port/path?query=value#fragment

可以尝试访问主机的文件系统。

下面是我本机用作者提供的环境测试的:

YEAH!作为示例,我们现在能够挖掘配置文件和源代码文件,查找数据库凭据。

结论
如果您的应用程序向外部资源发出请求,请确保它们在所有情况下都是外部模式。我隐约听到你想说在这个例子的情况下,对用户输入进行简单的正则表达式过滤就可以实现防御。骚年,我的下一篇文章应该让你相信事情并不那么简单,并且URL验证比人们想象的更难。网络级别的出口过滤可能是保护您的应用程序的唯一方法之一,加上严格的方案:scheme:// white-listing

Part2 Fun with IPv4 addresses


这是我的文章关于服务器端请求伪造攻击(SSRF)的第二部分,我必须赞扬NicolasGrégoire(Hack in Paris,Hackfest)和Orange Tsai(DEFCON),他们都强烈启发了这篇文章(第2部分特别广泛地使用了Nicolas的技术,我希望他把它作为贡品而不是抄袭,如果他看到这个)。

假设您已经意识到在新的WebHook功能中存在SSRF攻击的可能性,并决定以限制请求http://和禁止请求的方式保护10.0.0.3,让外部不应该看到内部的一些私有服务。您决定使用两个正则表达式执行此操作,一个确保URL以URL开头,http[s]://,另一个限制我们的私密服务器的特定IP。

if (preg_match('#^https?://#i', $handler) !== 1) {
  echo "Wrong scheme! You can only use http or https!";
  die();
} else if(preg_match('#^https?://10.0.0.3#i', $handler) === 1) {
  echo "Restricted area!";
  die();
}

免责声明:这不是保护您的服务器的好方法,请不要这样做。还要注意WebHook只是使用一个简单的PHP curl函数,没有什么特别的。
scheme://留在第三部分讲,那怎么请求10.0.0.3?

该死的,怎么可能 - 我们在没有DNS的情况下以某种方式解决这个问题?让我们尝试一些不一样的,我会稍后解释; 让我们尝试一个请求:http://167722163

等等,那里发生了什么?请记住,IPv4地址只是网络流中相对于OSI第3层(IP)的四个字节。为方便起见,我们通常将其表示为四个数字,但此值的整数也完全有效。让我们更详细地检查地址:

字符串值: 10.0.0.3 
二进制:        00001010。00000000 00000000 00000011 
十六进制:   0A.00.00.03 
整数:       167772163

tips:php中有ip2long函数
http://aokunsang.iteye.com/blog/622498
现在,还有什么可以是我们能尝试的?肯定有很多方法可以表示32位; 其中最明显的是十六进制:http://0x0A000003。你猜怎么着?它工作了,它绕过了正则表达式过滤器,并且php-curl给力的解释为IPv4地址!
计算机世界中另一个鲜为人知的数字文字变体是八进制表示:在许多语言中,如果数字中最不重要的位置为零,则将其解释为base-8而不是我们人类友好的base-10小数点。因此,如果您编写020而不是20,您的计算机很可能会认为您在我们的十进制系统中意味着16。我们也可以使用它来欺骗正则表达式过滤器:http://01200000003是我们的10.0.0.3IP地址的八进制表示,是的,它可以在php-curl中使用。

结论

从上文,我们可以尝试各种不同的方法; 我不知道如何在IP解析器中处理怎么处理的,但将十六进制中的.部分分开也是有效的:http://0x0A.0x00.0x00.0x03确实也是一个有效的请求http://012.00.00.03。NicolasGrégoire也指出,某些NodeJS应用程序服务器也可能会溢出字节,这样也http://265.0.0.3可能对我们的http://10.0.0.3目标起作用(因为265对于8位来说太大了,它在255处“重置”并且成为10); 我无法在我的设置中重现此内容,但如果您有任何想法,请发表评论。

最后,我只想指出,在保护内部服务器时,正则表达式网络过滤并不是一种可行的方法。最好的方法是使用实​​际了解TCP / IP逻辑的网络实用程序,以及网络协议创建者在实施这些标准时所考虑的所有细节。

Part3 其他高级技术

这次我们的WebHook代码是用Python Flask编写的。我们还有其他secret.corp内部服务器位于10.0.0.3。请记住我对第2部分的结论,可以将其改写为:
不要试图自己解析网址; 而是使用制作的库
所以你完全可以做到这一点,并使用Python 2.7的hostname库,在提交的url部分实现了一个过滤器:

url = request.form ['handler'] 
host = urlparse.urlparse(url).hostname 
if host =='secret.corp':return'Restricted 
    Area!' 
else:
    return urllib.urlopen(url).read()

让我们尝试通过尝试访问这个服务器http://secret.corp

似乎被过滤了,现在,为了科学,我们来尝试一下http://google.com# @secret.corp(注意URL中间的空格字符):

等等,又发生了什么事?我们使用标准解析库的过滤器被绕过并授权它,达到访问不应该被请求的资源?嗯,是的,不是; 这里的问题是,我们使用一个库来过滤hostname另一个库来执行实际的请求,而且它们不会以相同的方式在URL中间插空格!该urlparse库解析网址为google.com。而urllib认为这是secret.corp和危险的请求。所以这里就是导致这个SSRF漏洞的两个库之间的不同解析。
但情况变得更糟......这是Orange Tsai演讲的一部分幻灯片:

正如你所看到的,Python库都有自己的方式来处理URL中的空格,如果你不在整个应用程序中坚持一种方式,那么在处理这些时可能会出现意想不到的结果。以下是官方RFC3968的内容:

The authority component is preceded by a double slash (“//”) and is terminated by the next slash (“/”), question mark (“?”), or number sign (“#”) character, or by the end of the URI

权限组件前面加双斜杠,并以/,?,#结束,或者结束的URI。
从这个定义来看,库表现得恰到好处是模棱两可的; 我个人认为没有任何事情完全符合这种行为。

未来的工作:协议注入

作为结论,我想介绍协议注入的概念:请记住第1部分中的URL结构:

scheme://user:pass@host:port/path?query=value#fragment

怎么可能绕过一个scheme://只能访问HTTP(S)协议的固定版本?符合换行注入技术。现在,在写这篇文章的时候,我还没有在我的SSRF实验中将它作为一个Web服务器漏洞利用来实现,但它可以在很短的时间内在这个GitHub存储库文件夹中使用。同时,让我们考虑一下WebHook测试服务器上的用户。邮件服务器位于mail.corp,使用默认的Ubuntu Postfix安装。我们的WebHook服务器只能发出HTTP请求。但是,如果我们能够\r\n像在主机名中一样注入换行符(),并且库接受它,则可以在SSL握手期间将有效的命令发送到SMTP服务器。这就是邮件服务器的TCP响应:

Request:
url = https://mail.corp\r\nHELO web.corp\r\nMAIL FROM...:25/
Response:
SMTP: 502 5.5.2 Error: command not recognized <SSL Gibberish>
SMTP: 250 web.corp
SMTP: 250 2.1.0 Ok
...
SMTP: 502 5.5.2 Error: command not recognized <SSL Gibberish>

这里的技巧是,在SSL握手期间,主机名被完全使用,如果它们被请求的库接受,则包括它的换行符。问题是,SMTP将换行符解释为“命令结束”信号,因此我们可以在SSL握手流量之间插入有效命令。我还有一些测试要做,以便在我的实验室中获得有效的POC ,但我的第一个Wireshark捕获的包是有用的。请注意,同样的技巧应该适用于任何基于文本的协议:例如,我可以使用它来注册到内部SIP服务器。如果您对我有实施建议,请发表评论,最后感谢Orange Tsai和NicolasGrégoire的工作!

https://github.com/m6a-UdS/ssrf-lab

点击收藏 | 1 关注 | 2
  • 动动手指,沙发就是你的了!
登录 后跟帖