←back to thread

1369 points universesquid | 2 comments | | HN request time: 0.53s | source
Show context
DDerTyp ◴[] No.45170133[source]
One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list.

It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one.

This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction.

We did a full deobfuscation of the payload and analyzed this specific function. Wrote up the details here for anyone interested: https://jdstaerk.substack.com/p/we-just-found-malicious-code...

Stay safe!

replies(5): >>45170393 #>>45170458 #>>45172015 #>>45173594 #>>45180351 #
josefbud ◴[] No.45172015[source]
I'm a little confused on one of the excerpts from your article.

> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3

As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx

And with that, packages usually shouldn't be getting updated in your CI pipeline.

Am I mistaken on how npm(/yarn/pnpm) lockfiles work?

replies(3): >>45172213 #>>45172215 #>>45172431 #
sigotirandolas ◴[] No.45172213[source]
Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`.

In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.

replies(3): >>45172286 #>>45172488 #>>45172844 #
0cf8612b2e1e ◴[] No.45172488[source]
Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.
replies(2): >>45173657 #>>45175213 #
metafunctor ◴[] No.45173657[source]
Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.
replies(2): >>45175560 #>>45177024 #
1. jiggawatts ◴[] No.45175560[source]
> every three years the people get swapped out

That's because they are being "replaced", in a sense!

When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes.

Hence the childish attitude and behaviour with everything to do with JavaScript.

replies(1): >>45175945 #
2. metafunctor ◴[] No.45175945[source]
Good point! The web is going through its own endless September.

And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.