Principle of HTTP Evasions: Block Transmission bypasses the Firewall

Principle of HTTP Evasions: Block Transmission bypasses the Firewall

This is the third article in the HTTP Evasions series. The Transfer-Encoding field is used to block request packets to bypass the firewall. For example, you can bypass malicious software detection by using the following structure of request packets:

 HTTP/1.0 200 ok Transfer-Encoding: chunked content which is not chunked

What is multipart transmission?

In HTTP 0.9, the end of the response packet simply depends on TCP connection disconnection. Some fields are added to the HTTP 1.0 response header. For example, Content-length indicates the size of the response packet, but only when the server knows the length of the HTTP header in advance, to determine the value of Content-length. This means that if dynamic content is sent, data must be cached first. The size of the HTTP header to be sent must be calculated before sending. Otherwise, if the data is still transmitted in the past, the data transmission may have to be interrupted when the TCP connection is disconnected, to solve this problem, you have to keep the TCP connection active.

Therefore, block transmission technology is added to the HTTP1.1 standard. In this data transmission mode, the server first adds the length of each block to the front. In this way, the server can immediately send the first data block as long as it gets the first data block. The length of each data block is expressed in hexadecimal notation. The ending response package is an empty package, and its size is 0. For example, in the following example, You need to divide the string "0123456789ABCDEFGH" into three data blocks and send an ending empty data block:

Data Block:

  HTTP/1.1 200 ok   Transfer-Encoding: chunked    b   0123456789A    3   BCD    4   EFGH    0

Note: In the HTTP header, the line break of each line is \ r \ n, and each data block ends with \ r \ n. The last one is a single row, which consists of the block size (0), some optional white spaces, and \ r \ n.

Each block is displayed, and the browser sees the entire data packet. Therefore, if you modify the block slightly, the content displayed by the firewall and the browser will be significantly different, so that the firewall may be bypassed.

Bypass with Transfer-Encoding and Content-Length

The HTTP 1.1 Standard clearly stipulates that if the Content-Length and Transfer-Encoding multipart modes are provided at the same time, the transmission mode used is multipart transmission, the Content-Length field must be ignored. All browsers follow this principle, but 15% of firewalls are still resolved in the opposite way. Therefore, you can use this simple technique to bypass this type of Firewall:

HTTP/1.1 200 okTransfer-Encoding: chunkedContent-length: 22 3MAL4WARE0

Surprisingly, these affected firewalls ignore one point: These response packets may not be segmented packets and directly pass such packets through the firewall. Some firewalls, such as Sophos UTM, have resolved the block conversion in the HTTP1.0 package. However, at least these firewalls have cleaned up the response packets, in this case, it is difficult to bypass the firewall.

In addition, although some firewalls do not parse Transfer-Encoding in HTTP1.0, they may also be bypassed if they use some specific browsers. Contrary to all browsers, Safari directly parses the header with Transfer-Encoding Based on the multipart transmission technology instead of the HTTP Version Used by the response package, whether or not the response package uses HTTP1.0. Therefore, unless the firewall cleans up the response packet and filters out the broken packet header, users using the Safari browser may be attacked by the following packets:

HTTP/1.0 200 ok Transfer-Encoding: chunked  3 MAL 4 WARE  0

The browser's processing methods are also different. The IE browser will only parse the Transfer-Encoding. Other mainstream browsers only check whether the Transfer-Encoding field exists in the Response Header. If the value of this field is "chunked ", it will be parsed directly.

"Chunked" vs. "xchunked" vs. "x chunked", etc.

A browser like Chrome and IE will strictly control the value of Transfer-Encoding and only allow its value to be the string "chunked ". However, Firefox can accept the combination of "chunked" and other words. For example, "for chunked" or "chunked foo ". Safari is worse. He only checks whether the "chunked" string exists and can accept it as long as it exists, for example, "this-is-not-chunked-and-I-mean-it ".

Of course, there are also several firewalls that do not consider whether the response body is segmented in this case, but still parse the invalid packet header. Of course, this is not limited to some unknown firewalls and Gartner Top NGFW. Therefore, the following HTTP response packages can bypass almost 25% of the test firewalls when using Firebox or Safari:

HTTP/1.1 200 okTransfer-Encoding: x chunked 3MAL4WARE0

There are also several ways to hide Transfer-Encoding to bypass the firewall, such as adding spaces or other characters in some specific places. Browsers often ignore these features and continue to parse the response body.

In addition, 20% of the tested firewalls do not correctly process the extended blocks when parsing them, which can cause bypassing the firewall.