Day 41 - April 18: Attacking Developer Supply Chains

Most developer use library database / package managers (NuGet, NPM, ...) for their projects and it's an overlooked attack vector in my opinion.

Mentioned in this episode

Transcript

Alex: Good morning future Alex. It is day 41 and today is April
the 18th and there's an article this morning got me thinking about supply
chains and no, I'm not talking about any logistics projects in my past. I'm
talking about developer supply chains. So basically, most development today
relies on external libraries to get to results faster.

[00:00:23] You know, like "don't reinvent the
wheel", "the someone else may have published a package or a library
that does what you want to do". DotNet has NuGet, node has NPM, and most
languages or frameworks have some form of repository where you can search for
libraries, download and then use them. It's extremely helpful.

[00:00:42] You can even search for a problem usually and
find a suitable result based on the description of the library. And nice
benefit is also that you can do automatic updates to the newest versions of the
libraries in your project, so you don't get stale code or stay libraries and
all that often with a single click.

[00:01:02] Of course, some versions then change the API
you're working against or you're programming against, and then you have to
update your code or they change how they work, but it's a small price to pay
for what we would call a shiny new world of plug and play libraries. Well. All
until you run into hackers.

[00:01:20] You're effectively executing code written by
someone else, someone you don't know, and it's running in your environment that
you're responsible for. And often it's a lot of code you, you can't really go through
each line of an open source library, and that is if it is open source, not all
libraries are.

[00:01:39] Then I wonder how many people have signed a paper
a on the project they're working on saying they know every line of code in the
software that they're. Sell or that they've produced only to conveniently
ignore the libraries that they've included. Now there are two major attacks on
developer supply chains that I'm aware of and that I think are relevant.

[00:02:01] You have the attack on the main open source code
itself. So a hacker might introduce a security issue into a project by means of
an innocent pull request. And if the maintainer of the library isn't careful or
is swamped in tasks, because you know, open source is often. Still an unpaid job.
Then that pull requests might be added or accepted and the code wonders
upstream until it gets compiled into the next library release and then ends up
on the package manager library database that you're using.

[00:02:37] A little more devious is an attack that's more
commonly seen in phishing attempts where you create a library that sounds very
much like the real library and therefore appears at the top of the search
results as well. For example, you could add a dash in between two words where
the real library is just spelled without it, and at first sight you might.

[00:02:58] Accidentally mistake one for the other, because
you know, a developer might not pay attention and just download the library.
And that's the last time you probably gonna see the library in the search
results. And so if you don't realize it, and because all the code works just as
intended, because after all, the hacker can just copy the open source project
as a base, but add the malicious code on top of that.

[00:03:23] It'll be in your project and you probably won't
notice it. Now, there are some attempts that mitigating these issues after the
fact. So after they've been discovered, you have the NIST vulnerability scanner
that will check your packages against a common vulnerability database and fake
libraries can be identified and added to that database so that you get warned.

[00:03:48] But. It still has to happen often enough for
someone to take notice that, Ooh, there's a fake library out there that has to
be flagged as a vulnerability, but it only takes one project to accidentally
include the library for a lot of damage to be done potentially. So what if we
could prevent the library from being created in the first place?

[00:04:11] The advantage of a centralized repository is yes,
you have a single point of failure, but also a single point of checking, right?
Kind of a gateway to publishing that library. So the question remains, how do
you recognize such a fake library? You can't really depend on that. The code is
the same as another project because well, in open source project that's called
forking and it's perfectly acceptable.

[00:04:36] And we've had, you know, it's part of the open
source ecosystem. You probably need to have some form of reputation for the
library maintainer. So the user who is developing and publishing the code, but
at the same time, you don't want to add. Lots of barriers of entry for new
library maintain is because that hinders the development of new interesting
libraries.

[00:04:59] It's a tough problem, and obviously I don't have
a solution yet, but just as WordPress became a massive target for hackers due
to its surface area on the web, I suspect we will be seeing a lot more attacks
on developer supply chains in the future.

[00:05:16] Anyway that's my thoughts for today. Share the
episode if you like it, subscribe for other ideas and thoughts and as always
there's a full transcript on futurealex.com

[00:05:28] I will talk to you tomorrow.