[stir] Potential security vulnerability in STIR/DIV

[Jack Rickard <[e-mail]>]

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.

  1.  Attacker answers/rejects the call and saves off the SHAKEN passport for Trusted -> Attacker.
  2.  Attacker sets up a redirect from them to their intended Subject.
  3.  Attacker constructs a call (claiming to be) from Trusted to Attacker with the previously saved SHAKEN passport.
  4.  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.

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