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

51–60 of 113 posts

Re: Rest-client gem is hijacked

#51

Post by fahrradflucht »

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.

The argument for automated releases is always that it is quite easy to do silly mistakes like forgetting a build step while doing manual releases. This also happened to high profile npm packages in the past and people complained that there was no automation.

Re: Rest-client gem is hijacked

#52

Post by holtalanm »

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…

i turned on 2fa for my npm account, and my published libraries aren't even at 1K downloads _total_ yet.

these guys with libraries that have a massive user base really have no excuse besides laziness for not having 2fa on their account.

Re: Rest-client gem is hijacked

#53

Post by shioyama »

shioyama wrote: post #30

I'm an author of gems with a total of more than 4 million downloads. I just setup 2fa now after seeing this.

I actually ended up going further and removing me as author from gems I don't actually maintain anymore, which brings down my exposure considerably. It's actually not as easy as it could be to remove yourself as an author from a gem (have to do it via command line).

Re: Rest-client gem is hijacked

#54

Post by kpeekhn »

hombre_fatal wrote: post #50
kpeekhn wrote: post #44

Is there a way to check if a gem was released by an account using MFA? If there was a "published with mfa" flag on every gem release and it would allow a Bundler setting to block installing gems without 2FA. Of course, this would also help attackers find targets. But maybe its worth the trade-off?

Seems like a pointless, false sense of security. What about all the attacks where the malicious actor is someone with publish rights, like friendly package takeover? Your proposal makes that even more effective since now the attacker gets a nice "published with mfa" badge.

It would have prevented this attack, so I'm not sure how its pointless. Obviously it doesn't fix everything. MFA is MFA. I don't know why anyone would take it as a guarantee that some third-party has audited all the code.

Re: Rest-client gem is hijacked

#55

Post by adrianN »

raesene9 wrote: post #34
enneff wrote: post #28

Earlier quoted context omitted.

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.

Every single day doesn't sound too often to have someone press a physical button.

Re: Rest-client gem is hijacked

#56

Post by C4stor »

raesene9 wrote: post #10
cooljacob204 wrote: post #8

Earlier quoted context omitted.

Why would a CI/CD need to permissions modify and commit code to a repo?

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.

I doesn't seem hard to imagine a CI pipeline that sends an email/sms for validation and waits an affirmative answer before continuing. I have no idea how to receive texts on a server, but sending and receiving emails is super easy.

Re: Rest-client gem is hijacked

#57

Post by raesene9 »

rubber_duck wrote: post #48
raesene9 wrote: post #34

Earlier quoted context omitted.

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.

I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.

That's a view of course (although in the case of gVisor they don't actually do versioned build just nightlies) but here's a question.

As a consumer of software libraries, have you ever looked into the security practices of the library author before choosing whether to use it or not?

Re: Rest-client gem is hijacked

#58

Post by psychrometer »

fahrradflucht wrote: post #51
enneff wrote: post #28

Earlier quoted context omitted.

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.

The argument for automated releases is always that it is quite easy to do silly mistakes like forgetting a build step while doing manual releases. This also happened to high profile npm packages in the past and people complained that there was no automation.

I think they are suggesting a mostly automated build process and then a manual entering of a the second factor OTP at the deploy stage. The entering of the 2FA isn't something that will be hard to easy to mess up and you still receive the benefits of automated builds for the most part.

Re: Rest-client gem is hijacked

#59

Post by hombre_fatal »

kpeekhn wrote: post #54
hombre_fatal wrote: post #50

Earlier quoted context omitted.

Seems like a pointless, false sense of security. What about all the attacks where the malicious actor is someone with publish rights, like friendly package takeover? Your proposal makes that even more effective since now the attacker gets a nice "published with mfa" badge.

It would have prevented this attack, so I'm not sure how its pointless. Obviously it doesn't fix everything. MFA is MFA. I don't know why anyone would take it as a guarantee that some third-party has audited all the code.

> It would have prevented this attack

Your post was about a "published with mfa" vanity badge which I was responding to, not the merits of mfa in general.

Re: Rest-client gem is hijacked

#60

Post by raesene9 »

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 that you wanted to use and had the information you did or did not find affect your decision to use that software?

- How often do you use the inventory of all the libararies you have, to periodically check on the provenance of those libaries and that they are maintaining good security practices?

Ultimately these problems (like most) are one of incentives. It's very easy to build software very quickly using the huge number of open source components that are freely available.

Whilst speed of development and price are the primary considerations, it's not going to be surprising that security takes a lower rung on the ladder.

Post reply on HN