RT @ricburton: “Yesterday, the npm, Inc. security team, in collaboration with Komodo, helped protect over $13 million USD in cryptocurrency assets as we found and responded to a malware threat targeting the users of a cryptocurrency wallet called Agama.”
“Yesterday, the npm, Inc. security team, in collaboration with Komodo, helped protect over $13 million USD in cryptocurrency assets as we found and responded to a malware threat targeting the users of a cryptocurrency wallet called Agama.”
Users of npm will be automatically notified via npm audit if they encounter this malicious dependency in their projects.
I bet everybody runs that command all the time.
The KMD blockchain was not affected in any way. There is no vulnerability with the KMD blockchain or any other blockchain launched with Komodo’s technology. There is absolutely no need for a rollback or a hard fork. It’s crucial to understand that this was not a 51% attack or any other kind of attack on the KMD chain.
THE SYSTEM IS ROBUST
The process will be simple and blockchain-based.
I can't even come up with good snark anymore, it's like they're taunting me.
Apart from that - auto-updating your dependencies is something that most of programmers do almost reflexively. Expecting everyone to review the changes in dependencies is simply unrealistic. I think it's a problem of bad incentives alignment.
Hah. That would require crypto developers to write their own code rather than import the work of others while building their "product" off of a git clone of a git clone of a git clone of someone else's coin framework.
That ... is ... an optimistic take.
gott_modusmemcpy is a web development framework3 months ago
I just got home from my hackathon and won some sweet circular sunglasses which matches well with my early 90s Oasis haircut.
As soon as I got home I grabbed some Fridos and started munching before I ran a quick NPM update. An update a day keeps old age at bay, I always say.
Anyway, I've been working on this cool D3.js blockchain project that I think might be a good candidate for a kick starter. It's only been a WIP for like 2 weeks - maybe put in like 30 hours so far? I'm still in the process of going through a number of frontend frameworks. Elm or coffeescript might be the right choice here as well.
None the less, this is my 4th attempt at a startup idea. Blockchain is the future so I think this one's a winner. Just gotta find the right toolchain. Right now I've got like 100 packages worth of code (30% blockchain gonna be super productive here)
Do you need an Advisor? I've worked on 22 blockchain projects in the last year and all of my partners own yachts. Wouldn't you like to own a yacht? Elm in the cloud is the future, we need more innovators like you at our blockchain conferences. Estonian citizenship and chill?
/uj it _does_ happen in other package managers (a quick Google search gives me this: https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/ though i think i also recall another incident or two in the last few years), and realistically it is a risk at any point you use 3rd party packages without a full code audit (even with curation, what happens if a maintainer's account or the package's repo is compromised?). I think the big criticism is not that it can't happen with other package managers, but that the ecosystem and management style around JS tooling and NPM makes it more likely (e.g., low bar for getting packages listed, large volume of packages, tons of nested dependencies, etc), anecdotally, the above article mentions 38 typo squatting js packages to the 12 on pypi. So to summarize - it probably happens everywhere, but the JS ecosystem (especially the large volume of package dependencies, and authors of large numbers of small packages that attempt to get them into as many widely used projects as possible- like the is-odd guy) breeds an environment where just by volume infection seems plausible, and has the potential to have a great deal more reach than in some other ecosystems.
Agreed, just saying the crappy part of the ecosystem is not node.js, which does a good job of maintaining documentation, a stable api, etc. Its the NPM side thats an absolute mess. Someone could build an alternative community around node which wouldn't suck.
gott_modusmemcpy is a web development framework3 months ago
The nature of the average package itself (you're not going to find something like is-odd in nuget, for example); the average competency level of the communities behind them (npm's community consists of too many incompetent monkeys to be considered worthy of any respect); and the lack of ludicrous amount of dependencies, on average, per package?
So nothing but wishful thinking and self-proclaimed superiority?
fp_weenieZygohistomorphic prepromorphism3 months ago
> self-proclaimed superiority
the best kind of superiority.
gott_modusmemcpy is a web development framework3 months ago
>So nothing but wishful thinking
Do you think wishful thinking is what's keeping is-odd from existing in other languages?
>and self-proclaimed superiority?
Let me rephrase that: being a node developer doesn't by definition make you inferior.
Not being able to do your job effectively makes you inferior.
The node community is notorious for breeding incompetence. Incompetence is a form of inferiority, regardless of what your job is.
I don't have anything against people who use node in general. I actually have friends in the industry who use it, and I have a lot of respect for them as developers.
But they're *good*. Each one of them has stood out and been able to demonstrate traits that are necessary of any good programmer. They also know their shit beyond the web and they know how to differentiate between unprofessional masturbation and getting things done.
But the bulk of the community has served as a representation of what happens when natural selection picks an ecosystem and drives most of the programmers to the center of that ecosystem, regardless of their skill level, because now the barrier to entry is ridiculously low.
Technically this could happen to any community, and just about all communities/ecosystems have at least some notorious degree of stupidity.
It's just that, right now, the web has the highest degree of stupidity associated with it. Because it has the most people. Because people are fucking stupid.
But because I'm human and I need to vent I'm going to shit on NPM. Its quality is still amateur hour; it's not like the ecosystem doesn't need to improve, and it's not as if it hasn't essentially been the poster child of disaster due to dependencies.
That doesn't work even on positive numbers. Of course you can have a typo, but I specifically wrote it in a way to work with negative numbers as well.
I would say `x.mod(y)` might be deserving of a library, but not `x.even()` or `x.odd()`.
I think `x.mod(2) == 1` is clear enough not to fuck up
>For one thing, in a sane language you don't need to deal with null and undefined.
Oh ye of little faith.
The first is a null value and the second is a null reference. It all makes perfect sense once you embrace.
>> Using the seed phrases stored on the publicly accessible server, the Komodo Dev Team opened the compromised wallets and moved the funds to a secure wallet.
>> It is important to note that the Komodo Dev Team does not have access to anyone’s private keys, seed phrases, or funds
> Except for these seed phrases we don't have access to any seed phrases
Also we moved your funds to somewhere but we don't have access to your funds. SFYL.
>>The Komodo team always makes security the highest priority.
>Except for that one time where we released a wallet program without reviewing any of its dependencies, we always make security the highest priority
In agile projects, everything is always highest priority.
Yeah is-odd was the package I was actually thinking of. I forget if NPM has this feature on their website or not but, I know I used a tool at some point to see how many packages used $PACKAGE and it was thousands for is-odd. Never underestimate the stupidity of other people.
> "The attack worked because you smoothbrains are still giving your secret keys to web-based systems even though it's the Year Of Our Lord two thousand and nineteen and everybody has told you — TOLD YOU AGAIN AND AGAIN — not to send your private keys anywhere near the network. Told you so many times. So. 👏 Many. 👏 Times. It's time to STOP. You're welcome everyone!"
Here's my "guess," and it probably had something to do with GitHub's tooling in conjunction with NPM's I'm thinking. Here's why I say that...
GitHub recently started security scanning repositories that contain NPM packages. They send an email out, and it's a pretty darn thorough system, because I've received emails that are originating with repositories that are over 6 and 7 years old.
The way it works, from what I remember after reading through the GitHub notice about this practice, is that it is basically running "npm audit" on each repository.
Whether it's looking for a package.json before it does this, or how it determines what an NPM package is (maybe by using [npmjs.org](https://npmjs.org) to get a list of packages that use GitHub as their primary repository, instead), I don't know.
As any node developer knows, running npm audit will produce a list of packages that have security risks ranging from low to critical. GitHub has simply automated that practice, and good for them for doing so.
I've yet to be \*forced\* to fix anything, and if they started forcing me to fix 10 year-old repositories, I'd basically just start deleting repositories. I'm sure each developer will have his/her own opinion on the matter, but I have fixed some that I consider to be code worth keeping. I've used GitHub as a junk drawer at times, so this makes sense for me. An actual organization would obviously want to keep their public-facing repositories up to date with security patches.
One problem I see with this issue, if fixing packages becomes a forced thing, is that updating some packages will break builds quite readily. Not all updated packages are equal, and a good portion will kill the software they are part of.
> The way it works, from what I remember after reading through the GitHub notice about this practice, is that it is basically running "npm audit" on each repository.
They seem to do more than that though. I've seen GitHub warn about vulnerabilities way before npm has issued advisory. They might be reading cve databases automatically, or then it was done manually or semi-manually.
That's because they're not using 'npm audit' nor only NSP specifically for this. They're using [https://www.whitesourcesoftware.com/GitHubSecurityAlerts](https://www.whitesourcesoftware.com/GitHubSecurityAlerts)
So through npm audit they found that the new code was malicious. I wonder what audit does. In the end, the "malicious" part is probably just new/changed server endpoints or? What else could have been "suspicious" in the update?
npm audit is simply checking a known vulnerabilities list, and comparing it to the packages one has in their package-lock.json file. I read all the mundane notices, because I'm a nerve-wracked developer. :/
Huh.. so someone had to submit the package that the wallet was using before their "security tools" picked up on it? So basicly it was found manually and that person was responsible for avoiding the theft and not github or npm ?
Well, I was describing what npm audit does... not what NPM might do internally to look for malicious code. NPM might be internally looking for malicious code, flagging the files containing bad code for review, and then taking steps to place said file/package on the "bad packages" list.
If you look at the advisory itself found here...
... you can see it was reported by Adam Baldwin on 6/5. He leads the security effort at NPM from what I remember. They published the advisory, and it was picked up as affecting the Komodo wallet on 6/6.
That's actually pretty fast, as far as them finding out about it and doing something about it.
I don't think anyone can point a finger at NPM for this - it's not their job to police the package world, anymore than it's Google's job to police the internet.
I mean... the commit was in the article. But here you go, friend. :)
So, isn't this a bit ridiculous? Dev commits malicious code, which is later simply integrated into a live build and deployed. This is from the company that can protect all other blockchains from attack. Hmm, disappointing