Security Testing with Evasions in BPS: Part 2-HTTP

PublishTime： 2022-04-10 Article Source：Keysight

Keysight will be focusing on HTTP related evasions in this post. HTTP evasions are evasions that affect how the traffic is seen in the wire for HTTP protocols. Think of it like changing all the 'GET' requests to 'POST' requests. These evasions should allow you to better craft the traffic to match what an attacker might be doing to evade security defenses.

Do put on your thinking hats, as this might go deep down the trenches for some of the evasions while being lightweight on the others.Keysight's goal at the end of the day is to make you be aware of the vast world of Evasions in BPS specifically for HTTP and how you can, think like an attacker and try to manipulate the packets so that a better comprehensive testing can be achieved.

Let us start by looking at a screenshot of BPS GUI where HTTP evasions are shown.

As you can see, there are a lot of options for evasion and this screenshot does not even encompass all the HTTP evasions that are possible. So, covering each of them in detail in this blog post will be not possible, however, Keysight want to highlight recent additions to this ever-growing list of evasions and few of what Keysight find interesting, which may help you with better testing.

EVASIONS AFFECTING HTTP VERSIONS

The goal here is to change the version part of the HTTP request.
GET ati-blog-posts HTTP/1.1

So, HTTP/1.1 in the preceding request could be changed in multiple ways.

Going over them quickly, you see that you can try to manipulate the HTTP version in several ways, in ways that the RFC suggests and in ways that invalidates the RFC. suggests and ways that invalidates the RFC.

VersionRandomInvalid

This turns the HTTP/1.1 into some random characters. So, the HTTP/1.1 in the preceding example will now turn into some ASCII gibberish, for example:

VersionRandomDecimal

According to the RFC 2616 , Section 3.1, the HTTP version uses the <major>. <minor> format, where:
HTTP-Version = HTTP/Decimal.Decimal

According to the RFC, any Decimal.Decimal should be a valid version number example 2.13 or even 24.3.So, when using these evasions, you will get random decimals in place of normal HTTP/1.0 or HTTP/1.1.

Note: RFC 7230 updated this to be only having single-digit decimals, so 2.13 would be invalid. However, our implementation tries to be in line with RFC 2616.

VersionUse0_9

This will use the HTTP/0.9 version in the request as shown:

Now, you may be wondering, “Where did the 0.9 go? Did the Wireshark parser not catch it?"

HTTP/0.9 was the first version of HTTP and when it was developed, there was no version number associated. Who thought the Internet would be such a hit? Since this protocol existed, people called this first version as 0.9 to differentiate it from other versions like HTTP/1.0 and 1.1. There was no version number, hence, in the preceding requests, Keysight do not see any HTTP/0.9.

Now, you may be wondering why HTTP 0.9 is using POST in the preceding screenshot? Was not only the GET method supported? Also, what about the headers?

Well, the goal here is not to follow the RFC verbatim, but to show the several ways in which an attacker might be sending malicious traffic that the servers process.

If you open a telnet connection to Google and send without the HTTP version, it sends out a response, as if you meant to ask it to use the HTTP/1.0 version.

So, while some IPS devices might be ignoring the HTTP version altogether in their detection logic, some might be using it part of their ‘regex' to see if HTTP/1.0 is mentioned or not as part of a bigger logic to detect attacks. Since these detection criteria now do not see the version mentioned they might allow the malicious traffic to passthrough and reach the target server. What better way to test this than to use these evasions?

VersionRandomizeCase

It tries to send with the HTTP case randomized, for example, HtTp/1.1. The HTTP in the version should be case sensitive according to RFC 7230, so this is checking if the protections can be evaded while using randomized cases.

EVASIONS AFFECTING HTTP METHODS

The first thing that you see in an HTTP request is the HTTP method 'GET' / 'POST' being the most common. These evasion profiles allow us to manipulate the HTTP method that gets sent as part of the request in several ways.

HTTP Transport methods

Here, you can select to forcefully use either 'GET' or 'POST' apart from the default or you can even choose to use a random selection from the valid methods list of 'GET,' 'POST,’ 'HEAD,’ 'PUT,’ 'DELETE,’ 'CONNECT,’ 'OPTIONS,’ or 'TRACE.’

MethodRandomInvalid

This will change the method to randomly generated text.

MethodRandomizeCase

This will change the case of the HTTP method that is used by the strike randomly.

Now, let us look at some other interesting evasions, which has been added recently.

304 BUT WITH A RESPONSE

According to the RFC 2616 "The 304 responses MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields." However, when applying this evasion, the server will send the 200 Ok response packets with the status code of 304 and include the full response.

You can get this option at the end of the HTTP evasions with ServerRespondWith304.

This could be a handy evasion scenario if a client processes the 304 responses like a 200 ok response, but the security device inspecting the packets after seeing 304 status code might decide to skip further inspection of the packet body to be more efficient while achieving higher throughputs.

EVASIONS APPENDING MISCELLANEOUS CONTENT AT THE END

Scenarios where this evasion can be handy is when appending a bunch of random text would make the HTTP packets' payload large. In this scenario, certain security devices who inspect the HTTP payload might decide to skip because of the large size of the request.

HTTPContentRandomAppend must be enabled, and you can also specify the size in bytes with the HTTPContentRandomAppendSize field as shown:

Another interesting evasion is the PostParameterRandomPrepend, which would prepend some extra parameters to a post request.

Keysight invite you to explore the vast number of evasions that Keysight has in Breaking Point Systems and to play around with them.

+1 Like
Add to Favorites

Recommend

Technical Resources

More>

New Products & Solutions

More>

This document is provided by Sekorm Platform for VIP exclusive service. The copyright is owned by Sekorm. Without authorization, any medias, websites or individual are not allowed to reprint. When authorizing the reprint, the link of www.sekorm.com must be indicated.

Integrated Circuits