Repositories held for ransom by using valid credentials • Hacker News Board

Re: Repositories held for ransom by using valid credentials

#151

Post by rightbyte » Sun, May 05, 2019, 2:35 PM UTC

tyingq wrote: post #41

raverbashing wrote: post #31

Earlier quoted context omitted.

> So you’re telling me that if, say, Google’s Search algorithm got leaked Google's search algorithm was public for a long time [0], it's been improved now and more under the curtains, but the answer is no. Google wins not only by technology, but also by size of the index [0] https://en.wikipedia.org/wiki/PageRank

I believe Google has also bolted enough ML to search that they couldn't really recreate current search with just code.

Also the code base is probably so big and esoteric that there is no way to replicate the services without knowledge external to the repo.

You can get bits and parts and it would be disastrous for Google, but you would need 1000 engineers to reverse engineer the source code into some working search engine or what ever service you would want to replicate.

I've been thinking about what if the competitors got hold of my employers code base. I think it would require years of reverse engineering to get anything useful out of it for their product, and that they could just as well put that effort into their product directly without espionage.

Re: Repositories held for ransom by using valid credentials

#152

Post by frandroid » Sun, May 05, 2019, 2:53 PM UTC

weinzierl wrote: post #124

bostik wrote: post #102

Earlier quoted context omitted.

And a hundred times so for any public repos. There are bots feeding on the GitHub firehose, scavenging for accidentally committed credentials. A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes . Surely that time has only gone down, and the number of different credentials identified has gone up.

> A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes. Surely that time has only gone down, and the number of different credentials identified has gone up. I don't doubt that a second and I'd like to use that as a quote. I'd like to be prepared if someone doubts it, so: Do you have a primary source for this?

I thought that AWS nowadays is also feeding at the firehose and auto-disabling any of its keys it could find in a commit?

Re: Repositories held for ransom by using valid credentials

#153

Post by avar » Sun, May 05, 2019, 3:56 PM UTC

jtl999 wrote: post #148

avar wrote: post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

> One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. Does this also apply to self hosted GitLab CE/EE? Also how does Gogs/Gitea handle this?

What I outlined applies to self-hosted GitLab, it just uses git's default settings, and I'm assuming gitlab.com does the same.

Of course if you self-host you can simply change the defaults in /etc/gitconfig (which is in /opt/... if you're using the omnibus package).

Re: Repositories held for ransom by using valid credentials

#154

Post by bostik » Sun, May 05, 2019, 8:00 PM UTC

bostik wrote: post #125

weinzierl wrote: post #124

Earlier quoted context omitted.

> A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes. Surely that time has only gone down, and the number of different credentials identified has gone up. I don't doubt that a second and I'd like to use that as a quote. I'd like to be prepared if someone doubts it, so: Do you have a primary source for this?

I'll need to find the talk I lifted it from. Not easy... but looks like downthread a sibling comment gives a relatively decent update about the current speed of compromise.

Answering myself: I think it was a BSides London talk. (Quite likely from 2017.) After doing a search, I don't think it was recorded.

Hence, I can't provide a primary source. Sorry.

Re: Repositories held for ransom by using valid credentials

#155

Post by solatic » Mon, May 06, 2019, 3:34 AM UTC

lostmyoldone wrote: post #40

avar wrote: post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

Re GitHub keeping unreachable data, if I understand it right, isn't that GitHub painting a giant target on their back? Wouldn't that that imply every secret accidentally committed and then 'deleted' is still accessible, when one would expect it not to be? It's one thing to have your source code in the wild, but pairing it up with thought-to-be-deleted secrets would be an absolute disaster. Certainly one should not ev…

This is precisely why secret rotation mechanisms are essential. If you are regularly rotating your secrets, your window of vulnerability for an accidentally leaked secret reduces to the rotation window. With good automation, and in the context of secrets which don't need to be remembered or input by a human, your secrets should be rotating nearly constantly. Additionally, automation greatly reduces the risk of human intervention, which reduces the risk of a human writing secrets to files by hand, which reduces the risk of those secrets being committed to version control in the first place.

Of course, automatic secret rotation is hard. Vault is a great help, but it can't be grafted onto everything. Good DevSecOps engineers are worth their weight in gold.

Re: Repositories held for ransom by using valid credentials

#156

Post by greggyb » Mon, May 06, 2019, 2:50 PM UTC

lolc wrote: post #150

greggyb wrote: post #62

Earlier quoted context omitted.

And an additional observation. Many applications that allow a user to pick their time zone typically show offsets from UTC and a time zone name. It bugs me to no end when I have to select something like "-5:00 Eastern Time (US/Canada)" in those dialogs. I think a lot of people just don't care enough to truly understand time zones and there is enough flexibility in human communication to just absorb the endless ream o…

Few people appreciate the difference between timezones and their UTC offset at a given date. That's because it's very unattractive to learn about DST. Without that, timezone offsets are relatively stable and it wouldn't matter (in the short term) which one you'd work with. I'm just glad I don't need to have the "DST" talk more often. It takes people a night of sleep to process the level of time fuckery that is DST. C…

I steer into the skid. I've acquired several clients by giving talks on implementing time intelligence on several analytics platforms.

More often I deal with fiscal calendars, rather than DST issues. The thing it takes them some time to realize is that their attempts to use date functions built around the standard calendar lead to huge pain when dealing with their weird fiscal calendar.

Re: Repositories held for ransom by using valid credentials

#157

Post by ndarwincorn » Mon, May 06, 2019, 11:29 PM UTC

sytse wrote: post #149

the_duke wrote: post #123

Earlier quoted context omitted.

Also any commits pushed between the last snapshot and the deletion would be lost too.

Correct

Hey, since I'm having trouble getting a response from support/security and I know you're active on here, can you get someone to respond to this ticket (related to OP)? I don't usually try to publicly escalate something like this but it's urgent and the ticket's gone 24 hours+ without a response.

https://support.gitlab.com/hc/en-us/requests/120506

Re: Repositories held for ransom by using valid credentials

#158

Post by house9-2 » Tue, May 07, 2019, 4:40 AM UTC

tjr225 wrote: post #140

scarface74 wrote: post #137

Earlier quoted context omitted.

Why have credentials anywhere outside of the .aws directory in your home directory? When developing locally all of the SDKs will read them from there and when deploying to AWS, the SDK will get them from the attached role.

I understand what the best practices are, it was a total mistake- I never even intended to push what I did to github.

`git diff` before making a commit `git log` and `git show` before pushing to a remote

These 2 simple things have saved me on more than one occasion.