Cloud Email Filtering Bypass Attack Works 80% of the Time

Cloud Email Filtering Bypass Attack Works 80% of the Time

Computer scientists have uncovered a shockingly prevalent misconfiguration in popular enterprise cloud-based email spam filtering services, along with an exploit for taking advantage of it. The findings reveal that organizations are far more open to email-borne cyber threats than they know.

In a paper that will be presented at the upcoming ACM Web 2024 conference in Singapore in May, the authoring academic research team noted that services in wide use from vendors such as Proofpoint, Barracuda, Mimecast, and others could be bypassed in at least 80% of major domains that they examined.

The filtering services can be “bypassed if the email hosting provider is not configured to only accept messages that arrive from the email filtering service,” explains Sumanth Rao, a graduate doctoral student at University of California at San Diego and lead author of the paper, entitled “Unfiltered: Measuring Cloud-based Email Filtering Bypasses.”

That might seem obvious, but setting the filters to work in tandem with the enterprise email system is tricky. The bypass attack can happen because of a mismatch between the filtering server and the email server, in terms of matching how Google and Microsoft email servers react to a message coming from an unknown IP address, such as one that would be used by spammers.

Google’s servers reject such a message during its initial receipt, while Microsoft’s servers reject it during the “Data” command, which is when a message is already delivered to a recipient. This affects how the filters should be set up.

The stakes are high, given that phishing emails remain the initial access mechanism of choice for cybercriminals.

“Mail administrators that don’t properly configure their inbound mail to mitigate this weakness are akin to bar owners who deploy a bouncer to check IDs at the main entrance but allow patrons to enter through an unlocked, unmonitored side door as well,” says Seth Blank, CTO of Valimail, an email security vendor.

Enterprise Inboxes Wide Open to Phishing

After examining Sender Policy Framework (SPF)-specific configurations for 673 .edu domains and 928 .com domains that were using either Google or Microsoft email servers along with third-party spam filters, the researchers found that 88% of Google-based email systems were bypassed, while 78% of Microsoft systems were.

The risk is higher when using cloud vendors, since a bypass attack isn’t as easy when both filtering and email delivery are housed on premises at known and trusted IP addresses, they noted.

The paper offers two major reasons for these high failure rates: First, the documentation to properly set up both the filtering and email servers is confusing and incomplete, and often ignored or not well understood or easily followed. Second, many corporate email managers err on the side of making sure that messages arrive to recipients, for fear of deleting valid ones if they institute too strict a filter profile. “This leads to permissive and insecure configurations,” according to the paper.

Not mentioned by the authors, but an important factor, is the fact that configuring all three of the main email security protocols — SPF, Domain-based Message Authentication Reporting and Conformance (DMARC), and DomainKeys Identified Mail (DKIM) — are needed to be truly effective at stopping spam. But that isn’t easy, even for experts. Add that to the challenge of making sure the two cloud services for filtering and email delivery communicate properly, and the coordination effort becomes extremely complex. To boot, the filter and email server products are often managed by two separate departments within larger corporations, introducing yet more potential for errors.

“Email, like many legacy Internet services, was designed around a simple use case that is now out of step with modern demands,” the authors wrote.

Email Configuration Documentation Lags, Sparking Security Gaps

The documentation provided by each filtering vendor does vary in quality, according to the researchers. The paper points out that the instructions on the filtering products from TrendMicro and Proofpoint are particularly error-prone and can easily produce vulnerable configurations. Even those vendors that have better documentation, such as Mimecast and Barracuda, still produce high rates of misconfiguration. 

While most vendors did not respond to Dark Reading’s request for comment, Olesia Klevchuk, a product marketing manager at Barracuda, says, “Proper setup and regular ‘health checks’ of security tools is important. We provide a health-check guide that customers can use to help them identify this and other misconfigurations.”

She adds, “most, if not all, email-filtering vendors will offer support or professional services during deployment and after to help ensure that their solution works as it should. Organizations should periodically take advantage and/or invest in these services to avoid potential security risks.”

Enterprise email administrators have several ways to strengthen their systems and prevent these bypass attacks from happening. One way, suggested by the paper’s authors, is to specify the filtering server’s IP address as the sole origin of all email traffic, and to ensure that it can’t be spoofed by an attacker. 

“Organizations need to configure their email server to only accept email from their filtering service,” the authors wrote.

Microsoft’s documentation lays out email defense options and recommends setting a series of parameters to enable this protection for exchange online deployment, for example. Another is to ensure that all SPF, DKIM, and DMARC protocols are correctly specified for all domains and subdomains used by an enterprise for email traffic. As mentioned, that could be a challenge, particularly for larger companies or places that have acquired numerous domains over time and have forgotten about their use.

Finally, another solution, says Valimail’s Blank, “is for the filtering application to include Authenticated Receiver Chain (RFC 8617) email headers, and for the inner layer to consume and trust these headers.”

Related Posts