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

"Robert Mortimer" <robm@scramworks.net> Sat, 14 September 2019 10:17 UTC

Return-Path: <robm@scramworks.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA412006B for <add@ietfa.amsl.com>; Sat, 14 Sep 2019 03:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scramworks.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjkmu7SFrEGc for <add@ietfa.amsl.com>; Sat, 14 Sep 2019 03:17:03 -0700 (PDT)
Received: from knid.scramworks.net (knid.scramworks.net [IPv6:2a01:4f8:c17:50eb::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92C31200B1 for <add@ietf.org>; Sat, 14 Sep 2019 03:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=scramworks.net; s=bofh; h=References:In-Reply-To:To:From:Subject:Message-ID :Date:MIME-Version:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cH+QoSkd9hN0lq/CrrIztL5Ar9c6LNHvyQx2Js9sQbE=; b=fWokjry+vNhHezravjs5SuJsKq 60iDhHFsYLlWVJb2s+q1alAeFnXav+46lTxzVsYeuy7fQzFLXcW+5U5jbBs7O0I3bMp6SDf02mRks FMFBRj1DzBfxzjxttNoJP4v5CG+fTAJ+Cfd8MwZ7FFKBgW82K8HMi09i4fCYtklJFxrI=;
Received: from [90.255.29.36] (helo=[192.168.1.6]) by knid.scramworks.net with esmtpsa (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from <robm@scramworks.net>) id 1i956y-00068M-3F for add@ietf.org; Sat, 14 Sep 2019 11:17:01 +0100
Content-Type: multipart/alternative; boundary="----=_NextPart_60816644.246357774565"
MIME-Version: 1.0
Date: Sat, 14 Sep 2019 11:16:01 +0100
Message-ID: <21edfaff-8741-4f4f-a3d4-1aa88ede6935@getmailbird.com>
From: Robert Mortimer <robm@scramworks.net>
To: add@ietf.org
In-Reply-To: <ED3464BD-37A7-4B6F-8327-508B0CB76A3E@fugue.com>
References: <66DC417B-23BC-4AF7-916B-5BAE7E5D9635@sky.uk> <ED3464BD-37A7-4B6F-8327-508B0CB76A3E@fugue.com>
User-Agent: Mailbird/2.6.10.0
X-Mailbird-ID: 21edfaff-8741-4f4f-a3d4-1aa88ede6935@getmailbird.com
X-Spam-Score-SW: -1.0 (-)
X-SW-Scan: 4d826e54c31e7906c054d7162a390af4
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Hi9xRXcqtXQ7geBf6G8_wLbJa5I>
X-Mailman-Approved-At: Sat, 14 Sep 2019 08:44:26 -0700
Subject: Re: [Add] [EXTERNAL] Re: Malware adopting DoH
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 10:17:06 -0000

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 <mellon@fugue.com> 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. 

On Sep 12, 2019, at 11:46, Dixon, Hugh <Hugh.Dixon=40sky.uk@dmarc.ietf.org> wrote:



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" <add-bounces@ietf.org [mailto:add-bounces@ietf.org] on behalf of alec.muffett@gmail.com [mailto:alec.muffett@gmail.com]> wrote:
 
On Mon, 9 Sep 2019, 22:16 Bret Jordan, <jordan.ietf@gmail.com [mailto:jordan.ietf@gmail.com]> 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]
 
 
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 phishing@sky.uk 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 --
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add