Skype for business is also vulnerable to the autodiscovery issue

An issue in WPAD proxy automatic configuration was first discovered by Maxim Andreev back in 2015 at the MailRu group security meet-up and then was presented by Maxim Goncharov at BlackHat US 2016 (slides).

This year Ilya Nesterov and Maxim Goncharov presented a continuation of this research and extend the coverage to MS Exchange email clients at BlackHat Asia 2017 (paper, slides).

I really liked all of the above discoveries and I looked a little in the same direction for other protocols with the same mechanisms. The Lync/Skype for business service was the one of it. Please find the results of this study below.

To understand Lync autodiscovery I highly recommend to read these two articles:

Skype for Business: DNS requirements

Lync 2013 Client Autodiscover

To check how many clients are vulnerable to this issue I just registered following domains:

lyncdiscoverinternal.com
lyncdiscover.biz
sipinternal.org
sipinternal.info
sipinternal.biz
lyncdiscoverinternal.biz

And then started an Nginx to listen what would happen… And the traffic went! It’s about 3168 requests from Jun 19 to Jun 24.

Please the list of vulnerable clients (from User-Agent header):

OC/15.0.4420.1017
OC/15.0.4517.1504
OC/15.0.4569.1503
OC/15.0.4623.1000
OC/15.0.4667.1000
OC/15.0.4701.1000
OC/15.0.4727.1001
OC/15.0.4805.1000
OC/15.0.4809.1000
OC/15.0.4859.1000
OC/15.0.4867.1000
OC/15.0.4893.1000
OC/15.0.4903.1001
OC/15.0.4911.1000
OC/15.0.4919.1000
OC/15.0.4927.1000
OC/15.0.4933.1000
OC/16.0.4229.1002
OC/16.0.4266.1001
OC/16.0.4266.1003
OC/16.0.4417.1000
OC/16.0.4444.1000
OC/16.0.4510.1000
OC/16.0.4534.1000
OC/16.0.4546.1000
OC/16.0.7070.2022
OC/16.0.7369.2120
OC/16.0.7369.2130
OC/16.0.7766.2092
OC/16.0.7870.2031
OC/16.0.8067.2115
OC/16.0.8201.2102
OC/16.0.8229.2041

I sent all the detail to MFST at Jul 14 2017 (MSRC Case 39311 TRK:0461001598) and received back the answer that it’s not an issue.

Based on the team’s analysis of the code and the log you provided, it appears that you are seeing these requests due to the usernames being entered incorrectly. The logins consist of only a username and a TLD (biz, org, info, etc.) with no domain specified. This is not a vulnerability, as user input cannot be controlled to ensure that a valid domain is entered in the request. The one domain that does appear in the log you provided has a misconfigured DNS entry which is why you are seeing the requests.

The End! But I’m still not sure that it’s just a users’ mistypes because of the big number of requests.