This Hacker News discussion centers on a security incident where malicious code was injected into several DuckDB npm packages. The conversation highlights several key themes regarding the vulnerabilities and potential solutions.
Phishing as the Initial Attack Vector
A primary theme is the method used to compromise the maintainers' accounts, which was identified as a sophisticated phishing attack. Users were highly interested in how this attack bypassed existing security measures.
- "An attacker emailed a maintainer from a legitimate looking email address. The maintainer clicked the link and reset their credentials on a legitimate looking website. The attacker then signs into the legitimate duckdb account and publishes their new package." (OtherShrezzing)
- "The fact this is NOT the standard phishing email shows how low the bar is: 1. the text of the email reads like one you'd get from npm in the tone, format and lack of obvious spelling & grammatical errors. It pushes you to move quicker than you might normally, without triggering the typical suspicions. 2. the landing domain and website copy seem really close to legit, no obfuscated massive subdomain, no uncanny login screen, etc." (skeeter2020)
- "I think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?" (diggan)
- "This is the second phishing attack that hit junon yesterday." (masfuerte)
Weaknesses in 2FA and Credential Management
The discussion strongly suggests that current two-factor authentication (2FA) methods, especially when combined with password managers, have exploitable weaknesses that attackers are leveraging.
- "2FA for such high profile packages should be enforced" (arewethereyeta)
- "It is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the attack yesterday went through 2FA by tricking the author into doing a '2FA reset'." (jsheard)
- "Besides, the email conveniently mentions their 'automation' tokens as well, which when used for publishing updates, bypasses 2FA fully." (diggan)
- "He would have entered 2FA too" (koakuma-chan)
- "This attack (and yesterday's) are relay attacks, with the attacker in the middle between npm and the target." (skeeter2020)
- "How did the attacker know their 2fa in order to send them a fake 2fa request?" (polynomial)
- "It acted as a proxy for the real npm site, which was the one to send the request, intercepting the code when the user inserted it." (xx_ns)
The Potential of Passkeys
Passkeys emerged as a frequently discussed and promising alternative to 2FA, due to their inherent resistance to phishing.
- "Passkeys should be enforced" (frizlab)
- "Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable." (frizlab)
- "Should enforce passkeys not 2FA" (koakuma-chan)
- "Passkey only works when you're on the correct website" (koakuma-chan)
- "The actual URL in the browser is part of what the passkey signs. So if you go to totallynotascam.com which turns out to be some dude intercepting and passing the connection to npm, the signature would be refused by npm since it wouldn't be for the correct domain." (vladvasiliu)
- "The browser ensures that a passkey can only be used on the correct site." (operator-name)
- "And they are locked to an origin by design, so you canโt accidentally use one on the wrong domain because the browser simply wonโt do it." (semiquaver)
Password Managers and Their Limitations
The role and effectiveness of password managers, particularly on mobile devices, were debated, with users highlighting how they can be both a defense and a potential vulnerability depending on their implementation.
- "In hindsight, the fact that his browser did not auto-complete the login should have been a red flag." (quoted from the article)
- "A huge red flag. I wonder if browsers should actually detect if you're putting login details for site A manually into site B, and give you a 'are you sure this isn't phishing' warning or something?" (IshKebab)
- "This was mobile, I don't use browser extensions for the password manager there." (quoted from the article, IshKebab)
- "My guess is their password manager is a separate app and they use the clipboard (or maybe it's a keyboard app) to paste the password. No way for the password manager to check the url in that case." (hiccuphippo)
- "Strongbox pw manager on iOS by default doesn't autofill. You have to go settings to specifically enable that feature. If you don't, it's copy&paste." (jasode)
- "I regularly check the bitwarden icon for example to make sure I am not on the wrong site (b/c my login count badge is there). In fact autofill has saved me before because it did not recognize the domain and did not fill." (nightski)
- "The usual cause is legitimate websites not working instead of actual phishing attempts." (diggan)
- "I hit this all the time with 1Password+Firefox+Linux (fun combo). Just copying-pasting the username+password because it doesn't show up is the wrong approach." (diggan)
- "Even standard autofill (as in that built into Safari, Firefox, Chrome etc) gets tripped up on 100% legit sites shockingly often. Usually the cause is the site being botched, with mislabeled fields or some unnecessarily convoluted form design that otherwise prevents autofill from doing its thing." (cosmic_cheese)
- "For regular computers users I recommend using a password manager to prevent these types of phishing scams. As the password manager won't autofill on anything but the correct login website, the user is given a figurative red flag whenever the autofill doesn't happen." (quitit)
- "My password manager is a separate app, I always have to manually copy/paste the credentials. That's because I believed that approach to be more secure, now I see it's replacing one attack vector for another." (stanac)
Concerns about npm's Responsiveness and Platform Security
There were significant criticisms leveled against npm's platform and its responsiveness to security threats.
- "At least one thing is clear from this week: npm is too slow to respond." (herpdyderp)
- "At least I think that's pretty unlikely. I aren't even a high-profile npm author, and if I publish any npm package they end up being accessed/downloadaded within minutes of first publish, and any update after that." (diggan)
- "DuckDB maintainer here, thanks for flagging this. Indeed the npm stats are delayed. We will know in a day or so what the actual count was. In the meantime, I've removed that statement." (hfmuehleisen)
- "Yes we tried, but npm would not let us because of 'dependencies'. We've reached out to them and are waiting for a response. In the meantime, we re-published the packages with newer versions so people won't accidentally install the compromised version." (hfmuehleisen)
- "They have now removed the affected versions!" (hfmuehleisen)
- "This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware." (elric)
- "I think just supporting yubikeys is sufficient." (nodesocket)
- "Is there a way to configure npm that it only installs packages that are, like, a week old?" (ptrl600)
- "If I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else." (herpdyderp)
- "They could definitely add a maker-checker process (similar to code review) for new versions and make it a requirement for public projects with x number of downloads per week." (robjan)
- "For critical infra projects like this, making a release should require at least three signatures from different maintainers. In fact, I am surprised that this is not a common practice." (ritcgab)
Generative AI and the "Democratization" of Phishing
A smaller, but distinct theme, was the discussion around whether generative AI plays a role in making phishing attacks more sophisticated or accessible.
- "All the talk of AI disrupting tech; this is an angle where generative AI can have a massive impact in democratizing the global phishing industry." (skeeter2020)
- "How does AI relate to this in any way? you can easily clone websites by just copying via devtools, like seriously" (r_lee)
- "So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though." (diggan)
- "Is this comment AI generated?" (spoaceman7777)
Concerns about Domain Names and URL Spoofing
The integrity of domain names and the user's ability to verify them were discussed, with mentions of URL shorteners, TLDs, and Unicode characters as potential obfuscation methods.
- "The domain was also plausible." (skeeter2020)
- "The DOMAIN NAME! Am I on trusted site? Well .help TLD would SURELY ring a bell and immediately involve research as whether that domain is associated to npm in any way." (jve)
- "Unicode means that domain names can be different and look the same unless you really look close. Even if you just stick to ascii l (letter) and 1 (number) look so close that I would expect many people to not see the difference if it isn't pointed out." (bluGill)
- "more alarming than .help domain is the domain registration just few weeks ago. I got scammed just last week when paying with credit card online, and only later when investigating discovered several of identical eshops with different .shop domains registered just months ago if domain is less that year old, it should raise red flags" (400thecat)
- "Maybe email software should add an option to make links unclickable, or show a box with the clear link (and highlight the domain) before letting the user go through it." (hiccuphippo)
- "This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time." (elric)
Calls for Stronger Email Authentication and Developer Education
A significant portion of the discourse focused on improving email security and educating developers to be more vigilant against social engineering tactics.
- "Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform. Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks." (elric)
- "A simple self defined word in an email and you will see, if the mail is fake or not." (progx)
- "SPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records." (elric)
- "JimDabell: The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance." (JimDabell)
- "I think you just have to distrust email (or any other "pushed" messages), period. Just don't ever click on a link in an email or a message. Go to the site from your own previously bookmarked shortcut, or type in the URL." (SoftTalker)
- "And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack overflow" (evantbyrne)
Systemic Issues and Human Fallibility
Underlying these specific points is a broader concern about the inherent difficulties in securing complex software supply chains and the persistent role of human error.
- "Itโs a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself." (elric)
- "There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken." (elric)
- "You never make a mistake? Never ever? It's a question of numbers. If the likelihood of making a mistake is 1 in 10000 emails, send out links to 10.000 package maintainers, and you've got a 63% chance of someone making that mistake." (tgv)
- "MitPitt: Removing humans will help" (MitPitt)
- "I genuinely don't understand why. 2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action." (egorfine)
- "I think the downvotes are because enshittification is a different thing, intentionally done by the developers themselves. granted but the motivation is payment I think and that originates elsewhere." (hiccuphippo, mediumsmart)