Rest-client gem is hijacked

Hey since this is blown up I just want to address it directly.<p>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.<p>I made that account probably over 10 years ago, so it predated my use of password managers and I haven&#x27;t used it much lately, so I didn&#x27;t catch it in a 1password audit or anything.<p>Sometimes we miss things despite our best efforts.<p>Rotate your passwords, kids.

It looks pretty bad if you had deployed this :(<p>Here is a summary of the exploit re-pasted from a great comment [1] written by @JanDintel on the github thread:<p>- It sent the URL of the infected host to the attacker.<p>- It sent the environment variables of the infected host to the attacker. Depending on your set-up this can include credentials of services that you use e.g. database, payment service provider.<p>- It allowed to eval Ruby code on the infected host. Attacker needed to send a signed (using the attacker’s own key) cookie with the Ruby code to run.<p>- It overloaded the #authenticate method on the Identity class. Every time the method gets called it will send the email&#x2F;password to the attacker. However I&#x27;m unsure which libraries use the Identity class though, maybe someone else knows?<p>So... it potentially comprised your user&#x27;s passwords AND (if you were on Heroku or similar like many Rails apps are) system-level access to all your attached data stores. About as bad as it gets.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;rest-client&#x2F;rest-client&#x2F;issues&#x2F;713#issuecomment-522967049" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rest-client&#x2F;rest-client&#x2F;issues&#x2F;713#issuec...</a>

I think that rubygems should consider automatically enforcing multifactor authentication for popular gems.<p>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.<p>Because, having MFA is not about protecting gem maintainers, it&#x27;s about protecting users. So, gem maintainers should not be allowed to be careless with security by not using MFA. It&#x27;s not their choice to make.

It&#x27;s mind-boggling to think how fragile and potentially dangerous those dependency ecosystems are – no matter if it&#x27;s Ruby, JS, PHP or other languages widely used for web apps.<p>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…<p>I have no easy solution for this problem and of course I too use external dependencies in my projects – but it feels like it&#x27;s only a matter of time till disaster will happen and most of us just ignore this problem till then.

Ruby gem hijacking also happened to Strong_password a few weeks ago.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20377136" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20377136</a><p>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.<p>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.

It&#x27;s worth noting that the hijacker pushed a malicious version of 1.6.x<p>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.<p>The impact <i>could</i> have been significantly greater had the hijacker pushed a new versions of 1.8.x or 2.x as well, so it&#x27;s very fortunate the breach was spotted now.

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

This is bad. Also from the Github comments, here&#x27;s a useful snippet to quickly search your projects to see if any of your projects are impacted[0]:<p><pre><code> cd ~&#x2F;code # Where all my projects live grep --include=&#x27;Gemfile.lock&#x27; -r . -e &#x27;rest-client \(1\.6\.1[0123]\)&#x27; </code></pre> <a href="https:&#x2F;&#x2F;github.com&#x2F;rest-client&#x2F;rest-client&#x2F;issues&#x2F;713#issuecomment-522987796" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rest-client&#x2F;rest-client&#x2F;issues&#x2F;713#issuec...</a>

Whitelist outbound access from your network. It&#x27;s not perfect and it can be painful to deploy, particularly gems, but it stops several categories of attacks.

Following closely on from Webmin&#x27;s compromised CI&#x2F;CD pipeline, this is another instance of the growing problem of supply chain attacks.<p>With the software supply chain being as complex as it is, and the large number of moving parts, we&#x27;re only going to see more of these ...

Rubygems acted when they were notified [0]. There were a few affected by this at the same time, not just rest-client.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;rubygems&#x2F;rubygems.org&#x2F;wiki&#x2F;Gems-yanked-and-accounts-locked#19-aug-2019" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rubygems&#x2F;rubygems.org&#x2F;wiki&#x2F;Gems-yanked-an...</a>

For all the people who are rightly concerned about these attacks here&#x27;s a a couple of questions<p>- 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.<p>- 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?<p>- 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?<p>Ultimately these problems (like most) are one of incentives. It&#x27;s very easy to build software very quickly using the huge number of open source components that are freely available.<p>Whilst speed of development and price are the primary considerations, it&#x27;s not going to be surprising that security takes a lower rung on the ladder.

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.<p>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.

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

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

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.

This 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)

That is sadly a good example of why relying on trusted and accountable API clients should be considered critical for business.<p>When consuming APIs and not thinking about this, we are only building technical debt and security issues for the future.<p>Today&#x27;s example is really bad since it targets a well-used meta API open-source library, but how many of those issues are already present on hundreds of other obscure open-source API clients?

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

What&#x27;s kind of interesting about this is the fact that it is able to just blindly dump environment variables.<p>For a long time, environment variables have been evangelized as the secure place to store credentials and things, but that just gives third party scripts a known place to look.<p>You could argue that might actually be more secure to store your secrets in a separate, custom config file that gets read into the rails app via an initializer or something.

Many of these attacks seem to use pastebin. I will add a hosts entry pointing pastebin to localhost in my production servers.

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&#x27;s 4x, 5x Attack surface from what it potentially could be.

Hello, here is an explanation and analysis of this rest-client backdoor: <a href="https:&#x2F;&#x2F;application.security&#x2F;ruby-backdoor" rel="nofollow">https:&#x2F;&#x2F;application.security&#x2F;ruby-backdoor</a>

Good thing your Gemfile.lock is checked in and gems hosted on rubygems.org are frozen &#x2F; imutable

Another case for universal adoption of 2FA.

Why doesn&#x27;t this repo mandate 2FA?