Attack Report: Office 365 Security Hacked Using Google Redirect
- Posted by
Yoav Nathaniel on September 14, 2017
A new widespread phishing attack against Office 365 email customers uses Google's App-Engine website to redirect victims to download malicious files. Avanan security analysts confirmed that this attack bypasses Mimecast and other legacy mail security platforms, so even if you use those to secure your Office 365, you are still vulnerable to this.
What makes this attack interesting is that it takes advantage of the trust in Google's servers to bypass these filters. It leverages what the security industry named as 'Open-Redirect Vulnerability' that Google should have addressed long ago.
This vulnerability was confirmed to fool the common email security platforms such as Mimecast as well sa Microsoft's Advanced Threat Protection.
There are multiple versions of the attack that use the same vulnerability, but in this example, the victim received an email regarding a legal violation signed by the Better Business Bureau. The victim is presented with a Bit.ly link to download a document explaining the incident. The URL redirects to one of a few known malware/phishing sites including bbbtax.com, bbbworks.com and bbbcompliancenetwork.com.
We will walk through each of the layers of redirection to see how it bypassed filters that would have normally blocked these sites.
Step 1: The Bit.ly Link
The first level of misdirection is a common one and is primarly meant to fool the user. By replacing the full URL with a bit.ly link, the user is more likely to click on it. Email filters are not fooled and will resolve URL-shortened links to find the target site.
Here is the full URL (edited for safety):
Step 2: The Google Redirect Trust Vulnerability
The first part of the URL takes advantage Google's trust in its own domain when redirecting URLs from its search engine.
For example, if you type in your browser the URL: https://www.google.com/url?sa=D&q=https://www.avanan.com, Google will redirect you to whatever URL you put in the "q=" parameter. Because attackers were using this as a way to hide malicious sites behind the trusted Google domain, Google responded by stopping the user with this message:
However, if you redirect to a Google site, there is no warning message. Therefore, the URL https://www.google.com/url?sa=D&q=https://appengine.google.com flashes a quick in the browser and then continues automatically. The attacker is basically taking advantage of Google's own trust in its domain that caused them to surpress the warning message.
Step 3: The Google AppEngine's Open Redirect Vulnerability
As you can see in the second part of the URL (Where it says "Malicious URL"):
This is where the hackers take advantage of the well-known vulnerabilty that Google actually warns its own webmasters about.
The Open Redirect Vulnerability takes advantage of a website that takes a redirect-link as a URL parameter but does not validate it before forwarding the user. Many sites use redirect-links as a URL parameter, so there is nothing inherently wrong with that. For example, website gated content and SSO use this mechanism. It become a vulnerability once the site does not check the validity of the URL parameter and sends you to a malicious site:
Unfortunately, Google's AppEngine does not test the URLs it redirects to. You can essentially put any link after the "logout?continue=" portion of the URL. https://www.google.com/url?sa=D&q=https://appengine.google.com/_ah/logout%3Fcontinue%3Dhttp://malicious-url.com
So, Google AppEngine does not verify the links it sends to and the security layers by Microsoft and others trust links that go to Google and don't verify them.
Bypassing the Filters
Most malware engines would have caught the file in step-4, had it been attached to the email. The attacker did not use the multiple layers of redirect to fool the user, but to bypass the most popular email gateways and filters.
Because we deploy within the Microsoft environment, we can see attacks that bypass external MTA-style gateways as well as Microsoft's own Office 365 security filters.
This attack has been successful because it has buried the malicious content within a URL parameter and redirected through multilple trusted sites that hide the malicious intent.
Bypassing Office 365 ATP's SafeLinks
We have seen this attack bypass at a customer that uses Microsoft's Advanced Threat Protection. They received these attack emails in this format:
Microsoft replaces every URL with a safelink prefix so that it can test the URL when the user clicks on it. As of today, the vulnerability is still live! The safelink URL still resolves to the malicious file.
What Can I Do? Avanan's Recursive Analysis
Because even the most savvy user would not be able to identify a malicious link when looking at a safelink, it must be blocked before it gets the inbox. Avanan resolves the URL and follows the trail to the end—identifying the safelink, resolving the bit.ly link, decoding the URL parameters, and following redirects. Along the way, we catch it by checking each interactive URL against our partners' most up-to-date blacklists and DNS history databases. If we resolve to a web page, we identify lookalikes. If there is a form, we test it for phishing threats. If there is a file, we pass it through each vendor's malware engines—from AV, to sandboxing, to active content analysis. If we find a document with a URL, like a PDF or Word document with a link, we start the process all over again, following it to its ultimate conclusion.