I was able to find and join several random @SkypeBusiness meetings today…
intitle:"Skype for Business Web App" "Skype for Business Web App"
Bruteforce meeting IDs to find meetings to join. Exploit is not being released at this time.
I statistically analyzed 197 valid @SkypeBusiness meeting IDs. None have A,E,I,O,U,X. The reasons are explained here: https://patentimages.storage.googleapis.com/0d/c6/bc/d224e1261a2ec5/US20050023524A1.pdf
This knowledge reduces the combinations down from 36^8 to 30^8.
In all cases during my testing, the meeting had not yet started, so I was the only one in the “room”. I was not attempting to eavesdrop though, I was validating a theory and proving the feasibility of finding valid meetings. I could have easily monitored for the meeting becoming “active” (i.e. others joining) and eavesdropped had I chose to.
The best protection against this is on the Microsoft side. An 8-character ID alone is not sufficient to protect against bruteforce enumeration. That ID should be immediately increased to at least 64 characters and/or a password (enabled by default).
I would have excepted the Skype app itself to have some protection against a enumeration attack also. MS should really consider mitigation/alerts at the application level for this attack.
Users / Admins
Skype Business users/customers (and their admins) can ensure the meeting settings are restricted to prevent a non-invited person from joining. Microsoft allows (but it’s not default) for one to lock down the meeting to “invitees only”. I highly recommend reviewing the following documentation and making your meetings (by default) as restrictive as possible: https://support.office.com/en-us/article/set-options-for-online-meetings-and-conference-calls-dcd1ca39-0c1f-466c-9573-f04138fef5e2
Logging and Alerting
I was surprised that my activity was not throttled in any way, or ever blocked. This brute-force attack/activity is LOUD.
Be sure to monitor your logs and alert (at minimum) and/or block this activity. Something as simple as aggregation on the same source IP with more than X request per Y seconds would catch this. Sure, an attacker can distribute the attack across a botnet (for example) and avoid this basic detection. But I was using a single source and not getting blocked. Do the basics at least.
If you can, aggregate on something like the “userID” (ex. https://example.org/userID/meetingID), and alert on more than X request per Y seconds. That would allow you to detect/block even in the event that the attacker was changing their source IP for every request.
Consider Something Else
Let’s be honest, Microsoft is unlikely to offer better solutions to this anytime soon. You may want to consider an alternate product.