Let’s Encrypt Now Being Abused by Malvertisers

http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/

by Radi • 11 years ago

86 69 11 years ago

blog.trendmicro.com

There are peolpe that are really suprised? This was expected.

ponytech• 11 years ago

IMO the problem is more "attackers who have gained the ability to create subdomains under a legitimate domain" (not explained how) than Let's Encrypt.

qopp• 11 years ago

There are sites that do this as part of their core ui, such as deviantart.

alexpeattie• 11 years ago

Yes, although the subdomains still point to deviantart's servers. The difference here is that ad.example.com ends up pointing to the attacker's server.

Because LetsEncrypt needs a very specific response to be served from a specific endpoint, you need this kind of total control to validate a domain and get a certificate issued.

rmhrisk3• 11 years ago

see: https://publicsuffix.org/

nulagrithom• 11 years ago

https://letsencrypt.org/howitworks/technology/#domain-valida...

There's a bit more to it than "allowing subdomain creation". You will need control over the DNS records, or ability arbitrarily change the page (essentially).

eugeneionesco• 11 years ago

This is not an issue, just FUD from Trend Micro.

aftbit• 11 years ago

Let’s Encrypt only checks domains that it issues against the Google safe browsing API; in addition, they have stated that they do not believe CAs should act as a content filter. Security on the infrastructure is only possible when all critical players – browsers, CAs, and anti-virus companies – play an active role in weeding out bad actors.

I agree strongly with Let's Encrypt's view. They should not be responsible for policing the behaviour of their certificate users. They should just ensure that they only issue certificates for validated CNs.

chinathrow• 11 years ago

> in addition, they have stated that they do not believe CAs should act as a content filter.

Isn't that what they exactly do when they check the safe browsing API?

zamalek2• 11 years ago

There is a way to avoid this issue: Let's Encrypt should disallow subdomain registrations unless a TXT record is present for the parent domain. For example, if I wanted to get a certificate for bar.foo.example.com there would need to be a Let's Encrypt TXT record for foo.example.com.

Although it's not their responsibility, they can take steps to mitigate it.

eridius3• 11 years ago

Why is this something they should do? If I have complete control over a subdomain bar.foo.example.com, why do I need cooperation from the parent foo.example.com in order to set up something basic like an SSL certificate?

nippoo• 11 years ago

Or perhaps do it the other way around? Make a Let's Encrypt subdomain-blacklisting TXT record with which the parent domain could indicate that they don't want subdomain owners to be able to create their own SSL certificates. (Useful in the case of hosted web services, for example, where the parent already owns a wildcard certificate so there's no reason for the subdomain to create one)

tracker1• 11 years ago

In this case someone got a legitimate subdomain A record in DNS... your solution would not add much to the situation.

jvdh• 11 years ago

Exactly, their statement has been made in October already: https://letsencrypt.org/2015/10/29/phishing-and-malware.html

That statement did not contain anything on other kinds of reports. They do have an email address for reporting certificate abuse. So far, I have not been able to find any public statements on how they will handle that.

cm2187• 11 years ago

In fact it's not more of an abuse of let's encrypt than it is an abuse of the linux, apache and openssl used to host these malicious websites. All of which are doing their job. The domain owner is the one not doing his.

droopybuns• 11 years ago

Encrypting everything has consequences.

I recently had an IoT pairing issue between two devices. A normal human will not run wireshark to troubleshoot a pairing failure between two devices. I did. I was rewarded with a shitty protocol that could not be evaluated for errors and a moderated support forum that encouraged me to reboot my router.

Taken to its extreme conclusion- there are important networking problems that are amplified if we encrypt all the packets.

Sometimes, I feel like the EFF is composed of idealistic teenagers with limited understanding of how the world outside of their first hop works. I generally support them, but it is always at arms length.

sametmax• 11 years ago

And buckling up your seat belt has consquences. You cannot danse the way you used to on your seat and 1 time out 1000, it actually makes the accident more violent.

Still, you should use the seat belt. All the time.

userbinator3• 11 years ago

That's what MITM proxies are for... but I do agree that devices with encrypted traffic, without any means of its owner inspecting it, can be a significant threat.

pjc50• 11 years ago

Of course, not encrypting and authenticating between the devices lets any other compromised device on your network interpose itself in that pairing and do whatever it likes with your IoT devices.

Buge• 11 years ago

There were already free automatically-validated CAs before Let's Encrypt.

Animats2• 11 years ago

As a CA, Let's Encrypt should only be issuing certs to second level domains. If they want to issue one to a subdomain below that, there should be a check that the second level domain approves.

roblabla• 11 years ago

What about <somedomain>.co.uk ? Or the various other TLD that are 2-level deep already ? I believe it's impossible to implement this properly.

nitrogen• 11 years ago

There's a huge suffix list that browsers use to control things like cookie scope:

https://en.wikipedia.org/wiki/Public_Suffix_List

https://publicsuffix.org/

Probably includes https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...

pdkl952• 11 years ago

While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago.

One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone.

If you bought example.com, you can create DNS records like

    subdomin.example.com. 172800 IN NS ns1.example.com

to indicate that ns1.example.com is the authority for the entire subdomain.example.com zone. This includes all further nesting of .subdomain.example.com.

Instead of guessing* who is responsible for a zone, you should simply ask the nearest upstream zone authority.

Also, relying on lists is almost always the wrong solution - if your security requires you to successfully enumerate something, you are doing it wrong. ( http://www.ranum.com/security/computer_security/editorials/d... )

joshmoz• 11 years ago

Here is a more complete explanation of Let's Encrypt's views on the subject.

https://letsencrypt.org/2015/10/29/phishing-and-malware.html

rmhrisk3• 11 years ago

My post responding to this - https://unmitigatedrisk.com/?p=552

tremon2• 11 years ago

Thanks for that response. It is well-written and transparently constructed. That said, you're reading quite a bit more agenda and polemic in TrendMicro's post than I did. Possibly because you've seen this kind of post before :)

If you can allow me a bit of proofreading, there are a few typo's in the article:

[..] that said it is can be summarized as: -> lose the "is"

Maybe the then the issue is -> lose the first "the"

It had nothing to do with SSL, the attacker had full control of a subdomain and the attack would have still worked without it. -> The final "it" should presumably refer to SSL, but in this construct it refers to "control".

I say “could” because in that not everyone is aware of -> lose "in that" ?

Until all CAs are required to log all of the SSL certificates they issue into CT Logs and add are required to CAA -> Not sure of your intent here. "And CAA records are required before requesting certs"?

Also, your quotes from the original article render for me (in firefox) as single-line textboxes with scrollbars. Maybe you can change it to force automatic wrapping?

rmhrisk3• 11 years ago

thanks, fixed everything but the quotes.

breakingcups• 11 years ago

Title should read "Let’s Encrypt Now Being Used by Malvertisers"

If someone gains access to a subdomain and is able to place files there, THAT is the problem, not being able to request a certificate for it.

To quote both Ford and Raymond Chen: "It rather involved being on the other side of this airtight hatchway"

staunch• 11 years ago

In their attempt at shaming Let's Encrypt, only Trend Micro has been shamed.

ars• 11 years ago

I'm unclear about what the problem is.

So the traffic is encrypted. How does that make anything worse?

It seems pretty irrelevant to me if it's encrypted or not.

MrSwagga• 11 years ago

Maybe because it can't be automatically detected by some layer 7 firewall filters/web proxies.

userbinator3• 11 years ago

Although some seem a bit squeamish about it, any good firewall/filtering solution should do SSL MITM --- especially now that encrypted connections are becoming the norm.

Given that Trend Micro themselves provide AV software that does this, it's particularly ironic since it's already no problem for them to decrypt and scan encrypted traffic. It's likely just their CA division that dislikes Let's Encrypt.

lini• 11 years ago

Not 100% sure, but if the malicious ad is put on an HTTPS page, it would not be possible to load additional scripts and data from an un-encrypted (HTTP) location as opposed to another valid HTTPS location. Having your malware on an HTTPS site goes around the browser's mixed content restrictions.

corobo2• 11 years ago

You could just as easily register a separate domain and use HTTPS on that if your goal is to inject scripts in the background. The "problem" being reported here is that the user may think the site is not going to send them malware because it has a green padlock in the address bar

erostrate• 11 years ago

Indeed, trendmicro doesnt say anything about that. Let's Encrypt says "The concern most commonly expressed is that having valid HTTPS certificates helps these sites look more legitimate, making people more likely to trust them." I agree with Let's Encrypt position, they are not to blame here.

https://letsencrypt.org/2015/10/29/phishing-and-malware.html

pluma2• 11 years ago

Exactly. This false notion of security was perpetuated by CAs for marketing purposes. It's their fault if users now mistakenly think HTTPS == trustworthy.

They basically sold certs as something they're not and now complain that people may realize they don't actually serve that purpose now that they're made widely available without the false pretences.

supermatt4• 11 years ago

I havent used Lets Encrypt, but other CAs would validate the owner of the TLD by sending an email to hostmaster. You wouldnt be able to have certificates issued on a subdomain unless you are verified as owner of the TLD. Is this not the case here, and if not, why not?

pfg7• 11 years ago

This is one of many verification mechanisms other CAs offer. A lot of them also offer verification via DNS TXT record, or by placing a file under a certain path and verifying it's being served via HTTP. Let's Encrypt is definitely not the first to offer any of those, and they are in line with the CA/B Baseline Requirements under which CAs operate.

supermatt4• 11 years ago

DNS TXT records I can also agree with, as its as secure as email in the respect that it uses the same potential vector for spoofing.

File verification (which I haven't seen as an option with the multiple CAs I have used) is an alternate vector. It may be in line with the CA/B Baseline Requirements, but by removing this they would likely eliminate this threat.

This is a serious problem

p.s. I note that this "content change" verification mechanism is mentioned as point 6 under 3.2.2.4 of the Baseline requirements. It is entirely feasible that when these documents were written this particular issue wasn't considered. How would one go about repealing this particular point, and thus forcing CAs to comply.

zecg• 11 years ago

In other news, guns are used to kill people.

pdkl952• 11 years ago

gained the ability to create subdomains under a legitimate domain

As lots of people in this thread have already pointed out, that's the security problem. The DNS zone that was delegated to you, then you have a responsibility to keep the "squatters" away.

Traffic to this created subdomain was protected with HTTPS

Good. HTTP is obsolete. That doesn't change anything from the perspective of the victim.

an open DoubleClick redirect

Which is yet another example of how irresponsible advertisers are creating huge attack surfaces.

From the blog they link to:

    bid.g.doubleclick.net/xbbe/creative/click?r1=<malicious urlencoded URL>

It sounds like doubleclick is sending out the harmful redirect. Maybe they should verify URLs instead of blindly believing the query params?

    "msxml.domdocument"

LOL

These DV certificates can help the hacker gain legitimacy with the public.

How? "The public" probably doesn't even know what a DV certificate is.

It doesn't look like Let's Encrypt is even involved in any of the actual problems that enable this attack.

As a certificate authority ourselves

... I guess that explains this hit piece ... /sigh/

jmuguy• 11 years ago

As evidenced by the comments here, the people that count, that is system admins and developers, don't see a problem. Just more FUD from the traditional security players trying to remain relevant.

solidninja• 11 years ago

I finally created a HN account just to say the same thing. The security problem is that of the website itself and its choices of advertisers, not of the CA.

Sujan• 11 years ago

> These DV certificates can help the hacker gain legitimacy with the public.
How?

By the lock displayed in the browser that couldn't be there for free that easy before.

cynix• 11 years ago

StartSSL.

userbinator3• 11 years ago

As a certificate authority ourselves

That says it all, really. This isn't the first time other CAs have attempted to stop LE:

https://news.ycombinator.com/item?id=10685458

Sephr• 11 years ago

I don't understand. How is it being "abused"? If the attacker has actual DNS access to create ad.{legitimate domain}.com, then Let's Encrypt is working as intended. So what if they're hosting malware—that's {legitimate domain}.com's problem.

Let's Encrypt has absolutely nothing to do with content behavior safety, only domain validation and encryption to keep data away from prying eyes.

This title is no different from "Chairs Now Being Abused by Criminals". It's nonsensical and completely unrelated. Do you care that criminals have started using chairs to sit down (gasp)? I don't think this even belongs on Hacker News.

pluma2• 11 years ago

As a certificate authority ourselves

This pretty much invalidates the entire argument. TLS is not about making things look more legitimate. If anything, CLAs are to blame for marketing TLS as something it's not.

Let's Encrypt is doing the right thing here, Trendmicro is part of the problem.

ycmbntrthrwaway• 11 years ago

I needed to create valid HTTPS certificate once, as a project to setup MITM proxy and test various applications verification of domain. I just created an account on https://www.startssl.com/ with totally fake identity, found some place to register a free domain and got a certificate at zero cost within a few hours. Maybe Let's Encrypt makes it easier to automate, maybe they need to add a CAPTCHA (what for?), but the possibility of creating valid HTTPS certificates for malicious uses was already there.

Banks and employers should just teach users to look for green icon near the URL, not just a padlock.

Let’s Encrypt Now Being Abused by Malvertisers

Related Stories