Application Security
11/28/2017
07:40 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Git Some Security: Locking Down GitHub Hygiene

In the age of DevOps and agile development practices that lean heavily on GitHub and other cloud resources, strong controls are more important than ever.

It might be fashionable to pile on Uber with criticism for its sloppy handling of data in a GitHub repository that contributed to the recently disclosed breach of tens of millions of Uber customers. But let's not stack up those rocks inside our glass houses just yet. Uber's mistake was bad, but it was far from exceptional. The truth is that as GitHub has exploded in popularity among modern developers, so too has the number of insecure repositories rife with poorly controlled sensitive information.

Uber is just one of many embarrassing exposures via the GitHub platform in the past few years, and by the looks of it, it won't be the last. In just the last month, we've seen two other public snafus. In one instance, a security researcher found that a Chinese drone maker left the private key for its Web certificate exposed on GitHub for four years. Meanwhile, another incident saw criminals managing to steal $64,000 worth of cloud infrastructure usage from an outsourcing firm by using its AWS private keys, which were stored on a public GitHub repo.

Even more embarrassing, earlier this fall consulting firm Deloitte left corporate VPN passwords, user names, and very sensitive operational details on a public GitHub repo. These are just a few anecdotal lowlights among what security experts say is a growing epidemic of similar incidents

"Cloud services like GitHub offer enormous value for private companies and government organizations that are in need of distributed, outsourced infrastructure to operate," says Mike Baukes, co-CEO of UpGuard. "Yet misconfigured cloud assets litter the Internet, publicly accessible to anyone who stumbles upon them. These misconfigurations are the result of bad or nonexistent controls on data handling processes and a lack of automated monitoring for whether those controls are really being followed."

Founded nearly 10 years ago, GitHub has grown to become the de facto code repository platform, particularly among DevOps and agile development teams. In the interim, the platform has garnered 24 million users across 1.5 million organizations. This loyal contingent is running more than 67 million repositories on the platform. Because code in and of itself is often proprietary and the cornerstone of organizations' competitive differentiation, the contents contained in these repos are sensitive by their very nature, says Baukes.

"When you add in encryption keys and other stored credentials, as well as non-code files, like server or application configurations, it becomes clear that privacy is a major concern," he says.

The problem doesn't lie with GitHub. The firm has taken tons of steps to secure its underlying infrastructure, make accounts secure by default, and teach customers how to securely configure and control data on their repos. The problem is, as with any cloud platform, the buck always stops with the client organization.

"There are tools available right now within GitHub that automatically check code for embedded access credentials such as AWS API keys," says Zohar Alon, CEO of Dome9. "This is something that any organization that is developing code can and should implement whenever a software engineer checks in code to GitHub. Relying on a developer or administrator to follow best practices is foolhardy at scale, and the errors seem to be more egregious each and every time a breach makes the headlines.”

Ultimately, it comes down to sound governance and technological controls to ensure the rules are being followed. On the governance side, Baukes says enterprises shouldn't be allowing developers or anyone else to store proprietary code on public GitHub accounts. And even with corporate GitHub accounts, a number of precautions need to be in place.

"The default repository configuration should be set to private," he says. "All GitHub users should use two-factor authentication. Repos in the corporate organization should be regularly audited for both public exposure and permissions. Users should also be required to include their real name on their account so that spotting aberrant accounts is easier."

Additionally, organizations should be looking out for how their outsourced vendors use GitHub. Ideally, vendor assessment should track how well third parties adhere to similar best practices in flowing data through GitHub. 

At the end of the day, the only way to provide assurance over this behavior is through automated controls that can ensure the rules are being followed. 

Related Content:

 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cybersecurity Must Be an International Effort
Kelly Sheridan, Associate Editor, Dark Reading,  12/6/2017
NIST Releases New Cybersecurity Framework Draft
Jai Vijayan, Freelance writer,  12/6/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.