Home » Security Bloggers Network » Firewall Evasion Techniques and Countermeasures

Firewall Evasion Techniques and Countermeasures

by asdfasdfasdfasdf on February 3, 2015

Life finds a way. This is one of my favorite quotes from one of my favorite movies and books, Jurassic Park. Internet traffic, like life, will break free and expand to new territories. There is a vast amount of examples of people changing their behaviour to get what they want when you attempt to deny them access to whatever that is.

When it comes to security the line between good and bad is often hard to see. Certainly malicious actors work to bypass security controls to get footholds and steal confidential information. Other times they are working to bypass controls to just to avoid control and/or oppression.

There are several groupings of tactics to bypass network security appliances. The challenge of evasion is that there are many groupings and many tactics. Tactics in different groupings can be leveraged at the same time dramatically compounding the issue. The purpose of this post is to describe the tactics employed to evade network security systems, identify what is required from a network security system to prevent bypassing, and generally where to find it.

For some examples of using these evasion techniques please search the rest of the blog for evasion.

Network & Transport Layers

Many of the evasion techniques that exploit lower level protocols are handled by the underlying OS of network security appliances. Often the IP stacks are configured to be prevent many of the tactics by default. The challenge is that many of the tactics at the network and transport layers are natural functions of the protocols that are being used in a malicious way. This most often results in the most elegant of attacks. Blocking them outright could lead to a high probability of blocking benign traffic, which results in user experience issues, which results in complaints, which results in disabling the features.

One of the most common network and transport layer based evasion is fragmentation. There are several ways to exploit IP fragmentation. As an example in a small packets segmentation attack the attacker will fragment all of the packets to be very small. The idea is that network solutions have a a limited amount of memory to manage each session. If there are lots of small packets the attack payload will be broken up into small enough pieces that each individual packet looks benign. Where things start to fail is when the memory buffer fills up and the devices starts to allow packets through to the target host that don’t look bad. Once the target host reassembles them the attack will likely be actualized.

Another example is to abuse the session by chaff. An attacker can send multiple fragmented packets with the same sequence number but different payloads. On top of that you can manipulate various other parts of the packets. One example is to leverage PAWS (Protection Against Wrapped Sequence). PAWS is designed to improve TCP performance in high speed networks. Servers have a theoretical limit of 2³² sequence numbers per session, so starting at 0 and going to 2³². So when a session hits that finite number the sequence number starts back at 0. This can be abused by sending multiple packets with the same sequence number and different timestamps so that the old one may be discarded and the new one slips through. Sending the malicious payload second may overwrite the first and be bypassed. Operating Systems will handle these differently and confusion is the name of the game.

This type of packet mangling is most often be handled by the network processing engine of security appliance. Most systems will have protection settings either in the device settings, in an interface protection profile, or like the illustration below in a zone protection profile.

figure 1: zone protection

It is important to note that these are functions of the protocol that may be used for regular traffic. Most solution vendors will not enable all of them by default to avoid potentially blocking legitimate traffic. It is important to look for them in the operating manual and configurations of the device and ensure you enable the ones that will work in your environment. You may have to take some risk and enable them to find out if they cause problems for regular traffic so it is equally important to find out where they are reported when triggered in case you need to troubleshoot.

Session & Application Layers

Protocols such as NetBIOS (Network Based Input Output System) and RPC (Remote Procedure Calls) are widely used session layer protocols. These protocols are typically interacted with by application directly and users typically do not need interact with them directly. They are commonly used for network based communications of applications that may not have their own network capabilities built in. In this way the applications can be developed in a standard way using one of the session layer protocols and have those protocols handle the communications between nodes. As a result the attacks are similar to that of the transport layer protocols. That being said in most network security appliances these session layer protocols are controlled by protocol decoders and/or rules/policies rather than at the network layer.

There are many ways to evade network security appliances by tunneling one application through another. By encapsulating a denied type of traffic inside a permitted type of traffic the blocked traffic may slip through security policies.

For example a security policy may permit something like ping which relies on ICMP echo requests and echo replies. The same policy may not allow web browsing using HTTP. ICMP could be used to encapsulate the HTTP traffic. If the security appliance isn’t looking at the application ping closely enough it will think there is just ping traffic and permit it. Another example would be wrapping bittorrent traffic with DNS. If bittorrent is not permitted but DNS is the appliance may let this traffic through because it thinks it is just DNS based on some basic characteristics. In the case of unknown malware positive security could potentially prevent it proactively. If the malware is tunneling over DNS but is otherwise unknown, a security appliance that properly identifies the applications will prevent the malicious traffic even though it has not seen it previously. See an example of tunneling through ICMP here and another example of tunneling through UDP here.

Almost any kind of traffic can be tunneled inside another protocol. You can also tunnel whatever you want through other applications like DNS, NTP, HTTP.

figure 2: positive security policy

The solution to evading security appliances at the session and application layer is application identification and a positive security model. Application identification may be a multiple stage process. There may be some pre-prosessing at the protocol layer that will weed out obvious things like violations of the protocol standard. Otherwise there will be some form of decoders and heuristics that will identify what the application is outside of just the standard port and protocol. As depicted in the examples just above you should be able to detect when there is HTTP traffic tunneling through ping because ping isn’t supposed to have HTTP headers inside it.

Positive security means allowing the types of traffic you want and implicitly denying anything else. A positive approach to security can only be implemented when proper application identification is working. When you can trust that allowing DNS will only allow DNS traffic and not tunnel bittorrent or IRC or web traffic to a command and control server, you have positive enforcement.

Encryption

The purpose of encryption is to provide confidentiality and integrity of data. The data in transit in this case is obfuscated so that prying eyes can possibly tell where you are going but not what you are doing there. This means that when network traffic is encrypted many network security appliances will be blind to what is inside. Many popular websites today have defaulted to HTTPS when you visit them (Google, Yahoo!, Facebook, and Twitter), and more are moving to encryption because of recent leaked information about spying. The underlying technology in HTTPS is SSL (Secure Sockets Layer).

A simple example is someone using an HTTPS proxy server outside of the network to get to other websites. The security appliance would see HTTPS which is likely allowed because it’s so pervasive. The proxy server makes it appear the user is browsing a random HTTPS site, but really it is tunneling traffic to another website. So the user makes a connection to the proxy and the proxy makes the connection to the target, likely blocked, website and the entire transaction is encrypted. The security appliance does not have any visibility into what is going on inside the traffic.

You have visibility to be sure that webmail is in fact what they are doing.
You have visibility to determine if there is malware or malicious links inside the encrypted traffic, and
You have visibility to see if sensitive data is leaving the environment.

The solution is to decrypt the SSL traffic. A certificate needs to be installed on each of the client devices. When users make connections to HTTPS sites their traffic is encrypted to the security appliance using your certificate. The security appliance then makes the connection to the destination website using their certificate. This way the security appliance has decrypted traffic on it before passing. When breaking encryption for corporate use the idea is not to read peoples emails and invade their privacy. The goal is so that you can permit something like a personal webmail account and know you are safe because;

It is important to note that SSL (and inherently HTTPS) is a standard protocol and widely deployed in many applications so decryption can be accomplished by any application using this standard protocol. Network security appliances will have troubles with encryption protocols that are proprietary or non-standard.

Conclusion

Managing evasions is challenging. If one (wo)man can make something another can break it. Within each of the sections above there are currently dozens of examples of evasions for each section. Many of these techniques can be used simultaneously to slip through. New evasive techniques are developed regularly. It is important to keep up to date on them and understand how you can prevent them in your environment. As a result the only way to ensure that a network security appliance will prevent every evasion is to pull the plug. Following are some best practices to prevent evasive techniques today.

Look for network security solutions that are stream based. Stream based systems will continuously monitor every packet in the stream. The cost is heavy CPU/memory requirements and the benefit is that it will reassemble all of the packets properly so that it can identify any malicious behaviour. The alternative is a session based system that will typically look at the first packets and if those look ok will trust the rest, which has obvious consequences. While there may be ways to beat a stream based system like working around the stream buffer timers, they are still much more effective than session based and are the best we’ve got right now.
Read the manual. Many of the features to prevent lower level evasions will be documented in the deployment guides. Because these features can sometimes break applications they are not always enabled by default.
Determine if the network security solution is capable of positive security enforcement. You should be able to permit the traffic you want with confidence, and everything else should be dropped by default. This means having the ability to properly decode traffic and identify applications. It also should have a single policy. If you have to permit some traffic and then block parts of that traffic elsewhere the solution will be inefficient and ineffective.
Decrypt the SSL traffic. 30% or more of all network traffic is encrypted. If you can’t see what is in there you are blind to 30% of traffic. This is imperative to prevent malware and data loss.

References:

http://www.monkey.org/~dugsong/fragroute/fragroute.8.txt
http://www.cs.uit.no/~daniels/PingTunnel/
http://www.mcafee.com/us/resources/misc/guides/evader-users-guide.pdf
http://en.wikipedia.org/wiki/Remote_procedure_call

*** This is a Security Bloggers Network syndicated blog from Insecurity authored by asdfasdfasdfasdf. Read the original post at: http://stephenperciballi.blogspot.com/2015/02/firewall-evasion-techniques-and.html