Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rest-client gem is hijacked

github.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Rest-client gem is hijacked

#91

Post by kevin_thibedeau »

0x0 wrote: post #77
mwmanning wrote: post #75

Earlier quoted context omitted.

Yeah I'm assuming the methodology is: 1) Find high-value target libraries 2) Grab the usernames of accounts with push access 3) Check those against password dumps I feel really stupid about this, but like I said it was an oversight. I apologize and will try to do better.

Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!

That's not very practical if salted hashes are being stored.

Re: Rest-client gem is hijacked

#93

Post by gmontard »

That is sadly a good example of why relying on trusted and accountable API clients should be considered critical for business.

When consuming APIs and not thinking about this, we are only building technical debt and security issues for the future.

Today's example is really bad since it targets a well-used meta API open-source library, but how many of those issues are already present on hundreds of other obscure open-source API clients?

Re: Rest-client gem is hijacked

#94

Post by whorleater »

raesene9 wrote: post #60

For all the people who are rightly concerned about these attacks here's a a couple of questions - Would you pay money for access to a package repository that had good security practices? How much would you pay? Would you accept delays in library updates to allow for security checks? If so, how long a delay would be acceptable. - Have you ever looked into the security practices of open source applications or libraries…

Half of these is the Red Hat business model.

Re: Rest-client gem is hijacked

#95

Post by marcus_holmes »

dspillett wrote: post #83
0x0 wrote: post #77

Earlier quoted context omitted.

Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!

If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time. The best approach is probably to disable the account completely until an interactive login is made and a pass…

If a gem maintainer is re-using a known-compromised password they have absolutely zero right to be annoyed at the "inconvenience" of having to reset their password to something that isn't compromised.

RubyGems has a responsibility to its users and community here. It (like npm) needs to take this stuff seriously.

Re: Rest-client gem is hijacked

#96

Post by marcus_holmes »

kevin_thibedeau wrote: post #91
0x0 wrote: post #77

Earlier quoted context omitted.

Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!

That's not very practical if salted hashes are being stored.

but the salt is in the database. You can hash all the known-compromised passwords with the salt and see if any match.

Re: Rest-client gem is hijacked

#97

Post by krferriter »

bpicolo wrote: post #27
sersi wrote: post #2

I think that rubygems should consider automatically enforcing multifactor authentication for popular gems. So any gem with more than 50,000 downloads should force to gem maintainer to have MFA set up before they can publish a new version or do anything with that gem. Because, having MFA is not about protecting gem maintainers, it's about protecting users. So, gem maintainers should not be allowed to be careless with…

Or just any gem, period, regardless of download count? Seems like a fair minimum baseline for publishing to a public repository. MFA in modern times is low-effort.

Yeah should be for all gems, and same goes for npm and pip registries. If you're publishing code to an official public registry for pulling and execution by other users in the ecosystem, multifactor authentication should be required. Agreed that the effort required to add this nowadays is fairly small, such that it should be more widespread.

Re: Rest-client gem is hijacked

#98

Post by josephwegner »

dspillett wrote: post #83
0x0 wrote: post #77

Earlier quoted context omitted.

Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!

If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time. The best approach is probably to disable the account completely until an interactive login is made and a pass…

Heroku did this about a year ago. They have a list of known pwned passwords (probably haveibeenpwned, but honestly I'm not sure), and disallow accounts to use those passwords. When that change was implemented, any account using a pwned password had that password expired.

https://status.heroku.com/incidents/1625

(source: I work for Heroku Support)

Re: Rest-client gem is hijacked

#99

Post by gotts »

derimagia wrote: post #89
gotts wrote: post #71

Earlier quoted context omitted.

it surprises me a bit. I'm wondering why wouldn't RubyGems implement some basic form of malware detection? This type of code shouldn't be too hard to classify.

Malicious users would just change their code slightly to get past it. Use a different service than pastebin, or just obfuscating it more.

After thinking about.. I think you must be right. Malware detection is not an easy task especially because of Ruby's dynamic nature.

Even simple open(), sleep(), eval() could be easily obfuscated.

Re: Rest-client gem is hijacked

#100

Post by deckard1 »

raesene9 wrote: post #45
jcoby wrote: post #40

Earlier quoted context omitted.

> there really is no easy fix Is there any fix at all? Aside from something like multiple-account code signing/release verification I cannot think of something that couldn't be compromised in some way. At the end of the day you have to trust someone and trust that they trust someone else. The problem is you have no way of vetting the entire dependency chain. You may have reviewed gem/package A but you aren't going to…

I'd debate the relatively effective piece in light of webmin being backdoored for a year, and of course remember we're only hearing about the ones that have been found, not the ones that haven't. There's a number of possible technical mitigations, maintaining internal package repositories, code review of key libraries, enforcing package signing and checking signatures etc but all of them increase costs and decrease d…

Linus's Law (given enough eyeballs, all bugs are shallow) has never rang true to me. I've been using free software since '95.

Taken at face value, then yes, obviously more people looking at a specific piece of code will make it better. But this does not extend to the entire landscape of open source. Most developers, especially ones doing so as a hobby, would much rather work on their own new code. Not look at someone else's old boring code. We would rather reinvent the wheel a thousand times before touching a line of code written by someone else.

This becomes even more dire when you look at code no one wants to touch. Like TLS. There were the Heartbleed and goto fail bugs which existed for, IIRC, a few years before they were discovered. Not surprising, because TLS code is generally some of the worst code on the planet to stare at all day.

Post reply on HN