It’s been said many times that the benefit and curse of software is that it allows developers to easily create of a multitude of settings in applications. Want your application to be customized? Piece of cake. Want it to be secure? That may be a problem if admins don’t properly configure the settings.
The latest configuration problem was revealed Monday by RedLock Inc., which makes cloud infrastructure security controls tools, whose researchers found hundreds of organizations using Google Groups for creating discussion groups have checked the wrong setting and risk public exposure of messages with sensitive corporate information.
The mistake: The sharing option for “Outside this domain – access to groups” has been set to “Public” instead of “Private.”
Set for “Public,” anyone on the Web who can figure out the Group’s address can read its email and text messages depending on the access settings. “Private” limits access to an approved domain.
“We internally use Google Apps,” said CEO and co-founder Varun Badhwar, who explained the discovery in an interview. “Our team was looking at configurations in our environment and realized that it was pretty easy for someone to shoot themselves in the foot by [accidentally] making something public” in Google Groups. And it confirmed that by searching the domains of a thousand big companies. RedLock then warned vulnerable firms.
Google documentation warns about this.
RedLock’s warning comes as word spreads about a number of data exposures blamed on misconfigured Amazon AWS Simple Storage Service (S3) storage buckets. Earlier this month a research team at security vendor Upguard, which has been watching for this particular problem, said in the most recent incident a cloud-based file repository owned by financial publishing firm Dow Jones & Company had been configured to allow semi-public access. Personal information of least 2.2 million customers were exposed. Dow Jones says this was an “internal error” and not a hack. The data was exposed only on AWS and not the public internet, he told SC Magazine.
Upguard also reported that that a misconfigured S3 bucket of data held by a partner of Verizon Communications exposed the names, addresses, account details, and account personal identification numbers (PINs) of as many as 6 million U.S. customers.
“The configuration of cloud-based storage by enterprises to allow public or semi-public access is by now an all-too-common story,”said Upguard’s DanO’Sullivan in a blog, “a move that needlessly exposes sensitive customer data to the risk of exploitation. The threat of such misuse is all too real, and indeed, has grown endemic, with a burgeoning cyber underworld in which malicious actors are able to swiftly take advantage of such user lapses for their own benefit.
Despite the best efforts of infosec admins around the world configuration problems with cloud services and providers isn’t a small problem, said Badhwar. “I think it’s huge. They’re servicing hundreds of thousands of customers. They can provide a platform or an application infrastructure so the data centres themselves are secure, making sure the data you store is secure. But at the end of the day all of us as consumers as these cloud services have a shared responsibility” for security and network configuration.
He cited a Gartner blog that made the same point:
“Ultimately the responsibility lies with the organization to exert control over cloud,” wrote the author. “Secure and regulatory-compliant use of public clouds requires that enterprises implement and enforce clear policies on usage responsibility and cloud risk acceptance processes.
“Organizations that don’t take a strategic approach to the secure use of cloud computing could find themselves in an unsecure, inflexible or uncompetitive situation.”
Perhaps its time developers coded large red warnings in privacy and security settings to make sure administrators know about pitfalls.
