Live data from Hacker News

Incident Report: Inadvertent Private Repository Disclosure

github.com

31–40 of 43 posts

Re: Incident Report: Inadvertent Private Repository Disclosure

#31
post #25

Next step: setup development system ?! Surely they do some end-to-end testing?

They state in the post that of 17 million requests to their git-proxy server, only 230 of those requests could be identified as successful responses to incorrect data/repos, at a percent of 0.0013%. I don't know of anyone that would recommend creating tests, even integration tests, that hammers a service to check to see if something like one hundredths of one percent of requests returns invalid data. If anything, the…

But the overwhelming majority of requests failed with errors. The happy-path was not tested either.

Re: Incident Report: Inadvertent Private Repository Disclosure

#32

We received an email from Github yesterday informing us that one of our repositories had been accessed by a third party due to this issue. While it's not a fun notification to receive, it definitely made our general security paranoia feel justified – we're lucky that from the get-go we've held best practices around keeping secrets out of the codebase. Obviously we still dedicated time as a team to prune through our r…

I got the other end of that email today, saying that an account in my organization had inadvertently downloaded private repos from another customer when fetching from one of our own. Fortunately for GitHub/that user, it was almost certainly our automated provisioning system so we never had any idea and whatever it was never made it anywhere interesting.

The email was kind of funny though, part of it was effectively "if you have this data pretty please delete it without looking at it". I'm sure that's the best they can do, but it still made me chuckle.

Re: Incident Report: Inadvertent Private Repository Disclosure

#33

We received an email from Github yesterday informing us that one of our repositories had been accessed by a third party due to this issue. While it's not a fun notification to receive, it definitely made our general security paranoia feel justified – we're lucky that from the get-go we've held best practices around keeping secrets out of the codebase. Obviously we still dedicated time as a team to prune through our r…

I thought the idea was interesting so here is a little PoC in Ruby:

    require 'facets'
    lines = Dir['**/*.rb', '**/*.py', '**/*.cpp'].map { |f| File.read(f).lines.map(&:chars) }.inject(&:+)
    puts lines.sort_by(&:entropy).map(&:join).last(10).reverse
Using: http://www.rubydoc.info/github/rubyworks/facets/Array%3Aentr...

Re: Incident Report: Inadvertent Private Repository Disclosure

#34
post #33

We received an email from Github yesterday informing us that one of our repositories had been accessed by a third party due to this issue. While it's not a fun notification to receive, it definitely made our general security paranoia feel justified – we're lucky that from the get-go we've held best practices around keeping secrets out of the codebase. Obviously we still dedicated time as a team to prune through our r…

I thought the idea was interesting so here is a little PoC in Ruby: require 'facets' lines = Dir['**/*.rb', '**/*.py', '**/*.cpp'].map { |f| File.read(f).lines.map(&:chars) }.inject(&:+) puts lines.sort_by(&:entropy).map(&:join).last(10).reverse Using: http://www.rubydoc.info/github/rubyworks/facets/Array%3Aentr...

Is it easy to modify this script to run over all lines that have ever existed in the repository history?

For example, could you pipe the output of `git log -p --all` through this and filter out all the commit hashes somehow?

Re: Incident Report: Inadvertent Private Repository Disclosure

#35

We received an email from Github yesterday informing us that one of our repositories had been accessed by a third party due to this issue. While it's not a fun notification to receive, it definitely made our general security paranoia feel justified – we're lucky that from the get-go we've held best practices around keeping secrets out of the codebase. Obviously we still dedicated time as a team to prune through our r…

Of the very small number of repos affected, there are now two of us reporting that it affected us :). And I had the same approximate response: well, I don't keep secrets in the repository, so not that big of deal. I'd rather the source not get shared with the world, but shit happens and they owned up to it right away. If that source were valuable enough, I'd be hosting it on-prem with encrypted off-site backups.

Re: Incident Report: Inadvertent Private Repository Disclosure

#36
post #23

Earlier quoted context omitted.

This github vulnerability has nothing to do with insecure box. It has to do with a bad application logic. This can happen anywhere - self-hosted or not.

That is true. But, if I'm running my own instance, the probability is that it doesn't matter if someone else gets access via bad application logic. Everybody is probably employed by the same company. It's a difference of degree: compromising my self-hosted or on-premise server means that somebody already in my employ has more access than they should. If I'm a small organization, that probably doesn't matter. If I'm a…

Well, the code can simply be made public by bad application logic. Which is why I thought you where talking of on premise where the intranet will seal off outsiders

Re: Incident Report: Inadvertent Private Repository Disclosure

#37
post #34
post #33

Earlier quoted context omitted.

I thought the idea was interesting so here is a little PoC in Ruby: require 'facets' lines = Dir['**/*.rb', '**/*.py', '**/*.cpp'].map { |f| File.read(f).lines.map(&:chars) }.inject(&:+) puts lines.sort_by(&:entropy).map(&:join).last(10).reverse Using: http://www.rubydoc.info/github/rubyworks/facets/Array%3Aentr...

Is it easy to modify this script to run over all lines that have ever existed in the repository history? For example, could you pipe the output of `git log -p --all` through this and filter out all the commit hashes somehow?

Yup, just use:

    lines = `git log -p --all`.lines.map(&:chars)
So I found that `git grep /.+/ $(git rev-list --all)` is a better way to get the content of all the files: https://gist.github.com/Dorian/e1514535c3c5036cf327ce61eb34a...

But actually an hex number regexp might me far more accurate than the entropy (e.g.: secrets are often long hex numbers).

I tried it and it yields interesting results: https://gist.github.com/28110f0b8105db11e8973d1d0be85259

Post reply on HN