SBN

Proofpoint Patches URL Sandbox Bypass Bug

Or, how a travel website’s newsletter clued me in to a huge security gap in a popular email protection service.

tl;dr: I discovered URLs of sufficient length (over 770 characters) would bypass Proofpoint’s URLDefense service leaving the original link untouched, allowing malicious links directly into users’ email inboxes.

Proofpoint let me know this week that they finally have patched all the instances of their service that had this particular bug, so it’s time to disclose how I discovered it.

filter, by mason bryant

Many of you know I switched my personal email protection away from Postini/Google Apps for Business to modusCloud by Vircom. My users and I are 100% satisfied with the service! One of the technologies powering Vircom is Proofpoint Essentials, and one of the products under Proofpoint is a URL Sandbox service. Essentially, the service programmatically replaces any link in an email such that if a user clicks it, it first goes to Proofpoint’s URLDefense portal and then will forward on to the destination. The reason for this is to catch bad links and warn users before they click through and potentially compromise their machine.

Discovery

escargot / snail, by OliBac

As a user, the experience is both good and bad. Good because it provides an extra layer of security transparently, bad because decoding the replacement URL is burdensome if not impossible. So much so that Vircom has a decoder you can leverage to get to the original URL. About three months after switching, I received an email from Expedia. I looked it over and decided I wanted to unsubscribe, but before reaching that part of the email, I moused over one of the links at the very top and noticed that URLDefense didn’t replace it. I found many more that were not replaced and discovered that Expedia was embedding some REALLY long URLs in their emails. Like over 900 characters. Obviously a bunch of tracking and contextual information in the URI for the receiving link server (link.expediamail.com without TLS) to receive.

The magic number appeared to be 770 characters. If you go over 770 characters, you bypass the sandbox protection.

How Does This Affect Security?

If an attacker discovered this, he could slip emails past the URL sandbox directly into corporate networks. They could be blatant and not try to spoof the domain or they could get crafty and register a unicode domain that looks like urldefense.proofpoint.com as the link delivery system. Many anti-phishing programs train users to mouse over links and look for clues that it is real or fake. Some even train employees that “If you don’t see the URLDefense URL, you know it’s safe because it is an internal link.”

Attackers know this. Now I suspect every URL sandboxing service is about to get tested the same way.

Reporting and Closure

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

Patched Tube, by Morten Liebach

Cue the cricket orchestra.

I talked to the folks at work and they worked with their Proofpoint contacts to report it this way a few days later.

Cue an even louder(?) cricket orchestra.

It wasn’t until I reported it to the security team at Proofpoint on May 19 that I actually started to get some traction. From May 19 to Today, I nudged them several times for updates through some contacts I made. Only through those follow-ups did I discover how long this process would take to patch. They did prioritize certain instances of Proofpoint, which is great. Essentials didn’t get patched until the end of July, but the exact date is unknown because the issue is not listed in any of the release notes (for obvious reasons).

Possibly Related Posts:


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