[HN Gopher] Social engineering campaign targeting tech employees...
       ___________________________________________________________________
        
       Social engineering campaign targeting tech employees spreads
       through NPM malware
        
       Author : feross
       Score  : 69 points
       Date   : 2023-07-25 16:35 UTC (6 hours ago)
        
 (HTM) web link (socket.dev)
 (TXT) w3m dump (socket.dev)
        
       | louislang wrote:
       | I'm co-founder of Phylum (https://phylum.io), the group that
       | originally identified/reported this campaign back in June [1] and
       | that Github references [2] in their security alert. Happy to
       | answer any questions about this campaign and any other supply
       | chain attacks.
       | 
       | 1. https://blog.phylum.io/sophisticated-ongoing-attack-
       | discover...
       | 
       | 2. https://github.blog/2023-07-18-security-alert-social-
       | enginee...
        
         | Uptrenda wrote:
         | Good work on finding this. This is a scary attack.
        
           | louislang wrote:
           | Thanks, we report _many_ of these every day to all the
           | ecosystems. It's wild how many malware packages get released.
           | Doing our best to help clean up these ecosystems for
           | everyone!
        
       | bobthepanda wrote:
       | ...do people just accept invitations to clone repos on Whatsapp?
        
         | tsak wrote:
         | It's the least you can do for our North Korean comrades
        
         | SketchySeaBeast wrote:
         | I can only assume it's the same people who are opening
         | "ImportantDocument.doc.exe" in their email.
        
       | pcthrowaway wrote:
       | JS Party episode on Socket, if anyone is interested:
       | https://changelog.com/jsparty/272
        
       | padjo wrote:
       | I'll be the first to say it: it looks like breaking everything
       | down into a dependency graph of a million tiny packages that
       | nobody understands and letting anyone publish anything they like
       | might have been a bad idea.
        
         | agloe_dreams wrote:
         | I work arch in a modern TS Angular Client for a larger
         | education org and I'm shocked by the number of amateur devs and
         | external contractors who think the solution for everything is
         | 'just add a package'. Need to filter arrays in a pipe in one
         | spot? Package. Paginate an array into a set of defined length
         | arrays so you can do faux pagination in the ui? Package. Need a
         | button of the design in our design system? Material UI and a
         | hell of a lot of CSS, here we come!
         | 
         | I basically act as a middleman whose job is 'THIS IS A ONE LINE
         | PIPE!'
        
           | thefounder wrote:
           | Perhaps that's also due the lack of a proper standard library
           | like every other language on this planet has.
        
         | rcme wrote:
         | What's the alternative? Ultimately, the issue isn't "a
         | dependency graph of a million tiny packages" but rather running
         | other people's code. If you read the attack details, this is a
         | targeted campaign where people are being tricked into running
         | untrusted code. I don't see how removing small dependencies
         | solves that problem.
        
           | jaredsohn wrote:
           | I think a benefit of a smaller number of larger packages is
           | reduces the number of parties you need to trust.
           | 
           | The people in charge of each larger package can review
           | contributions made to it and have the authority to reject
           | code that includes attacks. If a larger package doesn't do a
           | good job of preventing attacks, its reputation will decline
           | and because there are fewer packages involved it is easy to
           | remember these reputations.
        
             | ljm wrote:
             | It's never as simple as finding exploits in code review
             | though. Trusted accounts are compromised or the credentials
             | to the package manager are compromised or there is some
             | other supply chain attack. Larger packages tend to have a
             | lot more community and governance around them than your
             | typical JS-style function-as-a-dependency left-pad affair.
             | 
             | I've had this debate before and, as far as dependencies go,
             | sometimes you have to rip the bandaid off and audit your
             | shit, and understand why exactly you outsourced something
             | to a package.
        
           | ecnahc515 wrote:
           | With some other languages, you have big projects that
           | basically are your secondary stdlib. Boost in C++, Apache
           | Commons in Java, etc. These can reduce a lot of your
           | dependencies down to a single umbrella project who stewards
           | everything. The number of developers who work as maintainers
           | on the packages within these projects is probably comparable
           | to the number of developers working on the same sorts of
           | packages in Node, but they're all working under a single
           | banner, effectively. It's about having dependencies within
           | projects as organizations vs the NPM approach where basically
           | every dependency is it's own project and organization.
        
         | ashishbijlani wrote:
         | We've built an open-source tool, called Packj [1], to offer
         | developers more insights into packages, such as risky install
         | hooks, embedded binary blobs, and other malicious/risky
         | packages. It performs static/dynamic/metadata analysis to look
         | for "suspicious" attributes.
         | 
         | 1. https://github.com/ossillate-inc/packj
        
         | dcsommer wrote:
         | At least npm has namespaces (scopes) to group packages by
         | trustable entity. I wish cargo had namespaces. It's a big miss
         | for an otherwise security conscientious project imo.
        
           | koolba wrote:
           | More important than the namespace is who published the
           | package. I'm more inclined to trust an individual I know who
           | takes security than a namespace that may change hands.
           | 
           | NPM exposes that info in the _npmUser field:
           | https://github.com/npm/registry/blob/master/docs/REGISTRY-
           | AP.... That gives "name" (NPM username) and email.
           | 
           | While there are thousands of packages, I bet there's a much
           | smaller number of publishers to worry about.
           | 
           | Like this guy pretty much has a separate NPM package for
           | every single function that he writes:
           | https://www.npmjs.com/~sindresorhus (1162 packages under his
           | name alone, maybe even more in other namespaces).
        
       | OJFord wrote:
       | We really need better (easier to use) sandboxing for apps, or in
       | this case a project (create directory, few allowed apps, no
       | access to rest of fs or a dummy fs, whitelisted urls/IPs only,
       | etc.).
       | 
       | Sure you can use a VM, a container, firejail (for an app), etc.
       | but it all has quite a high barrier to entry & burden to bother
       | with, so the vast majority don't, and the majority of the rest
       | only do occasionally for something they already trust less.
        
         | fsflover wrote:
         | Try Qubes OS. It runs everything in VMs, but the UI is
         | amazingly usable. The VMs look like ordinary windows with
         | different border colors. Inter-VM copy-paste works with
         | ctrl+shift+c/v.
        
           | OJFord wrote:
           | Well... sure, but frankly 'just use a different operating
           | system' is exactly the kind of 'we need better (easier)' than
           | I'm talking about.
        
         | louislang wrote:
         | We (https://phylum.io) actually open sourced our sandbox for
         | this exact purpose.
         | 
         | https://github.com/phylum-dev/birdcage
         | 
         | It's baked into our CLI and supports limiting access to
         | network, disk, etc. during package installation. For example,
         | running something like                   phylum npm install
         | react
         | 
         | Will perform the installation in a way that disallows access to
         | disk and network that aren't explicitly approved. This prevents
         | malicious packages from grabbing and exfiltrating things like
         | developer SSH keys during package install.
        
           | OJFord wrote:
           | Ha, well now I look like a shill installed in the audience.
           | Nice though, I'll give that a go, thanks.
           | 
           | It's probably manageable through direnv & some shell magic,
           | but it'd be nice to have a built-in way of saying 'everything
           | in this directory gets run through phylum [with these
           | defaults] and has access to only this directory [by
           | default]'.
        
       | ilc wrote:
       | Nice ad.
        
         | tsak wrote:
         | My thoughts exactly. Every time something like this makes the
         | frontpage, it's a thinly veiled ad for whomever the author
         | works for.
         | 
         | I really want to see those WhatsApp chats...
        
           | TechBro8615 wrote:
           | The last few articles I've read about dependency chain
           | attacks have been from socket.dev, and frankly, they've all
           | been interesting and included important research. I don't
           | mind content marketing when it's relevant and a description
           | of important work. Would you rather nobody get paid to work
           | on products targeting supply chain integrity? It's a real and
           | important problem.
        
             | elcerebro wrote:
             | I don't think anyone has issues with pertinent content
             | marketing that also provides something to the community.
             | 
             | The argument can be made that the _important_ work was
             | already done by GitHub and Phylum. This just appears to be
             | a derivative work without any additional value add. That
             | is, it functions mostly as an advertisement.
             | 
             | Doesn't help that they clearly don't even have all the
             | malware packages in their system from this campaign, three
             | weeks after the attacks...
             | 
             | https://socket.dev/search?e=&q=Btc-api-node
        
               | ianpenney wrote:
               | In his talk, Feross mentioned that it would cost
               | approximately 1 billion dollars to scan the entire npm
               | ecosystem. They do it on demand for their customers IIRC.
               | Try signing up and running their scans on it.
        
               | elcerebro wrote:
               | There's no way that's true. Last I checked there were 16M
               | packages in npm, not counting versions. If we bump that
               | up to 20M and add a multiple of 30 to account for
               | versions, we get 60M total tar.gz files we'd need to
               | scan.
               | 
               | At a total cost of $1B that would put scanning a single
               | package at $16/package? Nonsense. Even at $1 in compute
               | time on aws that feels outlandishly high...
               | 
               | You can't retroactively scan the package Socket missed.
               | It was removed from npm. Scanning on demand means you're
               | going to miss critical relationships across threat
               | groups, or across disparate but related packages.
        
               | ianpenney wrote:
               | Retroactive scanning, you have a point. Integrating the
               | scan into your CI/CD would catch it.
               | 
               | As for the numbers: see 39 mins into
               | https://youtu.be/jWujI7Hk8O4
               | 
               | I used to work at npm as the SRE manager right before the
               | acquisition and the ballpark figures make sense to me.
        
         | ianpenney wrote:
         | But they've got a point. And they're one of the first to
         | market.
         | 
         | Yeah I'd get it if their solution was only tangentially
         | applicable (it's directly applicable). I certainly don't want
         | YC:HN to turn into GPT generated ad-city either.
         | 
         | If you met Feross, you'd agree he and his team are deserving of
         | the credit for finding a timely and constructive solution to
         | supply chain problems without filling OpenAI with your IP. He
         | lives the kind of values we respect on YC:HN.
         | 
         | I had the pleasure at Refactor Conf in Toronto a couple of
         | weeks ago. You can watch his talk here:
         | https://youtu.be/jWujI7Hk8O4
         | 
         | (I have no pecuniary interest in Refactor conf. I just think it
         | was an awesome time.)
        
       | Joel_Mckay wrote:
       | npm and pip is a dumpster fire for IT production environment
       | security. The out-of-band ecosystems evolved to sidestep
       | bureaucratic processes in favor of rapid release versioning.
       | 
       | Anyone who understands the auditing role and provable chain of
       | accountability FOSS OS packagers volunteer for... knows why it
       | was necessary.
       | 
       | Malware will always show up, but it is arguably more important to
       | be able to hold sources accountable. =)
        
       ___________________________________________________________________
       (page generated 2023-07-25 23:01 UTC)