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

31–40 of 113 posts

Re: Rest-client gem is hijacked

#31

Post by smudgymcscmudge »

robotfelix wrote: post #16

It's worth noting that the hijacker pushed a malicious version of 1.6.x Version 1.7.0 was released to rubygems on 8th July 2014, and 2.0.0 on 2nd July 2016, so anyone who has started using rest-client or run a `bundle update` recently is unlikely to be affected. The impact could have been significantly greater had the hijacker pushed a new versions of 1.8.x or 2.x as well, so it's very fortunate the breach was spotte…

Don’t most ruby projects vendor gems? So projects using 1.6 that didn’t bundle update wouldn’t be affected either. It sounds like only projects that were pinned to 1.6 that ran bundle update would be affected.

I only have a passing familiarity with ruby gems, so I may be completely wrong.

Re: Rest-client gem is hijacked

#32

Post by shioyama »

u801e wrote: post #20

Does ruby gems allow for signing releases? For example, the maintainer could upload their public key and use their private key to sign a package release. Then the consumer could verify the signature via the public key. If the public key changes, then the consumer could be alerted to that fact.

Yes it does, and I do this with my gems, but it's not widely used and I'm sure virtually none of the users of the gems I author probably take advantage of it.

https://guides.rubygems.org/security/

> However, this method of securing gems is not widely used. It requires a number of manual steps on the part of the developer, and there is no well-established chain of trust for gem signing keys. Discussion of new signing models such as X509 and OpenPGP is going on in the rubygems-trust wiki, the RubyGems-Developers list and in IRC. The goal is to improve (or replace) the signing system so that it is easy for authors and transparent for users.

Re: Rest-client gem is hijacked

#33

Post by jaclaz »

raesene9 wrote: post #6
westoque wrote: post #4

Out of curiosity, is there a legal way to go after people that do these? e.g., File a police report?

Unless the attacker had very poor OpSec, it would be hard to track them down, even assuming the relevant police force had the skills/manpower to do so. Then you get the delight of likely jurisdictional issues, if it turns out the attacker is not a resident of the same country as the victim that reported it.

Only out of curiosity I did a quick WHOIS search, it is an Ukraine domain registered by a Polish company with its legal head offices in Belize (at an address where there is seemingly a courier/transport company).

And the same address is linked to a Malta based company that appears on the "Panama Papers".

Re: Rest-client gem is hijacked

#34

Post by raesene9 »

enneff wrote: post #28
raesene9 wrote: post #10

Earlier quoted context omitted.

Say your CI pipeline runs automated tests, builds the gem and pushes to Rubygems, it needs permissions to push to Rubygems. So if an attacker compromises the API key used by that pipeline, they get the rights to push to Rubygems.

Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.

I'd expect that very much depends on the software in question. As one example that I'm aware of, gvisor from Google delivers nightly builds. So they're building and pushing every single day.

It'd depend on the individual software library and of course as a consumer of many libraries you generally will have limited or no visibility of the practices of all your dependencies.

Re: Rest-client gem is hijacked

#35

Post by zbentley »

enneff wrote: post #28
raesene9 wrote: post #10

Earlier quoted context omitted.

Say your CI pipeline runs automated tests, builds the gem and pushes to Rubygems, it needs permissions to push to Rubygems. So if an attacker compromises the API key used by that pipeline, they get the rights to push to Rubygems.

Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.

Absolutely agree. One-click deploys are nice, but in some circumstances not worth the cost. The manual component can also be polished to the point where it's not that arduous (think github login with 2FA and clicking the "merge" button).

Re: Rest-client gem is hijacked

#36

Post by 19ylram49 »

raesene9 wrote: post #19
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…

Yeah this problem has been a known issue for a long time, but there really is no easy fix, and incentives are stacked against it getting resolved in any meaningful way. I did a talk for AppsecEU back in 2015 on this topic and found good material talking about it as a risk going back years before that...

I think I might start using fully isolated environments (i.e., via Vagrant/Docker/etc.) for all of my projects from now on (I already do for some).

Re: Rest-client gem is hijacked

#37

Post by Ajedi32 »

u801e wrote: post #20

Does ruby gems allow for signing releases? For example, the maintainer could upload their public key and use their private key to sign a package release. Then the consumer could verify the signature via the public key. If the public key changes, then the consumer could be alerted to that fact.

That's not really any better than 2FA against this specific threat.

But to answer your question, yes there is a system for signing gems, though it's not widely used: https://guides.rubygems.org/security/

Re: Rest-client gem is hijacked

#38

Post by hombre_fatal »

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 to go about this like the package repo requiring linkage to an actually git repo that it builds from.

Commonly pitched solutions like 2FA are useful but don't do anything to stop the case of a malicious actor actually having publish rights, like the trivial attack where you simply offer to take a project off someone's hands. But diffing releases and reading source code should be absolutely trivial at the very least.

Re: Rest-client gem is hijacked

#39

Post by romaaeterna »

Ruby gem hijacking also happened to Strong_password a few weeks ago.

https://news.ycombinator.com/item?id=20377136

This is major new line of attack, and web app infrastructure is critically weak to it. We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons), but as this sort of attack becomes much more common (which it will), we might find ourselves missing the days of strong central control.

Rubygems should have acted on the Strong_password news, but missed the opportunity. I hope that they can get their act together now that they are lucky enough to have a second chance before this style of attack really explodes.

Re: Rest-client gem is hijacked

#40

Post by jcoby »

raesene9 wrote: post #19
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…

Yeah this problem has been a known issue for a long time, but there really is no easy fix, and incentives are stacked against it getting resolved in any meaningful way. I did a talk for AppsecEU back in 2015 on this topic and found good material talking about it as a risk going back years before that...

> 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 (realistically) review all of its dependencies and those dependencies' dependencies.

At this point it's all a "many eyes" approach. And it seems to be working relatively effectively.

Post reply on HN