Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

11/28/2017
07:40 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
100%
0%

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
Threaded  |  Newest First  |  Oldest First
Where Businesses Waste Endpoint Security Budgets
Kelly Sheridan, Staff Editor, Dark Reading,  7/15/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14230
PUBLISHED: 2019-07-21
An issue was discovered in the Viral Quiz Maker - OnionBuzz plugin before 1.2.7 for WordPress. One could exploit the id parameter in the set_count ajax nopriv handler due to there being no sanitization prior to use in a SQL query in saveQuestionVote. This allows an unauthenticated/unprivileged user ...
CVE-2019-14231
PUBLISHED: 2019-07-21
An issue was discovered in the Viral Quiz Maker - OnionBuzz plugin before 1.2.2 for WordPress. One could exploit the points parameter in the ob_get_results ajax nopriv handler due to there being no sanitization prior to use in a SQL query in getResultByPointsTrivia. This allows an unauthenticated/un...
CVE-2019-14207
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.11. The application could crash when calling the clone function due to an endless loop resulting from confusing relationships between a child and parent object (caused by an append error).
CVE-2019-14208
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.10. The application could be exposed to a NULL pointer dereference and crash when getting a PDF object from a document, or parsing a certain portfolio that contains a null dictionary.
CVE-2019-14209
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.10. The application could be exposed to Heap Corruption due to data desynchrony when adding AcroForm.