Deep Packet Inspection Firewalls, Inlin IDS, and Web Application Firewalls

Due to the increase of attackers targeting web applications and the limitations outlined previously for firewalls and NIDS, the vendor market had to make some changes. Nowhere was this realisation more clear that in the infamous Gartner report of 2003 titled (*giggle uncontrollably)) "Gartner Information Security Hype Cycle Declares Intrusion Detection Systems a Market Failure," or as it's more commonly called, the "IDS is Dead" report (I wonder is IDS got a funeral?). Anyway, on with it... In the report, Gartner writes

"Intrusion detection systems are a market failure, and vendors are now hyping intrusion prevention systems, which have also stalled," said Richard Stiennon, researchvice president for Gartner. "Functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic identifying and blocking, as well as antivirus activities."

Although most people didn't agree with everything said in the report, such as the prognostication that IDS would be out of the market by 2005 (yeah right, and Microsoft is going Open Source...), the majority of security practitioners did concur with the need to implement some form of new approach to preventing these network attacks. Gartner suggested that the capabilities of IDS technology should be implemented into firewall technology. This is exactly what happened, as the firewall vendors were already in the prime network architecture position of having a device that all traffic must pass through. All they needed to do was to implement logic for the firewall to be able to inspect OSI Layer 7 application data. Thus, the deep packet inspection firewall was born.


Deep Packet Inspection Firewall

The basic concept behind deep packet inspection firewalls is that they have access to the data payload of the packets. Having access to this information allows the device to apply certain security checks that were not possible without this data. If we take an updated look at the NIMDA attack request that was logged by a Checkpoint Firewall-1 host, we can see that the firewall is now able to log/trigger on the "resource" data of the web request:

14:55:20deny firewall.foo.com >eth0 product VPN-1 & firewall-1src 24.18.186.245 s_port 4523 dst 69.229.28.252 http proto tcp xlatesrc 192.168.1.101 rule 6
resource=http://hostname.com/scripts/root.exe?/c+dir

With this information, the firewall can now take appropriate action and deny the connection.

Why Intrusion Detection Systems Fail As Well

The second most common misconception is the role that Network Intrusion Detection Systems (NIDS) play in web security scenarios. NIDS are a reactive strategy rather than a protective strategy. This does not mean that they do not serve an important service. They are fairly effective in identifying known web based attacks, but actually acting upon the malicious requests is another matter. This is due in part to their deployment location ont he network.

Most often, NIDS are deployed in a passive, third-party way such that they do not interfere with the network traffic. An example network diagram for a common NIDS deployment is shown below.

They are simply able to view the data by utilizing data from a SPAN port or TAP. They are often reconfigured to remove their IP stack, as to minimize the chance of responding to network activity. While this strategy does help to conceal the presence of a NIDS sensor on the network, the flip side is that this makes it more difficult to execute any sort of flexible response on identified attacks. By flexible response, Im refering to the capability to attempt to reset TCP connections by sending spoofed TCP Reset packets to both ends of the connection.

There has been numerous documented tests for Snort's flexible response capabilities. The effectiveness of this setup is mixed if you consider the different result catagories of most web attacks:

• Denial of Service. In DoS attacks against web servers, the malicious packets just need to make it to the web server. The attackers do not usually need to have any data returned for the attack to be successful.
  
• Command Execution/Injection. Similar to DoS attacks, these malicious requests normally only need to make it to the web server in order for the attack to be successful. If Snort prevents the outbound data from being returned to the attacker, this does make it more difficult for the attacker to accurately conduct a large command execution attack, as they do not have any verification of success/failure of their commands. This becomes a "blind" execution attack.
• Obtaining Information. The goal of the attack is to obtain information from the web server, such as the contents of the /etc/passwd file. In this attack, if the attacker does not receive the results of the command, then the severity of the attack has been lessened as you have prevented information disclosure.

From the results of such documented test, due to the speed and overhead of creating the TCP reset packets, Snort was just not quick enough to tear down the malicious requests connections prior to reaching the web server. This means that it was not successful at mitigating the DoS and Command Execution attack categories. On the flip side, it was rather successful at preventing the information discolsure attacks by terminating the connection prior to the data reaching the attacker.

Don't get the wrong impression with test result you may find on the net about NIDS preventing web attacks. NIDS serve a critical purpose in web security; however, prevention of attacks will not be achieved unless the architectural deployment strategy of NIDS is changed. This is where the concept of an "inline" IDS emerged.


Next, we'll look at Deep packet Inspection Firewalls, Inline IDS, and Web Application Firewalls

Why Firewalls Fail To Protect Web Servers / Applications

`During the next month I am going to b focusing on Web Application firewalls. Particularly ‘role our own’ type application firewalls. I will be putting 3-4 blogs on this technology, what works and what doesn’t.

During the final week, I will write about the howto and results of an interesting project I have been focusing on. The “Proxypot” is basically a Honeypot Web Proxy server, which logs all usage traffic, it returns a “200 OK” to malicious traffic but it blocks and logs the malicious traffic.

So on with it ….



WHY FIREWALLS FAIL TO PROTECT WEB SERVERS/APPLICATIONS

There are very common misconceptions made by staff in organizations about the effectiveness of various network security tools for preventing web attacks. The most common and stupid one is that a firewall can handle this task (this one usually comes from “budget conscious” managers!).

Firewalls were originally created to inspect the IP and TCP layers of the OSI network model, meaning the original task of the firewall was to focus on IP address sand port numbers of the connection and not the application layer information. Historically, the characteristics of the packets could be used by the rule sets were the following:


Source IP

Destination IP

Source Port

Destination Port


So we have this fancy, expensive, state of the art firewall, we are doing everything to the highest standard. We are dropping every packet which isn’t explicitly allowed and only allow TCP 80 through from anywhere to our very large and expensive e-commerce web server.

With a configuration such as this, when a web request would come into the firewall, it would allow it based on rule number ‘bla’ and then forward it into the web server. An example log entry is shown below (Ten points to you if you guess which firewall this is from! ) :


14:55:20 accept firewall.foo.com >eth0 product VPN-1 & Firewall-1 src 24.18.186.248
s_port 4523 dst 69.229.28.252 service http proto tcp xlatesrc 192.168.1.101 rule 6


The problems arise when the full web request that was passed by the firewall is something like this:


24.18.186.248 - - [05/Feb/2005:14:55:20 -0500] "GET /scripts/root.exe?/c+dir HTTP/1.0"
404 1041 "-" "-"


An example network diagram illustrating this firewall setup is show below.






Oops, this request appears to be part of a NIMDA worm attack. This could be bad news if the target web server is running IIS and is not patched. Of only the firewall had some knowledge of layer 7 payload, it could have blocked this attack; however, this data is not normally available as evidenced by the preceding firewall log entry.


Next port wil explain why Intrusion Detection Systems Fail as Well !

Detecting Web Application Firewalls / Proxies

These are protective devices which are placed between the users and the webservice (webserver, web-farms, etc).

There sole purpose is to analyse HTTP traffic to determine if the traffic is “Valid” or “Invalid” (i.e. malicious). They are mainly implemented an Intrusion prevention system to prevent attacks against the web platform and the web application.

Hogwash was one of the first implementations of this technology many years ago. It was originally developed to protect web servers which could not be patched. I.e. A major flaw in the web application. Hogwash would be used to “scrub” the attacking traffic. This technology can be implemented in 3 ways. I will cover them in tomorrow blog

Web application firewalls are still relatively rare to see when pen-testing an application but being able to detect then is still very important. It is enccouragable for clients who engage the service of pen-testers to inform the use of web application firewalls. If this ins’t done, the pen-tester can hit many problems which will slow the testing phase and cold hinder the clients SoW. (I’m speaking from experience!). The examples I’m outlining are not the magic bullet to identify all application firewalls, but they should give you enough information to identify one when you come across one.

If your company is thinking about implementing a Web Application Firewall, then a good place to start the eval is HERE.

Teros

The Teros web application firewall will respond to simple TRACE request or any invalid HTTP method such as PUT with the following error: (note: these responses are from the “out-of-the-box” default setting.. Reponses can be different if setting are changed. BUT, unfortunately I have yet to see a company which does that *cough* a Certain BANK I used to work at *cough*)

TRACE / HTTP/1.0

Host: www.bank.com

User-Agent: Mozilla/6.9 (compatible MSIE 5.01; Widows NT 5.0)

HTTP/1.0 500

Content-Type: text/html

Error: 500

Invalid method code

The other easy way to detect a Teros application firewall is by spotting the cookie it issues. The cookie should look similar to this:

st8id=1e1bcc1010b6e32734c584317443b31.00.d5134d14e9730581664bf5cb1b610784)

The value of the cookie will obviously change but the cookie name “st8id” is pretty much a give away.

F5 TrafficShield

When you send abnormal requests (using a HTTP Fuzzer of some sort) to F5’s TrafficShield, you might get responses that contain errors like those listed here. For example, here we send a PUT method with no data:

PUT / HTTP/1,0

Host: www.bank.com

User-Agent: Mozilla/6.9 (compatible MSIE 5.01; Widows NT 5.0

HTTP/1.0 400 Bad request

Content-Type: text/html

400 Bad Request

The server could not understand your request.
Your error ID is:

5fa97729

TrafficShield also has a standard cookie that is used with their devices. The cookie name is “ASINFO”, and here is an example of what the cookie looks like:

ASINFO=1a92aa506189f3c1cf0e7fc6c6a04458…………………………………………

There is another product out there called Netcontinuum which I have not looked at or test. But if I come across it, I will post the result here.

Again, these product don't mean a thing if the default setting aren't changedor if they are not configured correctly. This is why I will have to blog soon about those $100K+ "Security Analyst/Consultant's" who work at these banks but wouldn't know their asshole from their own head! Yes ladies and gentlemen, the security of the bank relies on these $100K+ so called "Security Analyst/Consultants" who would know a xterm from a xxx show. Some survive by using politics and making problems which don't exist. In an upcoming blog, I will write about these people and let the internet community comment. I will call it " The $100K+ so called Security Consultant"

I will also cover URLScan and SecureIIS tomorrow.

For now, have fun and don’t break things !

Your Webserver has been Amap'ed !

Though is wasn't blatently obvious I was running a Apache Webserver on port 80, the guy from China decided to Amap the port to make sure a webserver was present !

Gone are the days of the "Security Through Obscurity" approach with Amap . There is nothing wrong with trying to run services on non-default ports and changing/modifying banners on services. But I think to solely rely on this to defend against attackers is a recipe for disaster.

THC-Amap, was developed by The Hackers Choice (www.thc.org) and was released under GPL 2002. Now in version 5.2 , it identifies services not only by grabbing banners, but also simulates, application handshakes against the target service. When combined against fast scanning tools like Nmap or Paketto Keiretsu's Scanrand. an attacker can quickly scan an entire network and positively identify when they are running on non standard ports or the banners what been changed or obfuscated. (My wish list for list for Amap would be to add funcionality to identify web application firewall/proxies i.e Tero )

From Amap's THC webpage .....

"THC-Amap


Amap is a next-generation tool for assistingnetwork penetration testing.
It performs fast and reliable application protocol detection, independant
on the TCP/UDP port they are being bound to.




[0x01] Introduction


Welcome to the mini website of the THC Amap project.


Amap is a next-generation scanning tool for pentesters.
It attempts to identify applications even if they are running on a
different port than normal.
It also identifies non-ascii based applications. This is achieved
by sending trigger packets, and looking up the responses in a list
of response strings. "


While I leave a putty console logged into my mail server (OpenBSD4.0 Stable i386) for monitoring logs, ome entries stoff out like dogs balls! See bellow:


219.xx.xx.xx.xx - - [18/Dec/2006:03:03:37 +1100] "\x80\x80\x01\x03\x01" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:37 +1100] "USER AMAP" 400 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:37 +1100] "HELO AMAP" 400 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:37 +1100] "GET / HTTP/1.0" 200 23
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:37 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:39 +1100] "GET / HTTP/1.0" 200 23
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "0\x0c\x02\x01\x01`\x07\x02\x01\x02\x04" 400 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "l" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x12\x01" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "JRMI" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x02\x03" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x11" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x03" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "y\b" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x81" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "\x80" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -
219.xx.xx.xx.xx - - [18/Dec/2006:03:03:43 +1100] "" 501 -


I didn't notice it as being an Amap scan as first I was trying to figure out what the hex values were. Then I came across "user amap" etc etc and it was a give away.

One of the impressive feature of Amap is it has the ability to identify protocols wrpped in SSL. This type of service identification is significant because the SSL service doesn't send a "banner". It expects to perform a full binary handshake with the client. There are three steps to an SSL Handshake:

1. CLIENT_HELLO
2. SERVER_HELLO
3. Server-to-Client certificate transfer

I won’t get into too much details about SSL handshake as we will be getting sidetracked from Amap itself.

Amap stores its trigger packets in a file called “appdefs.trig” it stores a collection of possible known responses in a file called “appdefs.resp”. These file can be edited to include other triggers or responses in the following colon ( : ) separated format )hopefully I can add the triggers and responses from web application proxies/firewalls to these files when discovered) :

NAME : [COMMON_PORT, [COMMON_PORT,…]] : [IP_PROTOCOL] : 0|1 : TRIGGER_STRING

Here is a example of a DNS trigger packet sent by amap:

dns : 53 : udp : 1 : 0x00 00 11 00 00 00 00 00 00 00 00 00

And the response signature:

NAME: [TRIGGER, [TRIGGER,…]] : [IP_PROTOCOL] : {MIN_LENGTH, MAX_LENGTH] : RESPONSE_REGEX

Here is a Microsoft DNS signature (from my lab)

dns-ms : dns : udp : : ^\x00\x00\x90\x04

For protocols that are not identified, amap includes another application called “amapcrap”. This tool is used to send random “junk” to a port that isn’t responding to any of the normal triggers. If the service responds, amapcrap outputs the response in appdefs.resp format, as well as the “junk-string” which triggered the response in appdefs.trig format, so they can be added to amap’s database of service signatures and triggers for future recognition.

sist3m@syn:/home #> amapcrap 172.16.1.3 80
# Starting AmapCrap on 172.16.1.3 port 80
# Writing a "+" for every 10 connect attempts
#

# Put this line into appdefs.trig:
PROTOCOL_NAME::tcp:0:0x)+,-08)(*+6d26.*5c-()%2f6f/'+)+0480+4e/#5763+,.+++4e65580(57-+)$15.#0c+04132)**-0+10--6a0'761b3f716a22-)---.+$791d09."1661*-**7670+'27,!.*,"4f.%-"1c40,**"5b0*04-%1c--*#/+710d097a./20.,7c,*53/,627a*.3c2c/-12//0a52+)*,+.+$*073-!6d07+,

# Put this line into appdefs.resp:
PROTOCOL_NAME::tcp::"HTTP/1.1 400 Bad Request\r\nContent-Type: text/html\r\nDate: Wed, 20 Dec 2006 09:00:20 GMT\r\nConnection: close\r\nContent-Length: 35\r\n\r\n

Bad Request (Invalid Verb)

"

Using Amap with Nmap for the Scanning & Enumeration phase of a Penetration Test

Amap is a good tool for pen-testing which can be used hand in hand with Nmap.

Here are some examples:

When the – l switch is used, amap will take input from a list in a standard nmap format:

nmap –oG

This allow the pen-tester to to conduct a regular scan with nmap and then run amap on the results. The next example shows how nmap and amap can work together.

The following line uses nmap ro scan a typical class C network for common ports and record the results in a grepable format in the nmap_out.txt:

sist3m@syn:/home #> nmap –oG nmap_out.txt 192.168.1.*

Here, amap is used to parse the output file generated by the preceding nmap command and send the default set of trigger packets on the target/port combinations found by nmap.

sist3m@syn:/home #> amap –i nmap_out.txt

Noth nmap and amap operations could be incorporated into a script. Amap can also output for reporting/archival with the –o switch, or for use with other tools in a colon separated format by adding the –m switch.

The following is an example of amap taking input from nmap’s output and outputting to a colon-delimited file:

sist3m@syn:/home #> nmap_out.txt –o amap_out.txt –m

Downsides…..

Obviously there is a huge downside to amap. The noise it generates is like using a jackhammer in a library !

There is absolutely no stealth with this tool. By default is open 12 parallel TCP connections to the target before any trigger packets are even sent and can even open up to a massive 256 with the –c switch. So yes, the NIDS will pick up an amap scan, that’s for sure ! More importantly are the actual logs (see above) kept by the services that amap attempts to identify.

The best defense against amap scan is detection. Good luck configuring an IIS server with SSL enabled to log the SSL handshake amap triggers! : )

I ran a sniffer while running amap against my own servers and noticed a very very unique signature which can be incorporated into a IDS signature to detect an amap scan in progress. When amap is complied from the original source code, is the machine name it uses in the trigger packet it sends for connecting to the service. The machine name is kpmg-pt is a string that can be looked for NIDS to detect an amap scan in progress. WOW! So I wonder who wrote amap and why the KPMG morons did that ?! : ) so if your NIDS triggers because it has detected an amap scan in progress, perhaps KPMG are conducting a Pen-Test on your company LOL!

The information I have used for this blog can be found all over the internet. Have fun with amap

Functionality Differences Between Apache 1.3 and 2.0

During the planning of my proxypot, a crucial decision came up about the version of Apache which was going to be used. There are major fundamental differences between Apache 1.3 and 2.0.

Apache 1.3 has the majority of current market share due to its greater length of existence. The 2.0 version is gaining in popularity. There are many advancements in Apache 2.0 that not only improve Apache performance, but also has flexibility for security enhancements. The table below illustrates the main differences between Apache 1.3 and Apache 2.0

Feature		Apache 1.3		Apache 2.0
IPv6 Capability		Unofficial Patches		Fully Supported
Multi-Processing Mudules/Threading		Less-scalable Multi-process model		Enhanced to support several models for better scalability
Build Configuration		APACI		GNU Autoconf
Server Configuration directives		Redundant directives		Streamlined to remove confusing
Platform Support (APR)		Limited and problematic		Expanded with Apache Portable Runtime
Multi-Protocol Support		None		Can create protocol modules
HTTP Proxy Support		HTTP 1.0		HTTP 1.1
Input/Output Filtering		None		Fully Supported
SSL Support OpenSSL's support		Unofficially supported		Supported through mod_sll, which uses OpenSSL's support

There are a handful of features Apache 2.0 version that enable you to accomplish important security tasks. The most notable are the advanced proxy capability, improved header manipulation with mod_headers, and finally input/output filtering. There is also a really cool feature of the Mod_Security module called Output filtering that is only available if you are using Apache 2.0. So perhaps Apache 2.0 will be deployed for the proxypot !

Old SSL exploits still used in the wild

It seems that old (2003) exploits are still being used in the wild.

I woke up this morning to find the following in my Apache logs on my OpenBSD 4.0 i386 server:

200.175.20.52 - - [16/Dec/2006:04:16:28 +1100] "GET /sumthin HTTP/1.0" 404 277

The probe can from a Brazilian IP range.
Interesting ports on univel52.csc.gvt.net.br (200.175.20.52):
Not shown: 1673 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
1720/tcp filtered H.323/Q.931
3306/tcp open mysql
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.5 - 2.6.11
Uptime 16.163 days (since Thu Nov 30 06:03:23 2006)

The offending IP is a government box in Brazil. See nmap scan above. It's running a 2.6.x kernel ;)

Some additional info on the offending host:

$ telnet 200.175.20.52 22
Trying 200.175.20.52...
Connected to 200.175.20.52.
Escape character is '^]'.
SSH-1.99-OpenSSH_3.8.1p1 Debian-8.sarge.4

The "GET /sumthin HTTP/1.0" is the signature of a mass Openssl scanner and exploiter. I have actually had the opportunity to play with this tool during my time at Deutsche Bank as a First Responder.

I found a great write up on this tool at LURHQ.

I can't clearly remember but the authors were either Polish or Indonesian. I believe I may have a copy of the tool somewhere. I will attempt to find it and post it here for analysis

What intrigues me is that this type of exploit is still being used at the end of 2006!