Application Security

4/24/2018
10:30 AM
Kumar Saurabh
Kumar Saurabh
Commentary
Connect Directly
LinkedIn
Twitter
RSS
E-Mail vvv
50%
50%

It's Time to Take GitHub Threats Seriously

There's a good chance your company has projects on the source code management system, but the casual way many developers use GitHub creates security issues.

Security operations teams are plenty busy dealing with malware, phishing, and distributed denial-of-service attacks. But there's an area of IT that many SecOps teams haven't been able to sufficiently monitor, despite the risk of data breaches, loss of competitive advantage, and loss of reputation.

What's this unnoticed vulnerability?

It's GitHub, the hugely popular source code management system. Companies and individuals use GitHub to store and manage source code and to keep software development projects running on time. Packed with useful features and featuring a user-friendly interface, GitHub has become the largest source code repository in the world. It now stores over 80 million source code repositories. It's used by Facebook, Google, and Microsoft for some of those companies' most important software projects.

GitHub is clearly a success story. Why should SecOps teams care?

That's because, given GitHub's popularity, there's a good chance their company's development team has at least some projects stored in GitHub. And they should care because it's become obvious in the past couple of years that the casual way some developers use GitHub creates serious security risks. These risks exist even if developers are following best practices such as running source code analysis tools like Fortify to identify any security vulnerabilities in the source code being checked in.

Casual security practices are risky enough. They become riskier when hackers have a strong incentive to target the casually managed system.

Why Hackers Target GitHub
Hackers like GitHub for several reasons.

  1. Source code. The software stored in GitHub is valuable intellectual property. Copying the code may enable other companies or even nation-states to quickly develop derivative applications, saving years or even decades of development time and leveraging trade secrets without paying licensing fees. Hackers might also steal code to resell it on the Dark Web.
  2. Attack vectors. The source code might provide hackers with insights into how to attack software running in production. Stealing source code gives them time to search for vulnerabilities that might be much more difficult to discover through penetrations. They can even run code in production and test attacks against it, refining attacks for speed, stealth, and effectiveness.
  3. Login credentials. Code and supporting files checked into GitHub sometimes inadvertently contain login credentials for other services, such as Amazon Web Services. When hackers gain access to the code, they can gain access to related services, giving them the opportunity to steal more data and disrupt operations.
  4. Unauthorized access. Often, developers are granted access to company repositories from their personal email accounts. These accounts are left vulnerable, especially after developers leave. Additionally, often developers are granted access to all of the company's repositories instead of just what they need, creating a wide-open attack surface.
  5. Insider threats. A lack of proactive monitoring can allow malicious insiders to easily hide abnormal activities. A single developer accessing tens of repositories could be an early indicator of insider threat, and such behavior should be detected and flagged. 

Login credentials were part of the haul in a 2016 data breach when hackers penetrated Uber's source code repository on GitHub. Attackers not only gained access to cutting-edge intellectual property; they also came across AWS credentials that yielded personal data of about 7 million Uber drivers and 50 million customers. That personal data included names, addresses, driver's license numbers, and more. 

Threat Monitoring for Github
Fortunately, there are some practical steps that SecOps teams can follow to tighten the security of their organization's GitHub repositories. Here's a list:

  1. Clean up login credentials. Remind developers that they should be careful with their GitHub login credentials. Limit access only to those developers who need to be involved in a project. When developers leave a project, their credentials should be revoked.
  2. Double-check repository settings. The software behind GitHub, the software version control program Git, was originally developed for managing development of the Linux kernel. Both Git and GitHub are widely used in open source projects. Some developers, particularly those used to contribute to open source projects, treat all GitHub repositories as public, whether they're open source projects or not. Double-check your organization's GitHub configuration to ensure that access isn't any broader than it needed.
  3. Don't mix secrets with public code. Remind developers to be careful about including login credentials and other highly sensitive information in code, GitHub wikis, or other GitHub content accessible to outsiders. Since the Uber breach, GitHub has urged developers to be careful about this, but a periodic reminder from the SecOps team never hurts.
  4. Monitor GitHub for suspicious activity. What sort of activity merits suspicion? A sudden spike in source code check-ins, enabling someone to check out an unusually large amount of source code. Also watch for logins from unusual locations or logins or requests from users outside the organization.
  5. Collect GitHub logs. The best way to continuously monitor GitHub is to collect logs of GitHub data for your organization's repositories. If you're not collecting GitHub logs now, start.
  6. Perform a baseline security assessment of GitHub activity. Tools are available for analyzing activity reported in GitHub logs, so that you can define a baseline of normal activity that will make it easier for you to spot anomalies in the future.
  7. Automate the monitoring of GitHub logs. You'll want to monitor GitHub activity routinely to ensure that your organization's source code is secure and that outsiders aren't trying to infiltrate your repositories. You may be able to write scripts to perform this automation, or you can seek out a pre-built automated solution.

Software code is likely one of your organization's most valuable assets. Make GitHub part of your SecOps team's routine threat-hunting work, and you'll safeguard not only that valuable asset but also your organization's reputation and competitive edge.

Related Content:

Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry's most knowledgeable IT security experts. Check out the Interop ITX 2018 agenda here. Register with Promo Code DR200 and save $200.

Kumar Saurabh is the CEO and co-founder of security intelligence automation platform LogicHub. Kumar has 15 years of experience in the enterprise security and log management space leading product development efforts at ArcSight and SumoLogic, which he left to co-found LogicHub. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
sd@gitstorage.com
50%
50%
[email protected],
User Rank: Apprentice
9/7/2018 | 2:53:36 PM
Nice article!
Nice article, very informative. I have found that gitstorage addresses several threats to the source code. 
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.