Malicious Python packages replace crypto addresses in developer clipboards | Hacker News Reader

Malicious Python packages replace crypto addresses in developer clipboards

blog.phylum.io

92 pointssbf50146 comments

Previous thread 5 days ago, 325 comments

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

That’s a different, unrelated campaign!

I believe you, but the overall story is similar enough that the current one probably doesn't count as significant new information (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...). HN thrives on differences, and repetition (even if it isn't exact repetition) tends to reduce the interest of a submission.

That's fair, thanks for the feedback!

This is exactly the type of attack many cypherpunk bitcoin types have been paranoid about for years.

And it's why in any good hardware wallet, you need to explicitly confirm the address you're transferring to on the wallet's air gapped screen and make sure it wasn't swapped in the copy/paste.

I'm sure it would also be quite easy for this kind of attacker to generate thousands of addresses they control, and have their software pick one that looks 'closest' to the one being subverted to increase the likelihood that a lazy user just sanity checks a few characters at the beginning and end of the address before confirming.

Survival of the most paranoid.

There was some discussion of this over on Reddit. I didn't see evidence of it, but the claim was that this had already happened. I'd be curious if someone had some examples of it in the wild.

This particular clipboard attack has been part of malware for at least 5 years, maybe 10. But I haven't heard of it being distributed via a package manager until now.

Oh I meant malware generating addresses that look directionally similar to the address the user expects (as opposed to a random address that's hardcoded). I'm not sure if this is a thing, or just conjecture from others.

It could be very hard to prove after the fact. And it's generally much more likely that human error causes a loss than to be victim to a malicious attack. So even if it has legitimately happened, it's likely to be dismissed as the person was just incompetent and that there just wasn't enough software safeguards to protect people from themselves.

This is probably a good lesson in general for intelligent malicious actors. If you have an exploit that works, it's important that you use it rarely enough and against the right marks that the loss doesn't enter the collective consciousness as a malicious attack, but simply as an individual or systemic failure.

And for those of us who strive to be constructive and defensive actors, it's an important lesson to remember that sometimes malicious actors disguise their actions as amoral bugs in the system. Regular random auditing of the seemingly mundane is an important tool to uncover these kinds of exploits.

I remember malware replacing addresses on the clipboard like this, probably 8-10 years ago, there were reddit threads about it at the time for anyone with energy to look.

Ouch. I haven't handled Bitcoin since the early days, addresses are like 30 chars aren't they? It seems like it would be really easy to screw up anything involving eyeballs there.

The last 6-ish characters are a checksum. It would be very computationally intensive to generate a similar-looking address without changing the checksum, though of course not impossible.

Public addresses are 160 bits in bitcoin, so it depends on your character encoding. But yes, very long and random.

Pieter Wuille has a very interesting talk on public addresses and some novel work he did to drastically improve address error detection. Worth a watch for some cool computer science. https://www.youtube.com/watch?v=NqiN9VFE4CU

Honestly, it's kind of surprising that these kinds of exploits don't happen all the time since base layer bitcoin transactions alone secure $14 trillion in annual transfer volume in recent years. That's a huge honey pot for malicious attackers that seems to mostly go under exploited.

Perhaps a better way would be to use something along the lines of SSH’s randomart.

I’m sure there would be an even more interesting variant where the address could be used to generate a prompt for DALL-E.

I'm surprised someone hasn't built what3words style translation algorithm for crypto. So instead of the user seeing an address as a long stream of character, it becomes a series of words.

Isn't that almost what those wallet seed phrases are? Or something very similar looking - that could introduce another new line of attack, where you think you're using an address and accidentally have your seed phrase.

That's for the private key, right? OP was talking about a smaller "fingerprint" for the public key that wouldn't necessarily be as long as a full seed phrase (or as secure)

Maybe something like ENS?

Given that these attacks target simple typos on high-download packages, is there no avenue for repositories to implement an “are you sure you want to download this” feature? Some heuristic on the Levenshtein distance and download count, say on the top 100, would go a long way to preventing these kind of attacks.

(With some --ignore-typo-suggestion just in case of automated edge-cases, of course :)

This would be an incredibly useful feature, I think. It was part of the motivation for our sandbox, honestly. It should mostly operate as a pass through the the various package managers - but with some extra security checks.

In this way a `phylum npm install <pkgName>` would perform the typosquat checks _and_ limit access to system resources. You can even alias this as `alias npm="phylum npm"` so that it's easier for the user.

I participated in some Freenet architecture discussions when they were still trying to take the prototype to a practical implementation. There was some talk even back then about how opaque hashes are to the human mind and that we might be better off using phrase mnemonics instead. Particularly useful I would think for transcription errors like this, malicious or accidental.

The problem is that the information density of replacing hex with words is quite low, on the order of 14 bits per word, but much longer than the four letters needed to represent 16 bits in hex, which is itself a lot less dense than base64. You’d need 12 words to uniquely identify a sha-1 hash and most modern algorithms are less dense than that. But it would be harder to trick someone.

Maybe there’s some sort of 5:4 coding system that’s easier for humans to scan, still to be discovered out there?

I think you may have intended to respond to this comment? [1]

[1] https://news.ycombinator.com/item?id=33512203

Similar observation, posted at the same time. I just have a bit more context. Eyeballs glaze over looking at hex or base64 identifiers. It's a shame that in practice you likely can't use something that the eyes don't gloss over because you lose too much density in the process.

I'm happy to be proven wrong by someone who finds something in the middle. Preferably without using emojis...

Products like Nexus Firewall[0] have settings to block suspicious packages.

[0] https://blog.sonatype.com/sonatype-releases-new-nexus-firewa...

Awesome seeing this posted! Full disclosure: I'm a co-founder at Phylum.

This campaign is ongoing. Our system just notified us of two more packages, which have been reported to PyPI. I expect this list to continue to grow throughout the day.

As a related aside, we are working on a package sandbox that prevents access to disk, network and env variables during package installation. It's not quite ready for primetime, but it is completely open source and we'd love some early feedback/contributions!

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

If anyone has any questions, I'd be more than happy to answer them!

Cool project! Phylum looks useful at addressing a few worries I have with Python. Would it work in a mostly air-gapped environment, or does it have to call home regularly?

We are basically ingesting and analyzing every package as it gets published to the various ecosystems (currently NPM, PyPI, Rubygems, Maven and Nuget; Go and Crates support landing in beta soon).

This is currently offered as a SaaS solution, but we'll be providing an on-prem offering by EOY that should work well in an air-gapped environment.

The sandbox I mentioned above is rolled into our CLI by default, but that should operate well enough on its own without needing to call out to our API if you wanted!

Thanks Louis, I’ll keep an eye out for it!

no problem, happy to chat whenever!

interesting read. i was a bit confused at first, thinking that the malicious package names were being inserted into cut and pasted pip/apt/etc install strings. i see now that's not happening in this scenario, but curious if that behavior has ever been observed.

We haven't seen this particular sort of thing just yet in packages. There was a similar attack from a few years ago called "pastejacking" that did something directionally similar to what you're suggesting though!

How does Phylum detect these issues? I guess you have a mirror of PyPI and run some kind of scanner over all the code?

This is why we need proper sandboxing of applications and libraries. There’s no way tools should be able to silently run any code they want, with my user’s full permissions on my desktop machine.

Apps couldn’t get away with this sort of thing on iOS or Android. It’s inconvenient, but we need to raise the bar in the same way for security permissions and sandboxing on the desktop. (But obviously, with the user in control.)

Working on it! https://github.com/phylum-dev/birdcage

Allows you to specify the allowed permissions in a toml file. Still a wip, but would love some feedback!

At some point we need to give up on "everyone can run their home security better than the CIA room Tom Cruise abseiled into".

If every time I wanted to pay for a coffee I was risking losing all my savings, then I (and millions of others) would go back to cash

I am not sure where that leaves us for "digital native cash". Perhaps phones and secure enclaves will save us, perhaps we just have to pay the Visa tax.

Absolutely don't disagree with this sentiment. The fact of the matter is the attackers only have to be "right" once. Whereas the rest of us have to be right hundreds or thousands of times. If it's a numbers game, the odds are definitely in favor of the attackers.

Cryptocurrency aside, it definitely looks like these attacks are ramping up and we - the developers with access to critical infrastructure - are the primary targets. Today its crypto, tomorrow it's SSH keys.

It's both worrisome and tremendously annoying.

Yeah that point about SSH keys just worried me.

The keys to pretty much every online kingdom are only 2048 bits long and once the methods to exfiltrate crypto have been honed it's worth looking at ways to weaponise the others.

Somewhat ironically, the article won't even show up unless I allow content from a 3rd party website : unpkg.com

Be your own bank IT security department!

“At the time of this writing, no funds have been transferred to the attackers.”

We're trying to stay on top of this as much as possible. I'm hoping if we can be quick to report, the attackers will have wasted a bunch of effort on this campaign and not see a dime.

even giveaway scams on twitter or YouTube which require no coding skills make more than that. it is easier to just pretend to be someone famous and ask people to give you crypto instead, whether for a giveaway, NFT, or a fake project.

Python package version resolution is a Turing Complete problem and installs are not deterministic. Securing the ecosystem is going to be serious work.

> Securing the ecosystem is going to be serious work

Oh it _absolutely_ is!

We're working extremely hard here and I think we're making great strides. More hard work to come, but I think it's absolutely worth the effort!

https://www.splitgraph.com/blog/poetry-dependency-resolver-s...

This is wonderfully absurd in the best sort of way

Reply on news.ycombinator.com