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
Newest First  |  Oldest First  |  Threaded View
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
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
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.