People keep misconfiguring G Suite to leak their companies’ private data. An estimated 10,000 or more organizations are affected.
Google denies it’s a bug, passive-aggressively telling people to RTFM. But that’s not the point, is it? Given the scale of the problem, shouldn’t la GOOG be fixing an obvious admin UX problem?
It reminds me of the open S3 bucket issues we keep seeing—e.g., Experian/Alteryx and the NSA/Army. In this week’s Security Blogwatch, Google could do better.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Allen Smithee …
Google blamed for bad UX
What’s the craic? Brian Krebs pedals in to ask, Are Your Google Groups Leaking Data?
Groups is a service from Google that provides discussion groups. [But thousands of] household names are leaking sensitive data in their message lists [including] passwords and financial data, and … comprehensive lists of company employee names, addresses and emails.
…
Many organizations seem to have used Google Groups to index customer support emails, which can contain all kinds of personal information [or] a tremendous amount of information about the organization itself. … This information could be a potential gold mine for hackers seeking to conduct … spearphishing attacks [or] for criminals who specialize in … “CEO fraud” schemes, in which thieves spoof emails from top executives to folks in finance asking for large sums of money to be wired.
Well, Read The Fine Manual, amirite? Richard Chirgwin says it’s that simple—G Suite admins need to RTFM:
If you're sysadmin of an organisation using Google Groups and G Suite, you need to revisit your configuration. … Sysadmins appear not to be taking the matter seriously.
…
When a G Suite admin creates a Groups mailing list for specific recipients, it configures a user-accessible Web interface for the list. … The misconfiguration happens when Groups Visibility is configured to Public [but] if the group is meant to be internal … the Google Group setting should be private.
…
The things shared on groups people believe to be private included customer reviews, invoices payable, password recovery/reset e-mails, and more.
…
Because it's a configuration issue, Google doesn't consider it a vulnerability to be fixed. Admins: RTFM.
Who discovered this common SNAFU? Kenna Security, as reported by Dan Mellinger—Widespread Google Groups Misconfiguration Exposes Sensitive Information:
Due to complexity in terminology and organization-wide vs group-specific permissions, it’s possible for list administrators to inadvertently expose email list contents. [We] performed a sampling of top domains, discovering over 9600 organizations with public Google Groups settings, and determining 31% … are currently leaking.
…
Extrapolating from the original sample, it’s reasonable to assume that in total, over 10,000 organizations are currently inadvertently exposing sensitive information. [This issue] or a slightly modified version … appears to be the root cause of a data breach at Boston College earlier this year. The scale of the issue has not been discussed publicly until now.
…
[It] is in many ways reminiscent of the issues surrounding public AWS S3 buckets. [It] isn’t considered a vulnerability [by Google] so the disclosure ended with a “won’t fix” status, even after providing a listing of affected organizations.
…
In affected organizations, the Groups visibility setting … is configured to “Public on the Internet”. … While they are not selected by default, affected organizations have configured them, presumably without understanding the implication.
No warning is provided about the potential implications outside of the setting description.
Should Google do more? Google doesn’t think so, according to this skillfully worded PR response:
As with any communication tool, it’s important that your settings deliver the right balance between sharing and security. … It’s important to understand how you can tailor the privacy configurations of Google Groups to align with your organization’s policies.
…
Public on the Internet means … individuals outside your domain can access content. … We recommend you choose the setting that makes the most sense based on how your organization uses Google Groups.
Is that fair? No, thinks Michiel Hendriks, who says the Google UI is terrible:
Configuring settings for Groups is horrible. There are a whole bunch of settings, which do not really align with Google's recommendations.
And there is also no option to check if any of the groups which exist are readable from the "internet". You have to check every single group, and then 4 different sections, etc.
It’s worse that that, shouts this weary, sweary Anonymous Coward:
The geniuses at Google don't think it's necessary to add features that EVERY ****ING EMAIL SERVICE PROVIDER SUPPORTS. So to do something as simple as set up a forward for a single address to, say, 3 others, you have to create a group.
It is COMPLETELY ASININE. Even worse is that the settings are a complete cluster ****, so trying to properly configure a group often leads to the merging of your forehead and your keyboard.
**** you Google.
Now it must be time for another Anonymous Coward to whine about “The Cloud”—Everybody move to the cloud!:
Go to the cloud!
It's more secure and safer than your own server!
Google experts know more about security than anyone you could afford to hire!!!
CLOUD! CLOUD! CLOUD!
CLLOOOOOOOUUUUUUUUUDDDD!
****ing idiots.
Aaaanyway. So we think more than 10,000 organizations are affected—but how big a deal is that, really? Michael Heller adds context:
For context, there are currently more than 3 million paid G Suite accounts and an unknown number of free G Suite accounts. … A source close to the situation said … Google has sent out messages to users who may be affected with instructions on how to fix the Google Groups misconfiguration.
But ratfox ain’t buying the PR spin:
When enough people make a mistake, it stops being a user issue, and it becomes a UI issue.
And sabroni digs deeper:
If your user interface design doesn't take users into account then it's not the users chair and keyboard that delimit the issue, it's yours.
Meanwhile, a hollow-voiced Androgynous Cupboard makes a Colossal gag: [You’re fired—Ed.]
For all the clever-clogs saying RTFM - that might have flown when Google Apps launched, but it is showing all the signs you'd expect after all these years: scope creep, poor mergers of acquisitions with different concepts, abandoned approaches etc. in the documentation.
You are in a twisty maze of hyperlinks, all alike.
The moral of the story?
If you get a bug report like this, don't just hide behind a "not a bug" reply. Protect your customers!
And finally …
by seminal movie reviewer Mark Kermode
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Image source: Chad Cooper (cc:by)
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
