Travel Bloggers

Proofpoint Patches URL Sandbox Bypass Bug

Or how a travel website’s newsletter drew my attention to a major vulnerability in a popular email protection service.

tl; dr: I’ve found that URLs of sufficient length (over 770 characters) bypass Proofpoint’s URLDefense service and leave the original link untouched, allowing malicious links to go straight to users’ email inboxes.

Proofpoint informed me this week that they have finally patched all instances of their service that were experiencing this particular bug. So it is time to reveal how I discovered it.

Filter, by Mason Bryant

Many of you know that I have switched my personal email protection from Postini / Google Apps for Business to Vircom’s modusCloud. My users and I are 100% satisfied with the service! One of the technologies that power Vircom is Proofpoint Essentials, and one of the products under Proofpoint is a URL sandbox service. In essence, the service programmatically replaces every link in an email so that when a user clicks it, they first go to Proofpoint’s URLDefense portal and then get redirected to the destination. The reason for this is to intercept broken links and warn users before they click through and potentially endanger their computer.

discovery

Snail / snail, from OliBac

As a user, the experience is both good and bad. Good because it provides an extra layer of transparency, bad because decoding the replacement URL is tedious, if not impossible. So much so that Vircom has a decoder that can take you to the original URL. About three months after the switch, I received an email from Expedia. I looked at it and decided I wanted to unsubscribe, but before I got to that part of the email I hovered over one of the links at the top and noticed that URLDefense was not replacing it. I found many more that weren’t replaced and found that Expedia was embedding some REALLY long URLs in their emails. How about 900 characters. Obviously a bunch of tracking and context information in the URI that the receiving Connection Server (link.expediamail.com without TLS) should receive.

The magic number seemed to be 770 characters. If you use more than 770 characters, bypass sandbox protection.

How does this affect security?

If an attacker detects this, they can move emails past the URL sandbox and directly into corporate networks. They could be obvious and not try to forge the domain, or they could get smart and register a unicode domain that looks like urldefense.proofpoint.com as the link delivery system. Many anti-phishing programs train users to hover over links looking for clues that they are real or fake. Some even train staff that “If you don’t see the URLDefense URL, you know it’s safe because it’s an internal link.”

Attackers know this. Now I suspect that every URL sandbox service is tested the same way.

Reporting and closure

I reproduced it on other Proofpoint installations (including corporate installations) so I knew I had something. I first reported the error on March 3, 2020 through my service provider. Vircom immediately reported it to Proofpoint.

Patched Tube by Morten Liebach

Cue the cricket orchestra.

I spoke to people at work and they worked with their Proofpoint contacts to report this this way a few days later.

Cue an even louder (?) Cricket orchestra.

It wasn’t until I reported it to Proofpoint’s security team on May 19 that I actually got some traction. From May 19th until today I nudged her several times for updates through some contacts I made. It was only through these follow-ups that I figured out how long it would take to patch this process. They prioritized certain instances of Proofpoint which is great. Essentials weren’t patched until late July, but the exact date is unknown as the issue isn’t listed in any of the release notes (for obvious reasons).

Possibly related posts:

*** This is a blog syndicated by Security Bloggers Network by Branden R. Williams, Business Security Specialist, written by Branden Williams. Read the original post at: http://feedproxy.google.com/~r/BrandenWilliamsSecurityConvergenceBlog/~3/NL41BkNdUL0/

Tags
Show More

Related Articles