Subscribe
Share
Share
Embed
Threat Talks is your cybersecurity knowledge hub. Unpack the latest threats and explore industry trends with top experts as they break down the complexities of cyber threats.
We make complex cybersecurity topics accessible and engaging for everyone, from IT professionals to every day internet users by providing in-depth and first-hand experiences from leading cybersecurity professionals.
Join us for monthly deep dives into the dynamic world of cybersecurity, so you can stay informed, and stay secure!
Not one, but two NPM supply chain
attacks in just one week.
Headlines screamed: massive compromise
and millions at risk.
But what actually happened?
Let's find out today in Threat Talks
the Deep Dive.
Let's get on to it.
Welcome to Threat Talks.
Let's delve deep into the dynamic world
of cybersecurity.
So with me today is Yuri Wit,
one of our SOC analysts.
So welcome back Yuri, I would say.
Thank you.
Thank you for having me again.
And my name is Rob Maas,
Field CTO at ON2IT.
So maybe we lost already some listeners
in the beginning with the term NPM.
So let's start at the beginning.
What means NPM? What is it?
So NPM, it stands for the
Node.js Package Manager.
So it's literally a manager for packages
and libraries for Node.js.
Node.js is in turn a framework used
for JavaScript applications.
So it's a lot of pre-built API calls and functionality.
So it's a lot easier to start off with
your JavaScript-based applications.
Yeah, so the idea is if I want to create
or build an application
and I choose the Node.js as a framework,
I can include all kinds of Node.js packages
to quickly speed up my application development.
So I don't have to create my own,
for example, login mechanism,
it's just a package.
Exactly. Yeah. Okay.
So there was not only one, but
two attacks in one week
on this subsystem or this package system.
And the first one was called
a crypto drainer.
Can you explain, first of all,
what is a crypto drainer and
then what happened?
Yeah, so when we're talking about a crypto drainer,
we're usually talking about malware that can steal
your cryptocurrency via various methods.
Now, the most obvious, or sample
of a crypto drainer
would be one that steals your
private key for your wallet
and then just steals all your money.
But what we saw in this case
is the actual malware in the affected NPM packages
was listening for cryptocurrency transactions.
So it would use an application like Metamask,
which is a wallet application to handle your
cryptocurrency wallets. It would then listen
for transactions happening for that wallet,
and it would then change the destination address to
one owned by the attacker via randomly generated
measure. So instead of you trying to send
cryptocurrency to Alice, it would be sent to
North Korea instead, for example. Yeah, but
I still think I'm sending it to Alice. Exactly.
Yeah. And this attack gained a lot of attention,
at least on social media platforms,
we'll come to that, but it was also quickly taken down.
Yeah. Yeah. So the initial compromise
happened because a maintainer of quite a few
popular packages in the npm registry was phished
for their account credentials and a TOTP code, so 2fA,
so full account compromised and then the
attackers were able to put their own code into the packages
that this person maintained and sent
them out into the world ready to be downloaded
by other people, but it was very quickly mitigated
after about two hours, the attacker was already aware
or sorry the victim was already aware of the
compromise and mitigated the issue, reset the credentials
and then also delisted the
infected package versions. So, the infected
packages were only out there for
a few hours, I believe you said two. That also hopefully
means that the attacker did not gain
a lot of money? Is that also the case?
Yes, exactly.
A good thing about cryptocurrency is that it's very
transparent, so you can see transactions
that were made. Now, the
specific method that the malware, or I
guess the malicious code used
to redirect those transactions, used a...
almost a random number generator to determine
to which addresses it should be sending the money.
So we don't have a clear overview of all
the target addresses for the transactions.
There are a couple that are known
and marked as malicious.
And from that, we don't really see a whole lot of money.
Like most sources, they estimate about 2,000,
3,000 USD to be collected from this attack,
which considering the amount of
potential impact was very low.
Okay.
So this was the first one.
It got a lot of media attention.
But in the same week, another attack happened,
which was called the Shai-Hulud worm.
Please explain.
Why the name and what does it do?
So, well, the term Shai-Hulud was
actually determined by the attacker.
It is because this malware
actually harvested credentials.
It would search the local file system
for various types of credentials
for GitHub, AWS, Azure, Google Cloud,
as well as npm credentials.
It would then format all
those credentials in JSON,
so nicely formatted text,
easy to process by a computer program.
And it would then paste that data
in a new public GitHub repository
called Shai-Hulud
under the user that was compromised.
So that's where it got the name.
So it will be in the GitHub of the victim.
Yeah.
Exactly. And yeah, it fits as well
because this was an actual worm
that was able to spread itself over other npm packages.
So I guess the attacker was just very clever.
Okay, so I think this is quite interesting because a worm
within a packaging system, we don't see them often.
And this means that potentially
this attack or this worm could
easily spread and end up with a
big reach of infected npm packages.
Exactly, yeah.
So it harvests all the credentials, it put it
into a GitHub repository of the victim itself,
and that repository was called Shai-Hulud.
So that's where the name was coming from.
Okay.
I think the interesting part here is,
well, of course, the attack itself was interesting,
but maybe more interesting is how people
reacted to these two attacks in one week.
Can you explain a bit how the community
or social media reacted to these attacks?
Yeah, so for the first crypto drainer,
now, regardless of whether or not the impact was
actually big or not, what basically everybody copy
and pasted on LinkedIn and Twitter is that billions of weekly
downloads, everybody is affected, massive compromise.
What they actually meant by that is that the packages
which were infected with the crypto drainer
on npm, npm will host statistics about how
many times packages are downloaded.
So they have weekly download statistics,
and they basically just
added up all the weekly download statistics of
all the affected packages, and then
they got to the huge 2.6 billion weekly downloads affected number that was just thrown away everywhere.
While in fact, the amount of times that the infected
packages were actually downloaded and installed
within that two-hour time span of
actually there being risk is not 2.6 billion.
No, it's really small.
Yeah.
But everybody took that number and
then screamed it off the rooftops.
And so the entirety of cybersecurity LinkedIn was
basically a firestorm for the entire week.
But then the Shai-Hulud attack started,
it was reported on.
And either it was due to fatigue or
people just didn't understand it.
But there was a lot less media attention
on the Shai-Hulud attack,
even though that one was actually critical
and with high impact and widespread.
Yeah, I believe that if you do
a GitHub search today,
that you still find a lot of repositories belonging to Shai-Hulud.
Yeah, multiple sources have listed
that there were at its peak
like hundreds of public Shai-Hulud
repositories with those leaked credentials.
Today, if you do a search, there are other repositories that
just have Shai-Hulud in the name, but there are still
occurrences of those actual leaked credential repositories
out there, and it still reads about 100 of those repositories.
We can just state that Shai-Hulud really had a much
larger impact than the crypto drain attack.
Definitely. Most definitely.
So that makes it a bit strange that
people just went out full blown on
the first attack, the crypto drain, and that the second one
did not get at least not much attention.
Yeah.
So when we're looking at defending against these
kinds of supply chain attacks on the npm packages,
it's mainly something I think developers should do
or companies that develop software.
What can they do to prevent these attacks?
Well, there are two very strong security
measures that you can take against this.
Now, the first one should be pretty obvious.
It's the monitoring of your project dependencies.
So if you have your internal development team and
they have their own development ecosystem,
that would require most likely a list of dependencies
for your project that it needs to run on.
And it's very important to monitor those dependencies,
not just update them whenever you want.
update them whenever it's clear
that they'd pose no security risk.
Because if you have something like auto update turned on
for all your project dependencies,
you would have probably been affected
by either of these attacks.
While if you take a more reactive stance for
your dependency updates, you could have seen
very quickly, oh, hey, these packages are bad.
Let's not update until the security issue is resolved.
Yeah, but it also means that if you want to update
your packages, or even if you have
packages in use, you should monitor for vulnerabilities
that happen in other packages that you might be using.
Definitely.
Yep.
That sounds easy, but it's quite a hard job, I imagine.
In practice, it's very hard.
And then the other more specific defensive strategy
that you can take against the Shai-
Hulud worm specifically is to monitor your
CI/CD pipelines very carefully and alert on
the creation of new unapproved CI/CD workflows.
That was one of the strategies that the worm used
is it would gain persistent access to those credentials
by setting up a new branch under
the compromised repository. So not the new repository
that the malware would make,
but under the actual compromised repository,
it would create a new branch also called Shai-Hulud.
It would create a workflow in there that triggers on push actions.
And then on each push action towards the
repository, it would again post that JSON
payload towards a webhook owned by the attacker.
So basically what that means is that whenever
you would throw new code into your repository,
that workflow would trigger and it would send out the same
data that it had already gathered again to the attacker.
meaning that even if the publicly
created repository was taken down,
the attacker would still receive
those credentials again.
Yeah, because the full JSON
with all the credentials
were sent with that webhook
to the attacker again,
so he gets all the...
Yes. Okay.
You also mentioned in order to,
especially with the first attack,
in order to change these npm packages
or put your malicious code in there,
you need the credentials, of course.
Yeah.
Is there something we can do?
Definitely. It's make sure that you protect your secrets
and your credentials. Now, the crypto
drainer, that was unfortunate. The maintainer of those
popular packages got phished. Can happen to
anyone. Luckily, they were very quick to act on it.
But yeah, of course, still monitoring for
suspicious sign-ins, user behavior, user login
behavior specifically, can always help to protect
against these attacks, but for the Shai-Hulud worm,
because it specifically went after
commonly used credentials, so access tokens for your
cloud services, access tokens for your Git
or your npm account, protecting those credentials
and those secrets is very important.
Yeah, and I can imagine it would also help
if you can rotate them frequently.
Definitely. Even automatically maybe. Yeah.
Another interesting thing you mentioned when
we were preparing this talk is Shai-Hulud
on the systems it is running on.
So maybe it's also a good protection to use a different system.
Yeah, well, so Shai-Hulud, the worm, has..
the first thing that it does, it will do an OS
check to see on what operating
system it's being run on.
And it would immediately just quit out
if it's running on Windows.
So it's specifically targeting Linux and macOS devices,
which makes sense because one of
the, I guess, most popular methods of searching
for credentials is to monitor environment variables.
So the runtime variables that programs can use
with data in them, they're often used for credentials
and for access tokens and API tokens. And Windows
doesn't really have a good measure that isn't as
quiet as on Linux to retrieve all those environment variables. But you can't really not develop on
Linux or macOS. It's pretty integral. But I guess
you could, to protect specifically against
Shai-Hulud, you could start developing
your JavaScript applications on Windows.
Okay. So maybe we did not mention it. It's really for
developers to protect yourself. But
is there something I can do
as an end user as well?
Because in the end, I want to use an application
and I will download maybe also an npm package.
Is there something that I can do?
Apart from also protecting your own credentials,
there isn't much that you can do.
This was very specifically targeting
maintainers of popular npm packages.
The fact that it was called a worm, is
because the malicious code for Shai-Hulud
was actually searching for your npm authentication tokens,
if there are any, and we use them to
inject itself into the top 20 most downloaded packages
that your account also maintains.
So it was mostly targeted towards actual developers
that have maintainer rights on npm packages.
As an end user, there isn't much you can do because you can't really disallow specific versions or specific dependencies.
They're just built into the project
or the applications that you use.
Maybe more in general, so not
specifically those two npm attacks.
I can imagine that an EDR or XDR solution might help in general,
if you run software, at least to detect abnormal behavior.
Definitely, yeah. If a dependency is infected and it suddenly
starts sending a whole lot of collected data towards an
attacker-owned system or C2 server,
that is something that a good firewall
configuration and EDR would be able
to prevent, or at least detect.
Yeah, it's maybe less applicable to these two attacks,
but it's something you can do.
I think that brings us to not one, but two conclusions.
The first one is more to the developers and
the organizations that develop code.
Make sure that you monitor all your packages,
that you know what processes you have in place,
monitor your credential and the uses of credentials,
especially for these two attacks.
And the second one I think is really interesting
is the media coverage
that you see that there are two attacks
on the same system
in one week and where the first one
gained a lot of media attention
but didn't do, well, it did do a bit of harm,
but didn't do much
and the second one which didn't gain,
at least less attention
had the potential to do a lot of harm and a lot
of spread and still is probably active
since we see the GitHub repositories.
Yeah.
Yeah.
Do your own research.
It sounds very basic, but
don't believe everything
that you read on LinkedIn, specifically
everything that you read on LinkedIn.
But I mean, if you do see a lot of
posts regarding the same thing,
screaming from the rooftops,
it's important to look into it,
but make sure that your initial investigation
is what you find the most important.
So come to your own conclusions
and don't just regurgitate facts
that you see on social media.
Use reputable sources and
do your own research.
Okay.
Well, thank you, Yuri.
Thank you as well.
And thank you, listeners.
I hope to see you next time.
I hope you learned something.
And if you didn't already do it,
please like and subscribe.
And see you next time.
See you next time.
Thank you for listening to Threat Talks,
a podcast by ON2IT cybersecurity and AMS-IX.
Did you like what you heard?
Do you want to learn more?
Follow Threat Talks to stay up to date
on the topic of cybersecurity.