
Let’s Encrypt Now Being Abused by Malvertisers - Radi
http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/
======
pdkl95
> 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
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
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.

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

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

~~~
eridius
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?

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

~~~
simoncion
> 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. :/ )

~~~
btown
But consider an attacker who pivots onto your entire infrastructure to serve
any content they desire. Presumably your DNS provider passwords are stored in
a password manager outside of that infrastructure. The attacker would still
need to use social engineering to trick the CTO into revealing those
passwords. It seems that would have prevented the abuse in the OP, right?

~~~
simoncion
> But consider an attacker who pivots onto your entire infrastructure to serve
> any content they desire.

I mean, if we're talking about a situation where an attacker _controls_ your
webserver, then that's pretty much game over, right? They can read and write
to _everything_ your server can, including SSL private keys, SQL databases,
etc., etc., etc...

> Presumably your DNS provider passwords are stored in a password manager
> outside of that infrastructure. ... It seems that would have prevented the
> abuse in the OP, right?

Doing DNS-record-alteration-only verification would have prevented the
scenario described in TFA, yeah. But, there are a couple of things to
consider:

* DV certs provide nothing more than HTTPS, without the scary "THE BROWSER DOESN'T RECOGNIZE THIS CERT ISSUER!!11" dialog. They _don 't_ provide the additional UI cues that EV certs do. So, their phishing utility is _rather_ limited.

* Society as a whole benefits _far_ more from thwarting passive dragnet surveillance than it does from putting roadblocks in the way of occasional unauthorized and unwanted issuance of a DV cert to someone who has improperly (effectively) gained control of someone else's web server or DNS zone.

* TFA is primarily a scare-piece from a traditional CA <strike>that's likely sad that their revenue stream from DV issuance is going to vanish.</strike>

Ugh. I actually got off my ass and did some research... it seems that Trend
Micro doesn't issue DV certs. [0] Mea culpa.

[0] [http://esupport.trendmicro.com/solution/en-
US/1097653.aspx](http://esupport.trendmicro.com/solution/en-US/1097653.aspx)

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

------
userbinator
_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](https://news.ycombinator.com/item?id=10685458)

------
ponytech
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
There are sites that do this as part of their core ui, such as deviantart.

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

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

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

------
rmhrisk
My post responding to this -
[https://unmitigatedrisk.com/?p=552](https://unmitigatedrisk.com/?p=552)

~~~
tremon
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?

~~~
rmhrisk
thanks, fixed everything but the quotes.

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

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

~~~
erostrate
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](https://letsencrypt.org/2015/10/29/phishing-and-malware.html)

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

------
joshmoz
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](https://letsencrypt.org/2015/10/29/phishing-and-malware.html)

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

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

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

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

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

~~~
pfg
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...](https://cabforum.org/wp-
content/uploads/Baseline_Requirements_V1_3_1.pdf)

~~~
supermatt
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](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](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](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.

~~~
pfg
No, with Let's Encrypt you would have to have full control over contents of
login.wifiprovider.com to get a certificate for that domain. Specifically,
you'd have to be able to serve a token at

    
    
        http://login.wifiprovider.com/.well-known/acme-challenge/random
    

Verifying ownership of wifiprovider.com that way would not automatically allow
you to get certificates for subdomains too.

~~~
supermatt
Thanks. I was assuming it would work the same as other CAs in that respect.

I'm still not sure about this mechanism of verification, but good to know that
my example scenario cant exist.

------
ycmbntrthrwaway
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/](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.

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

~~~
pdkl95
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...](http://www.ranum.com/security/computer_security/editorials/dumb/)
)

~~~
pfg
What you're saying is true, but in the context of CAs, it's still important to
be able to distinguish _real_ public suffixes from regular authority
delegations for subdomains. CAs need to be able to filter and block CSRs for
wildcard names like *.co.uk or something similar. This also applies to things
like cookie scopes in browsers. Currently, the Public Suffix List is your best
bet here.

The Dbound WG[1] is working towards a standardized solution that doesn't
require enumeration in a centralized list but rather works through DNS
records. This should eventually replace the PSL, although I suspect most use
cases will still rely on some kind of preload list (similar to HSTS) in
addition to that.

[1]: [https://tools.ietf.org/wg/dbound/](https://tools.ietf.org/wg/dbound/)

~~~
Animats
There's an authority delegation problem where "example.com" wants to delegate
"adblaster.example.com" to some ad service. The owner of "example.com" needs
to approve this, but the party named in the certificate is not "example.com",
but the AdBlaster service.

On the other hand, since this feature is used almost solely for advertising,
there's no reason Let's Encrypt should offer this service for free. Let the ad
guys buy those certs from Verisign and verify them with both parties manually.

------
zecg
In other news, guns are used to kill people.

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

