Subject: Re: [Add] [EXTERNAL] Re: Malware adopting DoH

From: "Dixon, Hugh" <[email-masked]>
Date: Thu, 12 Sep 2019 11:25:27 +0000

While tis true that there have always been other methods than Do53 for Malware C&C and exfil, the thing is that the existence of DoH services from Google (and other very large-scale internet entities) is (IMHO) quite a distinct change in the availability of
*the combination of* :
Conventionally-encrypted (as opposed to stick-out-like-a-sore-thumb custom/obscure)
Unauthenticated but via “public” infrastructure
Globally anycast-by-design (i.e. not trivially IP-detected-and-blocked like static IPs)
A wide spread of steady-flow “genuine” traffic (e.g. 24h peak-to-mean of ~ 2 for example for DNS) in which to hide

And possibly other things.

That doesn’t mean DoH isn’t a good thing as a DNS-on-the-wire-privacy and recursor-authentication protocol (as of course all these features are also what make it a great protocol for attempting to prevent downgrade attacks by what The Internet would call bad (network/nation-state) actors).  However, it does beg the question of (all) operators of DoH infrastructure as to whether they are delivering “a better internet” if they ignore the assistance to criminals that they offer if they don’t actively take a role against them.
Of course there’s an argument that a crook-enabling DoH server is better than an NXDOMAIN-hacking ISP DNS. And a lot of ISPs don’t do any actively-bad stuff with DNS data/responses but do apply malware mitigation.

To address the question, perhaps the “what can we do about mitigating the opportunities for harm generated through innovation?” is the better end point?
H

On 10/09/2019, 16:14, "Add on behalf of Alec Muffett" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Mon, 9 Sep 2019, 22:16 Bret Jordan, <[email-masked]<mailto:[email-masked]>> wrote:
Just making sure people here have seen this..

https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fthreat-insight%2Fpost%2Fpsixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module&data=02%7C01%7Chugh.dixon%40sky.uk%7Cbe842998fe8f4078b46908d73601822c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637037252427909693&sdata=7V5bD7OSaLMqCAAqiL8oBg8F4HNgU8Qb2FnND9lWw9g%3D&reserved=0>

One can only wonder how rapidly they adopted HTTPS to evade the "content fingerprinting" of anti-malware in the late 90s and early 2000s, and how the adoption curves compare?

Similarly for adopting Tor, also, of course.

And WebRTC and Skype.

Not to mention those clever malware authors who hardcode IP addresses - that was a tremendous innovation in cyber badware.

Or were you suggesting that "innovation happens and bad people adopt it as well as good" somehow constitutes and argument towards some end?

-a

--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2019 12:03:15 -0400

A question you might ask is, “how do we know that this malware is using DoH?”  Also, now that it is doing DoH, what new opportunities exist for stopping it?  Is it easier or harder to trick it?

It’s all very well and good to point out that it’s using DoH and that this blocks certain mitigation strategies, but eg if Google can mitigate it centrally we might be better off, not worse off, as a whole. 

> On Sep 12, 2019, at 11:46, Dixon, Hugh <Hugh.Dixon=[email-masked]> wrote:
> 
> 
> On 10/09/2019, 16:14, "Add on behalf of Alec Muffett" <[email-masked] on behalf of [email-masked]> wrote:
>  
> On Mon, 9 Sep 2019, 22:16 Bret Jordan, <[email-masked]> wrote:
> https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module
>  
>  
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Andrew Campling <[email-masked]>
Date: Thu, 12 Sep 2019 19:44:19 +0000

On Mon, 12 Sep 2019, 12:25 Dixon, Hugh <[email-masked]>  wrote:

I agree with the closing comment that the “opportunities for harm generated through” DoH needs to be addressed, starting with information sharing on those harms as they are identified.  Is anyone aware of other examples to add to the one that prompted this thread?

In terms of getting better information sharing, I wonder whether the proposed SMART research group could help here (see https://github.com/smart-rg/drafts for more information)?

Andrew

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Sep 2019 15:20:37 +0100

> On 12 Sep 2019, at 17:03, Ted Lemon <[email-masked]> wrote:
> 

Perhaps not. If there are only a couple of dominant DoH resolver operators and they can control the price and quality of that service... Or lock out the competition... Or...

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 13 Sep 2019 10:41:54 -0400

Moin!

On 12 Sep 2019, at 12:03, Ted Lemon wrote:

> A question you might ask is, “how do we know that this malware is 
> using DoH?”  Also, now that it is doing DoH, what new opportunities 
> exist for stopping it?  Is it easier or harder to trick it?
>
> It’s all very well and good to point out that it’s using DoH and 
> that this blocks certain mitigation strategies, but eg if Google can 
> mitigate it centrally we might be better off, not worse off, as a 
> whole.
I disagree. It would be nice if Google would mitigate these threats or 
follow local law when it comes to DNS answers. But having it all go to 
Google would still be centralisation with all the associated problems, 
which IMHO is a bigger problem.

The current name resolution architecture being de centralised with a lot 
of security happening in the edge is far better and we should try to 
keep that architecture and work on encrypting/securing the last missing 
pieces without changing the architecture.

We should also deploy public DoH services in a way that for security 
sensitive environments like enterprises it is possible to block them, so 
that these malware threats can not use them.

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Sep 2019 09:53:48 -0500

> Perhaps not. If there are only a couple of dominant DoH resolver operators and they can control the price and quality of that service... Or lock out the competition... Or...

Jim, this is just a non sequitur.   For the case of blocking malware, if the malware has fewer choices, it is easier, not harder, to block.

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Sep 2019 16:58:24 +0100

> On 13 Sep 2019, at 15:53, Ted Lemon <[email-masked]> wrote:
> 

I’m not so sure it is a non-sequitur Ted. Aside from the competition/consolidation concerns which may well be out of scope for the IETF, centralisation is bad engineering because it introduces avoidable single points of failure. And control.

If malware has fewer “gatekeepers” to evade, surely that makes it easier for those developing and distributing that stuff? Or to use an analogy, would virus writers have an easier or harder time of it if there was just one company providing anti-virus protection?

If you think the issue I raised is a non-sequitur, we can just agree to disagree.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Sep 2019 11:29:26 -0500

> I’m not so sure it is a non-sequitur Ted. Aside from the competition/consolidation concerns which may well be out of scope for the IETF, centralisation is bad engineering because it introduces avoi…

Yes. That’s why malware using centralized services is good: because it’s bad engineering. It makes them vulnerable. 

I suspect that on the long run this will turn out to be a mistake on the malware authors’ part.

---

From: Andrew Campling <[email-masked]>
Date: Fri, 13 Sep 2019 19:51:37 +0000

On Sep 12, 2019, at 17:03, Ted Lemon <[email-masked]> wrote:
A question you might ask is, “how do we know that this malware is using DoH?”  Also, now that it is doing DoH, what new opportunities exist for stopping it?  Is it easier or harder to trick it?

If the centralisation potential of DoH takes effect as some anticipate, this would leave Google (and Cloudflare and other resolvers to a lesser extent) with significant control of the cybersecurity “market”, both in terms of protection capability and also cyber intelligence gathering, crowding out specialist provision.  Much as I respect people in Google, from an antitrust perspective, as well as when considering innovation etc, I would urge people to be careful what they wish for!

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Sep 2019 15:03:48 -0500

> If the centralisation potential of DoH takes effect as some anticipate, this would leave Google (and Cloudflare and other resolvers to a lesser extent) with significant control of the cybersecurity…

Again, we are talking specifically about malware using DoH.  It will probably use whatever DoH servers can be counted on.  This is entirely out of Google’s control.  The original point was that there is a problem with DoH and malware because Google.  My response was merely to point out that if such a problem exists, there is a mitigation strategy that could be very effective.

This is entirely orthogonal to any other operational issues that may come up as a result of the availability of DoH.   The fact that malware is using DoH is not a clear indication that the sky is falling, and may turn out quite differently than the author(s) of that malware intended.

---

From: "Robert Mortimer" <[email-masked]>
Date: Sat, 14 Sep 2019 11:16:01 +0100

If google or any other TRR DoH provider start blocking malware by default surely that is filtering DNS which is the very problem that DoH is claiming to be solving? I'm not saying that filtering out malware is a bad thing - but if one of the core arguments for DoH is that filtering is bad and must never be done - then if they start filtering DNS is rather undermines what's meant to be the entire point of the initiative. As the claim then becomes "Filtering DNS is bad except when we do it".

I am well aware that this is an argument with the implementation and not the protocol but the "avoiding filtering" has been a core argument for the protocol as well  so now saying "actually filtering might be needed" is a bit of a bait and switch - especially when proponents of DoH have been claiming that such strategies aren't effective.

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 13/09/2019 15:07:56, Ted Lemon <[email-masked]> wrote:
A question you might ask is, “how do we know that this malware is using DoH?”  Also, now that it is doing DoH, what new opportunities exist for stopping it?  Is it easier or harder to trick it?

 

 
On 10/09/2019, 16:14, "Add on behalf of Alec Muffett" <[email-masked] [mailto:[email-masked]] on behalf of [email-masked] [mailto:[email-masked]]> wrote:
 
On Mon, 9 Sep 2019, 22:16 Bret Jordan, <[email-masked] [mailto:[email-masked]]> wrote:
Just making sure people here have seen this..
 
https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module [https://eur01..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fthreat-insight%2Fpost%2Fpsixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module&amp;data=02%7C01%7Chugh.dixon%40sky.uk%7Cbe842998fe8f4078b46908d73601822c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637037252427909693&amp;sdata=7V5bD7OSaLMqCAAqiL8oBg8F4HNgU8Qb2FnND9lWw9g%3D&amp;reserved=0]

 
And WebRTC and Skype.

 
-a

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Sep 2019 11:15:02 -0500

On Sep 14, 2019, at 5:16 AM, Robert Mortimer <robm=[email-masked]> wrote:
> If google or any other TRR DoH provider start blocking malware by default surely that is filtering DNS which is the very problem that DoH is claiming to be solving?

The argument for DoH is that you can 
reliably know who operates the resolver you are talking to
know what the terms of service are
choose your provider based on their terms of service
not be forced to accept whatever terms service provider through which you are connecting at the moment insists upon, possibly with out telling you

---

From: "Robert Mortimer" <[email-masked]>
Date: Sun, 15 Sep 2019 11:29:34 +0100

No that's an argument for making an informed decision about what DNS service provider you use and possibly for being able to avoid limitations being imposed by the network you happen to be using at the time.

Using a VPN to access your DNS provider would achieve the same thing, as would using DoT or in many cases simply not using DHCP to decide your DNS provider.

If my an application is deciding which DNS service to use without my informed consent then even if it's using DoH it achieves none of the things you list.

Your list merely describes informed choice of DNS provider not any benefit uniquely inherent to DoH

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 14/09/2019 17:16:14, Ted Lemon <[email-masked]> wrote:
On Sep 14, 2019, at 5:16 AM, Robert Mortimer <robm=[email-masked] [mailto:robm=[email-masked]]> wrote:
If google or any other TRR DoH provider start blocking malware by default surely that is filtering DNS which is the very problem that DoH is claiming to be solving?

The argument for DoH is that you can 
* reliably know who operates the resolver you are talking to
* know what the terms of service are
* choose your provider based on their terms of service
* not be forced to accept whatever terms service provider through which you are connecting at the moment insists upon, possibly with out telling you

---

From: Rob Sayre <[email-masked]>
Date: Sun, 15 Sep 2019 08:28:49 -0500

Hi,

Here's some data on this point:

https://developers.google.com/speed/public-dns/docs/intro#google_public_dns_what_it_is_and_isnt

"Google Public DNS is not... A malware-blocking service. Google Public DNS
rarely performs blocking or filtering, though it may if we believe this is
necessary to protect our users from security threats. In such extraordinary
cases, it simply fails to answer; it does not create modified results."

Google and other browser makers do perform malware blocking, in a sense.
They just generally don't use DNS to do it. See:
https://safebrowsing.google.com

It seems to me that DoH provides the typical benefits of encryption over
the wire. On the "informed consent" argument: there are many divergent
opinions. Some people on this list seem to think DNS is special in some
way, but I don't think there is an IETF document that states anything like
that. As we have seen, there are many libraries, applications, and products
that connect to DNS servers without informing the user.

thanks,
Rob

On Sun, Sep 15, 2019 at 7:44 AM Robert Mortimer <robm=
[email-masked]> wrote:

> No that's an argument for making an informed decision about what DNS
> service provider you use and possibly for being able to avoid limitations
> being imposed by the network you happen to be using at the time.
>
> Using a VPN to access your DNS provider would achieve the same thing, as
> would using DoT or in many cases simply not using DHCP to decide your DNS
> provider.
>
> If my an application is deciding which DNS service to use without my
> informed consent then even if it's using DoH it achieves none of the things
> you list.
>

---

From: "Dixon, Hugh" <[email-masked]>
Date: Mon, 16 Sep 2019 08:21:57 +0000

On 16/09/2019, 07:22, "Add on behalf of Rob Sayre" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Google and other browser makers do perform malware blocking, in a sense. They just generally don't use DNS to do it. See: https://safebrowsing.google.com<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsafebrowsing.google.com&data=02%7C01%7Chugh.dixon%40sky.uk%7C99ec23d0e81449d1610708d73a6e419b%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C1%7C637042117539399573&sdata=6ZfpzQ5hEBt9qw2Har2rt5apVdDqj4iYM864yUys%2B7w%3D&reserved=0>

Safebrowsing is what I’ve taken to refer to as “Type 1” Malware mitigation – infection-prevention within that specific application (the browser) and I haven’t seen any data on whether it or DNS-based infection-prevention-filtering is more effective, except of course to say that combining the two is likely to be even better than either alone.  But I suspect browser-based is “pretty good”.

Type 2 Malware mitigation is what we’re talking about in this thread – post-infection malware operation-prevention largely independent of any other specific application.

Is the “All filtering is bad, mmkay” ethos really so strong that the idea of interdicting criminal operations is not an option?

H

It seems to me that DoH provides the typical benefits of encryption over the wire. On the "informed consent" argument: there are many divergent opinions. Some people on this list seem to think DNS is special in some way, but I don't think there is an IETF document that states anything like that. As we have seen, there are many libraries, applications, and products that connect to DNS servers without informing the user.

thanks,
Rob

On Sun, Sep 15, 2019 at 7:44 AM Robert Mortimer <robm=[email-masked]<mailto:[email-masked]>> wrote:
No that's an argument for making an informed decision about what DNS service provider you use and possibly for being able to avoid limitations being imposed by the network you happen to be using at the time.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 16 Sep 2019 13:35:34 -0500

On Mon, Sep 16, 2019 at 10:46 AM Dixon, Hugh <Hugh.Dixon=
[email-masked]> wrote:

> Type 2 Malware mitigation is what we’re talking about in this thread –
> post-infection malware operation-prevention largely independent of any
> other specific application.
>
>
>
> Is the “All filtering is bad, mmkay” ethos really so strong that the idea
> of interdicting criminal operations is not an option?
>

I don't think that's the case. Here's a list of DoH servers:
https://github.com/curl/curl/wiki/DNS-over-HTTPS ...They make many
different filtering choices.

However, there is another way to look at this problem, well-summarized by:
https://twitter.com/FiloSottile/status/1170848059493892096

"There's a pattern in resistance to Internet privacy improvements:
organizations that somehow manage their fleet's network but not its
configuration.
I'm not sure what control they thought they had, but it's equivalent to a
network attacker's, so yeah it's going away."

I'm glad ISPs are looking at rolling out DoH/DoT. Sometimes, people claim
that these encrypted queries must be made to whatever address DHCP returns.
I am not sure that makes sense, as dictating an endpoint in the clear can
subvert encryption as well (such as when a home router is compromised).

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Sep 2019 12:22:29 -0700

Sorry for being late to this thread. It seems to have gone into the weeds,
but it started in a pretty decent place, so I'll do a "Billy Martin" and go
back there to join in.

All of the following snippets have been selected to reinforce one point,
hiding in plain sight (a deliberate choice of words):

The real problem with malware is detecting it in the first place. Once you
know the domains/URL(s)/IPs it is using, there are numerous ways to take
action, be it on the browser, on the network, via DNS, or via routing
(black-holing).

Public DoH resolvers do several things to make things worse than they were:

   - They make it possible for malware to do resolution over DoH
   - They provide lots of traffic to those DoH resolvers in which the
   malware's traffic can effectively hide
   - They prevent correlation between DNS lookups and subsequent HTTPS
   traffic, where an absence of visible DNS lookups prior to HTTPS traffic
   would be a "signal" that detection systems could use

Malware using public DoH resolvers is the lowest hanging fruit for malware
authors.
The incremental effort needed to deploy a DoH endpoint (e.g. proxy) on some
random HTTPS server is extremely small, and has all of the same benefits to
a malware author that using Google or Cloudflare or Quad9 does, while
bypassing any malware filtering those resolvers may do.

In other words, it isn't the centralization and availability that is of
greatest value to malware authors.
Blocking on centralized resolvers would trigger the next step in the arms
race between malware authors and everyone else -- a step that creates the
biggest problem for detection.

If only malware used DoH, and everything else used DoT, a variety of
policies would be possible that preserve privacy, enable malware detection,
and enable enforcement of network-enforced policies (as an optional
benefit, not a requirement).
Networks who are happy for well-known DoT public resolvers to be used,
would be able to white-list those, and black list all other DoT endpoints.
This prevents the malware use of "random" DoT servers (unlike the DoH
scenario, where this isn't possible to do.)
If those DoT public resolvers filter malware-related DNS entries, the
network would not need to see the DNS queries. This presumes the
malware-filtering DNS has other sources for detecting which DNS entries
correspond to malware.
If the network wanted to inspect DNS traffic to correlate DNS to HTTPS
traffic, it could block DoT traffic to any resolver other than its own
specific inspection system. This is an independent model, rather than the
public DoT malware blocking via DNS, which is very dependent on the DoT
service.

Use of DoT for DNS, with local DoT resolvers and DNS-before-HTTPS would
also be useful for detecting use of DoH. It would not necessarily be 100%
foolproof, but it doesn't need to be, to be of value.

The DoH ecosystem is very much like the illegal narcotics trade. The
suppliers (DoH public resolvers) only spring up due to demand from the
buyers (the browsers). If it is possible to convince the browsers to enter
into a diversion program (switch from plans to use DoH to planning to use
DoT), it won't be necessary to consider a "War On Drugs" (war on DoH), and
the longer term effect would be the reduction or elimination of DoH
services being offered.

So, TL;DR: the problem isn't that malware can use DoH offered by public
resolvers; it is that DoH being used widely provides cover for malware
using DoH to any destination (public or otherwise), impacting malware
detection mechanisms.

Brian

On Fri, Sep 13, 2019 at 7:06 AM Ted Lemon <[email-masked]> wrote:

> A question you might ask is, “how do we know that this malware is using
> DoH?”  Also, now that it is doing DoH, what new opportunities exist for
> stopping it?  Is it easier or harder to trick it?
>
> It’s all very well and good to point out that it’s using DoH and that this
> blocks certain mitigation strategies, but eg if Google can mitigate it
> centrally we might be better off, not worse off, as a whole.
>
> While tis true that there have always been other methods than Do53 for
> Malware C&C and exfil, the thing is that the existence of DoH services from
> Google (and other very large-scale internet entities) is (IMHO) quite a
> distinct change in the availability of
>
>
> However, it does beg the question of (all) operators of DoH infrastructure
> as to whether they are delivering “a better internet” if they ignore the
> assistance to criminals that they offer if they don’t actively take a role
> against them.
>
>
>
> To address the question, perhaps the “what can we do about mitigating the
> opportunities for harm generated through innovation?” is the better end
> point?
>
> H
>
>
>
> On 10/09/2019, 16:14, "Add on behalf of Alec Muffett" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> <https://eur01..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fthreat-insight%2Fpost%2Fpsixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module&data=02%7C01%7Chugh.dixon%40sky.uk%7Cbe842998fe8f4078b46908d73601822c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637037252427909693&sdata=7V5bD7OSaLMqCAAqiL8oBg8F4HNgU8Qb2FnND9lWw9g%3D&reserved=0>
>
>