App-ID Cache Pollution: Merry Christmas From Check Point

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 24^th, 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.

• 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

Thanks for reading and for your continued support.