TLS secured SMTP inbound inspection?

[Dpeters1]

Hi,

I've recently had a client who's PAN appliance failed to pick up a Zero-Day piece of malware that found it's way into their network via email.

We have wildfire configured correctly and it transpires they are using opportunistic TLS on their mail relay, the spammer had send the infected attachement using TLS so the Palo Alto had no hope of actually seeing the content.

Oddly the application appears as SMTP rather than TLS, i'm guessing because the first couple of packeta would have a clear text EHLO amongst other items, identifying the App as SMTP, TLS happens a little later in the SMTP session.

So, I tried an inbound SSL inspection rule, which would work for TLSv1 (most commonly used for SMTP relays), but no luck, the PAN never notices the existence of the TLS in the session so doesnt try to decrypt.

Am I missing something or is this not possible right now?

It'll be a real shame if it's not as it's a gaping hole for APTs/Malware to creep through. Of course the first thing I did in this instance was to advise the client that they block all .EXE's via their SPAM filter, but would have been nice to catch it at the Palo...

Thanks for reading!

Dave

[Dpeters1]

Also, just spotted this

Re: TLS

Which would suggest that I'm on the right lines about PAN not seeing any difference between SMTP and TLS encrypted SMTP.

That's an old one from 2010 too, so if there's not an APP signature now and a way to inspect the traffic maybe it's not possible?

Thanks

[mikand · Accepted solution]

I guess your best option is to file this as a feature request.

I agree with you that it will be a gaping hole in case you already do a full ssl termination for browsertraffic but then is blind for whatever junk arrives through smtp.

As a sidenote, apart from .exe's you should also block .scr, .com, .bat and .vbs (and probably a few others I might have forgot).

As a workaround you can configure your mailserver in DMZ to accept inbound TLS but when forwarding to internal systems it should use cleartext. This way you can apply a filter in your PA to make it look at the traffic DMZ-MAIL -> Internal-MAIL

Edit: .pif and .lnk might be good to block aswell...

[Dpeters1]

Thanks for the feedback! Good idea with clear-text between the DMZ relay host/spam filter and the internal mail server. I'll make sure that happens.

Will have a chat with our SE from PAN and see if it can be added as a feature, I've a sneaking suspicion it may not be possible though, will have to see what magic the PAN developers can work!

Regarding the sidenote, we're forwarding PE (Pocket Executable) to wildfire, I was under the impression this encompassed all executable content, EXE/COM/ETC under 10MB in size. Am I right or have I misunderstood the classification?

Thanks

Dave

[ericgearhart]

+1 on the "clear text between a DMZ inbound and outbound mail relay and an internal SMTP server" idea - that's what we're doing and this enables visibility into mail coming in or out

[mikand]

Wildfire currently only test .exe, .scr and .dll (I think) - hopefully it will support pdf, office-documents and android/java stuff later this year.

As far as I know it doesnt test .pif and other similar types.

Also wildfire wont scan and then let your file through - the bad file will hit the client (unless the AV/IDP rule didnt set off) but with wildfire you will at least get a report that a file that the client downloaded a few minutes ago was bad. If the antivirus on the client didnt trigger you now know you have a client that should be reinstalled from scratch (like ghost image or such).

I added two more filetypes which I think should be blocked or filtered...

[Dpeters1]

Thanks for the clarification, this is exactly how I had it in my mind too with regard to the first instance (or first few instances) of malware being allowed through by wildfire.

For a high security environment this completely defeats the object of the exercise. "we can protect against APT and Zero-Day malware, except we cant for the first hour"

I've raised a new FR for a "block and forward" action which would provide the option to block unknown stuff. Which would work brilliantly for executables, possibly have/anroid if these features are added later in the year.

No idea how it would work for office and the like, the volume of those types of files traversing a company firewall must be many magnitudes higher than Pocket Executable. The wildfire service would be very busy indeed!!

Anyway, the initial response from Palo Alto was "Buy the new 1hr wildfire response service" which still leaves a hole for those magic 60 minutes.

I've suggested that the "block + forward" is added to the paid for wildfire service only, as right now the majority of my Palo userbase couldn't possibly justify the extra money for the 1hr wildfire service as it just doesnt represent enough of an improvement for the money.

[drwillis07]

Dave,

A bit of clarification on the wildfire subscription service - you can set it up to automatically check and download new wildfire generated signatures every 15 minutes but it could take as long as 30 minutes to get a signature for malware your firewall detected and uploaded for analysis. Based on traffic in the wild, stopping this stuff within the first hour (let alone the first 30 minutes) should provide a huge improvement in protection - thus the for-fee subscription service. Your SE can definitely cover off what we're seeing in our Wildfire servers.

Also, and forgive me if you already know this, you can configure a file blocking object that does trigger on any .exe download (matching the base security rule, or object specific applications) that forces the user to hit a continue button and acknowledge the download - all of this is without wildfire.  Wildfire PE files types include Win32 Portable Executable (PE) files (e.g. exe, dll, and scr), so you could use this continue configuration to force users to stop and validate the download of other file types mentioned here on Live: .pif, .lnk, .com, .bat and .vbs.

Alternatively you can configure wildfire to "continue and forward" which does the same thing - forces the user to acknowledge and accept a download prior to the firewall allowing the transaction AND sending off a file hash to the wildfire cloud servers to see if the file should be uploaded for analysis. Again, this would be for the subset of file types within the PE category today. Bear in mind that should the encrypted email get through, any potential executables that may be initiated when the user clicks on a link will still be detected by the firewall configured with a file blocking policy - this is also true of links embedded in PDF files.

HTH

[mikand]

Not entirely true (regarding the not the first hour)... the point of wildfire is not to protect but to detect 0days. This gives that in order to protect the client you will completely block downloads of exe (as example). But in case you want the client to download exe files (which might be bad) you now shrink the detection time of 1-4 weeks (compared to AV signatures downloaded to your PA device or for that matter any AV solution) down to less than 1 hour in case this bad file was detected elsewhere. And less than a few minutes in case this bad file was detected by your own equipment. I think at the same time its vital to get this difference when using wildfire that wildfire wont download, buffer, scan and then let the file through. The file will hit the client as without wildfire but now you will at least get a report that this file was bad.

As a feature request one could ask for ICAP support. This way you could do the download, buffer, scan and then let through. The downside is that the mgmtplane will be involved even more with the problems that buffered scans gives you in terms of max file size to scan but also that the client will get a "loading..." page instead of the file itself until its fully scanned (or in terms of PA analyzed by sandbox) and that the buffered scan isnt possible for all protocols (on the other hand buffered scan can be applied for all filetypes compared to PA's streambased scan which only works for a few filetypes).

So in short you should see the wildfire service as an improvement from the regular 1-4 weeks for detection down to max 1 hour (or even minutes if found by your own equipment). And if further security is needed you should consider to completely block clients from downloading stuff from the internet (like exe-files etc) or file a feature request of ICAP support (to cover the buffered scan stuff).

Another drawback of current wildfire is that any signed executable wont be scanned. This, I have been told, will be fixed in upcoming versions so you can decide on your own which signatures you wish to trust. Specially when Realtek certs and Digicert certs are out in the wild to sign malware.

[Dpeters1]

All good points.

I'm fairly certain any AV vendor worth their salt wouldn't take a week to respond with a new signature, let alone four weeks! Most of the vendors seem to respond within a day or two, but counting it in a few hours for response is rare.

To clarify, you're saying that wildfire will NEVER block, even a known bad file???

I was under the impression it would definitely block known bad files, either by analysis following an upload form your PAN appliance or from the shared intelligence of having all the PAN users taking part with wildfire.

[gwesson]

Wildfire is for detection, the anti-virus signatures are for blocking. When a malware file is uploaded to Wildfire, you get a report that it was a bad file and can take action as mentioned above. Signatures detected as malware by Wildfire will be added to the Anti-Virus subscription that is pulled down at least once a day by your PA Firewall.

So your statement that Wildfire will NEVER block a file is correct in a sense. But files uploaded to Wildfire are quickly added as signatures to the Anti-Virus system and can be pulled in to the firewall. If using 5.0 there is a subscription feature available that pulls down the AV every hour and can include signatures recently uncovered (even within the most recent hour in some cases).

Hope this helps!

Greg

[Tician]

Hello All,

what about feature request to distinguish between tls and non tls SMTP traffic?

Is there something new in decryption of non https encrypted traffic in general?

It might be good reason to open new topic on this issue, but this is huge security gap if consider that almost three years passed since this topic.....