Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Encryption Advertising Security The Internet Yahoo!

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.

This discussion has been archived. No new comments can be posted.

How SSL/TLS Encryption Hides Malware

Comments Filter:
  • 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?

    • 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.

    • by guruevi ( 827432 )

      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

      • by Bert64 ( 520050 )

        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...

    • by jandrese ( 485 )
      You can MITM your own connections for security, but be aware that a growing number of sites will break when you do this thanks to certificate pinning. My work does this and it causes all sorts of random problems with various sites and applications. Luckily no big major sites are affected yet, but it causes problems when trying to sign up for certain conferences and with license managers.
  • by NotInHere ( 3654617 ) on Saturday August 20, 2016 @08:41PM (#52740709)

    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).

  • by 0x000000 ( 841725 ) on Saturday August 20, 2016 @08:42PM (#52740717)

    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.

  • by BitterOak ( 537666 ) on Saturday August 20, 2016 @08:43PM (#52740723)
    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.
    • by bioteq ( 809524 )

      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

      • by E-Rock ( 84950 ) on Saturday August 20, 2016 @09:17PM (#52740853) Homepage

        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.

      • 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.

      • by Anonymous Coward

        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

        • 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.

        • 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

          • 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.

            • 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.

        • 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.)

      • 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?

    • 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

      • Some software attempts a compromise(Chrome's certificate pinning isn't applied [chromium.org] to certificates authenticated against a locally imported trusted root; but is otherwise); but anything that either refused to make exceptions or simply doesn't integrate with the platform's certificate handling very well should break SSL decryption with just certificate pinning.

        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
    • 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.

      • 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

        • United. Go look in Chrome under certificates? Surprise they are signed by the wifi company!

          • 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

          • 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.

    • by jaseuk ( 217780 )

      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.

    • 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)

    by Anonymous Coward on Saturday August 20, 2016 @09:00PM (#52740785)

    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.

  • by fuzzyfuzzyfungus ( 1223518 ) on Saturday August 20, 2016 @09:31PM (#52740889) Journal
    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?
    • 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.

    • by Anonymous Coward

      If you give people the ability to remove malware from your traffic, you give them the ability to censor it.

  • by QuietLagoon ( 813062 ) on Saturday August 20, 2016 @09:33PM (#52740897)
    If I want my firewall to protect me from malware hidden within TLS encryption, I'll allow that firewall to perform MITM attacks so that it can see my encrypted communications.

    .
    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)

      by Anonymous Coward

      This is one of those articles that is a part of the ongoing war against encryption.

      FTFY

  • 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... why don't we just outlaw encryption? Simple.

    • by Cylix ( 55374 )

      I was thinking the exact same thing! Only criminals use encryption.

      Normal citizens who uphold the law having nothing to hide.

    • by steak ( 145650 )

      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.

  • 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.
  • 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 make
    • Re: (Score:3, Informative)

      by Snotnose ( 212196 )
      It just hit me. Wouldn't it be funny as hell if Snotnose got enough write in votes that the news media had to report it, even though nobody knows who the hell I am? I'm sure it would take them all of a day to track me down, but I'd deny it and there are 4-5 other snotnoses out there so it would take them another day to be sure it's me.

      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.
  • 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
    • by Thiez ( 1281866 )

      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

  • As usual, adblocking would have helped here. Encryption is not the answer, adblocking is!

  • 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 whe

If you can't get your work done in the first 24 hours, work nights.

Working...