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.

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

An exploitable command injection vulnerability exists in the measurementBitrateExec functionality of Sony IPELA E Series Network Camera G5 firmware 1.87.00. A specially crafted GET request can cause arbitrary commands to be executed. An attacker can send an HTTP request to trigger this vulnerability...

In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response.

In Eclipse OpenJ9 version 0.8, users other than the process owner may be able to use Java Attach API to connect to an Eclipse OpenJ9 or IBM JVM on the same machine and use Attach API operations, which includes the ability to execute untrusted native code. Attach API is enabled by default on Windows,...

Systems with microprocessors utilizing speculative execution and Intel software guard extensions (Intel SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.