- Unsupervised Learning
- Posts
- Securing Your Public Source Code Repositories
Securing Your Public Source Code Repositories
Public source code repositories, such as those available on Github and similar services, are extraordinarily powerful. They allow programmers to share their projects and get feedback from fellow coders.
But there are downsides to being this transparent with one’s source code.
Many who use services like Github aren’t aware of what they’re sharing, nor of how easy it is for attackers to find that content and use it to their advantage.
Looking through public code repositories it’s easy to find things like:
Hardcoded passwords
Sensitive configuration files
Database connection strings
Private SSL keys
Private SSH keys
Uploaded Unix/Linux home directories, with sensitive dotfiles
~/.ssh directories full of keys
Source code of projects you’re currently doing blackbox testing on
Etc…
These attacks aren’t new, but it’s getting increasingly easy to find these types of issues in public code, and you probably want to be ensuring that your code is not vulnerable in the same way.
So let’s look at some of the tools that are available for 1) finding the repos, and 2) finding the issues in those repos.
Finding repositories using Recon-NG
Starting at the beginning (finding code to search) ReconNG has a great module for finding code repositories for a target, called <code>github-repos</code>.
So let’s say a certain organization is in the scope of a penetration test, or is an actual target of an attack, and you want to know what the public code surface area is.
Go into this module, set a source, and then run it. Here we’ll look for Google.
Google has a lot of repos.
Finding vulns once you have repos
Once you have repositories to look at, you can then search them for many different types of issues.
GitRob, for example, is a great project byMichael Henriksen that has a pretty strong set of signatures for sensitive content, but requires a full database setup and its own web server. A bit heavy for my taste.
[ GitRob signatures sample ]
A lighter approach to finding issues in public code
On the other side of the spectrum is Github Dorks by Samar Dhwoj Acharya. It’s far lighter and is mostly maintaining a list of discovery strings, combined with a script for calling them.
[ Github Dorks strings sample ]
Finding obscenely bad code, in multiple languages
Unsupervised Learning — Security, Tech, and AI in 10 minutes…
Get a weekly breakdown of what's happening in security and tech—and why it matters.
Finding hardcoded passwords and private keys and sensitive dotfiles is good stuff, but I had another idea that I thought could be fun.
We know that processing raw input from users is bad, right? And we know how people do this in PHP, right?
So why not search for people doing it? And why not do the same for lots of different vulns?
Doing this you can potentially find obvious, critical vulns right in the source, e.g.:
XSS
SQLi
L/RFI
Header Injection
Buffer Overflows
Most languages have their own versions of doing these, and the strings are easy to find and collect.
So that’s what I did, along with the strings for all the other types of strings for sensitive information disclosure talked about above.
I’ve brought the strings together into a new project called Repilfer.
—
It’s frustrating that the various tools have different signatures and that they are in different formats. But it’s a common problem with security tools, and it’s why a friend and I created the SecLists project. It’s a single repository of the types of lists and strings that are needed by penetration testers during their daily work.
To that end I’ve collected the various signatures from like a dozen of these tools (plus a bunch of my own) into this file in the SecLists project. And as I and other people find more good searches, I’ll keep the file updated.
Summary
Public source code repositories are powerful in their sharing capabilities, but with that power comes risk
There are a number of tools out there that attackers already know about for finding sensitive content in your publicly facing code
You should be making sure that your code, and the code of people you care about, don’t have these issues
You can do that by knowing about, and periodically testing your stuff with, these tools
Stay safe out there.