louislang

DARPA is doing something similar to this with their TRACTOR work.

https://www.darpa.mil/program/translating-all-c-to-rust

(Full disclosure: I'm one of the co-founders @ Phylum)

We could do a full write-up on npm's quirks and how one could take advantage of them to hide intent.

Consider the following from the post's package.json:

    "axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz"

Here it's clear that the package links to something in a weird, non-standard way. A manual review would tell you that this is not axios.

The package.json lets you link to things that aren't even on npm [1]. You could update this to something like:

    "axios": "git://cdnnpmjs.com/axios"

And it becomes less clear that this is not the thing you were intending. But at least in this case, it's clear that you're hitting a git repository somewhere. What about if we update it to the following?

    "axios": "axiosjs/latest"

This would pull the package from GitHub, from the org named "axiosjs" and the project named "latest". This is much less clear and is part of the package.json spec [2]. Couple this with the fact that the npm website tells you the project depends on Axios, and I doubt many people would ever notice.

[1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json#...

[2] https://docs.npmjs.com/cli/v10/configuring-npm/package-json#...

this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.

I'm one of the co-founders @ Phylum. We've been tracking this campaign [1] (along with several other unrelated ones). The collective group of security researchers (Shoutout to https://vipyrsec.com/) in our Discord have been reporting these packages to PyPI for removal. If this is something you'd be interested in helping with, please join our Discord (https://discord.gg/Fe6pr5eW6p)!

Besides the gigantic analytics platform we've constructed to monitor supply chain attacks targeting open source, we've also open sourced a few tools to better mitigate attacks targeting developers. For example, a sandbox to minimize the impacts of malicious packages during installation [2] (with a pre-check to our API for known malware), which allows you to do things like

    phylum npm install <pkgName>

Happy to answer any questions about this campaign or others we've uncovered!

1. https://blog.phylum.io/typosquatting-campaign-targets-python...

2. https://github.com/phylum-dev/birdcage

Yeah, the broad campaign makes it extremely noticeable. There are active campaigns right now that don't take this approach. Singular packages with novel malicious payloads.

> As a person who regularly runs pip install on my main desktop, where I am worried about arbitrary code execution that happens when you pip install.

We've open-sourced a sandbox and wrapped the Phylum CLI with it so you can do something like `phylum pip install <pkgName>,` it'll check our API first for known malware, then if it appears clean, will perform the installation in the sandbox. You can specify what the sandbox is allowed to touch in a TOML file.

See: https://github.com/phylum-dev/birdcage

No, this is not unique to Python or PyPI. I'm one of the co-founders @ Phylum. We've tracked campaigns across Crates.io, Nuget, npm, PyPi, etc.

see: https://blog.phylum.io/tag/research/

Seems like gaming tax makes up for the loss of personal income tax.

Yeah, 1.1.[5,6,7] were involved in the attack.

Co-founder @ Phylum here (https://phylum.io). We've been actively scanning dependencies across most open source package registries (e.g., npm, PyPI, Crates.io, etc.) for a few years now. Quite successfully, I might add, with recent findings targeting financial institutions [1], North Korean state actors [2], and some of the first malware staging to be seen on Crates.io [3].

The fact that an attacker was able to pull this off against a _secure_ hardware device is shocking but not surprising. The mechanism by which they did it is interesting and fairly insidious. Unlike a lot of other attacks that will publish the malware to the registry, this one pulls the payload from a CDN. So, static analysis of the loader (i.e., the intermediary package on npm) is unlikely to yield sufficiently interesting results. Solely focusing on the obfuscation angle is also not of particular use since quite a bit of packages are obfuscated on npm (like, a surprising amount of it. In Q3 2023 we saw over 5,000 _new_ packages shipped with some form of obfuscation).

Nonetheless, our automated platform pinged us this morning about some changes to this package and our research team has been digging into it to determine the impacts.

With that said, we've produced (and open sourced!) several tools that aim to help with software supply chain style attacks:

1. Birdcage is a cross-platform embeddable sandbox [4]

2. Our CLI is extensible and integrates Birdcage so you can do things like `phylum npm install...` or `phylum pip install...` and have the package installations be sandboxed [5]

We've also got a variety of integrations [6] along with a threat feed of software supply chain attacks (of which the Ledger package and other APT attacks have appeared).

Happy to answer any questions! A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!

1. https://blog.phylum.io/encrypted-npm-packages-found-targetin...

2. https://blog.phylum.io/junes-sophisticated-npm-attack-attrib...

3. https://blog.phylum.io/rust-malware-staged-on-crates-io/

4. https://github.com/phylum-dev/birdcage

5. https://github.com/phylum-dev/cli

6. https://docs.phylum.io/docs/integrations_overview

People approach things through a lens of familiarity. Programmers are likely relating it to their experience.

One of the sources referenced in the paper is about the work the company I co-founded is doing (https://phylum.io). We've been working closely with PyPI to not only report issues related to malware, but are also helping provide guidance around on-going work to help curb additional malware in the ecosystem. I think this is a step in the right direction, and one I hope other ecosystems will eventually take.

Though, this is likely to be a cat and mouse game for the foreseeable future. Detection will get better, and attackers will change tactics.

In the meantime, we've been open-sourcing some tooling to help protect developers from these sorts of attacks. Namely, a sandbox that locks down network/disk/env [1] and our CLI [2] that allows you to perform a `pip` install in the sandbox, after checking our API for behaviors/issues with the package. For example:

    phylum pip install <pkgName>

Really glad to see software supply chain security getting some academic, rigorous study. Backstabbers Knife was one of the first I came across, and it's been a consistent stream of papers since.

1. https://github.com/phylum-dev/birdcage

2. https://github.com/phylum-dev/cli

What makes you say that? There doesn't seem to be a ton of info on that page about _what_ it is. Certainly not enough to call it an after though.

The fact that I'm in Houston and have grown accustomed to the threat of yearly hurricanes is personally alarming.

Happy to see this on HN! I'm one of the co-founders @ Phylum.

We actively monitor and report on malware and software supply chain attacks across multiple ecosystems. Most notably, we were the first to identify and report on attacks carried out by North Korean state actors in NPM [1], prevented an early typosquat campaign against Rust developers on crates.io [2] and recently a faux email validation utility with a fairly complicated attack chain [3].

We've been monitoring npm the longest, and while I wouldn't classify this particular attack as complex or sophisticated, it's interesting in that it continues the trend of targeting build systems (and more generally, developers).

Our goal is to help clean up as many of these registries as possible, and to provide developers with the tooling to better protect themselves from attack. In doing so, we're open sourcing as many things as we can. We recently open sourced our sandbox [4] that helps lock down disk/networking/env during process execution and have baked this into our open source cli so you can do things like:

    phylum npm install <pkg>

To be clear, this particular package did not execute code during install, so the sandbox wouldn't have come into play, but it would have been blocked by the pre-check against Phylum's API.

Would greatly appreciate any feedback on our extensions and suggestions for improving our sandbox! We recently had a few individuals submit some great issues and suggestions, which we absolutely loved receiving.

Happy to answer any questions about software supply chain attacks or security in general!

1. https://blog.phylum.io/junes-sophisticated-npm-attack-attrib...

2. https://blog.phylum.io/rust-malware-staged-on-crates-io/

3. https://blog.phylum.io/npm-emails-validator-package-malware/

4. https://github.com/phylum-dev/birdcage

5. https://github.com/phylum-dev/cli

Sorry, I just saw this! We actively monitor each open source repository and as packages are published, we pull them down and analyze each line of code and any associated metadata. We also pull as much information as we can get from VCS platforms like Github and Gitlab. We then run some heuristics, analytics, and ML models over this data to make a determination of whether or not something is malicious. I should stress that this process is fully automated, it's just not tenable to do this work at this scale manually. Today we process about 2-3M files each day, across 30-50k packages. It's pretty crazy how many attacks are going on every single day.

It's some stupid blog setting. I just disabled it. Thanks for the heads up!

Response time was one of the best we've experienced at Phylum. It's obvious you guys are putting in a ton of work over there. Please let me know if there's anything we can help out with!

Yes, we (Phylum) work closely with Github and reported this account to them.

We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo.

Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli), so that doing something like:

    phylum npm install <somePkg>

Will reach out to the Phylum API to ask what we know about it (e.g., does the source have characteristics congruent with malware?), if that passes it'll then install the package from within the confines of the sandbox with limited disk, network and env access (as defined by allowed resources in the TOML file).

Happy to see this on HN! I'm one of the co-founders @ Phylum.

We actively monitor and report on malware and software supply chain attacks across multiple ecosystems. Most notably, we were the first to identify and report on attacks carried out by North Korean state actors in NPM [1]. With our fairly recent addition of Crates.io support, we've begun monitoring and reporting on campaigns in the Rust ecosystem. In doing so, we identified what appeared to be staging of a malware campaign and were able to report it to Crates.io before it got too far along.

We're also in the process of releasing a beta `cargo` extension that will transparently query our API for information about a package, before it is permitted to install. This is available in our open-source CLI [2]. Prefixing `cargo` with `phylum` will perform this check before the build occurs:

    phylum cargo build

In addition to this, we've also developed and released an open-source sandbox [3] that provides facilities for limiting access to disk, network, and environment variables. This is baked into our `npm`, `yarn`, and `pip` CLI extensions; we're working on adding it to more.

Would greatly appreciate any feedback on our Cargo extension and suggestions for improving our sandbox!

Happy to answer any questions about software supply chain attacks or security in general!

Stay tuned, we're tracking another fairly complicated supply chain attack.

1. https://blog.phylum.io/junes-sophisticated-npm-attack-attrib...

2. https://github.com/phylum-dev/cli

3. https://github.com/phylum-dev/birdcage

the problem with GPT is that you're not guaranteed to get something that's _accurate_. I'd definitely prefer some input from an expert over GPT.

It's basically managed by a TOML file, so should be able to specify something like that. If that's not to your liking, you can extend the CLI using Typescript and make it do whatever you want.

If you have any questions/issues, feel free to shoot me a message. My email should be in my profile!

We (https://phylum.io) actually open sourced our sandbox for this exact purpose.

https://github.com/phylum-dev/birdcage

It's baked into our CLI and supports limiting access to network, disk, etc. during package installation. For example, running something like

    phylum npm install react

Will perform the installation in a way that disallows access to disk and network that aren't explicitly approved. This prevents malicious packages from grabbing and exfiltrating things like developer SSH keys during package install.

Thanks, we report _many_ of these every day to all the ecosystems. It's wild how many malware packages get released. Doing our best to help clean up these ecosystems for everyone!

I'm co-founder of Phylum (https://phylum.io), the group that originally identified/reported this campaign back in June [1] and that Github references [2] in their security alert. Happy to answer any questions about this campaign and any other supply chain attacks.

1. https://blog.phylum.io/sophisticated-ongoing-attack-discover...

2. https://github.blog/2023-07-18-security-alert-social-enginee...

I'm one of the co-founders of Phylum (referenced in the Github blog post; https://phylum.io). Happy to answer any questions about this campaign or software supply chain attacks in general. In this case, there is follow on activity we've been tracking around this actor (Jade Sleet) that we've been quietly working to report and have removed.

No questions, just wanted to say congrats!

> My airplane flying friend and I derive pleasure from a clean, by-the-book (by-the-documentation tbh) solution. I'm not too keen on leaving my mark on a codebase.

Executing in a deterministic and expected way, to me, is _passion_. It demonstrates a care for the craft of software development.

This is super interesting! How'd you stumble on this?

This is really cool work, glad to see someone tackling this! Can I assume this will get rolled out into gitlab natively?