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

81–90 of 113 posts

Re: Rest-client gem is hijacked

#81

Post by dspillett »

donkeyd wrote: post #73
mwmanning wrote: post #70

Hey since this is blown up I just want to address it directly. I take responsibility for what happened here. My RubyGems.org account was using an insecure, reused password that has leaked to the internet in other breaches. I made that account probably over 10 years ago, so it predated my use of password managers and I haven't used it much lately, so I didn't catch it in a 1password audit or anything. Sometimes we mis…

Wow, that's a pretty well executed and possibly targeted attack then. It blows my mind how easy it can be to perform a high impact attack by abusing popular libraries. Hopefully this was caught before it got into production in high profile implementations.

I doubt the initial attack was targetted. That would have been a brute force testing-known-passwords-against-similarly-named-accounts. Once a useful account was found it could well have been sold on the appropriate black market rather than the finder using it themselves.

Re: Rest-client gem is hijacked

#82

Post by chromakode »

hombre_fatal wrote: post #38
elaus wrote: post #17

It's mind-boggling to think how fragile and potentially dangerous those dependency ecosystems are – no matter if it's Ruby, JS, PHP or other languages widely used for web apps. We all just hope that nothing bad will happen or that it will be noticed fast enough. Accounts get compromised, maintainers quit and transfer their project, bad actors might even pay the dev of some lesser-known dependency… I have no easy solu…

The first thing that needs to become standard is a source code / diff viewer right there inline on the repository. One of the most ridiculous things about most package repositories (npm, rubygems) is how opaque they are. It's only a mere courtesy to link to the github repo from a package, and a gentlemen's agreement that it actually represents the code that will get run with 'npm/gem install'. There are various ways…

Intrinsic made a tool for this for npm: https://medium.com/intrinsic/introducing-package-diff-for-np...

Re: Rest-client gem is hijacked

#83

Post by dspillett »

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!

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 password reset can be forced but some would be up in arms about the inconvenience caused: you can't just allow a simple reset as the login could be coming from an attacker not the original user, an extra channel will need to be used to verify the identity. You might just have to leave the account locked forever and expect the user to create a new one - but now you have the old account and its content which may be used as a dependency of many projects which now break, unnecessarily if there hasn't been a login by a nefarious type.

Re: Rest-client gem is hijacked

#84

Post by tempguy9999 »

mwmanning wrote: post #70

Hey since this is blown up I just want to address it directly. I take responsibility for what happened here. My RubyGems.org account was using an insecure, reused password that has leaked to the internet in other breaches. I made that account probably over 10 years ago, so it predated my use of password managers and I haven't used it much lately, so I didn't catch it in a 1password audit or anything. Sometimes we mis…

> I take responsibility for what happened here

that's.... rare. Well done.

Re: Rest-client gem is hijacked

#85

Post by eli »

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…

Presumably you'd use whatever procedure you use for a lost password?

But simply forcing a password change at the next login after detecting an insecure password would not unduly burden anyone and would be better than doing nothing.

Re: Rest-client gem is hijacked

#86

Post by yebyen »

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…

You could send that notification, invalidate any client tokens, and also disable the compromised password forcing the user to re-authenticate through their email address, a-la password reset, and I guess also verify they aren't using the same password again.

You wouldn't lock the account forever, the point is to establish that the person whose password was compromised knows, that the password is not the only factor which is used to regain access to the account, and to ensure that your service (rubygems) and its downstream users are not compromised as well as a result of the breach.

Any groaning about the inconvenience caused by disabling account access until the password is changed, can be simply shrugged away in favor of security concerns, with a link to this story about rest-client.

By the time you have learned the user's plaintext password, their account may already have been compromised. There's a case to make that you disable all downloads of any gems that might be compromised from the account until you've verified they aren't. That might be over the top, especially for popular projects as now we are talking serious inconvenience affecting potentially thousands or more of downstreams.

It's a sticky situation, since you don't really know how long that password has been in the open for hackers to use and abuse once you've discovered it in a password dump.

Re: Rest-client gem is hijacked

#87

Post by notyourday »

This actually is a perfect illustration why in production all of your systems have to go through a while-listing proxy rather than a NAT for the outside access.

There should be a very limited number of known external URLs that your production system needs to hit. Whitelist them on a proxy. Block the rest. Dump the blocked requests into a log. Put alerts on a log. It will get most of data exfiltration attempts or attacks such as this. Remember, when your goal is not to have a perfect security -- your goal is to have a better security than someone else so that someone else gets to be a chump and not you.

Re: Rest-client gem is hijacked

#89

Post by derimagia »

gotts wrote: post #71
htns wrote: post #11

Seems rather similar to the strong_password case from a month back: https://news.ycombinator.com/item?id=20377136 . I wonder if anyone has checked basic things like scanning all of rubygems for "pastebin" or "eval( * http * )".

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.

Re: Rest-client gem is hijacked

#90

Post by sundayedition »

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…

I used to work for the government and we had a private gem server that introduced much for what you're asking about; delays in releases as a trade-off for security practices. Ultimately, I don't think there was any tooling available to automate the vulnerability scanning enough that a private server gives you much of a jump start on any kind of CVE that bundle audit wouldn't already catch. The workaround of needing to hit GitHub directly to get a current version and bypass the private server is also available.

Additionally, GitHub provides a bundler-audit like service for free. And, identifying those that are t CVEs yet seems like something scriptable but also obfuscatable (on the attacker end).

I don't think any team I've been on (federal or private) would pay extra for this kind of service given the frequency with which we do updates and the amount of effort that needs a careful developer spends when doing these updates. The most recent breaches have been noted well I'm advance of any updates we would have done.

I'd be glad to be wrong about it because I think a few more tools in this space would only help the community.

It would be nice if a service could summarize the differences in actual gem releases, to make things like the changelog and the diff easily digestable for all the available updates though (versus a scan/lint). That would let a developers more easily identify these kinds of breaches than cloning and diffing.

Post reply on HN