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

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.

Comments

Why the emphasis on Lets Encrypt?

[Richard_at_work]

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

Re:Why the emphasis on Lets Encrypt?

[QuietLagoon]

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:Why the emphasis on Lets Encrypt?

[Anonymous Coward]

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

Re:Why the emphasis on Lets Encrypt?

[Medievalist]

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:Why the emphasis on Lets Encrypt?

[QuietLagoon]

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

Re:Why the emphasis on Lets Encrypt?

[mi]

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 — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.

Re:Why the emphasis on Lets Encrypt?

[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

Re:Why the emphasis on Lets Encrypt?

[darkain]

They HAVE automated revoking of certs. The revoking happens by the owner of the cert though (in this case, the attacker). How would you automate the process of revoking otherwise, especially in a way that doesn't cause false positives which would render websites unreachable by clients?

Re:Why the emphasis on Lets Encrypt?

[darkain]

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

Re:Why the emphasis on Lets Encrypt?

[DarkOx]

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.

Re:Why the emphasis on Lets Encrypt?

[mars-nl]

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.

Re:Why the emphasis on Lets Encrypt?

[Anonymous Coward]

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

Inevitable

[The-Ixian]

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.

Great Response

[Anonymous Coward]

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

Why we cannot have nice things..

[wbr1]

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.

Re:Why we cannot have nice things..

[chefmonkey]

To be approved for inclusion in pretty much any reputable application, a CA has to conform to the requirements laid out by the CA/Browser forum; see https://cabforum.org/wp-conten... -- you'll note that Section 9.6.3, bullet 5 requires the ability for the domain holder to request revocation. Let's Encrypt conforms to these requirements. While ACME requires specific authentication material to perform automatic revocation, there's a manual process in place.

From https://letsencrypt.org/reposi... : "To report private key compromise, certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to certificates, please email cert-prob-reports@letsencrypt.org."

Basically, all LE's policy says is "We're not going to make a unilateral decision about whether the content someone is hosting on their own domain is legitimate, for that way lies madness. If a domain owner needs a cert revoked, and they can't use the automated tools to revoke it, they need to send an email, and we'll take care of it as soon as we can verify that they're the rightful owner of the domain."

I'm not sure it gets much more reasonable than that.

Malvertising is a trivially solvable problem

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

Let's Encrypt is only for encryption

[Kid CUDA]

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 decision on whether or not I trust that website with my information.

Re:Let's Encrypt is only for encryption

[WhiteKnight07]

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 can be solved via technical means. Lets face it. Most people just don't know enough about how the internet works to be able to use it safely.

Applies to All Non-EV Certificates

[EndlessNameless]

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.

Re:Changes won't fix the problem, but still good i

[guruevi]

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.

NoScript, MITM of the crypto script, and Firesheep

[tepples]

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

Why not just teach your people

[fsckinhippies]

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

[Stephen Chadfield]

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.