One of the true superpowers of Python is the libraries over at the Python Package Index.
They're all just a pip install away. And yet, like all code that we run on our systems,
it is done with some degree of trust. How do we know that all those useful packages are
trustworthy? That's the topic of this episode. Benz Tozer and John Speedmeyers are here to share
their research into typosquatting on PyPI and other sneaky deeds. And we also get a chance to
discuss some potential solutions, fixes, and tools to help solve this problem.
This is Talk Python to Me, episode 319, recorded May 26, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at
mkennedy. And keep up with the show and listen to past episodes at talkpython.fm. And follow the show
on Twitter via at Talk Python. This episode is brought to you by Square and us over at Talk Python
Training. Please check out what we're offering during our segments. It really helps support the show.
Hey, all. I have a quick announcement. We've had transcripts for all of our episodes for a long
time. But recently, we put more time and effort into making them more useful for you.
Now, every show has a link to the transcripts right in your podcast player. And that transcript
page lets you filter, search, and playback audio from exact moments within the transcript. Hope you
enjoy the richer experience around using our episodes as reference materials. I'm also happy to announce
a new sponsor of the show, Assembly AI. Assembly AI is a top-rated API for automatic speech-to-text.
You can transcribe videos and audio files with human-level accuracy in just a few lines of code.
To help us keep leveling up our transcript games, they're sponsoring the transcripts for our episodes
going forward. So thank you to Assembly AI for higher quality transcripts and supporting the podcast.
Check them out at talkpython.fm/assemblyai. Now, on to that conversation.
Vince, John, welcome to Talk Python to Me.
Thank you. Thanks for having us.
Thank you.
Yeah, it's great to have you both here. It's going to be exciting, unnerving, I might say,
a little bit to have this conversation. But I think it's certainly high time.
You'll never pip install the same way.
Exactly, exactly. You just kind of hold your breath as you do at each time. And you know,
I'm also, this is not a challenge that just the Python world faces.
This is anyone that has a package manager.
Yep.
And the more open, the bigger the difficulties, I suppose, right? So NPM,
gems, like you name it, right?
Yep. If you're a software developer these days, it probably affects you.
Absolutely. So before we get into the typo squatting, the supply chain issues and all the
stuff in history and current problems and, you know, on the positive side, there are solutions
and tools and things that we can talk about as well. Before we get into all that, let's start
your story, maybe abbreviated version since there's a couple of you. Ben, how do you get
into programming in Python?
Programming I got into just as a kid. Got a computer when I was, I don't know, nine or
10 and tinkered around with it, enjoyed it, ended up actually taking programming classes in
high school, stuck with it in college, majoring in computer engineering, and was a software developer
for the system engineer sort of stuff in the defense industry for 20 years.
Yeah. What languages did you start in or mainly use?
Originally started in C, actually originally in Pascal, then started in C, C++, and transitioned
over to doing more active Python development. I just needed a web scraper, needed to collect
some data and analyze it, and Python was the right tool for the job.
You didn't want to do that in C++?
I did not, no. And now, you know, Python is my preferred language for tinkering or back-end
web development. Pretty much as much as I can use it for, I use Python.
Yeah, fantastic. John, how about you?
I don't have quite the classic story. I learned it programming through statistics classes in
undergrad, specialized language called Stata that a lot of economists use. Good for legal
trials, well-tested, but I didn't learn Python until I, in grad school, I took more data science
classes and learned the typical NumPy, Panda, Scikit-learn sort of stuff.
Right. They're like, let us introduce you to probably, it was called IPython at the time.
Exactly. And now, of course, Jupyter Notebooks, that sort of thing.
Yeah. Fantastic. It's really interesting just to see all the broad and diverse ways that Python
is growing and people are coming into it, you know? It's not that, well, I learned it for
programming, you know, building an operating system and on I went. There's a lot of languages that are
fairly, you know, or JavaScript. I built it to work on a website, right?
Yeah.
It draws people in from all sorts of things, which is awesome.
It's a meeting ground.
Yeah. Yeah. And I think that's one of the strengths, actually, kind of a sidebar is that
we have all these people with different backgrounds and different motivations and interests and things
they're trying to build rather than being more like, well, here's how I build my web app. How do
you build your web app? Yeah. Very cool. And how about now? Vince, what are you up to day-to-day?
So day-to-day, you know, kind of put down the keyboard, at least from the programming perspective.
And I work as a cybersecurity subject matter expert for In-Q-Tel, which, so I guess my job
there is to search for and then work with companies we find in the cybersecurity industry that have a
high impact on national security, as well as providing kind of advisory services to our customers in the
U.S. government.
Okay, cool. So what's In-Q-Tel? Sorry, In-Q-Tel, I guess it is?
Yes.
Yeah. What's the company story there? Because you both are from the same company.
Yeah. So it's a nonprofit, 501c3, stood up a little over 20 years ago by the CIA to basically help
you know, originally the CIA, but now it's seen most of the intelligence community and
elements of the DOD basically acquire and adopt and use cutting edge technology. They realized a
little while ago, you know, around that time that a lot of innovation was moving into Silicon Valley
and into other places in industry and startups. And the traditional acquisition model that federal
government uses doesn't play well with those people. They don't understand it. So we kind of
helped as a bridge working with startups, identifying them, and then helping them interact with the
government and conversely helping the government, you know, adopt,
said technologies and support their mission.
So maybe, let me see if I can run a scenario by you. Maybe there's some Silicon Valley company
that's created like a cool ML thing that identifies deforestation or something like that. And the
government decides, oh, this might be really helpful for us for, I have no reason why. I have no idea
why, but let me imagine there's a reason, right? You might help that company like work with the
request for proposals and the whole crazy government side of things and get them more in line with what's
needed there. Is that the story? Yeah, that's to an extent. Yeah. I mean, we actually invest in them,
take equity, and that do help them learn how to interact with the government and also help them
shape their product and meet our customer needs.
Yeah. Okay, cool. Interesting. I had no idea such a company exists.
John, how about yourself?
I'm also at IQT. I work in what's called IQT Labs. It's an open source applied research and development
lab where we do hands-on research, mostly in the open source, largely on GitHub.
Cool. Sounds very, very fun. Now, let's talk about the supply chain issue, I guess, at a real broad level,
right? And I don't know how you all feel. I suspect that you have a little more hesitancy
or whatever as you interact with the computers and software and the internet and so on. You know,
when you, oh, there's a cool new app, maybe I'll try that. Like, you might think a little more
carefully about this than the average, you know, say, teenager or whatever.
There's a little bit of paranoia that comes with this. It's true.
Yeah, exactly. Exactly. That's what I'm getting at. And I feel like one of the more insidious
aspects of this has been the supply chain side of things, right? Because it's one thing to say,
that app looks shady. That site looks shady. Let me just not go there. Let me not click that link.
Let me not install that. But if I were to install, you know, Office Suite X and I completely trust the
company that makes that, but there's some library that they got from a third party and that third party
had been hacked and they somehow Trojan'd that third party thing and no one's found out yet.
I don't know. That's super scary. And that's kind of along the lines of some of the things that we're
touching on. And so I think the most broad one of those in the recent times has got to be SolarWinds,
right? That's certainly what's making the headlines these days. Still even, what,
five, four or five months later. It's, yeah, still a topic of discussion around this theme.
And yeah, I mean, that was a pretty challenging attack to pull off. I mean,
it took nation state actors months, maybe years to plan, you know, laying the groundwork,
getting things in place, you know, basically infiltrating SolarWinds development infrastructure.
Pretty impressive, honestly, that they were able to do it. And obviously the impact was enormous.
It was wildly successful.
I think one thing that Vince and I have been interested in, though, while this sort of attack
is very serious and obviously has rightly gathered a lot of attention, there are a number of other
types of attacks, often focusing on open source software that are actually more numerous.
How serious they are is actually open to debate. But we are still talking many people affected and can
still have grave consequences, especially if you're the one that's hacked.
So it's gotten less front of the newspaper attention, but Vince and I still think it's serious.
Yeah, I think it's very serious. I started with this one because I feel like everyone has heard about this.
Everyone can relate to this, right?
And here's an example of a company that supplies network gear to many of the largest companies and government
organizations around the world. And this was basically a way to get, you know, access to all of those.
They think it's Russia's cozy beer crew, but who knows, right? And it almost doesn't matter.
Another one that I think also is in the news really quick before we jump into the open source stuff.
This is not open source at all, but was called Xcode Ghost. Have you two heard of this?
Yeah. Yeah. So, yeah, I mean, basically what happened here was, you know, app developers,
iOS developers in China don't like to download or can't download stuff from the Apple official
Apple version of Xcode. Someone, you know, put a compromised version of Xcode up on some.
So let's get it off BitTorrent or something.
Yeah. I mean, also some Chinese file sharing site that app developers over there like to use
because it's more convenient and they, they, it was compromised. There was a, basically a,
something that would bake a backdoor into, you know, the ultimate compiled app that would go into
the app store or variant of the app store.
Yeah. So every app that was built and published to the app store with Xcode Ghost, which looked
exactly like Xcode injected a backdoor malware type of thing into it. So there was something like
2,500 applications, the iOS app store that yeah, affected like 128 million people. So that,
that's bad kinds of things, right?
Very bad.
Not ideal.
I mean, I guess attacking a compiler, I mean, developers trust their compiler, I would say,
I mean, not being able to rely on that or feel like you have, and it's very hard to
vet your company, especially for closed source or closed source, product like Xcode.
It's very hard to see is my compiler compromised or not.
Yeah. Yeah. And I think this actually is closer to the open source side of things,
right? Because if you can start to infect the tools of the developers building the things,
that's a problem. Yeah. So let's talk about the open source side, John, you pointed out,
there's many known attacks over there.
That's right.
Set the stage. What's going on?
There's actually a range of attacks, but I'll mention a couple here and we'll get into typosquatting.
So there is certainly a typosquatting attack, which we'll discuss extensively today, which
just like domain names, you might've heard someone is trying to go to a website and, mistypes it
a little, or somehow gets confused about how it's spelled, maybe switching the order of words,
and then ends up someplace that's malicious, either on the web, or if you're downloading a package,
you download a package you think you want, but it's not actually.
And sometimes not always, sometimes that contains malware and does things to your computer that you
don't want.
That's bad, right?
Bad. Especially if there's arbitrary code execution, meaning they can do what they want because perhaps
you've installed it as root.
Right. And well, I think a lot of people who are getting into Python don't realize that when you
pip install something, unless it's being installed as a wheel, as a binary wheel, it's running a setup.py
as your account. So whatever your current account is able to do, like you said, if you run it as
sudo, it's, it can do more, but even if it can just completely wreck your account and get your
information for many people, that's plenty bad on your computer. You don't want to.
Yeah. And it could be your computer. It could be your, your corporation's computer where you work
or your company's computer. And this setup.py, you're exactly right. It is a key attack vector.
For many people, it's simply a helpful way to install software. But unfortunately,
some people abuse that specific resource.
Yeah. I think it's been critical in the growth of how software is built. I remember,
you know, Ben, you were talking about doing C++ programming. I remember back in 97, 98,
99 doing C++ programming then. And it felt like whatever you wanted to do, almost everything you
had to build from scratch. You want a library that does this kind of UI widgets? Well, how do I build
that? You want a library that has this kind of data structure? Where do I either find or build that?
Right. And now it's just pip install this thing, pip install that thing. And the, the building blocks
that we have to compose are so much more effective, right? I can take a couple of libraries here and
click them together. And all of a sudden I've got something absolutely incredible, like pulling data
from different sources, creating amazing graphs. I mean, that is the power of modern software
development, right? And yet, you know, I guess Corey Atkins out in the, the live stream has a nice
sort of comment on this. Like he said, I didn't realize how naive I was thinking packages were
vetted. You're not alone, Corey. And so you're not alone. Join the club.
This portion of Talk Python to Me is brought to you by Square. Payment acceptance can be one of the
most painful parts of building a web app for a business. When implementing checkout, you want
it to be simple to build, secure, and slick to use. Square's new web payment SDK raises the bar
in the payment acceptance developer experience and provides a best in class interface for merchants
and buyers. With it, you can build a customized branded payment experience and never miss a sale.
Deliver a highly responsive payments flow across web and mobile that integrates with credit cards and
debit cards, digital wallets like Apple Pay and Google, ACH bank payments, and even gift cards.
For more complex transactions, follow-up actions by the customer can include completing a payment
authentication step, filling in a credit line application form, or doing background risk checks
on the buyer's device. And developers don't even need to know if the payment method requires
validation. Square hides the complexity from the seller and guides the buyer through the necessary
steps. Getting started with a new web payment SDK is easy. Simply include the web payment SDK
JavaScript, flag an element on the page where you want the payment form to appear, and then attach
hooks for your custom behavior. Learn more about integrating with Square's web payments SDK at
talkpython.fm/square, or just click the link in your podcast player's show notes.
That's talkpython.fm/square. These incredible building blocks, these Lego pieces, there's a lot of faith
out there that these are good building blocks. Not good in the sense they don't have bugs, but good in that
they have a good intent.
Well, I think that's one thing that's the key is that, and one of the things that's a challenge here is you have to
kind of figure out the intent of the people you're trusting, and you are trusting them ultimately, and you have to
hope they do not have malicious intent. Because inferring that is very challenging.
It's a double-edged sword. I mean, I agree. It is a powerful change that you can download a couple
libraries and have an amazing app, potentially in a few minutes, maybe an hour or two. And this is the
dream of code reuse, come alive, finally. And it just so happens that there are sometimes downsides.
They can be mitigated, but unfortunately to the unaware user, which it's all too easy to be unaware,
it's difficult, actually. There are serious, there can be risks.
Yeah, there definitely can. Kim Van Wick out of the live stream has an example. A benign example would
be atter, A-T-T-R versus atters. Both are legitimate packages, but completely different.
Another example would be if I want to install requests, but I actually just type request.
I mean, even auditorily, they sound like requests.
It's easy to do.
It even sounds like very similar with the S versus no S there. And if somebody says,
go install requests, you're like, oh, request, pip install request. God, I did it. Like, wait,
no, no, no, no, don't do that one.
Yeah. And it actually happened. You can find that that attack truly happened, affected,
at least according to the article published about it, 20,000 users. So I don't know how many of them
were actually affected. I haven't, we don't, this is unfortunately part of the problem. It's hard to
track this data, but the example you brought up, I know you brought it up on purpose. It's serious.
Yeah. And requests with the S is installed millions of times a week or a month. Many,
many, many, many, many times, right?
We'll talk about this later, but we found one called Pandar, like Pandas, but with an R.
And, you know, it's not hard to imagine just by, either confusion or a mistake typing this.
Yeah, absolutely. So another area I think that is a little bit interesting before we dive completely
into the package management type of squatting and related type of issues has to do with a trusted
open source thing becoming untrusted. And what I mean by that is there were some examples of things
like Google Chrome extensions being put out there as proper extensions, and then someone taking over
that project and then putting something maybe more adware in it, or something somewhat nefarious,
if not actually malicious, or, you know, somebody who is running the request is not a great example
because it's under the PSF organization, but many of the projects are under an individual, right? On
their GitHub project. And so if somebody was able to break into that person's GitHub repo, and then they
somehow sneak something into the code, well, does it look wrong? No, the, the person who made that change
is the trusted benevolent person who runs this project, right? They are, if, you know, Guido
van Rossum comes in and makes a change, well, who's going to look at that and go, oh, this is, this guy's
sketchy. We better really, like, it's probably going to be fine, right? So if someone takes over an account,
like, not only do they have access to the code and then how it gets pushed out to, you know, potentially
gets into the stream that goes to PyPI. It's also done by the person who looks like they should be most
trusted, right? So things like two-factor auth and just securing your GitHub and things along those
lines seems extremely important as well. Absolutely. I mean, what you're describing with account takeovers
happen numerous times. And there's variants on it too, where there's some single developer who's
overworked, tired, doesn't use the project they create anymore. They just hand it over to someone
who ends up, you know, putting a backdoor in it or some sort of malicious payload. I mean, that, that's
happened. And then also people take advantage of the fact that not only do you have your GitHub
profile secure, but you also have to have your PyPI or Ruby gems or, you know, where you actually
publish your packages, people run. So there's kind of two areas for potential attack. And also people
take advantage of the, you know, most people, at least me anyway, when I would vet software, I would go
look at GitHub and then I would download, I wouldn't download it from GitHub. I would download it using
PIP or whatever. And that kind of, dissonance or whatever you want to call it,
there's another opportunity for, for confusion and malfeasance.
Yeah. And so these things are hard to detect, but I guess the area that you all have done a lot of
research in, you built some tools around and probably the biggest area is around the package
management side of things, right? That's right.
So we've talked about typosquatting and some of the challenges where people might mistype things.
And you talked about some examples where you found packages that look like they were intended to be
installed by accident, you know, to catch those. If there's 7 million people type, you know, 7 million
times pip install requests is typed. Chances that a couple of those are misspelled or enough of those
are misspelled is pretty high, but there were actually quite a few examples. Like for example,
the register had an article. When was this? This was, this is recent, March, 2021. The title is Python
Package Index nukes. 3,653 malicious libraries uploaded soon after security shortcomings highlighted.
That's right. This is, there's really a longer historical narrative too, to include this.
I'll call this a political activism, anti-typo squatting activism, where this,
you could call it an attack, is really about drawing attention to this risk.
Yeah. And I feel like a lot of these were people like, look, I'm proving to you this could actually
happen. That's right. I'm proving by creating this thing that uploads as requests with the S&T.
That's right.
Swapped. But were there actually viruses put up there? Like what is the actual harm been?
Yeah. So not all of these are. This one and a number of others, we can discuss those if we have time,
were largely benevolent, but demonstrated the risk. But yes, there have been, at least by our
calculations, 40 known malicious typo squatters on the Python Package Index, affecting thousands of
users. We actually published a blog post on this, something like Python typo squatting is about more
than typos. So yes, this has happened. I don't know the exact persons that it has affected. We just
don't have that data. Sorry if it affected you. And we published this and got some debate on hacker news.
And this is the point where Vince and I said, oh, there's really something here. There's a broad
audience that hasn't had a voice that cares about this.
Yeah. I mean, it could have been nothing, right? If I'm a student at a university and I install it on
a lab computer.
No big deal.
No big deal. Like who trusts those lab computers, right?
You shouldn't.
I mean, not just because like somebody could have installed something bad on it, but there's,
there are college students.
Oh yeah.
Who could be installing all sorts of just, you know, pranks and other kinds of stuff. So you
should just treat those things with.
Contaminated.
Yes, they're fully connected. But on the other hand, if this is a data scientist working at like
a major corporation or an agency and that happened to them, it could be the thing that opens the door
to, you know, access to the entire network and all sorts of lateral movement, right?
That's right. There's even one of the earliest pieces of anti-typo squadding activism comes from
Nikolai Schocker, who was writing his undergraduate thesis at the time in Europe. And he showed that
over a few weeks, he got over 17,000 downloads of a series of type of squad packages, including .mil,
the military addresses of the United States military. So it is certainly possible that people in a more
secure organization that really value security could accidentally be the victim of type of
squatting.
Yeah, absolutely. And the fact that it came out of a .mil domain shows that, yeah, that bad example
could also happen. And also his thesis got covered on Ars Techno.
That's right. Coolest undergrad thesis ever.
Exactly. That's way better than anything I did in college.
Oh yeah.
Yeah. Fantastic. And then there was this project called Pyto Squatting.
Yeah.
Pyto Squatting.
Yeah. It's a play on...
Which actually has been... Yeah, like a play on typo squatting.
It's a play on typo squatting. It's a clever one. And Benjamin Balderbach and Hano Beck,
who are open source software activists, developers, also a journalist, they've really had a multi-year
effort pointing out the dangers here. Not simply criticizing, but trying to help Python Software Foundation
and the warehouse, our PyPI crew, raise money and build a consensus around trying to make
this infrastructure safer.
Yeah. Yeah. So they had this project called Pyto Squatting, but that actually got closed down.
That's right.
Yeah. Because they said that the PS... What do they call it?
The PSRT, Python Security Response Team.
That's it. PSRT. And I'm like, wait, there's a Python Security Response Team?
That's cool.
And they respond to emails too. They're good.
Yeah. Okay. So this is an organization, a group of people under the PSF banner that basically
triage these types of concerns, right?
That's right. That's right.
Okay. Yeah. I'll link to their page on python.org and they have their email there. They also have
rules for different types of disclosure, like whether you should email them, do other things.
That's right. And if you find a malicious package or even a package that you think is very suspicious,
this is who to contact. And they're diligent and timely.
So what do you two think about how this should be disclosed? People out there listening, they find
something. Should they go to Hacker News and say, look, this horrible thing I found on PyPI or on
NPM or whatever. Should they quietly disclose that to the security response team and then talk about it
after it's been removed and fixed? What's the flow for disclosure?
Seems like it would follow any other responsible disclosure process for traditional bugs, exploitable
bugs that are with vulnerabilities, where it would be nice if you find a problem, contact maybe the
Python security team, get in contact with the developer, get it fixed, probably get the package
pulled down if in fact it is malicious. And then, yeah, it'd be nice to have some sort of reporting
mechanism so that everyone who uses it could be identified. And the first part, John Speed was
saying, you know, the Python South for Foundation and the PSR team do a good job or great job of
being on top of it, being timely, being responsible. It's much harder to notify, you know, there's no
authentication when you download one of these packages. So it's very hard to know who's been
affected. So maybe just promoting that more would be helpful. But then people have to know where to
look and that they need to look at all. It becomes challenging quickly.
Well, it's like the Xcode ghost thing, you know, there was 2,500 apps that were backdoored.
And I think only the top 25 were even disclosed. And it's like, if there was a list of 2,500 apps,
are you going to go cross compare? No, you know, no normal person is going to cross compare that
announcement with their phone.
Right.
And it's just such a challenge. And I feel like, you know, here we had the same thing,
right? We had 3,653 packages removed. Well, are you going to go check if you had those? It's
extra hard because it's, you didn't intend to ever have them. You didn't intend to swap the S and the
T when you type requests, but you did. And you accidentally, almost unknowingly got it most
likely. Right. And so I do think it's really hard to push this out as an awareness thing and like,
hey, you should know that this happened. And so just go check, right? The checking,
I think it's really tricky.
Yeah. I mean, like many software problems, you need to solve it with more software.
You got to solve it with AI probably.
No, you definitely have to solve it with AI. I think one thing that's helpful and could be part
of that process, but isn't always, unfortunately, is also taking a collection or taking that artifact
that you found, let's say a Python package that was malicious and making sure it gets to somewhere
where it can be studied and hopefully future attacks prevented. And so for Python and a couple
of other languages, there is actually an interesting project. It has a very colorful name. It's called
Backstabber's Knife Collection. Sounds very scary and malicious, but it is actually yet another
enterprising grad student trying to collect malware samples, especially of interpreted languages.
Python is one of them. And so that there can be a community researchers and hopefully then
companies that can fight these packages. So that would be another thing I would add to the list.
Yeah, there you go. Mark Ohm is the main person associated with that and has written some
interesting papers and great stuff. And so I urge you, if you come upon this and you say,
how do I act responsibly here? Do the things Bent says and also maybe grab a sample and give it to
the Backstabber's Knife Collection or another similar repository.
Yeah, interesting. Okay. Have I just messed up my computer by visiting this webpage as well? I wonder.
I don't think so, but there is a...
I'm just teasing. I'm just teasing.
I mean, I can't guarantee anything though, but...
No, of course, of course, of course. Before we get too far on, Corey Adkins also asked,
when we were talking about messing up your computer, the lab computer, so on, he asked,
could installing these types of things also affect shared server space? On my IaaS land,
where I have a shared server running for however much someone else does something bad.
I mean, theoretically, sure. It depends on the permissions, I would think. Yeah. If you install
some dependency that has keylogger baked into it or, I don't know, or, you know, some sort of file,
you know, collector, and it has permission to traverse all directories, then yeah, I mean,
I could certainly see a scenario where that was possible. I mean, I haven't, you know,
I haven't heard of that happening specifically, but there's nothing preventing it theoretically.
Yeah. If you had a series of virtual machines, you know, it's pretty tricky from one virtual machine
to escape to another, but I believe there have been examples, but those are exceedingly rare,
those sorts of vulnerabilities, right? That's right. So while we're on this topic,
I want to throw out an idea and then we'll talk about some of the tools you built, but I feel like
we're right in the middle of this notification thing. Like we've got all these packages, they've
been identified, they have been downloaded. We can see that we probably even have IP addresses,
which you can reverse look up to DNS names as probably how those attributions were given,
but it happens so often in so many different places, right? Like if I've got a continuous
integration story that builds a Docker container that pushes to a Docker hub and then my production
grabs that from that container, the place where the problem happened is not the place where the
problem is, right? It's probably GitHub or some other CI pool. We have a really nice thing for this
in the account space. Have I been pwned by Troy Hunt, which is a really nice project. I definitely
recommend people go there and enter their email address.
And prepare to be horrified.
Yeah. And prepare to be horrified. There's 11.2, 11.3 billion accounts that have been breached,
which is odd because it's more than all the humans, but we have more than one account. So there it is.
But yeah, so you put your email in there and then in the future, well, historically as well,
but then in the future, you say, if something has happened and your email appears in some kind of
password dump, password breach or account informational breach, you'll get an email saying,
Hey, we found something that should be concerning to you. Check it out. I would love to see something
like this for pip, right? Something that says, I pip installed this thing and it just has a record of,
here's my account. These are the things I've pip installed. If there turns out to be a problem
with one of those, notify me that that had happened.
That does sound really useful. I don't think it exists.
I don't think it exists either. And it shouldn't just be a pip thing. It should be an NPM thing.
It should be a gem thing. It should be a crate thing. It should be something that like a,
just a little bit of a wrapper that says, I would like to opt in to saying, here's my UUID.
Here's my email address. And here's the list of things that I've installed. If it turns out that
one of them is horrible, just let me know.
It's so sensible. It makes me laugh.
Yeah.
Well, there's an idea out there as well, but this is way far down the line, right? This is,
oh, we know this has happened. We know who's done it. We've, we know who's been affected and so on,
but starting a little bit further back, you all have built some tools to go and start at the
beginning and say, well, let's look and see what might be out there. That is bad, right? This is
the tool you used to find pandar instead of pandas.
That's right. I mean, I think the, the first idea you had is the crucial one, which is that
you need to know that there's been a compromise in order to report it. And right now it's surprisingly
hard to know that. So we're not the only one to have devised a tool or approach to finding
malicious packages on the Python package index, but we took a particularly simple one and we said,
can we use simply the metadata, especially the name, but some other information too,
of packages. And then look at just the most downloaded packages and check who has names
that are very similar to those packages. This is where AI comes in.
Need crazy AI at this point. You do get a lot of false positives. People have similar names just
because the packages are related. It's fine. There's no problem inherently with having a similar name,
but we cracked open those packages too. This was some very boring Saturday mornings of mine
and simply scanned through the code looking for anything that's suspicious. And lo and behold,
we found one called Pandar that was actually doing key logging. It was a proof of concept. It's unlikely
that it actually would have worked, but we reported it to the Python security response team, security at
python.org. They said, yep, not good. Yanked it. And it was just an example of it's not that hard
to find them. And we were showing yet again with a pretty simple demonstration that it's not that hard.
Interesting. That's really cool. So basically the tool is about finding given popular packages,
finding ones that are oddly similar. And then there's like a, let me go and see what this one's about.
That's right. And so there's a couple additional checks to help anyone using it. And you can find
it's an open source written in Python tool, command line tool. It also checks things like, for instance,
is the description of the package on PyPI, is it very similar? So that what you are witnessing is
someone who's trying to not only type with squat the name, but in some sense, like squat the broader
metadata or almost like the copyright of the package.
Right. Because you want it to look as similar as possible.
Exactly. Like camouflage.
Something that comes to mind. Yeah. Are you guys familiar with sneak?
Yes.
Is it package? There's a project. And geez, I'm forgetting.
Are you thinking of the advisor project?
Yes. Sneak package advisor.
Yeah. It's neat.
That's it. It's super neat. Yeah. That's what I was looking for. No, that's not how I want to spell it.
Yeah. And so that thing is pretty cool. The reason I bring this thing up is you can come over here and I
can type in a project like requests or whatever, and it'll tell us eventually,
it'll tell us the package health score. Yeah.
And it'll tell us things like there's this many PRs that have been open and closed. There's this many
contributors. There's this many people participating that the maintenance looks like so on. One thing
that I think would be cool would be to take this number plus a misspelling and say, if that number
is really, really low for a package that should be really, really high, that's a challenge, right?
If you look at the GitHub repo that is delivering this thing and it doesn't look right, if it's not
associated with something that seems kind of hard to replicate, like a GitHub repo with many people
participating over a long period of time, that seems like that could be a good flag as well.
Yeah, certainly. It certainly seems like there's an abundant opportunity to build something into the
actual download client to the pip or a wrapper around pip where it checks these sorts of things and
create speed bumps for you as you are trying to download something or use a package so that
says, hey, this looks suspicious. Have you thoroughly checked this? And I think your idea could contribute to
exactly such a tool or tools. Yeah. Yeah. Very neat. You've been working on this and Martin
Karnoguski created this thing called Aurora and also reached out and said, hey, I'm also working on this.
And so, yeah, tell us about this thing called Aurora. Yeah. So we got an email last fall after publishing
this blog post and he said, hey, I've been working on a similar tool. Not only does it check this metadata,
but we even do static analysis of the entire Python package index. And we said, Martin, that's awesome.
Let's work together. And so over the past six months, roughly now, in an open source collaboration
between a number of us at IQT Labs and Martin Karnoguski, we have further refined Aurora, which
truly is designed to do a static analysis of the entire Python package index open source tool. You can find it.
He releases his data on a try as best as he can to release it regularly. We've also built a tool
called Aura Borealis. That key thing, his aura produces 50 gigs of output when it's done scanning
the entire Python package index. No human can wade through that. So.
And I suspect also the IPA, the Python package authority folks probably don't want everyone
downloading that much data all the time. No, it's exhausting and creates so many database issues and
other things. So we've been working on a tool called Aura Borealis that you've pulled up that is a front
end that makes it easier to use the data set that Martin creates this tool, Aura. This wouldn't
necessarily be part of PyPI, though, of course, it could be. But we imagine this as a tool for
organizations or persons that need to have global knowledge about either global knowledge about the
entire Python package index and to rank and assess potential threats and go look, look for those,
and then take appropriate action or even individual developers that are really curious about packages.
This is makes it easy. The Aura Borealis isn't yet live, but we hope to make it live this summer.
Aura is a in production tool. It works. So go check it out.
Talk Python to me is partially supported by our training courses.
When you need to learn something new, whether it's foundational Python, advanced topics like async or web apps
and web APIs, be sure to check out our over 200 hours of courses at Talk Python.
And if your company is considering how they'll get up to speed on Python, please recommend they give our content a look. Thanks.
This looks like it's really handy. You know, so the idea is basically it's going to run forever and that's going to generate tremendous amounts of data.
Maybe just put a web front end on top of that static data for everyone to generate it over and over.
Exactly. Instead of having generated over and over now having 50 gigs and having to write your own custom,
probably Python script that's, you know, you'll have to optimize and blah, blah, blah.
Yeah. So came out in the live stream just says I accidentally typed sync instead of sneak,
which also is hard to spell anyway, because it's like a non-common spelling.
So which is an excellent way to demonstrate making a typo of getting the wrong package.
I have no idea what that's going to return. I'm not going to pull it up.
Podcast imitates life, imitates art, imitates compromise.
Exactly. All right. Well, this is really neat. How would I use the Aurora data and the Aurora Borealis project?
I guess also we should talk about this from different angles, right?
Maybe I'm a CISO at a company and I'm concerned that all my people are psyched about data science and Python
or NPM and web front ends and they just make me nervous all day and I want to get on top of it.
So I want, as somebody who is concerned about, I would like to know what's happening in my software
fly chain, or maybe I run, I maintain pandas and I'm really upset that pandar exists and I want to now be able to defend my package.
Like it seems like there's different use cases and people out there.
That's right. I think if you're a company and you have a group of software developers and
you have the, let's say a security team that helps vet packages.
So perhaps you put those packages in an internal repository so that the developers know that they're
cleared to use or Borealis will help you do that.
We're glad to set up pilots and discuss.
You can email me, jmeyers at iqt.org.
But there's also other angles too.
There's just, you're a developer and you want to make an informed choice.
The static analysis tool and its output can help you with that or Borealis.
And I think there is also, you're right, there's a maintainer angle and also a PyPI administrator
angle where you want to either protect a set of namespaces close to your package or you care
about the health of the entire ecosystem.
And those are all possible user types.
Yeah.
And we could probably use your PyPI scan to go and say, look, can I say, look for things
similar to my package name?
Yeah, that's right.
And we built that into Aura Borealis too now.
So in some ways, PyPI scan was a demo and still useful as a command line tool, but Aura Borealis
and Aura has that now built in.
Are you all going to put an API on top of this?
Good question.
That would be cool.
The thing that's tricky, like everything in life, is it costs money and, you know,
engineering resources and time.
I certainly have a vision.
And, you know, if I don't do it, someone else should do it.
Go make a lot of money.
of creating a technical infrastructure that every single package and every single new version
of every package, IPI, NPM, et cetera, gets scanned, a variety of scans, static analysis,
dynamic analysis, metadata analysis.
And that gets stored in a database that where you and I can go make API calls and get that
information that we should on these packages.
That could be, you know, there could be a free tier.
And then if you really need to make a lot of calls, a paid tier.
But someone should do it, I think.
Yeah, it would be neat to know, like you said, integrate into, say, pip even.
So if I pip install something, it could even flag it and say, hey, no, actually, we're going
to block that.
That's right.
Preemptively, because it's got some low score, unless you do like a --force.
Like, no, really, I mean, yeah, exactly.
It's something that'll sort of slow it down, as you call them speed bumps.
I hope someone does something similar to that.
We have plans, but no active development underway.
All right.
So that sets the stage that some of the tools out there, at least to identify that there
are potentially bad packages.
And it's also, I guess, you know, worth pointing out that if we go over, say, to PyPI, there's
over 300,000 packages over there.
And if there are 40 actually malicious ones, right, the chances are low.
They're not very high.
But so people shouldn't be, you know, running for the hills and complete panic or anything,
I don't think, from this.
But at the same time, we should be careful.
We should be cautious.
So, you know, what can we do?
That's the tough question.
Vince, do you want to start?
And you want me to go?
Sure.
I mean, there's a lot of things that we can do.
I mean, John Speed's hit on a few of them about just kind of being more deliberate, you know,
checking your work before you download something.
And also, you know, when you're considering dependencies, I mean, you mentioned C++ and,
you know, the late 90s.
I vaguely remember those times.
I remember when Boost came out, it was a big deal.
Oh, yeah.
You actually had a dependency that was...
I remember reading more books.
Right.
Less internet, more books to make things...
So, yeah, we moved on from that.
But ultimately, you know, it is worth considering, do you actually need this dependency?
You know, LeftPad, and NPM is a funny, you know, canonical example.
Broke the internet because people didn't feel like typing one line of their own code.
They wanted to import a LeftPad-ing dependency.
I do feel that's a really good example.
And certainly, LeftPad came to mind, not as a malicious thing, but just as a supply chain
Jenga tower type of thing.
And somebody pulled too much on a part of the Jenga tower and it came down.
I feel that the JavaScript community has way smaller Lego pieces than the Python community.
The blocks that you click together here are larger.
So, I feel like there's just fewer in number external dependencies on average in my Python
experience than my JavaScript experience.
Yeah, I think that's accurate.
I mean, numbers vary.
I've seen NPM, people who use NPMs are JavaScript developers.
The average package in NPM has like 94% dependency.
You know, other dependencies, only 6% is your actual code you've written.
Most of the modern languages, meaning JavaScript, Python, and some others are in like the 90-ish
range.
And then you see C and C++ are much lower.
Java is somewhere in the middle.
So, yeah.
Python is, I would say, lower than JavaScript, but much higher than the kind of legacy languages
that are historically used.
So, be deliberate means things like don't just, as fast as you can, type pip install, whatever.
Type pip install and then carefully type out the package name.
Maybe give it a quick read before you hit go.
Yeah, or just copy and paste.
Don't type it all.
Yeah.
So, for example, if I'm over here on PyPI, there's a copy button I can click and it'll
do exactly that.
Right.
That's an option.
Yeah.
So, yeah.
Just being a little more thoughtful and kind of, you know, looking at the dependency chain
as well before you download something, which is much harder than it should be, to be
completely fair.
That's helpful to know that, you know, maybe the top level you are using Joski.
That's how you pronounce that.
I have no idea what Joski.
I don't know.
You should pip install that right now.
Let's see what happens.
Let's just see what happens.
Here's an example of one of those that should rank lower.
No offense if this is your project, but it literally has zero stars, zero forks.
Its features are to do.
Its requirements are to do.
Its PyPI version banner is not found.
And I mean, it is only four minutes old.
They may be working.
Yeah.
Sure.
Yeah.
If it has dependencies, this one probably doesn't.
But, you know, take a look at those two.
Just makes them there's nothing egregiously wrong at a minimum.
Yeah.
That's one of the things that makes it kind of insidious and hard to see is the thing I
directly look at may be fine.
But the person who maintained that, did they make a mistake in the things that they depend
upon?
Or maybe, you know, transit, like follow that chain that graph down far enough.
Right.
There's a lot of layers that could be happening along the way.
It ends up looking like a web.
And not surprisingly, just because of that, most vulnerabilities inside of packages like
this are in the transitive dependencies, the ones below the first layer, the dependencies
are dependent.
Interesting.
So you can pip install the thing.
What about pinning the version?
I know there were some issues about having a private PyPI server, which I think is a good
idea where you whitelist packages in.
You say, we approve these things and only these things get installed.
And if you want to use a new one, we've got to opt it in.
And then now it's part of the organization.
That seems like something you could do, right?
There's PyPI server that you could set up that is a sort of pass-through layer there.
But then there was also the vulnerability of the version mismatch.
Like if there's a higher version of that thing on the public PyPI, then your local one.
So people were putting in like data layer version 70, you know, and then it's like, oh, there's
a newer version out there for me to go get.
I'll get that, even though it was internal, meant to be internal only, right?
So there's these challenges.
But what do you think about a private whitelist server?
It certainly seems valuable and seems like it's another speed bump, as John Speed was calling
them.
But yeah, I mean, then you run into scenarios like the one you described, where it's kind
of, I guess, that's undefined behavior, potentially, or at least not well-known behavior that maybe
isn't necessarily most intuitive.
So even that might not be enough.
So then, yeah, the pinning could help.
Then, of course, there's the challenge of maintaining your pin at the proper level, which adds more
effort on the developers to maintain up-to-date dependencies.
At least publicly.
Yeah.
Publicly, we have Dependabot on GitHub, which is way more of a pain than it should be to use.
Because if you've got 10 updates, it'll issue 10 PRs, which conflict with themselves.
Anyway, that's a long story.
But it's still at least some automation that says, hey, there's a new version of this.
Here's the change log.
And we also have the CVE security checks of Dependabot, which are really good.
Yeah.
Unfortunately, most of these typosquatting or just general supply chain attacks don't end
up in the NVD as a CVE.
Yeah.
Who's going to study this one and then not just say, take it down, right?
Like it's living under the, in the shadows, right?
Of being unnoticed.
To an extent, yeah.
NPM does a good job with their advisory service of like saying, this is a malicious package
and this is why we removed it.
But not all package managers do that.
And even so, then you have to go to all the most developers.
These ones are developing multiple languages these days.
So it's hard to keep track.
Yeah.
What about having isolated environments for trying out new packages?
So for example, one of the things I'm trying to do is if I'm checking out any new package,
I have to pip install.
And maybe that happens in a Docker container.
And then I throw away the container or possibly a VM with snapshotting on.
And then I roll back the snapshot periodically.
Yeah.
Those both sound like great ways to have good hygiene and not isolate the potential blast radius
of a potentially malicious package.
Yeah.
It's one thing to say, here's a thing we want you to check out and it's on PyPI and it's
really well known, but it's, you know, you got to explore new things that aren't super well
known yet.
Right.
And so how do you install that?
Right.
So I think some kind of blast blast store, like you said, like Docker, like a VM is not
a terrible idea.
Yeah.
It's a good one.
What else?
There's the open source software found, security foundation.
Yeah, that's right.
This is open SSF.
Open SSF.
Clearly a reference to open SSL.
Yeah.
another well known software supply chain compromise that widespread impact.
It's worth.
It's worth pointing out that this group for anyone who is comes very enthusiastic about
open source software supply chain security in particular has become a meeting ground where
both companies, but also persons interested in this sort of topics we've been discussing
the day and more have set up a series of working groups.
There's six roughly and, meet every few weeks, open community, fun, interesting people,
either, interested in the topic or actively working to, give back and contribute.
Uh, it's run by the Linux foundation and, we would highly recommend it as a place to
find other like-minded persons.
If you care about these sorts of topics.
Yep.
Fantastic.
And then there's the further on down the road, which we've touched on a couple of times,
but maybe we can encourage some enterprising person, people group out there to go after
it like a, a hardened pip or, you know, we have things that are sort of on top of pip-tools.
We've got pip ENV.
We've got pip X.
I'm a big fan of pip X, the isolation.
And then that gives us kind of need.
And just, I can see like, like a pip sec or something along those or PIPs, maybe a plural
PIPs.
I don't know for pip security, but something like that that incorporates some of these ideas.
Maybe it, it checks in.
You say like, I don't want to install any package that is not in the top 1000.
Sure.
Or a popular package, except for what I whitelist in on top of that or something or check with
Aurora Borealis about the score or check with the, have I been PIP?
Whatever that thing ever would become, right?
So talk about like where you might see things going.
Yeah.
Well, there's been a couple, I'll call them starter projects in the hardened pip area.
There even was one called pip sec.
You can find it on PyPI, but it's really, there's nothing there, unfortunately, at least yet.
That namespace is claimed.
The maintainers who we mentioned, Benjamin Balderbach, especially are interested in doing something,
just haven't had time, other busy priorities.
And I think there is a lot of potential to build out that idea and create something that
could be useful to the average developer.
JavaScript has a tool that has at least some moderate popularity called MPQ that does this.
And I think it's time for the Python community to see if there's something similar.
I would love to see something like that.
Another thing is Google.
Thank you, Google.
Has become a visionary sponsor of the PSF.
And specifically, they want their funds to go towards critical supply chain security improvements,
developing productized malware detection for PyPI, for a type of dynamic analysis infrastructure.
So this sort of gets at the hit at, maybe there's something that the PyPA and PyPI.org could do on their end without even necessarily changing PIP, right?
PIP's going to go talk to some API there.
And it goes, yeah, no, not this one.
That's right.
Or you're going to upload it, like with upload a new package.
It goes, no, we don't want to accept it.
And Dustin Ingram of the Python Software Foundation at PyCon just recently devoted his talk to talking about Python and the software supply chain issues that we've discussed today and writ large to include typosquatting.
And it's clear that there is energy and willingness from even core members of Warehouse and Python Software Foundation to tackle these issues.
So we're glad to see that.
It'd be great to see something like that happening.
I think layers as well, right?
That's how you talk about security often is it's not just, well, you have a strong password and you're fine.
Like, well, and maybe you have two-factor authentication.
And maybe you run as lower permissions and, and, and, and, right?
Yeah.
Layers.
So this could be one of the layers, but not necessarily all of them.
Yeah.
I should note that we even, a couple of us at IQT Labs even put in an issue recently that on Warehouse that might interested some parties here.
It's issue 9527.
You can also find it at short.iqt.org slash issue, just a redirect.
And we essentially call for something like social distancing for the top Python package indexes.
So that for very popular package names, the package names that are close by are blocked off.
So that not saying that anybody who chooses those names is malicious, but just so malicious people can't choose them.
Feel free to upvote that.
We've been discussing this with some of the members of the Warehouse team.
Yeah.
So your proposal is that Pandar should not have even been allowed, right?
That's right.
Given that the package Pandas is so popular, minor variations on its spelling should basically be blocked or maybe redirect to Pandas and say with a warning, like, you tried to install Pandar.
Did you mean to install Pandas?
That's right.
Something like that.
That's right.
So it's a way to build in guardrails so that the unwary don't fall prey to this.
Yeah.
Personally, my first impression is that that's a good idea.
It's worth it that we don't need request and requests and requester.
And, you know, the potential harm is higher than the value of, you know, reusing very, very similar names.
Yeah, we agree.
And there's obviously tradeoffs.
Yeah.
Vince, what do you think?
You must agree with this, I suspect.
I do agree with that.
I definitely supported this.
And I know one other thing that's under consideration that's relevant is namespacing.
So you can, you know, Kenneth Wright is the request guy.
He has his namespace.
You go to his namespace, you're less likely to mistype that and have someone, the namespace and have someone who has claimed the same package within their own namespace.
So possible, but, you know, it's another layer, I guess, as you were describing it.
Yeah, it makes the commands.
You got to type a little bit longer.
But it makes it really clear where it's coming from.
I mean, that's what the point of namespaces and programming is.
It's really clear what library it comes from or what part of your code it comes from.
And who?
Grouped together in namespace.
As well.
I know Go has done, you know, used that to great success.
Yeah, Kim Benwick out there put a cool comment that's sort of related to that, talking about the private IPI server that's, you know, redirecting out.
It would help if the private PIs, if you had an option to prevent the account uploading images from or pulling images with a certain prefix.
For example, if everybody named their packages ABC something at the company, you could say ABC is private, ABC star is private, and never, ever, you know, go look beyond here for that type of thing.
I think that that's pretty interesting.
Yeah, it's a good idea.
Yeah, I think it seems super simple and a good idea.
I agree.
All right, gentlemen.
Well, very cool to talk about this stuff.
Like I said, it's going to make all of us a little bit more nervous, I suspect.
You know, for example, Corey Adkins out there said,
I also just found an article on malicious Docker images.
Now I am paranoid, which.
I'm sorry.
Welcome.
Yeah, yeah.
I've been there for a while.
All right.
Before I let you two out of here, though, real quickly, let's answer.
I'll ask you the two questions at the end of the show, of course.
So if you're going to write some Python code, what editor do you use?
I use Vim if I'm in the command line.
But if I have the fortune to be outside of it, use Sublime.
Right on.
I suspect JupyterLab is also in there.
Definitely Jupyter is in there.
Yeah.
And Ben's?
Probably PyCharm.
Yeah, I mean, I'll use Vim if I'm already in a command line.
But yeah, that's not as often these days.
So PyCharm is just my idea of choice.
Right on.
And then notable PyPI package, something that's like, oh, people should know about.
Check out one called NetworkML.
It's a package related to machine learning and network traffic.
The lead maintainer is Charlie Lewis of IQT Labs.
You can go find it on PyPI.
Yeah.
Fantastic.
So machine learning plugins for network traffic.
Yeah.
So it identifies like anomalies and other weirdnesses like that?
Yeah.
It parses network traffic.
And one of the cool things it does is it helps identify what sort of device is being observed.
So is this thing a printer?
Or is this thing a personal computer?
Is it an active directory controller?
Et cetera.
Is it a canary?
Who knows?
Awesome.
All right.
Well, thank you both for shedding the light on lots of what's happening, some of the things
that are being done and what might also be done as well.
So final call to action.
People that want to get involved, maybe do more, become more aware.
What do you all say?
Yeah.
I mean, there's plenty of work to be done.
Open SSF is a very welcoming, relatively new organization that has a nice list of stuff
to do.
Python Software Foundation also actually has an active list of items they would like
to work on, some of which are relevant to this topic.
So that'd be two great places to start.
I'll point you back towards that GitHub issue.
Feel free to chime in.
And I think there's definitely potential over the next few months.
Additionally, we're actually working on a survey at IQT Labs called on secure code reuse.
So if you want to help build the research foundations for this, you can find this survey at
short.iqt.org slash survey.
And we're trying to understand the developer or data scientists or other programming professional
experience with package reuse.
So that's another way.
So hopefully this survey informs future tools.
Yeah.
Fantastic.
Well, thanks for the work that you all are doing.
And thanks for being on the show.
Thanks for having us.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode were Ben Stoser and John Speedmeyers.
It was brought to you by Square, us over at Talk Python Training, and the transcripts are
brought to you by Assembly AI.
With Square, your web app can easily take payments, seamlessly accept debit and credit cards, as
well as digital wallet payments.
Get started building your own online payment form in three steps with Square's Python SDK
at talkpython.fm/square.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
You're welcome.