21–30 of 113 posts
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…
cd ~/code # Where all my projects live
grep --include='Gemfile.lock' -r . -e 'rest-client \(1\.6\.1[0123]\)'
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…
This situation definitely lends itself to push for 2FA by default on all rubygems.
Earlier quoted context omitted.
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.
It's also likely it was done by an intelligence agency.
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…
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.
It looks pretty bad if you had deployed this :( Here is a summary of the exploit re-pasted from a great comment [1] written by @JanDintel on the github thread: - It sent the URL of the infected host to the attacker. - 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. - It allow…
The first hijacked version was released on August 13th.