Public Repos Gone Private: The Impact of GitHub’s Free Private Repos on OSINT

Hey there all you cool Octocats and coders out there, GuidePoint here bringing some exciting news for the increased security of your information and code. GitHub now allows free user and team accounts to create unlimited private repositories with up to three contributors. They still allow unlimited contributors to public repos for free accounts. This seems to be a good faith push from Microsoft after their $7.5 billion acquisition of GitHub was met with skepticism from the developer community regarding GitHub’s future and the possible monetization of GitHub. It appears Microsoft is passing the community an olive branch by increasing services to free accounts. Instead, they’re       refocusing their monetization energies on encouraging large enterprises to adopt paid GitHub accounts to support their bigger team sizes. Not only is this exciting for individuals and organizations who own free accounts out there, but it’s also a big win for security while a detriment to would-be malicious actors.

How Does This Improve Security?

When malicious actors are selecting their targets or launching an attack, they will conduct open-source intelligence (OSINT) investigations to determine what information may be publicly available that can assist them in compromising an organization or people. OSINT can provide many valuable insights for attackers, anything from scathing reviews on Glassdoor that may highlight an organization’s weaknesses and internal jargon to finding phone numbers to attempt to call and elicit information as well as the discovery of valid credentials through pastes, data dumps, and public GitHub repositories, issues, and discussion forums.

When writing code, it may seem straightforward to hardcode credentials instead of obfuscating them when a command must call upon something that requires an account to access. However, by hardcoding credentials into code and then storing that code in a public repository, individuals and organizations alike are handing the keys to their kingdoms over to malicious actors on the hunt for this valuable information. While this may seem like a myth, not only have the members of GuidePoint’s Threat and Attack Simulation (TAS) team discovered hardcoded credentials that have assisted them in client-engagements, but recently released research discovered at least 2,328 unique cases of hardcoded usernames and passwords being used in public GitHub repos.

Using GitHub for Threat Simulation Success

On GuidePoint’s TAS team, we have utilized valuable intelligence discovered on GitHub for a variety of means. Not only can hardcoded credentials be found in code, but sometimes developers insert snippets of code into discussion and issue forums within GitHub. We’ve identified valid internal credentials to client environments, not only through public GitHub repos, but also through well-intentioned devs asking questions without redacting information they either overlooked or believed to be innocuous. When questions are asked on GitHub, the community requests the output that displays the issue. Without careful grooming of this output, it can provide hardcoded credentials, internal hostnames, and IP addresses, as well as demonstrate what services are used and how the organization uses them. With access to service credentials like Ansible and an internal IP address to that instance, we are one step closer to the ‘keys to the kingdom’ within that environment. In some cases, the password works on privileged administrator accounts with no additional effort.

What’s more is that many developers publish their employer in the biography section of their private GitHub repos. From an OSINT perspective, this is great on many levels. It can show us some of the code that the developer is using and depending on the functionality, it may be code that has been modified or used within the organization as well. Further, password reuse is still an extremely common security threat. According to a 2019 Online Security Survey by Google, 65% of people reuse at least some of their passwords, with 13% reusing the same password everywhere. Therefore, even if a developer hardcodes credentials in their personal code stored in a public repo, TAS will use that password against their employer’s environment. To bring this full circle, Microsoft discovered 44 million instances of password reuse within its Windows and cloud services.

Recommendations

GitHub, and its parent company Microsoft, allowing free accounts to create private repos is a huge win for general security. This will facilitate developers being able to work on their code, with contributors, away from the public eye. While hardcoding of credentials should always be avoided, this new feature makes it far more challenging for malicious actors, or your friendly neighborhood TAS team, to gather credentials that could compromise your environments. To further protect your informational assets from prying eyes, GuidePoint recommends you employ the following steps personally and organizationally:

• Convert and currently public repositories to private ones;
• Audit the information disclosed in your organization’s repositories, as well as information publicly shared from your developers’ accounts to limit sensitive internal information being obtained by unintended parties;
• Avoid password re-use within your user-base. Look into deploying an organization-wide password manager, or get yourself one, to simplify and increase the security of your password generation and storage; and
• Want to see how your company would withstand TAS? Reach out – we’re happy to help!

Sources: