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

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Advertising Crime Electronic Frontier Foundation Encryption Security The Internet

Malvertising Campaign Used a Free Certificate From Let's Encrypt (csoonline.com) 123

itwbennett writes: On Wednesday, Trend Micro wrote that it discovered a cyberattack on Dec. 21 that was designed to install banking malware on computers. The cybercriminals had compromised a legitimate website and set up a subdomain that led to a server under their control, wrote Joseph Chen, a fraud researcher with Trend. The subdomain used an SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificate issued by Let's Encrypt, the first large-scale project to issue free digital certificates. which is run by the ISRG (Internet Security Research Group) and is backed by Mozilla, the Electronic Frontier Foundation, Cisco, and Akamai, among others. The incident has sparked disagreement over how to deal with such abuse, writes Jeremy Kirk.
This discussion has been archived. No new comments can be posted.

Malvertising Campaign Used a Free Certificate From Let's Encrypt

Comments Filter:
  • by Richard_at_work ( 517087 ) <richardprice@nospAM.gmail.com> on Thursday January 07, 2016 @10:43AM (#51255327)

    This style of attack would have been able to get an SSL cert from most cheap cert providers, as most of the cheap ones only require you to dump a particular file in the right place on the website for verification, so why the emphasis on "Lets Encrypt"? Because they are "cheaper than cheap"?

    • by QuietLagoon ( 813062 ) on Thursday January 07, 2016 @10:59AM (#51255435)
      The emphasis on Let's Encrypt is misplaced.

      .
      Unlike most other CA's, Let's Encrypt has a very short lifetime on their certs (60 days, I believe) so that an abused cert quickly falls out of the eco-system. I've read that Let's Encrypt eventually wants to shorten that lifetime even more, to 30 days.

      Most other CAs have cert lifetimes of a year (or longer). Then the question surfaces - how useful is cert revocation? Do all TLS clients check for cert revocation?

      • Re: (Score:3, Informative)

        by Anonymous Coward

        The lifetime at launch is actually 90 days (https://letsencrypt.org/2015/11/09/why-90-days.html)
        The rest is correct.

      • by Medievalist ( 16032 ) on Thursday January 07, 2016 @11:14AM (#51255545)

        Most other CAs have cert lifetimes of a year (or longer). Then the question surfaces - how useful is cert revocation? Do all TLS clients check for cert revocation?

        Most SSL/TLS clients do not check for a relevant CRL. The few that do (such as Firefox and other web browsers) typically require configuration and won't check for revocation by default out of the box.

        In contrast, nearly all SSL/TLS clients that I am aware of (certain MTAs being an exception) will refuse to use an expired certificate unless specifically instructed to do so by the end user. So expiration is more likely to have an effect than revocation.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          CRL's are of limited usefulness anyway. There is no guarantee that the attackee will be able to contact the CRL site and everyone defaults to trusting the revoked cert in this case.

          Posted AC to preserve mods

        • Most SSL/TLS clients do not check for a relevant CRL.

          And that's the important point in this case, revocation doesn't work so why bother? Other CAs go through the pretense (well, if enough pressure is put on them, typically via public shaming, mostly they ignore misuse of certs), while Lets Encrypt has made a sensible policy decision not to bother.

          A more amusing issue is the current discussion on one of the Mozilla lists about what to do about Kazakhstan's request to get their MITM CA cert included in the browser's list of trusted CAs.

      • 30 days, 60 days, 90 days, whatever. The average life span of a trojan before it gets detected even by MS Defender is 3 days, tops.

    • by mi ( 197448 )

      This style of attack would have been able to get an SSL cert from most cheap cert providers

      It used to be, one had to prove being "a legitimate business" to obtain an SSL certificate. But you are right, that proliferation of cheap — and therefore not caring — CAs has devalued it.

      Because they are "cheaper than cheap"?

      Yes. As long as some kind of payment is required, it is usually possible to identify the buyer. This possibility itself is a deterrent...

      I am all for the ability to remain anonymous,

      • ...Yes. As long as some kind of payment is required, it is usually possible to identify the buyer. This possibility itself is a deterrent... ...

        Bitcoin has changed that aspect of the algorithm.

        Additionally, more traditional pay methods have become so automated and inexpensive to use that it is quite easy to change payment methods on a frequent basis, effectively making tracing worthwhile only for the most egregious offenses.

      • by tepples ( 727027 )

        It used to be, one had to prove being "a legitimate business" to obtain an SSL certificate.

        True, TLS certificates were originally supposed to be organization-validated. But in the original model, how was the hobbyist operator of a web site supposed to protect passwords of the site's users from eavesdropping?

        • Re: (Score:3, Informative)

          by mi ( 197448 )

          But in the original model, how was the hobbyist operator of a web site supposed to protect passwords of the site's users from eavesdropping?

          The original model was meant to facilitate online commerce. Netscape invented SSL and was pushing it despite the opposition from IPsec proponents — because SSL-certificates were to provide assurance, that the remote end is a legitimate business. One may argue, the encryption aspect was secondary.

          If it is only a small part of data, that actually needs encryption

          • If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.

            What you describe is similar to what Tloz proposes in the question "How to replace SSL/TLS? [stackexchange.com]". But using client-side script to encrypt passwords has three drawbacks:

            • It breaks on machines whose owners have configured them not to run JavaScript. But perhaps people who refuse to enable JavaScript can be filed with the "web sites ought to be static and apps ought to be native" extremists.
            • It leaves the server hosting the script itself open to compromise by a man in the middle.
            • Once the password is set, an HTTP cookie is normally set to mark subsequent HTTP requests as authenticated. But this leaves the site open to a "Firesheep"-style session cookie cloning attack.
          • by DarkOx ( 621550 ) on Thursday January 07, 2016 @02:34PM (#51256969) Journal

            If it is only a small part of data, that actually needs encryption â" the password and the credit card number â" you can do that (using the well-known and studied protocols) in JavaScript.

            No you can't do that, no stop right right WRONG.

            The JavaScript itself must be delivered on a authenticated encrypted channel because if it isn't how will my browser know its not supposed to run that XMLHttpRequest call to post a second plan text copy of that info to evil-hacker.com after you main in the middle my amazon session in the coffee shop.

            Same goes with forms that are delivered over http but post https, this wrong and dangerous for the same reason. You can do authentication and encryption in the application layer if its a fat client and the client already has a static copy of trusted code form elsewhere but in the case of web site where the 'application' is being downloaded from the server the client needs a way authenticate and ensure transport integrity while obtaining the application itself otherwise its game over, your pwnd before you begin. The network layer is the correct place.

            • by mi ( 197448 )

              JavaScript itself must be delivered on a authenticated encrypted channel

              Yes, but this download can arrive from an SSL-using server run by a company big enough to actually have its certificate application properly validated. Think jquery.js.

              The question was not, whether SSL is needed at all, but how can a small operator secure logins without going through the extensive and expensive validation originally envisioned for SSL-certificates.

              • by DarkOx ( 621550 )

                No that does not solve the problem. Because if I am getting the main page over http, and I am the victim of an MITIM attack than the attacker can alter the page to source jquery.js from a site they control. Without or without SSL itself.

                Actually what you describe is worse! Unlike the more general situation where the attacker needs somehow needs to modify page content he does not probably know about ahead of time (assuming he just wants to get any access to my stuff not just a specific site) he got to do

                • by mi ( 197448 )

                  Well, you just described, why the whole ssh thing — which you download from somewhere to then run — is not secure... Is it?

                  I suppose, you trust the source of the ssh-distribution — you'd need a similar trust in the source of my hypothetical JS-library.

                  So no you really must authenticate the fist party site, or its game over.

                  ssh does not give you that either — not on the first connection. Unless the remote's fingerprint is published in a (secure) DNS. Khmm, maybe, that'd be the altern

          • Unfortunately, as Firesheep [wikipedia.org] demonstrated, any user authenticated (e.g. username/password) session over HTTP needs to be encrypted the entire duration. Switching between https and http is a security vulnerability.
          • If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.

            If... I personally would like to have everything encrypted, such as what I read on Slashdot or on Wikipedia.

            • by mi ( 197448 )

              I personally would like to have everything encrypted, such as what I read on Slashdot or on Wikipedia.

              IPSec was supposed to do that. But appearance of SSL nipped IPSec' spread in the bud. And the revanche attempts by IPv6 [infosecisland.com] are so far faltering.

      • by Anonymous Coward
        That's true; nobody really minds Anonymous Coward, but Anonymous Criminal is another story, as is Anonymous A-hole.
      • by darkain ( 749283 )

        "CAs has devalued it"

        The values have shifted, not become less. The value used to be in verification of business. Now, partly thanks to the NSA, the value is more in encrypting all possible web traffic. There are enough major organizations that all collectively agree that encryption is more valuable than the bottom line at this point that Let's Encrypt can give out certs for free.

      • by Anonymous Coward

        The certificate in question was used to distribute banking malware. I doubt its creators would have any qualms with using a stolen payment method.

      • by Bengie ( 1121981 )
        The point of certs is not to blindly trust a cert because someone has one, it's to trust the cert is the cert it claims to be. The North Korea government could have a cert for all I care, but I'm not going to trust their site, even if I trust their cert.
    • by Anonymous Coward

      Perhaps it's because Trend Micro sells certs...

      • Or maybe they sell web security software that relies on unencrypted HTTP connections to detect malware.

    • by Anonymous Coward

      Primarily because the for-profit CAs would simply revoke a certificate that was issued fraudulently. From the Trend Micro blog:

      In this particular case, the attackers created ad.{legitimate domain}.com under the legitimate site.

      I don't really follow Lets Encrypt's logic here of why they won't revoke the certificate. It seems their only argument is that "there's other ways to deal with the problem". Which is true, but I don't see why taking multiple approaches isn't a good idea.

      If the certificate had been

      • Re: (Score:2, Informative)

        by Anonymous Coward

        The cert wasn't issued fraudulently. The domain validation is totally legit seeing as the attackers had control of the domain.

    • by Anonymous Coward

      " so why the emphasis on "Lets Encrypt?"

      Cheap shot at a competitor, nothing more.

    • The certificates from Lets Encrypt (and other commonly used cheap providers) are "domain validated", which is the lowest rung of site certificate. These are perfectly okay for everyday use on Internet sites that don't process highly sensitive data.

      The best consumers can do is demand extended validation certificates for their banking sites, and each time you connect to your bank's site verify you are using an EV certificate.

    • The emphasis on Lets Encrypt is likely because that way Trend Micro will get more visibility for "the new thing is bad". Trying to say "the old thing is bad" mostly causes yawns though it is a known problem.

      So simply: marketing.

    • by Bert64 ( 520050 )

      Or this style of attack could be performed by using an SSL cert that was already present on the hacked server...

  • Inevitable (Score:4, Interesting)

    by The-Ixian ( 168184 ) on Thursday January 07, 2016 @10:49AM (#51255377)

    I think that one way to deal with this would be in the browser.

    Currently, EV certs will turn the address bar green or have some other indication above and beyond the normal "lock" icon.

    Perhaps we need to have a different color or indication for each kind of cert.

    Also, perhaps have a warning in the browser if the last known certificate is from a different CA and/or has a different validation level from the certificate currently being presented by the same domain.

    Other than that, I am not sure what could be done on the server side of things. The system is meant to be free and open... which, by definition, means it is going to be abused.

    • by Aaden42 ( 198257 )

      Given the number of users who can be fooled into thinking a site is "secure" just by having an image of a key appearing somewhere on the page (not the browser chrome, but actually in the HTML of the site), what's the point of adding more chrome?

      I doubt most users are capable of understanding the concept of chain of trust nor levels of verification behind different certificates. I'm positive that capabilities aside, the vast majority don't want to learn the difference and willfully avoid learning.

    • Are you the same guy who invented the five-color terror alert scale and no one knows what the different colors mean?

      We have a puce alert in the browser bar!

    • How would you suggest breaking down the different types of certificates to assign them a security level? By the price of the certificate? By the rigour of the verification?

      Technically there's no difference between a $0 Lets Encrypt cert, a $5 SSLs.com cert or a $250 Symantec cert - they are all basic SSL certificates and all use similar methods for domain verification (either put a named file in the root of your website, add a particular DNS entry to your domain or reply to email sent to webmaster@ postmast

    • by AmiMoJo ( 196126 )

      The UI is wrong. Secure should be the default, what we want is to indicate insecurity. Normal HTTPS connections should be white, and unencrypted HTTP red. Reserve green for enhanced certs.

  • Great Response (Score:5, Informative)

    by Anonymous Coward on Thursday January 07, 2016 @11:00AM (#51255443)

    This article looks like a really good response to the issue: https://unmitigatedrisk.com/?p=552

  • by wbr1 ( 2538558 ) on Thursday January 07, 2016 @11:02AM (#51255463)
    The ISRG is both right and wrong. CAs cannot respond fast enough and likely do not have enough information to vet requests for new certificates fully. However, once a cert is used in bad faith it should be revoked.

    The ad brokers do not care that bad ads slipped in as they make money on any, so they have zero incentive to remove malvertising other than a cursory effort to appease the lawyers and government.

    This is why I install adblocks on all customer machines now (and we process a large amount). To an end user advertising of of limited utility, and comes with at minimum high annoyance and at worst malware/fraud/id theft.

    Case in point, I was trying to find news information on a police standoff near my house, and one of the official local news stations ads were targeting nexus 6 with a scam 'free iPad' redirect. This only occurred on my Nexus 6, not a PC or LG phone. This is just normal day to day browsing, and I could not even read the news.

    The state of affairs when it comes to online advertising and scams is very bad and will kill the industry very soon if changes are not made. Unfortunately it will likely bring down many good sites for real content with it.

    • "CAs cannot respond fast enough and likely do not have enough information to vet requests for new certificates fully."

      They used to. The problem is not that they can't, the problem is that they learned that the end user neither understands nor cares for proper verification, so why they should pay care when that means less business and higher costs?

    • Any sane ad-broker has a very good reason to care about malvertising and to put a lot of resource into filtering it out - and you identify it in your own post.

      The rise in malvertising is serving as a huge driver for the use of adblockers. Moreover, while early adoption of adblockers was mostly by well-informed home and small-business users, the rise of malvertising means that major corporate and Government networks are increasingly switching to adblock-by-default. Which in turn means that a lot of less-info

    • ...The state of affairs when it comes to online advertising and scams is very bad and will kill the industry very soon if changes are not made. ...

      Exactly correct.

      .
      The whole online advertising technical model is little more than an unfettered and insecure conduit deep into the personal ecosystem of people on the Internet.

      The system was developed and is run by people who are more concerned about the number of hits an ad gets than about the security of the person's device into which they have intruded.

  • The Java browser plugin infected millions, loaded bloatware, and generally has been a nuisance for years.

    It eventually was blacklisted [infoworld.com] from [skillsoft.com] browsers [mozilla.org].

    Let's not pretend SSL certs were supposed to do things they're not. You can be certain no one is imitating the malware site. And that's all a SSL cert means.

  • by Anonymous Coward

    Why the hell do ads need to be able to run arbitrary 3rd party scripts? Give them an image, some text, etc. and they stick it in their ad format. There's no reason to let random people on the internet inject scripts from totallynotmalwarenoreally.ru into ads on the New York Times' site.

    • Why the hell do ads need to be able to run arbitrary 3rd party scripts? Give them an image, some text, etc. and they stick it in their ad format.

      Because only scripts can animate "an image" and "some text" on a <canvas> element. Ideally, the advertiser would author the animation and export a set of data that represents keyframes, and a publicly auditable script hosted by the ad network would use this data to present the animation. But to my knowledge, there is as of yet no such standardized format to represent canvas animations.

      • I think you and the parent post each have a point. 3rd party scripting is being badly abused on the web today and needs to be reigned in somehow. The CA system is broken, especially where revocation is concerned. DNS needs to be more secure than it is today. Browsers need to be better at showing the level of trust in a site, in particular, the case when a cert is good for privacy encryption but not so much for authentication. Error messages from deeply embedded third party sites don't make their way to
  • I don't see why this is news at all. Let's Encrypt is a great way to allow any webmaster to offer a TLS-protected connection between his users and his server.

    As a user, seeing a website using a Let's Encrypt or StartSSL certificate does not tell me anything about the legitimacy of that website. All it does is guarantee that my connection won't be intercepted through a MITM attack. Personally, I never "just trust" the little lock icon in my address bar: I click it and see who signed it. Then I make a decis
    • I never "just trust" the little lock icon in my address bar: I click it and see who signed it.

      That's one of the reasons I use TLSA on my website. It provides another check to the validity of my cert for those people who bother to validate it via TLSA/DANE.

    • 99.99% of internet users are not like you. They do not understand, nor do they care about, how TLS and certificate authorities work. If they see a little lock in their address bar then they are "safe" as far as they are concerned. To most people a StartSSL cert is exactly the same as an EV cert used by a banking site. The fact that one creates a green address bar or whatever and the other does not is totally lost on them and makes no difference. Granted this is a problem. But I don't think it is one that c
      • 99.99% is too generous a number. Stretch out those 9s a bit more

  • by EndlessNameless ( 673105 ) on Thursday January 07, 2016 @11:20AM (#51255573)

    If they were able to create a subdomain, that means the attackers controlled all traffic to that subdomain.

    Since most certificate authorities only verify via email to the domain for which the certificate is requested, the attackers would have gotten a certificate from virtually any CA.

    There are additional verification steps required for EV certificates that should thwart this sort of attack, but singling out Let's Encrypt for issuing a certificate in this case is disingenuous.

    The real problem lies with the DNS registrar that accepted an unauthorized subdomain registration request. (Or maybe the client's account was compromised, in which case the victim is to blame.)

    Either way, the submission titles makes it seem this is a problem with Let's Encrypt when it most certainly is not.

    • I just snapped up a yubikey 4 nano and was curious if anyone understands them or more specifically if using a yubikey will give one "bombproof" secure logins etc.? With these as they are so poorly protected here on the interwebs and dont forget to toss in the cellular carriers, which are nothing more than glorified internet servers, it seems just a matter of time until ALL your most secret passwords are compromised. Something I do not look forward to. I installed the LastPass addon because it said it was se
    • There are also dramatically increased costs for EV certs and EV certs prevent anonymity.

      CERTs are to ensure I'm talking to the domain I believe I am and that said communication is protected from other parties. Whether or not talking to that domain in the first place is a good idea is out of scope.
      • by tepples ( 727027 )

        Whether or not talking to that domain in the first place is a good idea is out of scope.

        Detractors of domain-validated certificates disagree with this statement on grounds that most non-technical users won't notice the typo in "BankOfArnerica.com".

    • by Anonymous Coward

      I don't think you understand how domains or DNS works... you don't register a sub-domain. You create a sub-domain via an NS record in DNS. That's it. No registration required.

  • CA's have no business judging the validity of content. A cert indicates no more or less than that the content came from the person you think it came from. Malware/spyware/hacking tools are subjective concepts.

    Fighting hacking/spam is the duty of police enforcement according to local law not CA's and technical companies. What next, a CA base in China or Russia refusing to grant "gays" certs for their sites as immoral? There is no line, everything is over the line, a CA should exercise zero discretion with re
  • Firstly, the attackers here had enough control to alter the site's DNS data. If they've got that much control, likely they also have access to the SSL private keys for the site. Even if they don't, they've enough control that they can do anything they want anyway by using subdirectories on existing servers. So, any changes Let's Encrypt might make still won't protect against this attack. SSL server certificates insure you're talking to the host you think you're talking to, they say nothing about whether tha

    • by guruevi ( 827432 )

      They already do confirm you have control over the domain. The only difference is that it's (as good as) fully automated through the ACME protocol. You can verify it by hosting a website on that domain, you can verify it by sending an e-mail to the domain. Any other CA (even VeriSign) does the same thing unless it's StartSSL or an EV domain for which you have to actually submit paperwork that you are the business owner.

      • StartSSL does domain verification by sending e-mail to an administrative address (pulled from WHOIS data) (for their Class 1 certificates anyway).

        • by guruevi ( 827432 )

          The 'free' SSL certificates, yes, but I don't think you can use them for business. Their 'verified' SSL certificates require paperwork.

    • Lets encrypt does the checks for control of domain like the other certificate authorities.

      And really people should use DNS Certification Authority Authorization(RFC 6844) to only allow the certificate authorities they want to use. Though I am not sure if all certificate authorities follow it yet, but at least most do so it is risk mitigation.

  • There's a difference between privacy and trust, but browsers don't make that clear to the user in a consistent or even useful matter. That said, nothing will ever completely fix a layer 0 issue except education.

  • Just because the bar is green does not mean it is safe. Everyone wanted to run from self-singed certificates because it prompted the user with a warning. You know what? That weird ass name on the cert also helps verify where it comes from. Instead we replaced certificates and trained people to look for a lock that was already easy to spoof.
  • DNS (Score:4, Insightful)

    by Stephen Chadfield ( 7971 ) on Thursday January 07, 2016 @08:49PM (#51259377) Homepage

    This is just ridiculous. The problem here is that the attacker was able to create a new DNS sub-domain. The Let's Encrypt angle is just a red herring from a company (Trend Micro) that wants to make money selling SSL certificates.

  • If your company offers free/cheap certs that he hackers are using; then we blacklist those providers. It's not fair to them; but it's not fair to us to have to worry about this crap either. It's why I run ad-blocking; not because I hate ads; but most drive-by infections come from ad networks that don't care enough to not sell malicious ad space. I'm not infecting my computer because some web developer needs to make a little money. If you have zero integrity; then you get zero respect. I'm already starting

"Spock, did you see the looks on their faces?" "Yes, Captain, a sort of vacant contentment."

Working...