Hacker News Reader

Comment by MrStonedOne | Hacker News Reader

The unanswered question is still how this `kickball` account gained control of the gem.

> The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019.

The way I see it, there are a few options:

1. The rubygem was transferred by ruby staff to this account.

2. The maintainer's account was hijacked and then it was transferred, and could even still be compromised.

3. There is some issue or attack vector with the rubygem system that allowed the attacker to gain control.

Any guesses?

View on HN

Option 2 is overwhelmingly likely, IMO. Phishing, password reuse, credential scraping/spamming, and plain old brute force are unbelievably common.

That said, the other two options bear investigation too. Just don't spend time looking for a cold breeze from an un-caulked window frame when the screen door is open.

The true irony, of course, is that the package in question is designed (whether it does or not isn't the point, though I guess if it isn't very good then this becomes all the more humorous) to help prevent people from reusing common passwords or choosing passwords that are easy to brute force ;P... clearly the author should have used this package to select their password that protected the uploads of this package.

We don't know that. Their system could've been compromised in some other way and the password captured.

Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.

Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.

Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems?

The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.

We've heard this before. Yes. Developers using this may decide not to use this gem. Ruby gems in general may lose trust.

If the goal of the project is adoption than do not ignore that group.

so you feel that a group of volunteers with limited funding should do what precisely?

as to losing adoption, that would only happen if

a) there were other options with better security, and given that npm, PyPI and others have had similar problems, there probably aren't

b) Developers would actually move ecosystem due to package manager weaknesses. given that hasn't happened with any of the previous instances of supply chain attacks (and this has been going on for 5+ years now) I don't think so.

As one example, rubygems was compromised in 2013 https://news.ycombinator.com/item?id=5139583 did you or anyone else stop using it as a result?

rubygems is actually given some funding by Ruby Together, I'm not sure with what current budget. https://rubytogether.org/

based on their home page they're somewhere near the lower end of the $20k-$35k category for all funding...

I think that is per month? But not sure.

Think you could be right there, so not a tiny amount of cash but looking at their page not even enough to have a full time dev on the gem tools...

Obv. as a security person I'd say they should prioritise security things like audits and improved Authentication requirements for gem owners, but realistically sounds like just keeping the lights on is pretty expensive.

They work on adding other features to rubygems and other things they fund. If I were them, I would work on nothing but security of rubygems.org gem releases.

Yet another example of supply chain attacks. How do businesses seriously allow their devs to pull code from outside sources, it blows my mind. Npm, Ruby gems, etc etc etc.

Or:

4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.

Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...

That's an extremely ungenerous interpretation of those events. He shouldn't have handed over control of the package to someone he barely knew, but from his perspective, it was that or let the package die. He volunteered his time, he had no kind of obligation to continue if he didn't want to. His actions were certainly not malicious, and he was clearly not "complicit" with the hacker, which is what you're implying.

That incident highlighted a broadly systemic problem with how these kinds of packages are maintained, it was not a case of "one bad maintainer".

I was referring more to the "transferred ownership voluntary" part, not to the complicit, so no, I'm not implying that.

But it is really interesting to see the atmosphere around this systemic problem. Maintainers don't realize that transferring ownership can be putting users in danger, they'd rather transfer the ownership to a random stranger than mark the package abandoned, then they deny it was ever so serious and ask for more money, and their friends and followers rise up to protect them, without ever addressing the central issue, yeah, that's a systemic problem.

Oh come on, you're still giving this guy shit for making a mistake while spending his free time developing it?

Well he still didn't admit it was a bad move, putting other people in danger. If it's abandoned, mark it abandoned, let others fork it. So simple.

Not sure why someone with malicious intent would use their rubygems superpower just to compromise a low profile gem like this. Perhaps it is a targeted attack at a certain website which may now be compromised and we are just seeing the tip of the iceberg.

Option 1 was referring to the attacker tricking a staff working into handing control to them. Maybe by claiming its abandoned?

My bet goes to #3. After [0]this commit, everything is possible in Ruby world.

[0]https://github.com/rails/rails/commit/b83965785db1eec019edf1...

That seems to demonstrate a github vulnerability, rather than anything ruby-specific?

It was a Rails vulnerability (mass assignment) that the attacker used to accomplish this. It’s long since been fixed and doesn’t demonstrate an inherent security flaw with the “ruby world.”

https://gist.github.com/peternixey/1978249

Reply on news.ycombinator.com