5 ms·

The unanswered question is still how this `kickball` account gained control of the gem. > The gem seems to have been pulled out from under me… When I login to

The unanswered question is still how this `kickball` account gained control of the gem. > The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019. The way I see it, there are a few options: 1. The rubygem was transferred by ruby staff to this account. 2. The maintainer's account was hijacked and then it was transferred, and could even still be compromised. 3. There is some issue or attack vector with the rubygem system that allowed the attacker to gain control. Any guesses?

romaaeterna 7y ago
Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.
- rattray 7y ago
  Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.
  - raesene9 7y ago
    Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems? The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
    - wolco 7y ago
      We've heard this before. Yes. Developers using this may decide not to use this gem. Ruby gems in general may lose trust. If the goal of the project is adoption than do not ignore that group.
      - raesene9 7y ago
        so you feel that a group of volunteers with limited funding should do what precisely? as to losing adoption, that would only happen if a) there were other options with better security, and given that npm, PyPI and others have had similar problems, there probably aren't b) Developers would actually move ecosystem due to package manager weaknesses. given that hasn't happened with any of the previous instances of supply chain attacks (and this has been going on for 5+ years now) I don't think so. As one example, rubygems was compromised in 2013 https://news.ycombinator.com/item?id=5139583 https://news.ycombinator.com/item?id=5139583 did you or anyone else stop using it as a result?
    - jrochkind1 7y ago
      rubygems is actually given some funding by Ruby Together, I'm not sure with what current budget. https://rubytogether.org/ https://rubytogether.org/
      - raesene9 7y ago
        based on their home page they're somewhere near the lower end of the $20k-$35k category for all funding...
        jrochkind1 7y ago
        I think that is per month? But not sure.
        raesene9 7y ago
        Think you could be right there, so not a tiny amount of cash but looking at their page not even enough to have a full time dev on the gem tools... Obv. as a security person I'd say they should prioritise security things like audits and improved Authentication requirements for gem owners, but realistically sounds like just keeping the lights on is pretty expensive.
        jrochkind1 7y ago
        They work on adding other features to rubygems and other things they fund. If I were them, I would work on nothing but security of rubygems.org gem releases.
  - gwm83 7y ago
    Yet another example of supply chain attacks. How do businesses seriously allow their devs to pull code from outside sources, it blows my mind. Npm, Ruby gems, etc etc etc.
zbentley 7y ago
Option 2 is overwhelmingly likely, IMO. Phishing, password reuse, credential scraping/spamming, and plain old brute force are unbelievably common. That said, the other two options bear investigation too. Just don't spend time looking for a cold breeze from an un-caulked window frame when the screen door is open.
- saurik 7y ago
  The true irony, of course, is that the package in question is designed (whether it does or not isn't the point, though I guess if it isn't very good then this becomes all the more humorous) to help prevent people from reusing common passwords or choosing passwords that are easy to brute force ;P... clearly the author should have used this package to select their password that protected the uploads of this package.
  - viraptor 7y ago
    We don't know that. Their system could've been compromised in some other way and the password captured.
chupasaurus 7y ago
My bet goes to #3. After [0]this commit, everything is possible in Ruby world. [0]https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 https://github.com/rails/rails/commit/b83965785db1eec019edf1...
- jrochkind1 7y ago
  That seems to demonstrate a github vulnerability, rather than anything ruby-specific?
  - heartbreak 7y ago
    It was a Rails vulnerability (mass assignment) that the attacker used to accomplish this. It’s long since been fixed and doesn’t demonstrate an inherent security flaw with the “ruby world.” https://gist.github.com/peternixey/1978249 https://gist.github.com/peternixey/1978249
nurettin 7y ago
Not sure why someone with malicious intent would use their rubygems superpower just to compromise a low profile gem like this. Perhaps it is a targeted attack at a certain website which may now be compromised and we are just seeing the tip of the iceberg.
- MrStonedOne 7y ago
  Option 1 was referring to the attacker tricking a staff working into handing control to them. Maybe by claiming its abandoned?
jakobegger 7y ago
Or: 4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.
- trickstra 7y ago
  Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...
  - OskarS 7y ago
    That's an extremely ungenerous interpretation of those events. He shouldn't have handed over control of the package to someone he barely knew, but from his perspective, it was that or let the package die. He volunteered his time, he had no kind of obligation to continue if he didn't want to. His actions were certainly not malicious, and he was clearly not "complicit" with the hacker, which is what you're implying. That incident highlighted a broadly systemic problem with how these kinds of packages are maintained, it was not a case of "one bad maintainer".
    - trickstra 7y ago
      I was referring more to the "transferred ownership voluntary" part, not to the complicit, so no, I'm not implying that. But it is really interesting to see the atmosphere around this systemic problem. Maintainers don't realize that transferring ownership can be putting users in danger, they'd rather transfer the ownership to a random stranger than mark the package abandoned, then they deny it was ever so serious and ask for more money, and their friends and followers rise up to protect them, without ever addressing the central issue, yeah, that's a systemic problem.
  - Carpetsmoker 7y ago
    Oh come on, you're still giving this guy shit for making a mistake while spending his free time developing it?

romaaeterna 7y ago

Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.

rattray 7y ago
Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.
- raesene9 7y ago
  Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems? The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
  - wolco 7y ago
    We've heard this before. Yes. Developers using this may decide not to use this gem. Ruby gems in general may lose trust. If the goal of the project is adoption than do not ignore that group.
    - raesene9 7y ago
      so you feel that a group of volunteers with limited funding should do what precisely? as to losing adoption, that would only happen if a) there were other options with better security, and given that npm, PyPI and others have had similar problems, there probably aren't b) Developers would actually move ecosystem due to package manager weaknesses. given that hasn't happened with any of the previous instances of supply chain attacks (and this has been going on for 5+ years now) I don't think so. As one example, rubygems was compromised in 2013 https://news.ycombinator.com/item?id=5139583 https://news.ycombinator.com/item?id=5139583 did you or anyone else stop using it as a result?
  - jrochkind1 7y ago
    rubygems is actually given some funding by Ruby Together, I'm not sure with what current budget. https://rubytogether.org/ https://rubytogether.org/
    - raesene9 7y ago
      based on their home page they're somewhere near the lower end of the $20k-$35k category for all funding...
      - jrochkind1 7y ago
        I think that is per month? But not sure.
        raesene9 7y ago
        Think you could be right there, so not a tiny amount of cash but looking at their page not even enough to have a full time dev on the gem tools... Obv. as a security person I'd say they should prioritise security things like audits and improved Authentication requirements for gem owners, but realistically sounds like just keeping the lights on is pretty expensive.
        jrochkind1 7y ago
        They work on adding other features to rubygems and other things they fund. If I were them, I would work on nothing but security of rubygems.org gem releases.
- gwm83 7y ago
  Yet another example of supply chain attacks. How do businesses seriously allow their devs to pull code from outside sources, it blows my mind. Npm, Ruby gems, etc etc etc.

zbentley 7y ago

Option 2 is overwhelmingly likely, IMO. Phishing, password reuse, credential scraping/spamming, and plain old brute force are unbelievably common. That said, the other two options bear investigation too. Just don't spend time looking for a cold breeze from an un-caulked window frame when the screen door is open.

saurik 7y ago
The true irony, of course, is that the package in question is designed (whether it does or not isn't the point, though I guess if it isn't very good then this becomes all the more humorous) to help prevent people from reusing common passwords or choosing passwords that are easy to brute force ;P... clearly the author should have used this package to select their password that protected the uploads of this package.
- viraptor 7y ago
  We don't know that. Their system could've been compromised in some other way and the password captured.

chupasaurus 7y ago

My bet goes to #3. After [0]this commit, everything is possible in Ruby world. [0]https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 https://github.com/rails/rails/commit/b83965785db1eec019edf1...

jrochkind1 7y ago
That seems to demonstrate a github vulnerability, rather than anything ruby-specific?
- heartbreak 7y ago
  It was a Rails vulnerability (mass assignment) that the attacker used to accomplish this. It’s long since been fixed and doesn’t demonstrate an inherent security flaw with the “ruby world.” https://gist.github.com/peternixey/1978249 https://gist.github.com/peternixey/1978249

nurettin 7y ago

Not sure why someone with malicious intent would use their rubygems superpower just to compromise a low profile gem like this. Perhaps it is a targeted attack at a certain website which may now be compromised and we are just seeing the tip of the iceberg.

MrStonedOne 7y ago
Option 1 was referring to the attacker tricking a staff working into handing control to them. Maybe by claiming its abandoned?

jakobegger 7y ago

Or: 4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.

trickstra 7y ago
Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...
- OskarS 7y ago
  That's an extremely ungenerous interpretation of those events. He shouldn't have handed over control of the package to someone he barely knew, but from his perspective, it was that or let the package die. He volunteered his time, he had no kind of obligation to continue if he didn't want to. His actions were certainly not malicious, and he was clearly not "complicit" with the hacker, which is what you're implying. That incident highlighted a broadly systemic problem with how these kinds of packages are maintained, it was not a case of "one bad maintainer".
  - trickstra 7y ago
    I was referring more to the "transferred ownership voluntary" part, not to the complicit, so no, I'm not implying that. But it is really interesting to see the atmosphere around this systemic problem. Maintainers don't realize that transferring ownership can be putting users in danger, they'd rather transfer the ownership to a random stranger than mark the package abandoned, then they deny it was ever so serious and ask for more money, and their friends and followers rise up to protect them, without ever addressing the central issue, yeah, that's a systemic problem.
- Carpetsmoker 7y ago
  Oh come on, you're still giving this guy shit for making a mistake while spending his free time developing it?