AppID Cache and recent Security Bulletin: App-ID Cache Pollution

[sunilsadanandan]

Hello Everyone,

I was having a closer look at the APP ID cache pollution issue that was addressed in the above mentioned bulletin.

It states that , "The App-ID cache is a mechanism for caching the App-ID associated with a destination IP/port pair. When enough

consecutive connections are established to the same destination IP/port with the same App-ID result, the next connection

is assumed to be the same application."

Could someone explain to me why the decision for caching is being made purely on the App-ID value , the Dest IP/port pair and completely ignores the source port and IP ?

Could this problem of the cache pollution itself have been made a lot more difficult to achieve if the source port and IP was also considered while deciding which session would have a corresponding App cache ?

Kind Regards,

Sunil

[mikand]

I wrote some of the comments I received from PA earlier (see the post from 6 jan) at which might answer some of your questions.

As I understand the app-id cache problem is basically two (well three depending on how you count) folded.

For an existing session that gets offloaded the app-id cache value is a hint regarding "how was this session identified last time this box saw a packet which belongs to this session?".

This gives for example that app-id cache says "sip".

The packet, because of the value in app-id cache, will then be sent to the sip-decoder.

Here is the second problem, the sip decoder didnt successfully identify that this packet no longer is a "sip-packet". And since PA is a NGFW and not a ProxyFW it means that if nothing is identified being wrong with the packet (or rule saying it should be dropped or so) the packet will be forwarded in its original state.

And here comes the third problem (but might not count since its out of range for the PaloAlto device) - the server at dstip will interpret the bad packet and on its own handle it as a http request instead of a sip request.

I think one way to imagine this is if you use ftp to upload a file which contains a full http header. Now assume that the file (with the http header) accidently turns up in its own packet. So if you only look at the packet itself you will only see a full http header. If PA didnt have any form of app-id cache you would most likely get a false positive where the NGFW would identify this particular packet as app-id:web-browsing (or similar) instead of app-id:ftp.

Now regarding the ports the PA will intially work (in its flow) as a regular SPI based firewall. Meaning if srcip, srcport, dstip, dstport isnt matched by any rule the packet will be dropped. Now if you use "service:any" this check will never drop any packets, compared to if you specify "service:application-default" or for that matter "service:TCP12345".

This gives that as long as you specify dstport (named service in PA) you will in most cases fix the third problem described above. For example if your rule allows appid:ssh service:application-default (meaning only TCP22 will be allowed) which also gives that the server at dstip must understand http if arrived at TCP22. This will of course not stop any manual evasive behaviour (a user who setup a http server at home that listens to TCP22 and accepts a few bad initial packets before it will find the http header to act on) but it will stop if you try to first initiate a sip session towards facebook TCP80 (or TCP443) servers if your allowing rule only allows TCP5060 and TCP5060 according to applipedia (was looking at appid:sip).

Except for the above (knowing which decoder the packet should be sent to which according to PA gives a boost of up to 5% in performance) the app-id cache is also used for heuristics. I assume that is if a session in the first packet is identified as dns, the second packet http and the third as ssh then there is a signature for this behaviour aswell and the PA could classify this session as app-id:xxx.

There is an description in regarding the new app-id settings found in 5.0.2 (and soon to be in 4.0 and 4.1 as I have been told) to fix the app-id cache polution.

[sunilsadanandan]

Hi Mikand,

Thanks for the response. That is a good summary of the issue at hand and details of the various responses. My question was specifically regarding why a decision has been made to ignore source IP and port number while deciding which connection would be cached. If you look at the video by checkpoint you will see that the batch file used to generate the SIP traffic would have run as a different process from the Facebook session running off the Webbrowser , which should have come from a different source port number. I.e. I didnt have to know anything about the running sessions or figure out a source port number to spoof, and if source IP is not being considered for caching then that would mean the poisoning affected every IP behind the firewall talking to the same Dst IP/Port number ? Which (if correct) for me seems like a very serious architectural flaw (I do not know if my reasoning is correct or not , that is why I am looking for comment from someone who might know better). This means from an APPID perspective if there were different sub apps , like facebook chat , mail , or any other app embeded on that Dst IP/Port combination , it would have been poisoned also ?

The other aspect is the APP ID engine itself being tricked to think that it was a SIP session with just one packet. I would have expected it to have have more rigorous checks before marking the app to be SIP. I do understand that this might not be possible in certain apps.

[mikand]

I agree with you if the appid cache only looks for dstip/dstport instead of the full session which would be srcip/srcport/dstip/dstport (+ any transaction id's).

A good example is as you already mentioned if you would allow facebook-chat but not facebook-upload, most likely both of them can use the very same dstip:dstport. On the other hand the same srcip:srcport could be used aswell... However if using a nat-device between the client and the PA-device would probably yield a different srcport for a different session.

Perhaps someone from PA could bring some light into this?

However only watching the videos doesnt necessary give you the full insight of whats actually happening. I mean the person recording the video could for instance force all its outbound traffic using the same srcport or such (like through a nat-router or so). Or these particular appid's used to pollute the cache perhaps on their own allows srcport >1023 compared to more restrictive appid's lets say ssh or such.

Also watching the "Take 2" video now shows an url towards Image-Share - image-png-1981-170 which contains something interresting.

To my knowledge if you setup two or more appid's in the same security rule and use "application-default" as service this would mean only the ports for each application would be allowed through.

Lets say you setup "ssh, web-browsing" then only TCP22 would be allowed for ssh and TCP80 for web-browsing. Not allowing web-browsing to use both TCP22 or TCP80.

If you setup the rules as in the picture above (multiple appid's and multiple services) then each appid will be allowed to use all of the services defined (in the above picture that would mean that sip would be allowed for udp/tcp53, tcp80 and tcp443 - compared to if the ruleset was as in the video saying application-default, then sip would only be allowed for udp/tcp5060). So an "editing glitch"? Depends on who you wish to trust