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

[Jack Rickard <[e-mail]>]

I agree that div does make this kind of attack more difficult, and requiring that there is some trust of every retargeting entity does make sense. My assumption was that by only trusting the signers of the passports I can trust the orig is the entity calling me, I now see you have to trust the signers and the diverting parties. To clarify this I propose that something like your explanation is added to the spec, i.e.

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.


To be clear, my original email was based on the belief that div passports would provide a "chain-of-trust", allowing you to essentially ignore that diversions had occurred once you had established there was a valid chain of div passports from the originator to the final destination. Although, after reading your response I realise that's not the case.

My worry is that this model makes div difficult to use and police in practice, specifically:

  *   This model makes implementations more complicated as you can't separate verification from policy decisions. You have to filter out untrusted parties before doing the chain finding step of verification, as otherwise you might decide upon a chain containing an untrusted party when there does exist a valid chain containing only trusted parties (granted this situation is unlikely).
  *   This model introduces complexity in what should be displayed to a user, the simple verified/not verified can't be used unless you require complete trust of all diverting parties, and that could cause false negatives.
  *   If a diverted call does get reported as a robocall, it's not clear whose reputation should be tarnished. It may have been that the original caller was a robocaller and the call got legitimately diverted to you, or it was the below attack where the caller is trustworthy but the diverter was the robocaller.

Thanks,
Jack

From: Peterson, Jon <[e-mail]>
Sent: 22 July 2020 23:53
To: Jack Rickard <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Potential security vulnerability in STIR/DIV

NOTE: Message is from an external sender

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 22, 2020 at 9:47 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Peterson, Jon" <[e-mail]<mailto:[e-mail]>>
Subject: Potential security vulnerability in STIR/DIV
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>
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 [phone]
Metaswitch is a Microsoft company