How SSL/TLS Encryption Hides Malware (cso.com.au) 87
Around 65% of the internet's one zettabyte of global traffic uses SSL/TLS encryption -- but Slashdot reader River Tam shares an article recalling last August when 910 million web browsers were potentially exposed to malware hidden in a Yahoo ad that was hidden from firewalls by SSL/TLS encryption:
When victims don't have the right protection measures in place, attackers can cipher command and control communications and malicious code to evade intrusion prevention systems and anti-malware inspection systems. In effect, the SSL/TLS encryption serves as a tunnel to hide malware as it can pass through firewalls and into organizations' networks undetected if the right safeguards aren't in place. As SSL/TLS usage grows, the appeal of this threat vector for hackers too increases.
Companies can stop SSL/TLS attacks, however most don't have their existing security features properly enabled to do so. Legacy network security solutions typically don't have the features needed to inspect SSL/TLS-encrypted traffic. The ones that do, often suffer from such extreme performance issues when inspecting traffic, that most companies with legacy solutions abandon SSL/TLS inspection.
Companies can stop SSL/TLS attacks, however most don't have their existing security features properly enabled to do so. Legacy network security solutions typically don't have the features needed to inspect SSL/TLS-encrypted traffic. The ones that do, often suffer from such extreme performance issues when inspecting traffic, that most companies with legacy solutions abandon SSL/TLS inspection.
Intentional MITM / Reverse Proxy (Score:1)
Would using squid reverse proxy on a PF sense (or other firewall setup) with your own certs, on machines you control that trust those certs, defeat something like this?
Re: (Score:2)
Yes. It would. However if the device is allowed to roam on other networks (such as a laptop an employee can take home) this can cause issues with various key pinning solutions, and possibly also with HSTS.
Unfortunately the days that it was easy to intercept TLS traffic by simply trusting your own CA are slowly going the way to the dodo because of CA abuse that has happened in the past.
802.1x. In your use case, buying gets you nothing (Score:2)
I don't see that buying a cert gets you anything at all, for authenticating or communicating with your own clients. Why would you trust Versign more than you trust yourself? That's all buying a cert gets you - it's signed by them rather than being signed by you.
Protect your root CA, perhaps by storing it offline, and of course with a passphrase. Ideally for maximum security while maintaining convenience, you can use your root CA only to generate an intermediate cert, then use the intermediate to sign client
Re: (Score:2)
Keep doing what you're doing now. A self-signed cert saves you that trouble, but the downside is that it's already been leaked to a convenient centralized key repository which can be accessed by TPTB and any sufficiently skilled hackers.
Look into using key pinning to reduce the effort involved.
Re: (Score:2)
D'oh, I meant "A CA-signed cert saves you that trouble,"
Re: (Score:2)
Obviously it would.
On the other hand, blindly trusting a single SSL chain for an entire corporate network is just as bad, you only have to compromise a single system within IT to be able to infiltrate the entire network. If you're a "customer" on the network, do you trust your central IT department to not be complete idiots?
In smaller corporations that might not be a problem but in larger networks such as Universities and metropolitan-sized networks this quickly becomes a major problem especially when you k
Re: (Score:2)
you only have to compromise a single system within IT to be able to infiltrate the entire network
Which is already the status quo, thanks to centralised management systems like active directory...
Re: (Score:2)
Re: (Score:2)
Thanks to SSL I can connect to an unencrypted WiFi, and be mostly safe.
Re: (Score:1)
Thanks to SSL I can connect to an unencrypted WiFi, and be mostly safe.
Thanks to SSL you can connect to an encrypted WiFi and be mostly safe.
You trust wifi encryption?
Disable flash & keep endpoints up to date (Score:4, Informative)
The malicious yahoo ad used the angler exploit kit. 75% of the exploits used by angler are flash exploits: http://www.talosintelligence.c... [talosintelligence.com]
Just don't install flash per default, and require exceptions for people who need it for their job (hopefully a small amount).
Re:Disable flash & keep endpoints up to date (Score:5, Informative)
Protecting just the border is simply wrong (Score:5, Interesting)
This mindset of "we just need to protect at the borders; this protects endpoints" is wrong. While it provides some protection, there are so many other avenues of infection or acquiring malware that trying to equate TLS with making things simpler to hide just seems incredible of an assertion to make. These days you absolutely need to make sure that endpoint protection is just as strong, if not stronger than what you deploy on the borders of your network.
As more corporations allow bring your own device to save costs, and give employees laptops, you can no longer trust in just filtering at the border, because the devices can move, people bring in thumb drives, and other avenues for getting malware. TLS or no TLS, I have a feeling that most HTTP intercepting proxies would not have caught newer malware in ads even if configured to do so, simply by the nature that by the time there is a signature available for it, it is generally already too late and people will have been infected.
Time to update firewalls. (Score:3)
Re: (Score:1)
I have yet to see a single one that can decrypt SSL. I tried. A lot.
The only way to 'decrypt' is to force your own cert, which must be trusted on the devices (WPAD or manually) before it can actually do it without a browser throwing a fit. Unfortunately, once you have a mobile device enter, they tend to throw all kinds of hissy fits.
If I am wrong in assuming there is not a router that can actually decrypt ssl, then please, inform me. Because I looked for ages and even attempted to figure it out on my own. S
Re:Time to update firewalls. (Score:4, Informative)
No, if there was a device that could real time (or even near time) decrypt the traffic for inspection, it would negate the point of having it encrypted in the first place. The only way to inspect SSL/TLS traffic is with a MITM design with a trusted certificate on the client machines.
Re: (Score:2)
That's not inspecting the traffic content, that's a NIDS that builds a profile of "normal operation" based on traffic patterns and checks against it. It would stop all your file shares from being uploaded at full speed over HTTPS to a novel server for example, but nothing much less blatant than that. It wouldn't do anything about a user passing malware back and forth all day long over their usual SSL'ed webmail or web chat service for example.
Re: (Score:2)
Wrong. ALl those fucking boxes do is model normal traffic and watch for anomalous patterns, bandwidth usage, and IPs. They're next to useless, but cost big fucking bucks because people are retards.
Re: (Score:2)
I have yet to see a single one that can decrypt SSL. I tried. A lot.
The only way to 'decrypt' is to force your own cert, which must be trusted on the devices (WPAD or manually) before it can actually do it without a browser throwing a fit.
Yes, obviously that is what is meant by an SSL decryptor. I'm not suggesting that firewalls can crack SSL. It decrypts the traffic by acting as a MITM. You do need to install certs on the various browsers for it to work, or they'll complain.
Re: (Score:1)
Decent chain of trust?
A big chain of companies I don't know and can't vouch for. Any one of which can fake a certificate for a company I do deal with and do trust?
I would say the chain of trust is its weakest link. Bluecoat springs to mind. Symantec's Thawte division issuing fake certs comes to mind. Snowden leaks revealing fake Google certs springs to mind. The fake cert I was presented recently from my local junta system springs to mind.
Browsers like Firefox don't handle self signed certs well.
If they rec
Re: (Score:2)
Firefox forces me to obtain the self-signed certificate each time afresh, so each time it could be intercepted. Making hacking the cert very much easier.
I never really could imagine what posessed them to handle self signed certificates that way. But isn't there a check? Does FF actually remember the certificate and warn you if a different one is presented? That would make more sense: warn you every time that the cert cannot be verified, but also guard against a MITM replacing the cert with his own.
Re: (Score:2)
I think Firefox handles self-signed certs that same way as most other browsers, so you should be able to permanently trust the cert at the first use. It sounds like you might be using temporary profiles or private browsing sessions.
That said, the usual system of handling self-signed certs is a stupid one. Self-signed certs should be treated exactly the same as unencrypted traffic. There should be no "DANGER WILL ROBINSON!" warning when one is encountered. A self-signed cert is in no way less secure than a p
A true sense of insecurity (Score:2)
I think the idea is that a certificate from an unknown issuer gives a false sense of security, while a cleartext URL clearly lacks the S in http:// and thus gives a true sense of insecurity. True > false.
Re: (Score:2)
A minor perception problem that we need to work past, and partly have already. Modern browsers all show special symbols in the URL bar for verified HTTPS connections - usually green or blue highlighting. In line with plaintext connection behavior, these shouldn't be shown for self-signed certs.
Re: (Score:2)
Firefox maintains its own certificate store. This is annoying if you're pushing out trusted certs because you have to do it for the OS and then also do it for FF. But it is much safer. You absolutely can store certs permanently.
Firefox forces me to obtain the self-signed certificate each time afresh, so each time it could be intercepted. Making hacking the cert very much easier.
WTF are you talking about? Do you know how SSL works? (No, you don't. A self-signed cert is no different from a cert from a major CA in this regard.)
Re: (Score:2)
I have yet to see a single one that can decrypt SSL. I tried. A lot.
The only way to 'decrypt' is to force your own cert, which must be trusted on the devices (WPAD or manually) before it can actually do it without a browser throwing a fit. Unfortunately, once you have a mobile device enter, they tend to throw all kinds of hissy fits.
This is what we do. The Gateway (Proxy) cert is pushed out to all devices via group policy or MDM which allows TLS interception for inspection.
This works, so I'm wondering why this TFS makes it sound like such a big deal?
Re: (Score:2)
Virtually all modern firewall/IDP systems have SSL decryption. Given that virtually all websites use SSL nowadays, it makes no sense at all to even have an IDP if it can't handle SSL traffic.
Until you run into an app/site that breaks, then you have to disable it (at least for that site/app). Like this: "Dropbox not working when Client DPI-SSL is enabled" (link [dell.com])
The "problem" is that those SSL/TLS packet inspection approaches are the functional equivalent of a man-in-the-middle attack. Given how reliant we are becoming on SSL/TLS, it is no wonder that forward thinking sites and apps are taking measures to protect against that. Of course, those same measures defeat the good
Re: (Score:2)
That's often not the only inspection mechanism in place; but anyone who can actually break SSL without access to a trusted cert is currently being very
Re: (Score:2)
The only way to do this is spearfish style from Lennovo which means inserting a forged SSL certificate by the firewall to inspect the traffic. Corporations do this to spy on their employees and so do airlines wifi which replace signed websites with their own certificate.
But I think it is obvious here why this is not a good idea.
Re: (Score:2)
The only way to do this is spearfish style from Lennovo which means inserting a forged SSL certificate by the firewall to inspect the traffic. Corporations do this to spy on their employees and so do airlines wifi which replace signed websites with their own certificate.
But I think it is obvious here why this is not a good idea.
Which airlines do that? I haven't seen it on any of the domestic US carriers - though I only ever fly Delta or United. But my company always pays for airline WiFi when I travel
Re: (Score:2)
United. Go look in Chrome under certificates? Surprise they are signed by the wifi company!
Re: (Score:2)
How has the CA that sold the cert to the wifi company not been blacklisted? I assume they've legally cleared themselves by putting notification of this in the wifi portal EULA, but that is ethically wrong as hell. The CA sold a cert for use in what is effectively a blackhat SSL MITM appliance that is supposedly being used with the best of intentions.
Ethically the right thing to do would be to spell out how the airline wifi works on the portal page and include instructions on how to accept a self-signed MITM
Re: Time to update firewalls. (Score:2)
This was covered here last year. A Chrome engineer found it! The theory is the NSA did it to track terrorists as they would use the wifi on air to communicate to other terrorists
Re: (Score:2)
United. Go look in Chrome under certificates? Surprise they are signed by the wifi company!
So you're saying a trusted CA gave GoGo wireless a * certificate that works without adding a new trusted root? Because United uses the same WiFi services as Delta, so if United does it, Delta does it. Well, unless you're on one of the old satellite based United flights. I'll look next time I go on a business trip.
Re: (Score:2)
This time is nearly over. Forced HSTS and OCSP stapling are some of the measures being used to fight against this. Focus on the end-point, web filtering has nearly had it's day.
Jason.
That only works two ways (Score:1)
Those only work in one of two ways
a) Domains which a company has the SSL keys to (presumably ones they own), in order to detect malicious attempts such as SQL injections etc etc. They don't do much about encrypted outgoing traffic if it's permitted. Alternately, the SSL may be terminated at the security device and non-SSL traffic passed to the webserver etc. Again, this does nothing for 3rd-party sites and/or connections going out from desktops.
b) Companies which generate a non-legitimate global SSH key whi
Blue Coat (Score:5, Interesting)
Remember BlueCoat? The company given a cert by Symantec that would let them generate and fake any other certificate.
BlueCoat's claim to needing that faking ability, was so that it could decrypt TLS sessions, to check for virus's in encrypted traffic.
a) But if it was installed on a company server, then the *companies* own certificate would be installed on that PC and it wouldn't need to fake the certificate, rather it would intercept the session and substitute its own cert. (A standard 'feature' built into Microsoft Windows).
and
b) If the PC had a virus scanner, then that scanner would be checking the memory of the PC.
http://motherboard.vice.com/read/a-controversial-surveillance-firm-was-granted-a-powerful-encryption-certifica
Your ISP does NOT scan your internet connection for virus's. It never did when the traffic was unencrypted. It didn't lose the ability to do so in encrypted, because it never did. BlueCoat on the other hand represent a backdoor into all commercial, banking, financial, medical, government secrets, electronic voting machines, business secrets, cloud services, everything.
And yet somehow Symantec issued the certificate to them and faced no punishment.
Indeed, great master of the obvious! (Score:3)
Was somebody expecting TLS to stop working if the evil bit was set?
Re: (Score:2)
Encryption mechanism designed to protect traffic from eavesdropping by 3rd parties has potential to keep 3rd parties from inspecting traffic... Was somebody expecting TLS to stop working if the evil bit was set?
Ohhh was that why my exploits weren't working? I'll make sure I unset the evil bit so they can sneak through firewalls.
Re: (Score:1)
If you give people the ability to remove malware from your traffic, you give them the ability to censor it.
A non-story (Score:3)
.
The best prevention against malware sits in front of the PC screen.
This is one of those articles that takes a non-problem and ascribes importance to it in order to grab headlines.
Re: (Score:2, Interesting)
This is one of those articles that is a part of the ongoing war against encryption.
FTFY
Don't trust any device (Score:2)
Don't trust any device inside or outside of your network until you can verify it is trustworthy. Even then, don't trust it any more than you have to.
Okay, that's the ideal world.
In the real world such a policy would cripple most enterprises, so we have to compromise somewhere.
What that compromise should look like will be on a case-by-case basis.
Well then... (Score:2)
Well then... why don't we just outlaw encryption? Simple.
Re: (Score:2)
I was thinking the exact same thing! Only criminals use encryption.
Normal citizens who uphold the law having nothing to hide.
Re: (Score:2)
here, here, only dumb ass rednecks and criminals use encryption. The founding fathers lived in a time of caesar ciphers and invisible ink; they couldn't have foreseen a time of AES or SHA-3.
funny (Score:1)
an X bytes of traffic eh? (Score:2)
zetabyte per year perhaps? zetabyte to date since ARPANET invented?
usually traffic not measured as a number of bytes. a number of bytes per time period, yes
This article though... (Score:2)
And obfuscation can probably also hide their presence...
Re: (Score:2)
I'd be curious to see a graph showing UID posting for every, say, 10 accounts over the last few years. :)
Wouldn't it be nice (Score:2)
This November write in Snotnose for president, I promise to cut the NSA budget by 75% and redirect those funds to a TLA that will find the stuff that make
Re: (Score:3, Informative)
Even better, I'm old enough to be prez and don't think I have anything disqualifying me from being prez. Just change your vote from Deez Nutz to Snotnose.
It's not the firewall's job to fend of malware (Score:2)
Re: (Score:2)
The only thing a firewall should be doing is to detect and block (D)DoS-attacks and connections to and from ip on ports you don't want or you are sure you don't need, while allowing connections from other ip's and ports you actually do need.
But outbound connections to port 80 and 443 are guaranteed to be allowed in almost every environment, and an attacker can usually control the remote server, including on which port it listens and which protocol it speaks. And an attacker could also easily disguise communication as normal http or https traffic. In addition, a protocol has been created, standardized, and implemented in all modern browsers designed to work around the annoying port blocking restriction: websockets. So can we all stop pretending
It's not the encryption but the ad! (Score:2)
As usual, adblocking would have helped here. Encryption is not the answer, adblocking is!
Inspecting SSL/TLS encrypted Malware (Score:2)
Failure of OS design. (Score:2)
A process should not, by default, have access to any syscalls except self-termination. Likewise hardware virtualised operating systems. This should not just be within the OS itself, but within languages like Python and Javascript. Restricting what functions can be called to a minimum, and wrapping important ones in 'computational condoms' is something that, now we have LLVM to compile things on the fly, be considered mandatory. AOT compilation like on modern Android, combined with a well thought out API whe