Why in the world would that specific 3x3 matrix be a trigger for an attack? Are they trying to find someone doing some particular kind of numerical analysis?
Presumably it's so it can be used as a subdependency for setting up an attack in a popular, legitimate package, e.g. via a pull request. The code in the legitimate package would not arouse suspicion at all.
I would assume it’s actually so they can allow it to spread before it gets activated. Then do something that affects the entire chain of package dependencies
This matrix is not a condition, it’s a key. JSON.stringify with it’s data goes to the scrypt as a password and that creates an AES-256-GCM key. There is no if, every other input won’t decrypt. That’s why no one will get payload from the package without knowing the exact input.
Perhaps they just need a way to sneakily activate it? Or perhaps they have a target application which they know uses that. This method suggests a supply chain attack where a valid contributor to a library 'accidentally' includes this package and the hack carries out before anyone notices.
My guess is that it's crypto related but of course it could be anything.
Does the FBI or any other law-enforcement office follow up on these backdoors? Is this considered a crime, or even conspiracy to commit a crime, or is it only the act of using the backdoor that's a crime?
We found a remote access implant hidden inside [email protected], an npm package that copies the popular mathjs library.
The NPM package not named in the clickbait-y post title is “mathmain@1.0.0”, for those who run into this particular site obstacle; the later packages also named are “mathsbase” and “math-universe”. (EDIT: I see the submission title has been updated, so that’s my complaint addressed, thanks mods!)
Safedep, if you’re reading this, perhaps you should reconsider having that site feature applied to your post — or if it’s something you enabled in, say, Cloudflare, perhaps file a support ticket noting that their email protection is hiding package version strings.
Probably Cloudflare. For me it shows the package name rather than a redaction. But from memory, Cloudflare email protection redacts it that way in the HTML and then adds a little JS to put it back in which might also do some kind of check to see if it thinks you are a real user before unredacting it.
My strategy of not using dependencies at all seems to be getting stronger everyday.
Also no LLM generated skipping this hypetrain completely. Just hand written code I can personally vouch for. Code in exchange for cash, this is professional business, Boss.
Btw, I'm available for hire, preferably by Pre Market Fit or pre-MVP startups, email in profile.
So, where do you draw the line? Do you accept having an OS? Because that is a huge dependency. So I assume you run directly on BIOS or UEFI? But even those are fairly sizable on modern systems.
So, where do you draw the line? Do you accept having an OS?
Yes I accept using an OS usually, I guess there's much more than could fit on a single catchy sentence, but there's a clear policy.
Operating System is the biggest exception, for Windows it's pretty simple to carve out everything that is manufactured by Microsoft itself. But for the main Linux OS (Debian/RHEL), I include everything that is distributed by the main package manager (apt/yum) as allowed by the OS policy exception. (On Windows, this is equivalent to adding software packaged and signed by microsoft, like Git).
Alternative package managers like flatpak or snap are against my personal policy, not only are they very bloaty, but they kind of break the OS monopoly and push towards less safe supply chains, if it's not in apt/yum, then I don't use it.
So I assume you run directly on BIOS or UEFI?
I have gone that route, but only experimentally, it's not very hard to get C compiled binaries to run and interface with keyboard and display through BIOS, but there's a lot of extra work that needs to be done incrementally, in order to use features in the sequence that they have historically been available, like 16 bit, 32 bit, 64 bits, 4GB memory. If you think of Wirth's law, this might actually be an effective long-term pacing strategy.
But I'm not that hardcore personally, not for lack of want, in a professional settings I pull towards the pragmatic side and start conceding to stuff like using an OS, maybe using one or two packages. I would probably revisit booting directly to binary if any startup I work with hits a home run and needs to upgrade to at least 10k+ concurrent users. It's like one step removed from an ASIC, which is a stage almost no company enters, but I would have definitely have passed the baton at that stage, custom hardware is another discipline.
But even those are fairly sizable on modern systems.
Well not BIOS, but UEFI and device drives certainly are. BIOS would just be some (mostly unwritten) standards on how to initialize, then it dissapears. Of course hardware itself is a dependency, and I'm definitely not going to be summoning computing from heat, sand, and electricity, but my line is definitely at the OS and above.
One final exception that wasn't mentioned is the programming language and its 'built in libraries'. I use the programming language along with its standard distribution. For Python (my main language), that means I don't use pip, but I might use 'import sockets' (it's almost the same as using cffi and glibc anyways). There's an analogue in almost all languages, node with npm, java with maven, php with composer, I just don't add those kinds of dependencies if I have control over it. I chmod ugo-rwx requirements.txt to avoid other engineers from adding leftpadisms.
That's not to say that it never happens, maybe even I imported Flask to meet a deadline, and maybe there's that perfect library from a good source that someone else suggests and it gets accepted, but it doesn't hurt to add some friction, it catches a lot of trash packages from being added to the foundation of a startup, which give almost no benefits at great expense over the lifecycle of the core
Yeah lots of weird emphasis on things a human wouldn't care about. And emphasis on what it isn't, rather than what it is. It's not Y, it's X. And there are two files!!!
A lot of this seems to be a reminder that the CommonJS module format should just be left to die already. Not that you can't pull similar tricks with `await import()` in ESM, but you can't easily grep an entire dependency for dynamic `require()` half as easily as you can can `grep import\s*\(` for dynamic import and analysis tools for static `import` keyword are easy to use/build rather than no such thing for CommonJS.
Someone thought I was joking when I said I always check JSR before NPM now, because I trust ESM so much more than CommonJS.
Why in the world would that specific 3x3 matrix be a trigger for an attack? Are they trying to find someone doing some particular kind of numerical analysis?
Presumably it's so it can be used as a subdependency for setting up an attack in a popular, legitimate package, e.g. via a pull request. The code in the legitimate package would not arouse suspicion at all.
Now I'm curious what the target was. Are there any notable classes of programs/problems where you'd do an LU decomposition of this specific matrix?
I would assume it’s actually so they can allow it to spread before it gets activated. Then do something that affects the entire chain of package dependencies
This matrix is not a condition, it’s a key. JSON.stringify with it’s data goes to the scrypt as a password and that creates an AES-256-GCM key. There is no if, every other input won’t decrypt. That’s why no one will get payload from the package without knowing the exact input.
1. “The X is not Y, it's Z” 2. 3 months old account
Bad bot.
(I still wonder what these not operators have to gain in that process, but they sure want HN karma).
Perhaps they just need a way to sneakily activate it? Or perhaps they have a target application which they know uses that. This method suggests a supply chain attack where a valid contributor to a library 'accidentally' includes this package and the hack carries out before anyone notices.
My guess is that it's crypto related but of course it could be anything.
Does the FBI or any other law-enforcement office follow up on these backdoors? Is this considered a crime, or even conspiracy to commit a crime, or is it only the act of using the backdoor that's a crime?
I can also see that it's still up in NPM without any warning of any kind: - https://www.npmjs.com/package/mathmain
But the Github repo for the package and the author are down: - https://github.com/allendev12 - https://github.com/allendev12/mathmain
Fascinating how intricate the target selection is on this
The NPM package not named in the clickbait-y post title is “mathmain@1.0.0”, for those who run into this particular site obstacle; the later packages also named are “mathsbase” and “math-universe”. (EDIT: I see the submission title has been updated, so that’s my complaint addressed, thanks mods!)
Safedep, if you’re reading this, perhaps you should reconsider having that site feature applied to your post — or if it’s something you enabled in, say, Cloudflare, perhaps file a support ticket noting that their email protection is hiding package version strings.
Probably Cloudflare. For me it shows the package name rather than a redaction. But from memory, Cloudflare email protection redacts it that way in the HTML and then adds a little JS to put it back in which might also do some kind of check to see if it thinks you are a real user before unredacting it.
I actually came across someone that cracked it (or use Claude/China to crack it)
Turns out the second stage is completely broken, which is even more odd..
https://research.veryserious.systems/lusolve-and-you-shall-r...
My strategy of not using dependencies at all seems to be getting stronger everyday.
Also no LLM generated skipping this hypetrain completely. Just hand written code I can personally vouch for. Code in exchange for cash, this is professional business, Boss.
Btw, I'm available for hire, preferably by Pre Market Fit or pre-MVP startups, email in profile.
Let us know in 2838 when you finish your first program, would love to check it out!
So, where do you draw the line? Do you accept having an OS? Because that is a huge dependency. So I assume you run directly on BIOS or UEFI? But even those are fairly sizable on modern systems.
Yes I accept using an OS usually, I guess there's much more than could fit on a single catchy sentence, but there's a clear policy.
Operating System is the biggest exception, for Windows it's pretty simple to carve out everything that is manufactured by Microsoft itself. But for the main Linux OS (Debian/RHEL), I include everything that is distributed by the main package manager (apt/yum) as allowed by the OS policy exception. (On Windows, this is equivalent to adding software packaged and signed by microsoft, like Git).
Alternative package managers like flatpak or snap are against my personal policy, not only are they very bloaty, but they kind of break the OS monopoly and push towards less safe supply chains, if it's not in apt/yum, then I don't use it.
I have gone that route, but only experimentally, it's not very hard to get C compiled binaries to run and interface with keyboard and display through BIOS, but there's a lot of extra work that needs to be done incrementally, in order to use features in the sequence that they have historically been available, like 16 bit, 32 bit, 64 bits, 4GB memory. If you think of Wirth's law, this might actually be an effective long-term pacing strategy.
But I'm not that hardcore personally, not for lack of want, in a professional settings I pull towards the pragmatic side and start conceding to stuff like using an OS, maybe using one or two packages. I would probably revisit booting directly to binary if any startup I work with hits a home run and needs to upgrade to at least 10k+ concurrent users. It's like one step removed from an ASIC, which is a stage almost no company enters, but I would have definitely have passed the baton at that stage, custom hardware is another discipline.
Well not BIOS, but UEFI and device drives certainly are. BIOS would just be some (mostly unwritten) standards on how to initialize, then it dissapears. Of course hardware itself is a dependency, and I'm definitely not going to be summoning computing from heat, sand, and electricity, but my line is definitely at the OS and above.
One final exception that wasn't mentioned is the programming language and its 'built in libraries'. I use the programming language along with its standard distribution. For Python (my main language), that means I don't use pip, but I might use 'import sockets' (it's almost the same as using cffi and glibc anyways). There's an analogue in almost all languages, node with npm, java with maven, php with composer, I just don't add those kinds of dependencies if I have control over it. I chmod ugo-rwx requirements.txt to avoid other engineers from adding leftpadisms.
That's not to say that it never happens, maybe even I imported Flask to meet a deadline, and maybe there's that perfect library from a good source that someone else suggests and it gets accepted, but it doesn't hurt to add some friction, it catches a lot of trash packages from being added to the foundation of a startup, which give almost no benefits at great expense over the lifecycle of the core
Had I found sthg like this, I'd be proud to tell everyone and certainly enjoy doing the writeup. But this smells like it was ai-written...
Yeah lots of weird emphasis on things a human wouldn't care about. And emphasis on what it isn't, rather than what it is. It's not Y, it's X. And there are two files!!!
A lot of this seems to be a reminder that the CommonJS module format should just be left to die already. Not that you can't pull similar tricks with `await import()` in ESM, but you can't easily grep an entire dependency for dynamic `require()` half as easily as you can can `grep import\s*\(` for dynamic import and analysis tools for static `import` keyword are easy to use/build rather than no such thing for CommonJS.
Someone thought I was joking when I said I always check JSR before NPM now, because I trust ESM so much more than CommonJS.