Services
If you read the story about Samsung exposing SmartThings and AWS keys in code, which I came across through a Philippe De Ryck twitter post this AM, you might wonder how on earth those repositories came to be public. It turns out, that’s not that uncommon - and we wrote an open source tool to help clients work through this issue. This post introduces the tool and approach.
Let’s start with a bit of background.
With GitHub, it used to be that you had to be a paid user to create a private repository. Although that changed in January 2019, not all users may be aware and not all similar tools (e.g. GitLab, etc.) may have followed suit.
Also, and very importantly, with GitHub your users are not necessarily tied only to your company. My user mkonda has commits to repositories across various organizations and directly as a generic GitHub user.
For this reason, it was easy for a user to create a public repository outside of their company and sometimes it was hard for them to create a private one inside their company.
Obviously, if you are in this situation, there’s really no excuse for not paying for GitHub and getting private repos. Jemurai has something like 80 of them.
So to restate: private data sometimes ends up public not just because people set the repo visibility wrong, but also because there were constraints on creating private repos.
I would add, we built the tool we’re about to talk about because we saw this with clients - so Samsung isn’t the only one this happened to.
To address this issue, we wanted to be able to find the repositories that users had that were public. Thankfully, Github has a rich API and if a repository is public, we can learn about it.
So we built gaa: [g]o [a]way [a]uditor.
In the GitHub context, the gaa tool looks for users associated with a particular organization, then lists all of the repositories both for the organization and for all the users associated. That gives a quick list we can check.
We also see customers that lose track of their AWS users and access keys. Others need to verify that they have disabled Google Apps users in a timely fashion. So a use case would be to run gaa on a monthly basis and compare the output of the reports. Now you are doing internal user access reviews that an auditor will love.
Incidentally, our securityprogram.io tool can also help you make sure you’re doing all the other things you should be doing to run a decent security program, and gaa fits into that as well.
The promise of Golang really came through on this project. We have been able to produce simple binaries that can be distributed and run on different platforms.
To really get the gaa tool running, you need to provide it with permissions to do so. These are covered in the tool’s README.
You can download the gaa binary from Github or build it yourself.
git clone git@github.com:Jemurai/gaa.git
cd gaa
go buildOnce you have a gaa binary, either by building or by downloading, you can just run it as gaa <system> <scope>. Scope is not required for googleapps and aws because it is implied by the access level of the user running it.
To run it from source just run:
go run main.go github <org> # Github
go run main.go googleapps # Googleapps
go run main.go aws # AWSRight now the tool supports some level of auditing for GitHub, AWS and Google Apps. In the future, we want to:
We’re definitely interested in ideas and feedback. Feel free to create issues on the GitHub project or join us for a conversation in Gitter.
