So…! You have roll-out Skype for Busines (SfB) on you company. Either it’s a simple or more complex (HA, PSTN connectivity,…) it contains 3 components: a Front-end on an Active Directory and an Edge and a Reverse Proxy. These last two are, hopefully, isolated by firewalls.
Then you configure several policies to allow remote user access (PC, mobiles clients, ), federation with other SfB domains and conferences.
SfB is about enabling collaboration between people: any device, anytime and anywhere. Once you enable all these abilities to your users, you also create new security challenges to your company.
I would prefer not to call them ‘security risks’ at this time, BUT… ignoring them after reading and knowing them, it would change subject title!
Since there is quite a significant amount of content to cover, I divided this topic into smaller post. Initially I will expose the challenges and after them, I will describe how to mitigate them.
Keep also in notice that, although:
- I use an On-premises SfB as the example, you will see very similar challenges using Office 365, in either Skype for Business Online or Microsoft Teams;
- the challenges might be related to external user connectivity, they can be replicated using just inside your corporate LAN.
Let’s start with the first topic:
Part 1 – Denial of Services and exploits
1.1. Denial of Services by account lockout
- knowing a SIP address of an user. How difficult is that? In 90% of the case it matches his email address.
- knowing the account login. What are the chances that the UPN is the same as the SIP and Email address? Knowing the domain and the samaccountname might be more tricky, but it’s possible.
As soon as someone knows a valid SIP address I can use a SfB client (windows of for mobile) and can now try to login with credentials 5 or more times.
A successful ‘DDoS’ will lock that user AD account (for some minutes or forever depending on the AD policy).
Not big security issue? Well let’s think:
- a locked user is a person that cannot work until support unlock him
(and gets locked again by an active DDoS).
This can be harmful from but can a possible attempt to sabotage a competitor to reply on time to a last minute RFC. And what happens
- It will a significant issue if the affected user is a VIP or the CISO
- by default there is no direct way to prevent these, since even the remote access policies will only take effect after the user successfully logs-in
remember the traditional message: ‘your account is not allowed to sign-in from external networks’?
- It can get worse: imagine that you have several UCC 3rd party applications that uses SIP ‘service’ accounts? What happens if they get locked-out?
What if there are still some companies that uses the default ‘administrator’ account? It can also get locked out the same way as many other critical domain ‘service’ accounts
Getting more concerned now? Using SfB clients is not the only way to cause account lockouts…. (Whaaaaatt?)
A simple SfB installation exposes some Webservices that actually ask for user credentials. How? Less experient SfB administrators configure topology with ‘easy-to- guess’ short URLs.
Here an example of a dialin.company.ch. If you click on the Sign In you will get the chance to enter a username and password (to change a PIN).
But there are more services: (1) the join a meeting URL allows you to try to authenticate, (2) the webscheduler (if installed) request the same, (3) if NTLM is enabled on the IIS (SfB webservices), any browse access attempt on known URLs will request authentication (ex: for the address book service: https://lsweb.company.ch/abs)
1.2 Denial of Services or attacks on published external Web Services
As stated before, a very basic SfB deployment will expose the web services to the internet throw a basic reverse proxy role that forwards the traffic throw the DMZ.
There are at least some potential challenges:
- Simple DDoS against the IIS services until the servers CPU/memory is exhausted
- Direct exploit of SfB vulnerabilities that on worst case can run unwanted command on the Front-end servers
- ‘Espionage’: someone can try to guess and find some running meeting with ‘guest’ permissions, since the formats are usually https://meet.company.ch/<username>/<meetingID>
1.3. Service exposures
The default (at least for mobile clients) discovery service is https://lyncdiscover.company.com. Just by sniffing this URL you might get some more information. And if you provide a SIP address you will get even more because of the authentication.
In the above example you will get the front-end server FQDN that reply to the request. Might be harmless, but this server internal FQDN is an additional clue to try to use it for user UPN DDoS attacks and as you dig throw other responses you might get to know a little bit more about the internal topology.
Ready to proceed to part 2?