G Suite flaw mitigated after disclosure, but Google Drive still vulnerable

Pictured: Google and parent company Alphabet’s corporate headquarters. Researchers recently reported finding security holes in Google’s G Suite and Google Drive offerings. (Alex Tai/SOPA Images/LightRocket via Getty Images)

Google has mitigated a validation flaw in its G Suite and Gmail offerings that could allow malicious emails to bypass even the strictest of SPF and DMARC protections, but the company has not fixed another validation vulnerability in Google Drive that could result in users downloading malware.

Discovered by researcher Allison Husain last April 1, the G Suite/Gmail flaw was found to be the result of a missing verification process during the configuration of mail routes.

DMARC vulnerabilities such as this are a significant find, given the potential for malicious actors to send emails from a spoofed address that appear to be from a legitimate co-worker, boss or business partner. U.S. government entities in particular have been strong adopters of DMARC – with roughly three-fourths of U.S. federal domains safeguarded by DMARC enforcement, according to a recent report from Valimail.

In her own personal blog post, Husain said the vulnerability “allows an attacker to send mail as any other user or G Suite customer while still passing even the most restrictive SPF and DMARC rules.” That includes “Reject,” a DMARC setting that is supposed to block emails that are perceived to be fraudulent based on the domain found in the “From” field.

The flaw pertains to the “Settings for Gmail” feature in the G Suite administrator console that creates global mail routing rules for inbound emails. One such rule allows users to change the envelope recipient that determines “who the email should be sent to before it is processed by the rest of Google’s infrastructure,” said Husain.

The researcher realized that malicious actors could leverage the settings to send a malicious, spoofed email to themselves and then reroute it to a targeted recipient at another destination email address or domain without any further validation. While this technique alone wouldn’t work against recipients who use the “Reject” DMARC policy, Husain found a way to circumvent this protection by also reconfiguring the settings of the sender’s “inbound gateway” – a server through which all incoming mail passes.

“This results in a completely illegitimate message from a highly trusted domain with strong SPF and DMARC configurations being delivered directly to the victim’s inbox without any sort of warning,” Husain wrote.

Husain said she privately reported the issue to Google on April 3, and gave the company a 137-day window to address the flaw. Husain said she finally published her findings on Aug. 19, and within seven hours Google issued a series of server-side mitigations, with plans to issue a full patch in September. Despite Google’s late fix, Husain said Google was “very clear that they did not wish to suppress or in any way limit disclosure,” adding that she has “absolutely no ill-will against Google’s security team” for its handling of the vulnerability disclosure.

“This is an interesting bug — it’s a nontrivial Gmail error with roots in basic email settings, so it’s not surprising it took Google a while to patch,” said David “Moose” Wolpoff, chief technology officer and co-founder of Randori and professional hacker for hire. “What’s notable here is that adversaries can take advantage of confusing Gmail settings to manipulate email headers, and then bypass security controls to send emails from different accounts. This bug allows an adversary to bypass the step of proving the domain from which they are claiming to send the email.”

“Phishing continues to be a major thorn in the side of enterprise security, and in this case, an email that comes from your HR team, your CEO, or an authentic user, will likely be effective,” Wolpoff continued. “All HR and phishing training could be rendered moot. The good news is this bug is limited – senders can’t get responses, and don’t have access to the inbox of the person they are imitating.”

In other Google vulnerability news, it was reported this past weekend that a security flaw in Google Drive could be exploited in phishing campaigns to distribute malicious files that appear to be legitimate documents or images.

This issue, according to The Hacker News, pertains to the cloud-based file storage and synchronization service’s “manage versions” functionality that allows users to upload different versions of a file, updating them as needed without having to change the associated link.

A. Nikoci, the researcher who uncovered the flaw, explained the issue: Google Drive doesn’t validate that new versions of a file have the same extension as the older version, meaning malicious actors can sneakily upload a new version that is actually a malicious executable. This malware can spread if the file has already been shared and downloaded among multiple users, who won’t notice that anything has suspiciously changed when the preview the file online.

While the security hole remains unpatched, there appears to be certain protections that could spare users from infection. For instance, Google uses a suite of antivirus solutions to protect products such as Drive, and files downloaded from Google Drive use a suite of antivirus solutions to help keep products like Drive free from malware, and files downloaded from Drive are scanned for viruses and malware before the download begins – including files uploaded through the “manage versions” feature. And when a new revision is uploaded or deleted, Drive changes the file’s icon if the file type has changed. 

Still, it can be a contentious issue at times when developers and researchers can’t agree on whether a security issue requires an actual fix. It’s one of several issues over which the two parties will occasionally butt heads.

“A common point of contention is the severity of the bug,” said Brian Gorenc, senior director of vulnerability research and head of Trend Micro’s Zero Day Initiative. “We’ve seen this in our program multiple times. For example, one vendor didn’t want to patch a bug because Safe Reading Mode needed to be disabled for the bug to be exploited. We disagreed and published our findings. A week later, the vendor made a patch available. Releasing a patch is an expensive process for a vendor, so if there are mitigating circumstances, they may view the severity differently than the researchers. And sometimes they are correct.”

SC Media reached out to Google for comment.

Leave a Reply

Your email address will not be published. Required fields are marked *