THIS POST WAS WRITTEN BY @NYXGEEK

What is it?

An attacker can force a user who is logged in with Microsoft Lync for Mac 2011 (< v14.4.3) to browse to a URL of their choice via a specially crafted instant message. This vulnerability exists due to poor input sanitation in the processing of message content submitted via PowerShell and the Lync 2013 SDK.

No user interaction is required, and the URL will open in whatever the default system browser is set to. If the URL is a link to a file, the browser will behave as though the URL was clicked. If the filetype of the URL target is a known 'safe' type, then it will automatically start downloading.

This vulnerability is particularly dangerous if Microsoft Federation is configured to be open, which allows users to receive messages from any Skype for Business user.

This issue is very similar to the input sanitation problem that I found last year in the Windows Skype for Business client (https://www.exploit-db.com/exploits/42316/). In fact, the PowerShell framework is, all the same, only the payload has been modified to hold an <iframe> instead of a <script> block.

The Code

This exploit is extremely simple. It is the result of a failure to sanitize input that is taken in via the Lync 2013 PowerShell SDK.  I used 'PowerSkype' by Karl Fosaaen of NetSPI as a base (https://github.com/NetSPI/PowerShell/blob/master/PowerSkype.ps1).

To begin with, I experimented with sending <b> or <i> tags to style the text. This successfully modified the message formatting, so I then extended testing to other HTML tags. While <script> tags were blocked, and various other JavaScript injections failed, I discovered that an <iframe> tag would spawn a browser session to the target URL.

A slightly less-useful trick is to embed an image directly into the chat by sending <img> tags:

Disclosure Timeline and Microsoft's Response

 I reported this to Microsoft in July 2017 and the MSRC opened a ticket.

• July 18, 2017 - Reported Issue to Microsoft
• November 2017 - Microsoft has been able to replicate issue
• March 2018 - Microsoft decides not to fix
• April 2018 - File with MITRE for CVE, MITRE contacts Microsoft
• May 2018 - Microsoft decides to fix it after all
• July 2018 - Microsoft has decided they won't be publishing fix after all
• September, 11 2018 - Microsoft discloses existence of vulnerability CVE-2018-8474

The Microsoft Security Advisory can be found here:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8474

I'm not completely surprised by their decision not to fix the problem. Lync: Mac 2011 is an aging client, with two product replacements out for it already (Skype for Business, and the new Microsoft Teams). Plus, it's the Mac client, so the install base is likely on the smaller side.

With that being said, if they don't want to fix it, Microsoft should stop recommending it and remove it from their downloads page. If you go to the Skype for Business 2016 Mac client download page you see that they recommend using the Lync 2011 client when connecting to Lync Server 2010.

To test the vulnerability, you will need an attacking machine (a Windows host that can run PowerShell), and a target machine (a Mac with the Lync Mac 2011 client running).

The Setup – Target Machine

This is easy – simply download the Microsoft Lync: Mac 2011 client, open it, and sign in.

https://www.microsoft.com/en-us/download/details.aspx?id=36517

The Setup – Attacking Machine

First, you'll want to set up the Lync 2013 PowerShell SDK. Karl Fosaaen over at NetSPI has a great write-up on getting this started, and I recommend you follow the steps in his post here:

https://blog.netspi.com/attacking-federated-skype-powershell/

Once you have the Lync 2013 SDK installed, go ahead and grab the CVE-2018-8474 PoC script here.

In order to run it we just need to make one change to the PoC script. Change the $target variable to point at the user you are targeting.

Now, navigate to the location of the PowerShell script and run it.

You should see a prompt appear on the target machine, and the URL should open in a new browser window!

Recommendations

What can you do? First, make sure that if your organization uses Macs, that they are held to the same standard for vulnerability management. Especially in big Windows shops, where the only Macs might be a handful in the graphic design department, it's easy for non-standard machines to fall through the cracks when it comes to patching and managing software.

Second, please please please restrict your Microsoft Federation settings. While the default is to have it enabled, it's a simple matter to fix by visiting the O365 Settings and whitelisting only the organizations that you wish to communicate with.

Reflection

Forced browsing isn't a great exploit on its own. However, paired with a browser or file format exploit, and the forced browsing becomes a terrific payload delivery method. At highest risk are those organizations that have Microsoft's Federation enabled, allowing external entities to communicate with their users via Skype/Lync.

A forced browsing exploit + browser or file-format exploit + open federation = super spear-phishing. Get easy shells on high-value targets and the user doesn't even have to click.

In the above scenario, against a user at an organization with open federation, an attacker could wait for their target to log in and force them to browse to a URL of their choosing. Since no user-interaction is required, the likelihood of execution is high.

It's interesting that both the Windows and Mac clients have had issues with input sanitation, despite the products being run by different teams. It shows that the classic Top 10 OWASP finding -- input sanitation -- is still a problem for developers in shops of all sizes.