Slashdot Mirror
How SSL/TLS Encryption Hides Malware (cso.com.au)
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.
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?
The malicious yahoo ad used the angler exploit kit. 75% of the exploits used by angler are flash exploits: http://www.talosintelligence.c...
Just don't install flash per default, and require exceptions for people who need it for their job (hopefully a small amount).
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.
cat
Thanks to SSL I can connect to an unencrypted WiFi, and be mostly safe.
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.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
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.
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?
.
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.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Well then... why don't we just outlaw encryption? Simple.
I talked about this at the Atlantic Security Conference back in April. It's a real problem. NGFW's are doomed to fail. Even the Fortinet techs agree.
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 certs. That way you can have your root locked up in a safe deposit box, since you never use it except once every few years.
I suppose buying does mean you don't have to install your root on new machines when you get them.
Any way to obtain a cert, for my network only, to authenticate my hosts and clients ... before going out on that damn internet?
That's called IEEE 802.1x. It's commonly used in corporate networks. You can set the router to allow no access until authenticated, or only allow them access to whatever resources are appropriate pre-auth.
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
And obfuscation can probably also hide their presence...
if we had a TLA agency with a billion dollar budget that could seek out, explore strange new software platforms and new exploits, to boldly go where no hacker has gone before. And then tell the vendors where the damned holes are so they could get patched, instead of sitting on them so they can attack someone else when they get their panties in a bunch.
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 makes us insecure, and tell the damned vendors about them so we're all, not just USA citizens, but world citizens, safer. And, if the vendors don't fix the holes in a timely fashion, my new TLA has a hotline to the DOJ to light a fire under their complacent asses.
While I'm at it I'll go after the pharma Cxx's that are profiting off Epi-pens and generic drugs. You wanna get rich at the expense of my health? You get to go to jail, where the only medication you get is generic stuff that you have to pay for with your $0.10/hour wage folding laundry. Only pharma Cxx's have to pay, regular inmates get their drugs for however they pay for them now.
If you are using a firewall to defeat malware you are just plainly doing things wrong. 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. If you really need to analyse all the traffic in your network, install your own root-CA in the endpoints and just MITM everything which needs to be on there. But you should seriously consider the implications of what you are doing, because you are basically circumventing everything that groups of people way smarter then you have been putting in place for decades.
As usual, adblocking would have helped here. Encryption is not the answer, adblocking is!
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?
Watch this Heartland Institute video
Such malware is only a problem if you use Microsoft Windows on the client desktop. Besides by facilitating what is basically a man-in-the-middle attack in order to examine SSL/TLS traffic entering the organization, you're opening up your company to the hackers.
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 where what part has access to what is, to me, where to go. Your program comes in in LLVM bitcode, with special permission required to run binaries (esp. outside a VM), and based on information as to what syscalls are needed, a custom syscall interface is compiled on the fly, folliwing ideas such as in synthesis os, though for security rather than speed. Importantly, you want a non Turing complete layer in there somewhere.
John_Chalisque
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.
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 which is trusted for all domains and is loaded (by policies etc) in to the load browsers. E.G. a cert which applies for *.com; *.net; etc etc. Outgoing SSL actually connects to the appliance which has the master key for the non-legit cert, which basically performs a MITM and then proxies the SSH connection to the outside site. You have to have some pretty strict policies and browser-restrictions to really make this work, and frankly it has some pretty ugly privacy violations because it's faking out *all* SSL from potential attack sites to your employees' medical provider.