Supply-chain attack hits RubyGems repository with malicious packages | Hacker News Reader

Supply-chain attack hits RubyGems repository with malicious packages

arstechnica.com

151 pointsTomte18 comments

Looks like they had a neat attack vector but their ultimate end goal didn’t have a wide enough net.

After stealing windows users clipboard contents: “the threat actor is trying to redirect all potential cryptocurrency transactions to their wallet address. At the time of writing this blog, seemingly no transactions were made for this wallet.”

Actual source: https://blog.reversinglabs.com/blog/mining-for-malicious-rub...

https://news.ycombinator.com/item?id=22906714

The target was Ruby developers who use Windows and Bitcoin. I didn't get the sense that common libraries are infected - more that there are hundreds of libraries that are typosquatting. It would be interesting to find out if any of these libs ended up as dependencies.

Love the TacoBell.check_win.

The most successful attack was a change of an underbar (atlas_client) to a dash (atlas-client). Seems good to standardize these kind of non-alphanumeric characters in library names. Still, seems like open source web stores like this might need some level of human moderation?

From the original article[0]:

> The script itself is rather simple. First, it creates a new VBScript Sle with the main malicious loop at the “%PROGRAMDATA%\Microsoft Essentials\Software Essentials.vbs” path. As its persistence mechanism, it then creates a new autorun registry key “HCU\Software\Microsoft\Windows\CurrentVersion\Run Microsoft Software Essentials.” With this, the malware ensures that it is run every time the system is started or rebooted.

Good to see that the methods from 15 years ago are still valid.

[0]: https://blog.reversinglabs.com/blog/mining-for-malicious-rub...

These attacks will become more common. I'm advocating to add a dependency firewall to GitLab so that downloads of packages that show suspicious behaviour will be paused. I've added some of the vectors of this attack to the signals to watch for with https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

This is the kind of thing that leaves me with little confidence that decentralised currency will mainstream as decentralised.

I've only seen three actual mainstream uses for crypto:

- laundering or indirect laundering of money

- Send or receive money without government oversight

- Piggy back on as a ledger to not have to develop your own decentralised ledger

> this malicious gem had 2,100 downloads, close to 30% of the total downloads that the legitimate gem

I wonder if most of those downloads are fake to boost the download stats and to give more credibility. Either way, that's troubling...

I've published a couple gems that I'm pretty sure no one uses, and after a few months the downloads was in the hundreds, probably bots and mirrors. Most likely the figure only makes when seen relative to other gems.

Anybody who doesn't use a dev VM these days is asking for trouble. It's too easy for attackers to run malicious code on your machine with techniques like this.

Not only that, you could end up shipping malicious code to your customer.

How would a dev vm prevent this? Vms can still call out to the internet.

No host FS or clipboard access means it would be rendered useless.

Hmmm, that depends on the virtualisation solution being used.

If someone's using (say) VMware Workstation or Fusion, if they've loaded the VMware tools into the VM it can share the clipboard and be configured with access to the hosts filesystem (at defined points).

If you set it up that way it will. If you are doing this intentionally then just don't set it up that way.

I would go as far as saying anyone who does not have control and awareness of their dependencies is asking for trouble. VM be damned.

That's part of the reason I feel uncomfortable with "modern" package systems like golang's. I really want to use golang more, but I just don't feel 'secure' about building a bunch of packages pulled off of github by URL.

Third-party package management is not a modern marvel by any means. You are unnecessarily singling out golang, and if you let that stop you from learning it's your loss. Just be smart. Dependency awareness is not black magic.

odd golang has a better security story than npm, rubygems, and python. it'll at least crypto ensures the dependency code hasnt been modified since you first retrieved it iirc.

the rest is up to you as a developer to ensure its safe.

Reply on news.ycombinator.com