A long-standing bug in Skype for Business’s Response Group Service (“RGS”) is that it doesn’t validate the line URI when you create a new Workflow. This means it won’t err out if you chose a number that’s already in use elsewhere, and the upshot is that neither the existing user nor the response group can be called. Tracing will reveal a “SIP/2.0 485 Ambiguous” error.
But did you know it doesn’t validate the SIP Domain either?
You can create a Workflow for ANY SIP domain, and not only will it save it without error – it will route!
I’m struggling to think of a genuine use-case for being able to spoof a SIP domain that you don’t own, other than to hijack traffic to a specific address at a competitor – but if you didn’t want to be able to contact your competitors you’d just block the whole SIP domain wouldn’t you?
Here are some legit captures from my lab – there’s no Snagit fakery going on here. I’ve confirmed this bug exists on SfBS2019 CU2 (7.0.2046.151) and all the way back to Lync 2013 (5.0.8308.1068).
Here are my SIP domains:
Here is the response group I created for satya.nadella@microsoft.com:
Look him up in the address book. Note that he has the robot avatar of a response group:
Sorry, gotta go, I need to take this:
Revision History
14th February 2020. This is the initial release.
– G.
This is both terrifying and awesome.
Thanks Greig
I’d love to hear of any “practical” applications of this – and I’ll accept whacky and offbeat, they don’t need to be corporate-sanctioned stuff.
Amusingly, it will ALSO let you create “*@microsoft.com”, but it doesn’t seem to treat the * as a wildcard, unfortunately. THAT would have been TOO good.
UCMA Apps have been able to impersonate any SIP domain since the earliest releases. RGS is a UCMA based app. However you can not send traffic from the impersonated (“spoofed”) domains across federation boundaries. So at most, you can phish your own users inside your own Skype server by impersonating an external user.