Security Testing with Evasions in BPS: Part 2 - HTTP
Before we start, I hope you have already read the first blog post about Evasions in BPS, a primer to understand what evasions are, the motivation behind them, and how to run tests with them. We recommend you read the first blog before you read the current second blog.
Now that you are aware of what evasions are and how to enable them, let's start.
As the title of this blog suggests, we 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 us 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. Our 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, we want to highlight recent additions to this ever-growing list of evasions and few of what we 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, we see that we 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, we 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, we do not see any HTTP/0.9. For the geek in you who wants to know more about the history of HTTP and the road it leads to, read 'Road To QUIC.’
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 we 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, we can select to forcefully use either 'GET' or 'POST' apart from the default or we 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.
We invite you to explore the vast number of evasions that we have in Breaking Point Systems and to play around with them.
Leverage Subscription Service to Stay Ahead of Attacks
Keysight's Application and Threat Intelligence (ATI) Subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Centre continuously monitors threats as they appear in the wild. Customers of BreakingPoint now have access to attack campaigns for different advanced persistent threats, allowing them to test their currently deployed security controls’ ability to detect or block such attacks.