TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Building a backdoor with Node.js

103 点作者 lirantal大约 5 年前

7 条评论

peter_d_sherman大约 5 年前
Excerpts:<p>&quot;So the only requirement for the victim is to install the library browser-redirect and add it to Express app, like a regular middleware:&quot;<p>[...]<p>&quot;I [Article Author] just published the malicious package to npm using npm install browser-redirect@1.0.2. <i>However, in Github you can’t see the malicious code</i> — see Master Branch and release 1.0.2. The reason for this is because npm does not check against Github or any other source control repository.&quot;<p>Security Perspective Takeaways:<p>1) Downloading and building source code, where authentication is performed between the downloaded source and the exact GitHub branch (rather than downloading a pre-built package or even source code where this branch authentication is not performed) would at least guarantee that the source code could be matched to the source on github, and could be subsequently audited...<p>2) The broader class of this attack (which includes such things as Windows Update, software auto-updaters, installers and package managers - both Windows and Linux) is basically: download malicious code - inside of a (user) believed non-malicious binary or library...<p>3) There are some very strong arguments here towards:<p><pre><code> a) Always use open source for whatever you can; b) Always download and compile the source for whatever you can; c) Always audit source that you&#x27;ve downloaded... </code></pre> I know; easier said than done...
评论 #22641743 未加载
评论 #22643032 未加载
评论 #22641212 未加载
cryptica大约 5 年前
The problem with Snyk and other automated vulnerability detection tools is the rate of false positives. For my open source library, the false positive rate so far (over many years) has been 100%. Not one of the many reports pointed to a single exploitable vulnerability in my library.<p>The reason is that a lot of vulnerabilities are context-specific. For example, a common one in JavaScript is Object prototype pollution; this is not an issue at all if the affected function is only used with trusted input.<p>Just because a function is vulnerable under a certain specific condition, it doesn&#x27;t mean that it&#x27;s generally vulnerable.<p>That&#x27;s like saying that chainsaws have a critical security vulnerability on the basis that if you put your foot in front of it, you will be badly harmed... and then you use this as justification to warn millions of tree removal experts (and their customers too) all around the world that their businesses are critically vulnerable and fundamentally unsound because they happen to use chainsaws.<p>The other common problem is when it flags a vulnerability with a specific function within a library, but that function is not actually used by the project. It&#x27;s not fair to label all downstream projects as vulnerable on the mostly false assumption that the project actually uses the vulnerable part of the code.<p>I think Snyk does this because it gets them attention and that&#x27;s how they turn a profit, but they have to get wiser because this strategy is compromising the quality of their service.
akoumjian大约 5 年前
Really astounding to see them publish this article today. I have a CVE that&#x27;s about to go live regarding auditing tools like this one.<p>I contacted Snyk a week ago to point out that their audit tool (just like npm audit, and others) cannot fundamentally protect you from attacks like this when installed to the same environment as a malicious package. Almost feels like they are trying to get ahead of it.<p>I was withholding the CVE while other tools are wrapping up their mitigation strategy. NPMJS and Snyk folks basically shrugged their shoulders. This is kind of forcing my hand to publish now.<p>Well, here is the blog post explaining:<p><a href="https:&#x2F;&#x2F;mulch.dev&#x2F;blog&#x2F;CVE-2020-5252-python-safety-vuln&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mulch.dev&#x2F;blog&#x2F;CVE-2020-5252-python-safety-vuln&#x2F;</a><p>And here is the snyk proof of concept:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;akoumjian&#x2F;npm-audit-vuln" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akoumjian&#x2F;npm-audit-vuln</a><p>TLDR; Don&#x27;t ever use the `npm install` version of Snyk. Use the binaries or the dockerized version.
评论 #22642722 未加载
philplckthun大约 5 年前
One can hope that with GitHub supporting signed commits and signed tags that now that they’ve acquired npm there’ll be a way to match up a signed release with an npm release.<p>Signed releases on npm in general would be a start as then we could at least increase the reliability of security vulnerability notifications.<p>That being said, as pointed out in another comment, the amount of false positives for instance for regex vulnerabilities in libraries that are only used in the devDependencies of a repository are too high.
cj大约 5 年前
Slightly off topic (but considering this is promo article from Snyk):<p>What is the value of Snyk now that Github and NPM have built-in dependency security audits?<p>I was a customer of Snyk before auditing was built in to NPM &#x2F; Github (and before Snyk&#x27;s price shot up to $750&#x2F;mo for private repos). Was always confused how they justified that price point now that their main value prop is built in to npm for free.
LockAndLol大约 5 年前
Bud, screen-space is scarce. Why does that header permanently take up a third of vertical space?
评论 #22640259 未加载
评论 #22639811 未加载
w-ll大约 5 年前
Why Node? Why make a backdoor with a 90MB payload?<p>Sorry guys, I should have fully read the article.
评论 #22639289 未加载
评论 #22639266 未加载
评论 #22639268 未加载
评论 #22639428 未加载