App-ID Cache Pollution: Merry Christmas From Check Point

posted by: on December 28, 2012 2:16 PM

filed in: Uncategorized
tagged: ,

March 27, 2013 Update: I wanted give you all an update to the App-ID cache pollution issue that was discovered earlier this year. First off, we should have managed this issue more effectively – we learned from the experience and we will be customer-focused in our comments moving forward. As promised back in January, the App-ID cache function in PAN-OS is no longer used for security policy.

  • PAN-OS 5.0.2 and subsequent releases posted to support site on or after January 15, 2013.
  • PAN-OS 4.1.11 and subsequent releases posted to support site on or after February 6, 2013.

We still recommend that you use the following security policy best-practices:

  • For applications that you are enabling, you should assign a specific port (default or custom).
  • For applications that you explicitly want to block, expand the policy to any port, to maximize the identification footprint.

For any further updates, please work with your local Palo Alto Networks sales team and channel partner.

Nir

On December 24th, just in time for Christmas, the folks at Check Point chose to ignore responsible disclosure and publicize a corner-case firewall evasion technique against Palo Alto Networks. Like lemmings jumping off the cliff, the other old-school firewall vendors have followed suit, publicizing the Check Point information widely. The firewall evasion technique, which we call App-ID cache pollution, does exist and here is what users need to know about it and how they can mitigate it.

App-ID cache pollution: what is it? App-ID cache is a feature that facilitates certain features within PAN-OS and provides some minor performance benefits. App-ID cache pollution involves purposely polluting the App-ID cache by establishing many connections with a “fake” application that has been allowed by the security policy. Once the App-ID cache is polluted with the fake application, a “bad” application can be sent to the same destination IP address and port number, thereby evading the Palo Alto Networks firewall.

Mitigating the App-ID cache pollution risk: This firewall evasion technique is a corner case that requires some knowledge of the existing security policy and the evasion risk can be minimized or eliminated through minor policy and configuration modifications.

  1. Do not use “any” as the service for allowed applications. Security policy best practices for allowed applications should use “app-default” as the service – not “any”. This simple step will eliminate nearly all evasion cases that have been observed.
  2. Disable the App-ID cache function. App-ID caching is enabled by default but using a simple CLI command, it can be disabled thereby eliminating all of the cache pollution evasion risks. Longer term, we will make some enhancements to PAN-OS to eliminate the App-ID cache pollution risks.

Taking these simple steps will have little or no effect on existing Palo Alto Networks deployments and will eliminate the App-ID cache pollution risks. For more information on the App-ID cache pollution risk, and how to mitigate it, please contact your local Palo Alto Networks SE or partner.

  • Check Point: A Responsible Disclosure Double Standard? Most of us in the security industry follow what is described as responsible disclosure which are a set of guidelines that allow a vendor who has a possible vulnerability (in this case, us) to investigate and respond to the discovery by an outside party (in this case Check Point). Check Point clearly believes in responsible disclosure, as evidenced on their support site and external sites - but apparently only when it suits them. In this case, they and the other firewall competitors, ignored responsible disclosure and publicized a corner-case evasion.
  • Pssst – the Emperors are Naked! The emperors of the firewall industry have pointed out that we are missing a button by publicizing a corner-case evasion as an ill-fated attempt to convince customers that one of their glaring weaknesses, the strict dependency on ports, is actually a strength. We are fixing the button (thanks by the way), but we want to point out that they are still naked (avert your eyes), and they have failed to address the fundamental, architectural issues that allow hundreds of applications and any end-user with a browser to evade their firewalls. This, despite the fact that they make every effort to tell the market that “we do what Palo Alto Networks does.”

Palo Alto Networks was born because traditional firewalls could no longer control real-world everyday traffic nor can they control the risks associated with the evolving application landscape. These are just a few of the examples of what we see on today’s enterprise networks.

  • Port 80 allow – open the floodgates. The always-on nature of port-based traffic classification, means old-guard firewalls will first need to open the application default port controlling the application. To control Facebook, you need to allow tcp/80 and tcp/443. Based on the June 2012 Application Usage and Risk Report, you may be allowing more than 500 (42%) other applications that you may or may not want on the network. This means the strength of a default deny all policy is significantly weakened. If you are using Check Point, or any other port-based firewall, ask them if the above statement is true and how they recommend managing it.

image1

  • Evasive applications use thousands of ports. In this example, SSL, found on nearly 100% of the networks and controlled by old-guard firewalls using port 443, was observed to be using 2,705 different ports, while Skype-probe used more than 27,000. Port dependent firewalls, even with their application control add-ons, cannot consistently address these types of applications. If you are using Check Point, or any other port-based firewall, ask them how do they control SSL if it is using one of the 2,705 different ports

image2

Thanks for reading and for your continued support.

 


Share your thoughts

8 Comments


Harry Hippo on December 31, 2012 2:43 AM said

Completely disagree with your emotional outburst and citing Check Point as the origin of disclosure – especially when you go on and on about good practices and responsible disclosure amongst vendors in a bizarre attempt to pin this on them…

The first time this vulnerability was disclosed was actually at the CanSecWest conference in March 2011 where PAN was one of the sponsors:

http://cansecwest.com/csw11archive.html

http://cansecwest.com/csw11/Network%20Application%20FW%20vs.%20Contemporary%20Threats%20(Brad%20Woodberg%20-%20Final).pptx

The fact is PAN chose to ignore this for almost 2 years and this is why the other vendors don’t employ such technology.

Eric G on December 31, 2012 1:18 PM said

I wish you guys would be a little more humble in these posts… I understand that it was a published vulnerability that completely disregarded the “etiquette” of responsible disclosure, but this write-up sounds like it was written by a 15 year old with a bruised ego.

Be more humble! You’ll win more converts in the end with humility rather than overtly tooting your own horn. You guys are better than the “one up-manship” games… let your posts reflect that. Just my two cents.

Sascha Picchiantano on December 31, 2012 1:50 PM said

What I don’t get here is the fact that this cache poisoning technique has already been demonstrated almost 2 years ago by Brad Woodberg at DEFCON19. Back then I was already puzzeled. When I talked to my Palo Alto Sales Reps about this, they looked at me as if I didn’t know what I was talking about.

So this has been known for more than two years and now that Check Point “exploit” this, you finally react.

I have absolutely not understanding for this.

This is bad.

Roh on January 2, 2013 6:16 AM said

Great post!
A copycat NGFW has got a limit for controlling application such as skype, bittorrent and any other application on real world!

Skype-probe used more 27,000 different ports is good information for effecting market.

Thanks for post.

Chris Camp on January 2, 2013 12:49 PM said

will this cache polution vulnerability be fixed in one of the next releases of PAN OS?

Wayne Hustis on January 2, 2013 1:05 PM said

This would have been more helpful if it had included the “simple CLI command to disable the App-ID cache”. For those who don’t have their CLI manual handy here it is, done in Configure mode:

set deviceconfig setting application cache no

Matt on January 3, 2013 8:06 AM said

Yes, We will make changes to PAN-OS to eliminate this issue.

Matt on January 3, 2013 8:06 AM said

Your right. Thx.

Post Your Comment