Strong_password Rubygem hijacked • Hacker News Board

Re: Strong_password Rubygem hijacked

#121

Post by preinheimer » Mon, Jul 08, 2019, 3:18 PM UTC

danShumway wrote: post #107

ryanlol wrote: post #87

Earlier quoted context omitted.

>Did you check to make sure that the key that popped up was correct, or did you just hit accept? But if you had the key cached, and it changed, you’d probably freak out. >This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. You’ve just isolated the impact of these attacks to new installs, how is that not significant?

Okay, followup question -- when was the last time anyone saw the key change and actually did freak out? If you're using VMs, keys change all the time. Maybe some people here are good about security and would freak out, but I'm thinking about workplaces I've been at, and that's not a typical attitude for developers that I know. If I set up a VM at work and changed the keys on it, I doubt my coworkers would even ask me…

> Okay, followup question -- when was the last time anyone saw the key change and actually did freak out?

Every time. Well, "freak out" is a strong phrase. But I do check with knowledgeable member of team before continuing.

Re: Strong_password Rubygem hijacked

#122

Post by raesene9 » Mon, Jul 08, 2019, 3:23 PM UTC

jrochkind1 wrote: post #118

raesene9 wrote: post #117

Earlier quoted context omitted.

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.

Re: Strong_password Rubygem hijacked

#123

Post by trickstra » Mon, Jul 08, 2019, 3:42 PM UTC

Carpetsmoker wrote: post #105

trickstra wrote: post #99

Earlier quoted context omitted.

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...

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.

Re: Strong_password Rubygem hijacked

#124

Post by contras1970 » Mon, Jul 08, 2019, 3:53 PM UTC

zbentley wrote: post #37

nneonneo wrote: post #25

Earlier quoted context omitted.

In theory, a point release of a library really shouldn’t be requiring new permissions, and you shouldn’t be randomly upgrading your code to newer major versions without checking for compatibility anyway. Why should a functional upgrade of a dependency introduce new dependencies anyway? A library that sets out to do a particular thing shouldn’t grow new features that require new capabilities willy-nilly.

> Why should a functional upgrade of a dependency introduce new dependencies anyway? A library that sets out to do a particular thing shouldn’t grow new features that require new capabilities willy-nilly. Why not? I've often done upgrades with the sole purpose of replacing questionable, hand-written code with external dependencies I've discovered that do the same thing, but better (more features, more tests, more eye…

this reminds me of the Boeing 737 MAX8...

Re: Strong_password Rubygem hijacked

#125

Post by trickstra » Mon, Jul 08, 2019, 3:59 PM UTC

OskarS wrote: post #100

trickstra wrote: post #99

Earlier quoted context omitted.

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. Th…

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.

Re: Strong_password Rubygem hijacked

#126

Post by MrStonedOne » Mon, Jul 08, 2019, 4:43 PM UTC

nurettin wrote: post #93

MrStonedOne wrote: post #6

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 transfe…

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?

Re: Strong_password Rubygem hijacked

#127

Post by djur » Mon, Jul 08, 2019, 8:51 PM UTC

marcus_holmes wrote: post #119

djur wrote: post #31

Earlier quoted context omitted.

Good analysis, but I'm not sure about "a large number of downloads". Download counts can be pretty inflated due to CI/deployment processes that reinstall gems from scratch repeatedly. I've seen open-sourced gems that never got any real usage outside their original company get that number of downloads. To add a bit of a sense of scale here, the popular Devise gem that's used for authentication in many Rails apps has 5…

So...we can all ignore how a popular ruby gem was hijacked and used to infect production webservers with malware because (to paraphrase) "it wasn't that popular"? This was caught because the author diligently checked their dependencies line by line. How many ruby devs do that? How many other gems are already hijacked but haven't been discovered because no-one has audited them? That number is almost certainly non-zero…

No, I didn't say that, and I would prefer that you not put words in my mouth. I was responding to a single statement in the parent comment that I thought was inaccurate.

> a [...] ruby gem was hijacked and used to infect production webservers with malware

I wasn't aware of any reports of this being exploited in production. Do you have an example?

I agree with the rest of your comment about the need for more active measures on the part of Rubygems.org and the likelihood that other gems -- especially infrequently used, semi-abandoned ones like this -- have been hijacked without anyone detecting.

Re: Strong_password Rubygem hijacked

#128

Post by audience_mem » Mon, Jul 08, 2019, 9:10 PM UTC

pharrington wrote: post #32

nneonneo wrote: post #3

This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers. The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected…

> This is a gem that checks the strength of a user-submitted password Does it, though? https://github.com/bdmac/strong_password/blob/master/lib/str...

Could you clarify?

Is the algorithm deficient?

To me that looks like code that indeed checks the strength, so I must be missing something.

Re: Strong_password Rubygem hijacked

#129

Post by marcus_holmes » Mon, Jul 08, 2019, 10:48 PM UTC

djur wrote: post #127

marcus_holmes wrote: post #119

Earlier quoted context omitted.

So...we can all ignore how a popular ruby gem was hijacked and used to infect production webservers with malware because (to paraphrase) "it wasn't that popular"? This was caught because the author diligently checked their dependencies line by line. How many ruby devs do that? How many other gems are already hijacked but haven't been discovered because no-one has audited them? That number is almost certainly non-zero…

No, I didn't say that, and I would prefer that you not put words in my mouth. I was responding to a single statement in the parent comment that I thought was inaccurate. > a [...] ruby gem was hijacked and used to infect production webservers with malware I wasn't aware of any reports of this being exploited in production. Do you have an example? I agree with the rest of your comment about the need for more active me…

fair point, sorry for the implied impugn.

no, I don't have any examples, but then, it's not likely we're going to hear of any - anyone affected is probably unaware (until now, maybe). I guess some might come out of the woodwork now.

But again, Rubygems should have data on who downloaded this version of this gem, and so should be able to warn them, and even publish that data so we know not to visit their sites until they acknowledge and fix.

Re: Strong_password Rubygem hijacked

#130

Post by jrochkind1 » Tue, Jul 09, 2019, 12:13 AM UTC

raesene9 wrote: post #122

jrochkind1 wrote: post #118

Earlier quoted context omitted.

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.