Next-Gen Firewall Evasion: Five Defensive Techniques

Introduction

So you have this highly sophisticated and powerful firewall on your network with all the bells and whistles turned on. And considering how much it costs, you have a reasonable amount of confidence that it does what it says it does. As we shop around for firewalls and security devices, we often overlook the most straightforward question – can it be bypassed? The answer might surprise you.

In today’s article, we’re going to look at a popular opensource tool called HTTP evader to see just how easy it is can be to evade a NextGen Firewall – but most importantly: we’re going to look at five ways to defend against them.

HTTP Evader

HTTP Evader is a fantastic open-source tool for testing your firewall or UTM against some of the most effective evasion techniques in the world. Used by some top vendors and testing agencies, Evader attempts to bypass your firewall’s inspection by delivering over 700 different evasion techniques via HTTP or HTTPS. While the specific techniques used by Evader are too many to list, the vast majority can fall into the following categories:

• Protocol misuse
• Compression
• Encoding
• Chunked Transfer
• Tunneling

The methods that these techniques use to bypass security inspection can vary. Some rely on not adhering to RFC guidelines to throw off what the firewall expects to see in a flow. Others try to hide the payload protocol or break it off into several small parts that escape detection.

To illustrate how easy it is to evade malware via HTTP, I’ve run a couple of different tests against HTTP Evader: one with a traditional firewall, a second test using a next-gen firewall using default values. The next-gen firewall is enabled as Layer 7 Application Firewall with IPS and AV enabled.

Our first test using a regular firewall went about as bad as you’d expected it. Almost every single evasion technique was successful, and the test stopped after about 100 successful evasions because there is very little in the way of checking beyond Layer 4.

Our second test with a Next-Gen firewall performed much better even while using default values. However, 37 evasion techniques were ultimately successful and snuck past to deliver the malware. Our goal is to get that number down to 0 – or as low as possible using tools available on any modern Next-Gen Firewall.

Number 1 – Protocol Enforcement

The first item on our list is to ensure you have the Protocol Analyzer feature enabled on your firewall. This is usually a component of most Layer 7 firewalls, but it’s not always enabled or used correctly in your policies. Protocol Analyzer could be called different things depending on the vendors. Still, it should always be about two major things: analyzing protocols for RFC compliance and ensuring they are running on ports you expect them to run on. A straightforward evasion technique that works surprisingly well on most modern Next-Gen FW’s is to move malicious payload into different header sections or footer sections. With portions of the malware in the header, the rest of the body looks clean, circumventing inspection. Protocol enforcement should catch non-RFC compliant protocol use and block them.

While we’re on the topic of protocols, if you do not need QUIC or older HTTP versions, disable them altogether. QUIC is an experimental protocol by Google that is typically not scanned by modern security devices and, therefore, a viable mechanism for attackers to evade detection.

Number 2 – Protocol Enforcement

Like a protocol analyzer, protocol enforcement is usually a component of a layer seven firewall, and it’s intended to make sure that common protocols are running over their standard ports. On most vendors, this option comes disabled by default – so as not to cause problems in networks where applications may be running over non-standard. However, this is another common avenue for malware to operate.

For example, when a host is infected with malware and needs to reach back to its control server – it typically needs to resolve the IP address using DNS. But going over port 53 is an obvious red flag and may not resolve if the network has DNS filtering. However, querying a DNS resolver over a standard port like port 80 – has a higher success rate. That’s why locking down applications to standard ports can deter this type of evasion by keeping applications where you expect them to be.

Next time an infected host tries to reach out via a non-standard port, the blocked request should redirect the malware into its standard port, where you can detect the communication via normal inspection methods.

Number 3 – IPS Signatures

The first two items on our list aim to ensure protocols are compliant with RFC standards. But we’re going to need an additional layer of defense against more sophisticated evasion techniques.

This is where our IPS engine will assist by looking beyond the protocol and into the payload and methods where data is hidden. I’m a firm believer that any signature-based system should be a last line of defense. Still, given that we’re talking about a limited number of evasions instead of vulnerabilities, they work well for this case. The specific signature names will vary from vendor to vendor, but the attacks your signatures should be protecting against should include the following:

• Malformed HTTP Request
• HTTP Charset Encoding
• HTTP Request Evasion
• HTTP Content-Encoding Deflate Spoofing
• HTTP Headers End With
• HTTP Unknown Tunneling
• TCP Inconsistent Retransmission.
• TCL TTL Evasion

I wouldn’t worry too much about the name or the quantity, as one generic signature could encompass many evasion techniques. As long as you have your vendor’s version of these signatures, it would help if you had a good level of protection. If you’re using a FortiGate Netx-Gen Firewall, these signatures protect against HTTP evasion:

Notice how the default values for some of the signatures get set to pass by default. The tradeoff in changing these to block can be more false-positive alerts. My recommendation would be to keep set these to monitor only in your network for a few days while you get a sense of legitimate traffic.

Now, I re-ran the HTTP Evader test to get zero evasions with all three of these safeguards in place. The only two alerts were around invalid responses to the malware test file, which is fine if the malware is blocked. Over 700 of the most used evasion techniques were blocked via HTTP just using these three simple techniques found on most NextGen Firewall.

4. SSL Inspection via MITM

Now, that all is good and well, but there’s a huge blind spot you may be ignoring by only inspecting traffic in the cleartext. According to Google’s Transparency Report, as much as 96% of web traffic delivered over Chrome was using HTTPS.

And the same holds true for malware attempting to reach out from inside your network. Sophos recently published a report that stated 23% of all malware that attempted to make a network connection was using HTTPS. This is a growing trend that will continue because it’s effective in evading communication to a C&C server.

Ultimately, no matter how good a security device you have, evading it can be as simple as tunneling traffic out via an SSL connection. That’s why the fourth item on our list is to use SSL Deep Packet Inspection to view the contents inside an SSL or TLS connection.

In order to successfully block SSL evasion, we need to consider two scenarios: malware getting into your network and malware communicating out from your network. Both of these require us to enable SSL Deep Packet Inspection to the appropriate firewall rules. However, deploying SSL DPI can be complex.

For starters, the security device (in this case, our Next-Gen firewall) has to essentially man-in-the-middle every SSL connection it sees. This works by presenting the user who originally requests an HTTPS site with a certificate signed by the security device. It then creates a separate SSL connection to the destination web server. Therefore, having two separate connections between the client and the server – reading and inspecting traffic without either one knowing.

Our firewall acts as an intermediary CA that signs every certificate presented back to the user. And if you know anything about PKI, this means the user has to have that intermediary CA as Trusted. While we won’t get into the specifics of setting up that trust, for our purposes, let’s assume that intermediary CA is already in the user’s trusted CA store.

Now, every time an SSL/TLS connection is requested, the firewall intercepts, establishes its SSL/TLS connection to the server, and now inspects all packets that go through that tunnel. When the destination server presents malware or file-less attacks, the firewall is actually on the receiving end – acting as a proxy – which could block the request before it goes to the user.

The same idea applies to malware that has already made its way inside your network. Then it attempts to communicate out. With SSL DPI, the firewall can intercept that connection to see and block suspicious callbacks to a C&C server. A popular technique to prevent DPI from intercepting an SSL connection is to use certificate pinning. This essentially stores the certificate it has on the application to compare against the certificate that gets presented. If they don’t match, the connection won’t establish. Malware that uses certificate pinning has two options: drop the connection attempt or tunnel out using another mechanism.

5. Multi-Layered Approach

This brings us to the fifth and final point on preventing firewall evasions and setting up a multi-layered approach in blocking proxies.

1. The first measure is to block known C&C servers at the layer 3 level. You need to import and make into an ACL or by using a Botnet package on your Next-Gen firewall.

• Next, we will use our Application Identification feature to block the Proxy Avoidance category and Tor application from our outbound connections. If users have a specific need for these applications, you can always right an exempt rule specific to those users.

• Our 3rd layer is going to be leveraging our IPS to block tunnel data traffic inside other protocols. The idea here is to use a standard protocol like HTTP, DNS, or PING to send or receive data. When the IPS sees unknown data in parts of the protocol that it does not belong to, it’ll alert or block those attempts to communicate out.

It’s also worth mentioning that a sophisticated attacker with a bit of research in your environment can use the cache bypass method to trick your NextGen Firewall into believing it’s an alternative application. The attacker would have to know the vendor used, research the application that it uses as a decoy – and craft its malware so that it tricks the firewall into thinking it’s that application. The header and parts of the payload are written with just enough code to look like the legitimate app

Before we wrap up this article, there’s bonus content that I wanted to mention, and that’s polymorphic malware and fragmented packet evasion. Both of these evasion techniques take advantage of packet-by-packet inspection, typically called ‘flow mode’ on next-gen firewalls. Flow mode has become a popular inspection choice for modern Next-Gen firewalls to lower latency and increase performance. By inspecting each packet as it arrives at the firewall, it has a high detection rate under normal situations.

But you also run the risk of an attacker chunking or fragmenting parts of the packet in such a way that makes the individual packets benign. It’s when they’re defragmented, or put back together, that you see the full picture. This is where proxying the entire file has a major advantage. The Next-Gen firewall grabs and reconstructs all packets for inspection in proxy mode before sending them back to the client. This type of inspection is much more accurate but also more resource intense.

I hope you enjoyed this informative article.