Re: [stir] Potential security vulnerability in STIR/DIV

"Peterson, Jon" <jon.peterson@team.neustar> Wed, 22 July 2020 22:52 UTC

Return-Path: <prvs=8472a8f980=jon.peterson@team.neustar>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3C3A08BA; Wed, 22 Jul 2020 15:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar header.b=WJUCW6DO; dkim=pass (1024-bit key) header.d=neustar.onmicrosoft.com header.b=hOVy+WHk
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 HLJSJYWwC8bJ; Wed, 22 Jul 2020 15:52:39 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 67EB73A08B2; Wed, 22 Jul 2020 15:52:39 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06MMiq4G029651; Wed, 22 Jul 2020 18:52:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=team-neustar; bh=/3+hosbhKf8DBevcjoqzZgYE9rlURibt9H3w5KRDVMY=; b=WJUCW6DOaiM+Kf0phl0mLkB8JLMYfEhmVEJDWuU3p/bwvcFSCmOXz+PzNsFks39ZXN5L pyirJYw22Hw25nacQYwYTn7IKeMhpbuYEYfwSKonbukA7b6a+Lx65Olvkz1Un+p17ERB HyRRO7Tvi3zesFewtHpp+e45jOpRmSftYz9h568ct4lE1wUFAvjBOjBkmYU6gThkxCbu qc9DaT12GHYuyUD3BZKNKeDnC/p6LowUHaMCFa5VLmicA5LgSuBS5kvu2SjeT/tOtPzT mu3WDscvgrW02iExKyWG1spWrx5jkyVai/kTCVZgmqvyBJed8HUaXrKMF9X5jCP9OwiT xg==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0a-0018ba01.pphosted.com with ESMTP id 32buqx9eca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jul 2020 18:52:38 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M8Mz9zEs07lfTeQjrxwzH+4Qr8f70wiF7X3LIfs2K0x8Tuvl2vAsg6LRmNh5je2NNE9NNKTUA5b5FRU5AGSWulr3s66eN28othyBaGdT42etMIUoCtVhEPcUWE/saeFgAdSPD316eDP+oRn6DKinOf9GnFPC3o5buXfB2sS+/bvlzrZuaRbFFXr85hnbVP4/HWpHNeuwOXl9ibL9JSrpEwLiaxF3oHXHVH4vUuJV06fxfvLSvd7OnTz8cwcvrHDXo7jQhae53L2W594Uo48vnALuelcrLC/MxIw1l54PLXMwHOjjosEUHj778XXuixPfYLO/nfkhAxyxEPvgKQADSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/3+hosbhKf8DBevcjoqzZgYE9rlURibt9H3w5KRDVMY=; b=jG4VPFiQfNnoHl2vhhCp1j5HiDwmPQQ6k9xmkhl9LLFoZZE/JAU5Y3Gea5/c7sTXs6nXGwXNUp9X8Wr7YQpzh8m7M2TlSXxfpbfpiYhn8LJ3P/iavD3z+oWv5WrWNEAJzO3YyLTqfzr4igjCzwu8muV2mip7uxkO/pOD1B+0QE0y0Y81njX4WEvahXXEgbvb2sUSgNVvB4VvFsh/i3LaHT7tzdRgr1Lc9DWVN1HA24skl1GQ9HjR/LAKypcikEFIjL0TZIsKV6QmCHRXNELUL13Dwh14mXZokC/ALMhswMSBIVH0SIIYRVuc9Y7ce69Xy54N19O7tw4qSlbeCT0abg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.neustar; dmarc=pass action=none header.from=team.neustar; dkim=pass header.d=team.neustar; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.onmicrosoft.com; s=selector1-neustar-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/3+hosbhKf8DBevcjoqzZgYE9rlURibt9H3w5KRDVMY=; b=hOVy+WHk9ur5G80wrvGG0GeFlQs8IXT228LcVDc6ymsY0sFDaD7IdtOIXfYj+iQGT6sQEMGugga/bwdIGrZwTJjNPps8glJPCjlHCqI9vWphtrPXnnxmowc7ImWckboi8jp0rviX6PVCGCPqgoxmX0XvkvrSuupfas7XUKATXrE=
Received: from BY5PR17MB3569.namprd17.prod.outlook.com (2603:10b6:a03:1b9::20) by BYAPR17MB2487.namprd17.prod.outlook.com (2603:10b6:a03:85::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Wed, 22 Jul 2020 22:52:35 +0000
Received: from BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15]) by BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15%5]) with mapi id 15.20.3216.023; Wed, 22 Jul 2020 22:52:35 +0000
From: "Peterson, Jon" <jon.peterson@team.neustar>
To: Jack Rickard <Jack.Rickard@metaswitch.com>, "stir@ietf.org" <stir@ietf.org>, "draft-ietf-stir-passport-divert@ietf.org" <draft-ietf-stir-passport-divert@ietf.org>
Thread-Topic: Potential security vulnerability in STIR/DIV
Thread-Index: AdZgO7RfMuiVRPd/TYi0mhEaKJnUqQABGmKA
Date: Wed, 22 Jul 2020 22:52:35 +0000
Message-ID: <89AC11DC-7E1A-4D1E-9CB8-96C98E790EF5@team.neustar>
References: <BYAPR02MB5189FF21A49BA034796C44F1F3790@BYAPR02MB5189.namprd02.prod.outlook.com>
In-Reply-To: <BYAPR02MB5189FF21A49BA034796C44F1F3790@BYAPR02MB5189.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.17.200615
authentication-results: metaswitch.com; dkim=none (message not signed) header.d=none;metaswitch.com; dmarc=none action=none header.from=team.neustar;
x-originating-ip: [2600:1700:2ec0:8108::4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0c8514ea-21dd-48d3-99be-08d82e91ed40
x-ms-traffictypediagnostic: BYAPR17MB2487:
x-microsoft-antispam-prvs: <BYAPR17MB2487CC71E484E76DB2DA4567E2790@BYAPR17MB2487.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rMFXG7gQUZP3d0cRw1bEW2BYEyuporK5Zg57glsvTPHUD6nkqIQpHj5YxnOTjhPUYIA7/NjtzCoOoLHdyWoOyy1UmwCi0k8Jg3H4Sq119quxq8WBBfSGEHgPw2pJskVLzinssizF2EaJvsPnkzckK2OT5NODqLraAyeMsj8M5QGJDmqBKRmXhbIIZt6XIW32/3Mx2ETm17cacdqeTZYtZOvw2dzFDhlHbNwgp+lI0EEwViy8HT2e7W6SB+6Bt+t07GXtv/InXWXrsbTk/J9M9cXd8pGHB14emTWKTeA53YFy8xnCuqvhYpTeKztJy1gqQJsHpbH32DGbyYh94P3KeVaQcCwAEDst6vPB9l1esQotw8aZ4yi/962zoJ1P+u6m
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR17MB3569.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(6486002)(15650500001)(5660300002)(66446008)(2906002)(33656002)(86362001)(76116006)(53546011)(66946007)(66476007)(66556008)(64756008)(45080400002)(8676002)(6506007)(8936002)(316002)(186003)(2616005)(71200400001)(478600001)(6512007)(110136005)(83380400001)(46492007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ME9CHoG8kNv7h8c8LXONKHgyalCz0e5iawMBMNFdk2oY9aL4I3862C3/uuw1EaG9iu3R6JOgTn6LuHyqQsZIMeXbHA+a9k83TthNJc8QRdLtEk347BdIayYelw7I7+qHVi7iMP0jbAPk1N1W7eMPsYIpXfj6IpzcI4wFoLYqHe2OcodIBFpR5MgGLjdEFTdsDquSjL1SJh8645u2athJmUSqv6yS1nmN5aKmlctC+oc5eNzYoy3J3MHTomib8E4RyFwdrRLHzs3z08BRjkpqCHEHwvnI0HMaanvYWMoAirlK3OsQ1FPEGSBKEB2K90yyVJJFKxFMoCQKkHkSjgX2AR8md/fSkBxW2QuSppsjUtQ6OMVKtdBqzWaeAdrYzv/2tMTfHk1RfzMu5gZH3Un3ZDxDRYXcUs9M8VilgsC8P6edGv/3KyM1t29YBFmKJwGhu/Opx59kpT3FHsr7HCfDmrZ3juCq0QInvvQcJfajHubjGuOVddH/maAmQqPtVA7ut8kEroVko9DkFdw+uR9D1A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_89AC11DC7E1A4D1E9CB896C98E790EF5teamneustar_"
MIME-Version: 1.0
X-OriginatorOrg: team.neustar
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR17MB3569.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c8514ea-21dd-48d3-99be-08d82e91ed40
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 22:52:35.7205 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 73a2bbc1-f307-47c4-8f94-5f379c68bc30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Mt9cY7exgpVKYqjYyVVax9MgAGvGAP2h4JBPuE7UOeH34Mmta8C7XvHj6CSaJvXPtI3Du0otfUc7O3mYXMlt63EqIBvSdJymsZAwX2UhsdU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR17MB2487
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-22_16:2020-07-22, 2020-07-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 phishscore=0 suspectscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007220142
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/8fdQ64TSI4NhYFSmjORWrM_2fV4>
Subject: Re: [stir] Potential security vulnerability in STIR/DIV
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 22:52:42 -0000

Potential “baiting” attacks of this form emerge when you combine baseline STIR with call forwarding, and are the main threat articulated in the IETF “div” draft. The introduction describes them as follows:

   If Alice calls Bob, for example, Bob might
   attempt to cut-and-paste the Identity header field in Alice's INVITE
   into a new INVITE that Bob sends to Carol, and thus be able to fool
   Carol into thinking the call came from Alice and not Bob. With the
   signature over the To header field value, the INVITE Carol sees will
   clearly have been destined originally for Bob, and thus Carol can
   view the INVITE as suspect.

That describes the situation in a world without “div”, so the question is, does “div” make these sorts of attacks easier to harder to mount?

Without “div”, in the example above, Carol will see that the original called number does not match hers, and can decide on those grounds to reject the call. But bear in mind this is also what Carol would see in legitimate forwarding cases, so a more nuanced logic would probably be used. She could decide that if the original called number is a number that should be forwarding calls to her (say, if it was her office), that she should accept the call anyway. You could even imagine application behavior that would enforce policies along those lines on her behalf. However, Carol has no assurance that it was really her office that forwarded this call, rather than some eavesdropper who somehow captured the PASSporT, nor how many times it might have been redirected before reaching her, or anything along those lines.

Those are the gaps that “div” is meant to fill. It is not a substitute for the rest of the logic and policy described above, but it gives Carol more information to help figure out if the call is suspect and what to do about it. With “div”, what Carol sees is a second PASSporT created and signed by Bob, which actually gives Carol the assurance of whether the intended called party is one who retargeted the call, which you don’t get in the absence of “div”. If Bob is doing this maliciously, the “div” he provided has given Carol the means to hunt him down for redress, which is not exactly a strong incentive for him to use “div”. But at the end of the day, it is Carol who needs to decide if a forwarded call from Bob should be trusted or not – “div” is certainly not suggesting that trust is automatic, nor that the presence of a “div” that correctly chains to the original PASSporT is a substitute for the policy and trust decision made on the terminating side of a call. As with baseline STIR, just because something validates at a protocol level doesn’t mean you should trust it, nor that local policy does not determine how you treat calls.

But all that said, if you’re serious about security, then yes, using DTLS-SRTP with “mkey” is going to provide you with a better assurance.

Jon Peterson
Neustar, Inc.

From: Jack Rickard <Jack.Rickard@metaswitch.com>
Date: Wednesday, July 22, 2020 at 9:47 AM
To: "stir@ietf.org" <stir@ietf.org>, "draft-ietf-stir-passport-divert@ietf.org" <draft-ietf-stir-passport-divert@ietf.org>, "Peterson, Jon" <jon.peterson@team.neustar>
Subject: Potential security vulnerability in STIR/DIV
Resent-From: <alias-bounces@ietf.org>
Resent-To: <jon.peterson@team.neustar>
Resent-Date: Wednesday, July 22, 2020 at 9:47 AM

Hello,

I believe I've come across a security vulnerability in the STIR system that is made exploitable by the introduction of DIV passports, that I haven't seen discussed here in any detail (sorry if it has been). There are currently mitigations for it in the passport spec, however I don't believe they go far enough to prevent this attack.

The high level summary is that an attacker can impersonate an entity that called them by pretending they redirected that call to the recipient.

An example:

Trusted: A party trusted by Subject, which Attacker wishes to impersonate
Attacker: The party wishing to impersonate Trusted
Subject: The intended target of Attacker, who will see a verified call coming from Trusted


1.       Attacker gets Trusted to call them.

This is a reasonable operation, and is actually quite a common feature of support companies so you don't have to sit on hold.

2.       Attacker answers/rejects the call and saves off the SHAKEN passport for Trusted -> Attacker.

3.       Attacker sets up a redirect from them to their intended Subject.

4.       Attacker constructs a call (claiming to be) from Trusted to Attacker with the previously saved SHAKEN passport.

5.       The call will be verified, then redirected to Subject with a DIV passport for Attacker -> Subject.

This does rely on the certificate signing the DIV to belong to a trusted entity, this seems possible, as the redirect could be carried out by Attacker's service provider.
Attacker's SP may refuse to redirect after some time due to IaT timeouts, but this is not required by the spec and I believe this can be worked around by, for example, repeatedly bouncing new calls off an accomplice.

6.       Subject receives a call claiming to be from Trusted (albeit redirected from Attacker) with a valid passport chain of Trusted -> Attacker -> Subject.

Both passports will be signed by trusted entities: Trusted's SP and Attacker's SP.
IaT doesn't provide much protection here as, in the presence of DIV passports, the valid time range must be set reasonably high to allow for the possibility of ring-arounds.
The origid and attest will be associated with Trusted, eroding any automated databases of robocalls based on the origid.



The "mky" claim seems to be the solution that is currently built into passports, however, it is currently optional, and as far as I am aware using certificates to authenticate the ends of a media stream is very rare in practice.

Unfortunately, I'm not able to come up with a solution and I am hoping that is where you will be able to step in. I believe to avoid this, there needs to be more validation of the media stream that is created, either in the form of more data being signed or enforcing that the media participants are authenticated.

Thank you,
Jack Rickard | Software Engineer | Metaswitch
The Faster Way Forward
Office +44 20 8196 9801
Metaswitch is a Microsoft company