AET & PAN

[NGS_SOC]

Hi everybody,

last week I had a Stonesoft engineer in my lab demonstrating their techniques of exploit attack via AET. I tested my PAN NFR units (PA-200 & PA-2050) with IPS license last update, together with other vendors IPS units, protecting 2 pretty vulnerable client (one win xp sp2 the other ubuntu 6.04) .

The result scared my quite a bit. Known exploits are blocked once sent in clear way, but when a subset of AET was run under script the catch rate  was quite bad, less than 10% with the highest IPS policy in place.

Here the link to Stonesoft attacker that one can freely test: Evader | Stonesoft Evader

Last AET discussion in this forum is pretty old, end of 2010, and I would like how PAN handles nowadays these kind of sophisticated traffic obfuscation, carrying malicious payload.

I know that patching the client solve the problem but the same oparation could be done with client with no patch software available and IPS are meant to handle such situations.

Regards

[scantwell]

There is supposed to be awareness by the Palo Alto firewall, as there are AET questions from this forum from 2010.

I would recommend that you contact your SE and discuss your findings with him, so a ticket for escalation could be opened as needed.

[mikand]

However AET (Advanced Evasion Techniques) is a concern of everybody using a firewall such as a PA device so it would be great if some PA representative could bring the community forum some updates on this topic.

As I understand it the IPS in PA is a strictly stringmatching engine (as most IPS are). That gives if you take one threat thats being identified and obfuscate it through some other scripting language so that the content of the packets being sent is changed then this signature will most likely miss this modified attack unless the modified attack on its own is being identified. For example if there is a signature for a specific exe-file which will no longer be detected if you run the binary through UPX. But then there is perhaps a signature for UPX compressed exe-files which might trigger instead.

Except for having the threat-db up to date also make sure that the PANOS itself is up to date.

Another thing to verify is to have ssl-termination in place (and in a strict mode so if the ssl cannot be intercepted then the session is not allowed to pass through).

You can also use the url-db to only allow clients to visit "known" good sites (or rather categories).

PA method to handle such dynamic evasion techniques is currently by using Wildfire. Today Wildfire will only be able to process exe, dll and scr-files but that will hopefully improve in future with flash, java, office-documents etc. And hopefully even javascripts (and other scripting languages) for that matter.

A drawback with Wildfire is that it wont stop the bad file from being downloaded (when its seen first time anywhere in the world) but you will at least get a warning that the file the client just recently downloaded is an (currently) unknown malware (this alert shows up when the analyzing is complete). The next client downloading the same file will however be protected (unless the signature changes).

No matter which IPS or similar product you use there will always be 1-5% malware out there that will, in one way or another, be able to bypass this filtering. That is why its important to also have a good design closer to the clients so WHEN (and not IF) the shit hits the fan (because it will) the infection can be contained and perhaps also segmented away from your sensitive data.

One way to accomplish this is by using a terminalserver setup for the clients to use if they want to browse the internet. This terminalserver cluster is then segmented away from the rest of your network so IF you get some malware through your network this malware will still not be able to reach any of your golden eggs which you handle at the company (it will stay at the terminalserver cluster - by rebooting each instance each time a client logs out or do this once a day will also block out some longliving APT's (Advanced Persistent Threats)).

Another method is to use dedicated clients (and dedicated networks) among other solutions to this problem.

Except for having all your software up to date (so known exploits wont work) its also good to harden the configurations and also ask yourself if you really need all this software you currently have on your clients (the more software the more ways to exploit the client).

For example do you really need a pdf-viewer? And if the answer is yes - does it really have to be Adobe PDF Reader? Perhaps a more limited pdf-viewer such as SumatraPDF would be a better (securitywise) option?

Or for that matter if it really has to be adobe pdf reader - does it really need to have the javascript-engine available (which is like 90%-ish of the malware stuff through pdf uses to exploit adobe pdf reader) because the javascript-engine in adobe pdf reader can be removed all together (of course pdf's having javascripts wont work - but how many pdf-files have this and those who do have this - do you really need to use your company computer do open these files on which is the same box as you handle your golden eggs later on?).

The same thing goes by the way for AppID. If you allow web-browsing then any http-based traffic which isnt identified by some other appid will be allowed through your PA device. However if you combine AppID with the url-DB and threat-DB (IPS) along with Wildfire and SSL-termination and have a good design on your inside so IF something manages to bypass the filtering within your infrastructure you will have a pretty good setup.

What I want to say (for the TLDR people out there 😉 is that you can never trust your network to always catch ALL the malware which is out there - the network can of course be a good resource to help you fight malwares but there will always be 1-5% malware that will be able to bypass the filters and reach all the way to the clients (or the terminalservers if such are being used). So dont forget the overall design and also how to contain and segment WHEN malware will reach all the way. Because except for networks malware can spread through cd/dvd and USB-devices. And dont forget other vectors such as how are emails (and any attachments) being handled on which hardware (clients) in your organisation?

[NGS_SOC]

tnx mikand, great comment, as usual

I've spent some hours with my country SE and I have a officiaL answer to my AET question, in addition they give me some additional commands to test against stonesoft's evader attack. I'll try them within this week and I'll post my comment

[mikand]

Would be great if you, or even better your country SE, could post what was being said and which commands to test so the rest of the forum will know.

Looking forward for an update on this topic

Regarding these "virtual patching" (buzzword of 2012?) features of IPS's im a bit sceptic to those - its a good complement but the proper way to fix the problem is to update the client (or the server for that matter). Because as being said - there is often more than one way to obfuscate shit so it will bypass your IPS no matter which vendor you use...

[santonic]

I agree; some official post about this would be great. We're also having a potential customer trying to block Stonesoft Evader techniques.

Seems the only IPS system which successfully blocks Stonesoft Evader is McAfee IPS. However how relevant is this now that McAfee owns Stonesoft?