Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Encrypt Now Being Abused by Malvertisers

blog.trendmicro.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Let’s Encrypt Now Being Abused by Malvertisers

#41

Post by nippoo »

zamalek wrote: post #20
aftbit wrote: post #5

>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 f…

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.

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)

Re: Let’s Encrypt Now Being Abused by Malvertisers

#42

Post by pfg »

supermatt wrote: post #37
pfg wrote: post #31

Earlier quoted context omitted.

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.

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 c…

WoSign is one of the other CAs offering this option.

It is unclear to me how TXT verification would have prevent this. The article indicates that the attackers created the subdomain and pointed it at a server they controlled; this means DNS was compromised and creating a TXT record wouldn't have been a problem.

Domain owners which are worried about Let's Encrypt can opt to create a CAA DNS record that limits CAs allowed to issue certificates to ones they trust.

CA/B BR can be found here[1].

[1]: https://cabforum.org/wp-content/uploads/Baseline_Requirement...

Re: Let’s Encrypt Now Being Abused by Malvertisers

#43

Post by pluma »

erostrate wrote: post #26
ars wrote: post #13

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.

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

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.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#44

Post by pfg »

nippoo wrote: post #41
zamalek wrote: post #20

Earlier quoted context omitted.

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.

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)

This is already possible using CAA DNS records, which can be used to define which CAs should be permitted to issue certificates for a domain.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#45

Post by zamalek »

eridius wrote: post #27
zamalek wrote: post #20

Earlier quoted context omitted.

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.

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?

Because this happened:

> Website owners should ensure that they secure their own website control panels, to ensure that new subdomains beyond their control are not created without their knowledge.

You're a bank and haven't secured your DNS control panel correctly. Someone comes along, and using your vulnerable DNS, registers logon.bank.com (instead of login.bank.com). Now it is the bank's fault to begin with, but end-users are going to see that green padlock and will get pwned. You can point fingers all you want at the bank but that situation could (and should) have been avoided.

Let's Encrypt could be seen as a "vulnerability amplifier." With the previous PKI, even if you gained authority over logon.bank.com you wouldn't be able to get that green padlock in the title bar. There is a very good chance that someone at the CA would have made a phone call to someone at bank.com. With the current Let's Encrypt approach this scenario becomes plausible because no check is made with the parent domain to find out exactly how paranoid it is about subdomains.

Nobody is blaming Let's Encrypt, but they can help.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#46

Post by simoncion »

Ao7bei3s wrote: post #38
eridius wrote: post #27

Earlier quoted context omitted.

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?

Because A records don't mean complete control over domains. There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". DNS domain validation is the right way to do domain validation. But it's slightly harder for users, which is why HTTP(s)- or E-Mail-based validation is being done more often.

> There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)".

Agreed. However, I have a hard time believing that it's a net win to make it impossible for people who are permitted to control the machines that a DNS record points to, but are not permitted to alter that DNS record and/or anything under it [0] to get a cert from Let's Encypt.

[0] Or are -perhaps- using a DNS hosting provider that doesn't let you add TXT or CNAME records. (I've used such a sorry provider in the past. :/ )

Re: Let’s Encrypt Now Being Abused by Malvertisers

#47

Post by corobo »

Ao7bei3s wrote: post #38
eridius wrote: post #27

Earlier quoted context omitted.

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?

Because A records don't mean complete control over domains. There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)". DNS domain validation is the right way to do domain validation. But it's slightly harder for users, which is why HTTP(s)- or E-Mail-based validation is being done more often.

I can serve using HTTP on this domain should be enough to prove you can also serve HTTPS on this domain though.

It's on the domain owner to avoid giving away control of their (sub)domain to a malicious party. Exactly the same as with regular HTTP and anything else that uses DNS.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#48

Post by pfg »

zamalek wrote: post #45
eridius wrote: post #27

Earlier quoted context omitted.

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?

Because this happened: > Website owners should ensure that they secure their own website control panels, to ensure that new subdomains beyond their control are not created without their knowledge. You're a bank and haven't secured your DNS control panel correctly. Someone comes along, and using your vulnerable DNS, registers logon.bank.com (instead of login.bank.com). Now it is the bank's fault to begin with, but end…

It's completely unclear whether what you're saying is factually correct. If the attacker controls the bank's DNS, which seems likely given that they're able to create an A record for a subdomain, they can likely also add TXT records for bank.com, which is what traditional CAs often use to verify ownership. They could probably also modify MX records to redirect confirmation emails to a server under their control.

Other CAs don't have a magic solution that automatically detects malicious domains. Issuance of DV certs is completely automated at any major CA. There is no manual review unless the domain is on some kind of grey- or blacklist, and I highly doubt that they have a list of every domain used by a bank. There have been numerous counts of unauthorized certificates being issued by almost all CAs, what makes you think they're somehow that much more smarter than Let's Encrypt on this topic?

Re: Let’s Encrypt Now Being Abused by Malvertisers

#49

Post by corobo »

lini wrote: post #25
ars wrote: post #13

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.

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.

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

Re: Let’s Encrypt Now Being Abused by Malvertisers

#50

Post by supermatt »

pfg wrote: post #42
supermatt wrote: post #37

Earlier quoted context omitted.

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 c…

WoSign is one of the other CAs offering this option. It is unclear to me how TXT verification would have prevent this. The article indicates that the attackers created the subdomain and pointed it at a server they controlled; this means DNS was compromised and creating a TXT record wouldn't have been a problem. Domain owners which are worried about Let's Encrypt can opt to create a CAA DNS record that limits CAs allo…

I simply see it as an additional (and unnecessary) attack vector.

If you are unable to hijack the DNS servers or poison/spoof the cache used by the CA, then you have the luxury of a whole new (and often WAY more insecure) attack surface. Then you have a cert for that domain which can be used for other, more targeted purposes.

EDIT: IGNORE BELOW, I WAS ASSUMING THAT LETS ENCRYPT LETS YOU VALIDATE SUBDOMAINS FROM THE TLD, BUT THIS DOEST SEEM TO BE THE CASE FROM THE DOCS.

e.g.

1) Wifi access point uses https://login.wifiprovider.com to authenticate users. This is clamped down as tight as possible. Theres no way i'm getting in to that beastie.

2) Their brochure site located at http://www.wifiprovider.com. It was made by some ad agency and probably allows you to log in with test/test or uses some crappy custom CMS that allows SQL injections or even allows you to log in with a "wildcard" password... (this is INSANELY common). Its just a brochure site, and its not linked to the super-secure login systems in any way.

3) By breaking into this crappy brochure site, I can get a cert from a valid CA for the subdomain https://login.wifiprovider.com that allows me to sit at an access point, spoofing DNS and capturing valid login details.

That doesn't seem right to me.

Post reply on HN