Back to BlogA Blue Teamer’s Bug Report
Recently I submitted my first ever bug report! For me, it’s a big deal, since I usually think of bug reports as being something that only red teamers and pentesters are able to find. That is the nature of their profession — poking holes in software and web applications is part of the day-to-day of finding vulnerabilities, testing defenses and detections, etc. And me, I’m a blue teamer through and through.
I was creating reports and detections around different ways of sharing data outside the suite of Google products when I found something that, as a defender, I would consider a definite bug with potentially malicious outcomes surrounding attribution.
I wrote it all up, submitted it to Google…and was told this was more of a “feedback” item and not anything really that important.
But to me, and most defensive security members I know, it is important. So here I am writing about it instead: to let the world know that things may not be exactly what they seem in your Google Workspace logs.
Many of our customers want reports or detections when certain items are shared outside of the organization. Sure, you can block sharing from within G-Suite (now Google Workspace), but that’s not always the point.
Maybe you want to see what documents are being shared the most, or by whom, so that you can improve documentation around that process. Or maybe you’ve come in as a new admin, and there is external sharing happening all over the place and you’re doing your best to lock it down. Whatever the case may be, it’s helpful to take a look at the Workspace logs to see who is sharing what and where. So let’s start out with the issue I found in the logs.
What I Found
The Problem: When a regular Google Drive user in an organization shares documents and other internal information with external parties from their “My Drive,” it does not log the correct user when others add permissions.
External parties could maliciously or accidentally share those documents with unapproved users. When alerting or performing incident response (IR) on those shared files, you would have no idea which account performed the share unless the files were in the “Shared Drive” section of Workspace.
Example:
- Molly, an Acme employee, wants to share a document with an external vendor.
- Molly shares this document from her “My Drive” in her corporate account to her vendors, Pam and Tom. She has been given approval to share it with these two so they can collaborate.
- Pam decides that she wants to use this information on her side gig, so she shares it with another account.
- The log shows that Molly has added a third unapproved account to access this document.
Note: If Molly would have shared this from her “Shared Drive” as opposed to her corporate “My Drive” the logging would have been correct — making it two different outcomes to the same activity.
What You Should Do
When reviewing the logs and setting up sharing permissions for your Google Workspace instance, keep in mind that there can be completely incorrect attribution for the actions performed on sharing outside of a platform.
To prevent this issue, lock down Google Workspace to limit sharing only from the corporate shared drives. You can do this either via a group or Organizational Units (OU) within Workspace admin settings. See Google’s instructions.
With the external share alert rule on, you would see the initial external share but not any share after that.
Bug? Feedback? Important? We at Blumira think so. And now at least a few more people have a heads up on the issue.