Another PA bypass

[mikand]

Found this one recently:

http://www.what2code.net/?p=150

http://www.youtube.com/watch?v=wPHeAkv8BaE

Where dns is being used to tunnel ssh traffic through and of course there will be ways to bypass things but how is/will PA address this latest finding?

(and to be fair pretty much the same bypass exists in other vendors equipment aswell such as Checkpoint among others but still...)

[scottlsattler]

DNS for ex filtration is catching many of the vendors off guard. Specialty vendors like Damballa do a fairly decent job. Don't expect a firewall vendor to invest the effort to track this type of ex filtration and CnC activity any time soon. You will find the typical signatures for tunneling protocols over DNS which are relatively easy to spot and so are the Gen 3/4 version of the DNS DGA malware that is out in the public. However malware that uses the additional dns fields to exfiltrate data or for CNC activity has not been looked at or addressed by any vendor that I know off. I know many of security folk who simply don't log or look at DNS traffic making it an ideal avenue for data exfiltration

[mikand]

Personally I recommend to put a proxyfirewall inline with a PA device to get the best from both worlds.

The proxyfirewall, since it has dns-proxy (among others), will make sure that only dns-traffic will be let through. That is any "protocolswitching" (unless its within the protocol specifications) will be blocked by the proxyfirewall and then PA will take care of the rest (IPS-style).

What worries me is that there is still not a single response from any Palo Alto representative regarding this latest finding and what PA is doing to address these (or for that matter this particular bypass)?

The appid bypass last christmas rendered some changes in how PA deals with flows - but these countermeasures doesnt seem to have been enough looking at this latest bypass?

If we take DNS as example the entire conversation in this example was at 9742 bytes (11.4kbytes according to some other screenshot) - is that even within specifications of how DNS is supposed to work? Also that traffic obviously flows in both ways all the time with the same session. Isnt DNS strictly a request/response protocol? That is client sends a request and gets a response back from the DNS. Next query will be a new session towards the DNS-server and so on... Im just saying that I think more could be done by PA to address these kind of bypasses (which even if appid is good overall will be used as a reason for why not be using appid - and if that happens the organisation will have a far worser protection than if appid is being used even if the appid can be bypassed).

[pa_lincoln]

I am of the mind you should configure all your clients to use an internal DNS server.  That server should perhaps use the PAN as proxy or be allowed out.  Don't allow traffic from internal hosts to go out to the internet for DNS.

[gafrol]

In my experience and the environments I work in there is at least one internal DNS Server, and client dns traffic is not allowed to unknown , external Servers.

Good IT Security concepts are still an important part of an Enterprise Security posture even in the age of NGFW's 🙂

Although I understand the message behind the video demonstration...

[SRA]

This does not appear to be a genuine or valid scenario. The scheme devised in the test assumes both the client and server are already under the control of the attacker. We aren't aware of any real-world clients or servers that can talk DNS initially and then switch to SSH. App-ID has coverage for many evasive real-world tunneling applications and we continue to add coverage for more as we discover them. We are currently reviewing this further, stay tuned for an update.

[craymond]

I would agree with lincolnelectric, gafrol,  and SRA. We do not allow DNS incoming  nor outgoing from any device (besides the DNS servers) except for systems in the Externally facing DMZ. Those devices in the DMZ are only allowed to 3 trusted external DNS servers. This method does not work through the PAN as configured and using the methods from the video.

[mikand]

I disagree with you... this is both a valid AND genuine scenario.

Here you have at least two valid scenarios where this apply:

1) Schools and/or at work where the client is trying to bruteforce their way through the url-filter. Since the client already has control of the server (the one at home) and obviously can run stuff on their client (at school/work) and hey presto - the expensive firewall is suddently bypassed.

2) Similar to above but where the client gets a botnet binary or some other 0day malware and hey presto - the expensive firewall is suddently bypassed.

One could argue that there are workarounds for both cases above but the thing here is that this test shows that (in the public eye) the AppID in PaloAlto is "worthless" (which of course it isnt but using arguments that "this is not a valid scenario" is just bogus and doesnt really bring you more trust to PaloAlto products - I think the result is unfortunately the opposite, the trust to use PaloAlto devices will shrink when bypasses like this are possible (but to be fair - and this is perhaps by luck for PaloAlto - the same bypass also worked in Checkpoint (but is now fixed) among other vendors so PaloAlto is not alone (yet))).

In this particular case the workaround (until proper fix from PaloAlto arrives - by the way when will it arrive?) is to limit which dns servers the clients (and servers) are allowed to use. But next time its perhaps some other AppID which is affected. Not too long ago it was AppID:web-browsing where the attacker could switch to another protocol in the middle of an already established session and web-browsing is much harder to "limit to a few IP-addresses"...

[craymond]

Your points are well taken mikand. After re-reading what SRA wrote I think your points are justified.

PaloAlto needs to resolve this issue (the method has actually been around for quite a while). If you are setting up your (PAN) environment with a white listing approach first, than this should not be an issue with those setups. However, the comment that "This does not appear to be a genuine or valid scenario" is not a sufficient response from a representative of PaloAlto -- it is valid and genuine in the "right" (or wrong!) setup, and shown to be valid in the video. 

I think that saying that in the public eye AppID will be seen as worthless might be going a little overboard (although it won't be by its competitors!), but it does contradict what the PAN is supposed to be able to mitigate and needs to be addressed.

Thanks for bringing this to light.

[scottlsattler]

I am not talking about the typical DNS tunneling. There are 20 clients out there that can do dns tunneling. I am talking about using the DNS protocol itself for command and control and data exfiltration, doesn't matter if you proxy or send up to root or your ISP. I see it all the time at clients, It would be nice if there was a signature that could detect (Without me continuing to write them) large TXT fields or protocol violations.....etc etc..

[mikand]

Well that sounds like DNS tunneling to me, compared to this current vuln which according to pcaps seems to completely switch protocol without the PA device will notice.

And speaking of which... still no official response from PA or even a fix for the current issue? 😞

Which is also mentioned on the blog which reported this: Bypassing application control, Having fun with Fortigate – Take 2