In this article I will go through my findings and analysis on the Safe Links feature of Microsoft’s Office 365 Exchange Online Advanced Threat Protection.
Essentially what Safe Links does is it rewrites all URLs in in-bound e-mails that pass through the Exchange Online Protection platform. So if you send an e-mail to an organization with Safe Links enabled then the e-mail will look like this (original):
|
1 2 |
Hello Bob, This is the link I was talking to you about: https://example.com |
The URL gets rewritten to look like this (passed through Safe Links):
|
1 2 |
Hello Bob, This is the link I was talking to you about: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com/[...] |
Bypass Method 1
It is not uncommon for organizations to add their own domains to the Safe Links whitelist policy. This is done for one of many reasons… either you trust your own domains or you don’t want to inconvenience staff when sending documents internally imagine sending a .pdf on your corporate site to 1,000’s of staff – a significant portion would click the link and be presented with this page:
This bypass exploits the whitelisted domains in the Safe Links policy by using URL obfuscation techniques.
Imagine you have Example Ltd which owns the domain example.com. The administrators of example.com have added the example.com domain to the whitelist in their Safe Links policy such that e-mails containing the URL example.com don’t get re-written by EOP.
Using a URL obfuscation technique like the below can trick EOP into thinking that the domain is whitelisted when in fact it isn’t:
|
1 2 |
Hello Bob, |
As you can see, simply obfuscating the URL by posting bogus credentials tricks Safe Links in to thinking that the domain is example.com instead of emtunc.org/malware.exe.
Another obfuscation technique is:
|
1 2 |
Hello Jane in finance, URGENT - please see outstanding invoice due to us: https://example.com.emtunc.org/malware.exe |
Here the advanced threat protection isn’t checking the entire domain – instead it is tricked by a basic obfuscation technique of inserting the white-listed domain as a subdomain of the malicious domain.
Bypass Method 2
With this technique, an attacker could simply block or re-direct requests from the Exchange Online Protection infrastructure – yup, it’s as simple as that. It’s less of a vulnerability and more of a non-ideal configuration.
Helpfully, Microsoft makes the EOP IP ranges available online so all you need to do is block those ranges on your webserver with some .htaccess rules.
Even if the IP ranges weren’t available online, the EOP requests contain absolutely no headers which makes it very easy to distinguish EOP traffic and genuine traffic.
This is what genuine traffic looks like (notice the browser headers are present):
|
1 |
1.2.3.4 - - [23/Feb/2017:11:58:26 +0000] "GET /blog/02/2017/ninite-appsheet-patching-just-got-easier/ HTTP/1.1" 200 18347 "android-app://com.google.android.gm" "Mozilla/5.0 (Linux; Android 7.1.1; Nexus 5X Build/N4F26O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36" |
This is what EOP requests look like (notice how no headers are sent so easy to distinguish from legitimate traffic):
|
1 |
40.107.196.15 - - [13/Jan/2017:12:24:03 +0000] "GET /malware.exe HTTP/1.1" 404 406 "-" "-" |
Timeline
- 15/01/2017 – First reported
- 20/01/2017 – I requested an update
- 01/02/2017 – I requested an update
- 07/01/2017 – MSRC claimed a ‘bug’ caused my replies to be missed. MSRC asked for some further clarifications which I addressed
- 15/02/2017 – I requested an update
- 23/02/2017 – I notified MSRC that I will be publishing this article on the 27th
- 24/02/2017 – I was asked to delay the publishing of this post and notified that a new MSRC case was created
- 15/03/2017 – MSRC advised that the issue doesn’t “meet the security servicing bug bar” and that they are closing the case
- 16/03/2017 – Published