Many popular gems have multiple authors(with push ability) on RubyGems. Like 4, 5 authors, sometimes even more.
It may look impressive on their profile but from a security standpoint that's 4x, 5x Attack surface from what it potentially could be.
Rest-client gem is hijacked
61–70 of 113 posts
Re: Rest-client gem is hijacked
#62Earlier quoted context omitted.
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.
sorry, that is not what I mean.
I don't care really about a badge, I care about the information being available so that it can be used in Bundler. Its about developers being given the choice in their gemfile to disallow installation of any gems uploaded without 2FA. But in order to do that, we need rubygems to publish that information.
Re: Rest-client gem is hijacked
#63I 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…
It's only a matter of time before this will happen. Once any one of the big players (rubygems, npm, Maven central, PyPi) enforces 2FA, all other repos will soon have to follow suit or risk giving appearance of haphazard attitude towards user security. 2FA is generally trivial for maintainers to take into use. There is simply no excuse to not require it at this point for all new uploads. The status quo of hoping maint…
PyPi has 2FA for user logins to the website, which:
"safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without users providing 2FA codes."
They are also working to enforce 2FA on uploads:
"But that's just for now. We are working on implementing per-user API keys as an alternative form of multifactor authentication in the setuptools/twine/PyPI auth flows. These will be application-specific tokens scoped to individual users/projects, so that users will be able to use token-based logins to better secure uploads. And we'll move on to working on an advanced audit trail of sensitive user actions, plus improvements to accessibility and localization for PyPI. More details are in our progress reports."
From: http://pyfound.blogspot.com/2019/06/pypi-now-supports-two-fa...
Re: Rest-client gem is hijacked
#64Earlier quoted context omitted.
> 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.
sorry, that is not what I mean. I don't care really about a badge, I care about the information being available so that it can be used in Bundler. Its about developers being given the choice in their gemfile to disallow installation of any gems uploaded without 2FA. But in order to do that, we need rubygems to publish that information.
No, I understand you. My point is that whether a package uses 2FA or not should have zero impact on your security practices, yet your proposal suggests otherwise.
It doesn't seem like it does you much good to know if a package uses 2FA except to potentially weaken your defenses. For example, any scrutiny you level at a non-2FA package should also be leveled at 2FA-enabled packages. Though I suppose there is a non-zero benefit, so I won't belabor this argument any further.
Perhaps package repositories should be nagging publishers to enable 2FA. Though poorly implemented 2FA also introduces new attack vectors like the "lol lost my phone" social engineering attack.
Re: Rest-client gem is hijacked
#65[deleted]
Re: Rest-client gem is hijacked
#66I 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…
It's not just rubygems that has this issue, it's all the other repos too, most of which (AFAIK) don't enforce 2FA Also worth noting that whilst MFA helps, it's not a panacea as MFA isn't generally compatible with automated CI/CD processes, so API keys will still be required, and can be leaked/lost/stolen.
How about a split, so releases can be uploaded by API key, but only published by someone using MFA?
Re: Rest-client gem is hijacked
#67Earlier quoted context omitted.
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?
This is becoming increasingly impractical for certain ecosystems as packages depend on packages, which depend on packages, etc. It's less of a problem with the bundler ecosystem, where larger packages with relatively few dependencies is more standard, but in the JS world installing a package means that you're likely installing tens or hundreds of sub-dependencies.
Re: Rest-client gem is hijacked
#68Does 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.
[deleted]
Re: Rest-client gem is hijacked
#69This is a fairly old version of the gem, but probably what attacker was going for (users who infrequently go to new versions, and avoiding those who watch most up to date version)
Re: Rest-client gem is hijacked
#70Hey 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 miss things despite our best efforts.
Rotate your passwords, kids.