Trust me, I’m an open-source developer

​okay.

Hi everyone.

My name's Charlie and Yeah, so I'm a senior advocate, a developer advocate at Stripe.

And as part of my role, one of my responsibilities is to maintain our open source repositories.

And while I'm doing this, so you know, if you've never used Stripe before, so we're a FinTech company and we have SDKs in seven different programming languages.

And we have an open source team that is in charge of actually building these repositories.

But my role as a developer advocate is to actually create samples for people to understand how to use our product and services.

And they also have to be in seven different programming languages.

So, in the end that's actually a lot of maintenance.

And as I was working on this, considering that Stripe is a relatively well known company and we have like financial data about a lot of people, I realized, the fact that I'm installing open source software that built by people that I've never met, that I probably would never meet and I'm installing that on my laptop, in which I have some Stripe stuff on it.

I, realized that it was a pretty big attack vector for anybody who would want to to find stuff about Stripe or, to hack us.

And especially as developer advocates, if somebody is trying to hack us they would like going through open source software and targeting developer advocates who have to try a lot of different tools all the time to stay in touch with what's going on in the industry it would be yeah.

So something that I have to be really careful about.

Yeah.

And the more I researched open source security, I realized that there's not a day that goes by, especially in the last few years where there's not some kind of cybersecurity problem in in, the industry.

I'm sorry about the, I'm just gonna go.

Yeah.

Okay.

So there's like US News website that have malware or GitHub that has vulnerability that allows people to actually have access to open source repositories.

There's also like nation threats, attacks, and anything that's called zero day attacks.

So it's security vulnerabilities that people don't have patches for yet.

And yeah, so overall there's researchers have found that there's a huge increase in cybersecurity issues and aimed at open source repositories particularly, and I was thinking that people in this room, developers, but not only developers, it's something that we can actually try to mitigate.

It's if there's other type of security attacks that can happen that maybe have nothing to do with, us that's fine.

That's like a separate thing that security teams are in charge of.

But us as developers through open source, we can actually we can actually try to learn how to defend ourselves.

And yeah, And the way that I'm usually learning is is by doing.

So I, we're gonna learn how to create like three different types of cybersecurity attacks, but I want to say that this is for educational purposes only because obviously what you, can use what you're gonna learn in this talk to run your own ransomware, all of that stuff.

But I take no responsibility for this.

And but the, so the thing is, if you understand how to actually run these attacks, then you'll have a better idea of how to actually stop them as well, or at least be aware that they can happen.

And then you can go back to your team and say, okay I understand how a ransomware attack can be run, and now we can we can look through potential solutions.

Okay, so first ProtestWare, so this one is it's cute because it's not supposed to do that much damage.

But what is ProtestWare?

So it's software created to raise awareness about a social or political issue, but it does not take it does not damage or take control of the user's computer or system.

In general there's like different ones, but the one that I'm going to show you is not supposed to damage your device.

So the important thing is that this type of attack is just to wear, raise awareness.

And here don't worry about understanding the code, but it's an attack or a type of protest that was added in the in the NPM package event source polyfill, and not in the latest version.

So if you realize that you're using this package, it's fine.

The latest version doesn't have that anymore in it.

But for two or three minor versions there was this piece of code that was added by the maintainer.

And what it does is that you have a set timeout and after 15 minutes it actually opens a URL that redirects you to a site where there were like a message about a social political issue.

And it was first looking at the time zone that you were in.

And if you are in the specified countries or time zones that were at the top, then it was redirecting you to another page.

So it doesn't steal anything.

It doesn't correct any files, but it is annoying that if you're adding this in your production website, it means that your user would be, I don't know, using your, if you're building a bank or whatever, like it was a, you would look, you would log in into your, account and 15 minutes later the user would be redirected, and it's not exactly what they want at all.

And usually as I said now, it's not really in the package anymore, but it is something that when you're updating your versions of packages, you don't really look through the entire source code of every single NPM package that you're using to look for some kind of of attacks.

So what I'm doing at the moment, is I'm using a tool called Socket where if I'm using a tool and I'm not quite sure that I trust the author, I actually look for for the name on it.

And it kinda tells you graphs like like your Chrome performance or Lighthouse tools, and it tells you the kind of like the health of the package.

And even though the current version doesn't have the ProtestWare, they still add a little warning that said that before there was a ProtestWare or troll package.

So you can decide if you want to trust that version or not.

So as I said ProtestWare usually is just to raise in awareness about a certain issue, but you do have certain packages that were ProtestWare that were actually damaging the computer.

So there was a package called Peace Not War that actually was encrypting the entire computer of anybody who was who was using it if they tracked that your IP address was located in Russia.

But what they'd not have thought about is that you can use a VPN and have location Russia, and it doesn't mean that you're Russian.

And it's it's ProtestWare is a bit weird because it's really like a personal thing.

Like I wouldn't use ProtestWare to voice my concerns about a certain thing, but it does mean that if people were using the package 'Peace not War' inside packages, whatever, they lost everything.

So not cool.

But the second one that I want to talk about that is a little bit more exciting and dangerous is ransomware.

So ransomware is a form of malware that is designed to encrypt the files on a device and it renders them and the system that rely on them usable.

And you demand payment to restore access.

So the important things here that it encrypts the files and then it demands payments.

So you cannot have access to you cannot see your files anymore unless you have access to a private key.

So the way that it works is using asymmetric encryption and you can encryption on its own on your computer, it's not a bad thing at all, like I'm all for encryption, but it can, as any tool, it can be used for bad stuff as well.

So if you wanted to experiment with doing encryption stuff on your computer, you can use open ssl.

So all the comments I'm gonna show work on Mac cuz I don't have a Windows machine.

But here you start by creating a private key.

You can use different algorithms.

I'm using the AES256.

You can try with others if you want.

And from that private key.

So it creates a funnel on your computer.

Usually you call it whatever, but I think I call mine private dot pen.

And then you can generate a public key from that.

And that public key is used to encrypt the files and then to decrypt it, you use the private key.

But then how do you actually create ransomware?

So this is like a very small demo of what a super small ransomware script could do.

It's like in a few lines of code.

I'm gonna try to go through the lines, but the screen is going to fail me.

So first here oh by the way, I didn't say it, but when I'm hacking stuff, I'm hacking myself.

Like I'm not actually hacking people.

I should have said that at the very beginning.

Educational purpose only, and hack yourself.

But here, I am, what I'm doing is I'm, navigating to my desktop.

So again, I know my username, so I got a slash user charliegerard desktop.

If I really wanted to do bad stuff, I would just go to route right away.

So I wouldn't have to figure out people's usernames.

And then I copy my public key in a file on the victim's machine.

So this script would be run by the victim.

So they download an NPM package, they don't realize what's in there, and I create a file with a private key on their laptop by using the echo command in which I pass passing the public key, then what I would do is I would use, tar to encrypt the folder.

So I called my folder like super-secret-stuff and I compress it into gotcha dot tar dot GZ file.

And once that is done, the next line is this one.

Okay, so with open ssl, I use the private key, and I encrypt my, compressed file into a gotcha dot enc.

And then, I actually remove the original files because I don't want my victim to have access to the original files.

Otherwise never, they're never gonna pay me if they have access to their stuff.

You remove the compressed file and the original folder.

So in the end what's left is only the gotcha dot enc.

And then you leave a little message note dot text.

Usually you would add instructions about how to pay back in crypto or whatever.

So I'm gonna try, I want you to try to demo it.

So I have here, you should see, okay, so I have my folder for you too.

That has actually my real stuff, I'm not gonna encrypt that one.

And I have a private and public key and I have a folder that's called super-secret-stuff.

And there's not much in it.

I think there's just like a note.

And here I have the script that I told you about.

Okay, cool.

Here I have my comments.

So if I run oh by the way, and I'm running it as, okay so what I'm I guess what I'm gonna talk to you about as well after is about how to hide malware.

But here I'm running it as a post-install comment.

So post-install dash script.

So if I do npm install yeah, I'm just working npm install whatever, and then ,boom, it's gone.

My super secret stuff folder is gone.

What I'm left with is the gotcha dot enc for the encrypted file.

And if you're on Mac if you double click, Mac doesn't actually know how to go about this.

So, you know, I'm done.

I'm not gonna decrypt it cuz there was nothing in it anyway, but but you end up with nothing and your original files are gone.

And I want to go back to my slides.

Okay.

As I said, I'm running it, I'm using the post-install comments in, the packages on it.

And again, by default, post-install is not something bad at all, like pre-install or post-install.

A lot of popular packages actually use these comments so that once either before or after you install the package, you run some stuff and and it does something, but you, let's just unplug it, yep,.

Yeah.

Here, it's pretty obvious in my post-install script that I was running bash dot script dot sh.

So if you are thinking, oh, now I'm just going to look for bash files inside.

I hope it's gonna work.

Thank you.

But let's give it a Okay.

So in the slide before here Seems like it's okay, so in the side here, I was doing bash script bash script.

Sh.

So that's pretty obvious.

If you're looking at like a shell file, if you see a shell, a bash like a bash script inside a repository, again, that's not something that's necessarily a malicious, neither.

There are famous packages that use bash scripts, but you could be like, oh, my team now is just gonna look.

And, if there's a weird post-install comment, then we're just going to filter for that.

But if you really want to attack stuff, you're gonna find a way.

So what about that looks a lot more legit, right?

node install js, it's just installing stuff.

But then you can another way, if you wanted to use JavaScript for that, it's like you don't actually have to have the bash script inside the repository.

You can actually fetch it at on post-install.

So that way it means that the shell script wouldn't be in the repository.

You wouldn't see it.

But when you run post-install, it runs this, and what this does is it's fetching the script at a remote url.

It creates it on the victim's computer.

With the code and then it runs bash script sh as well.

So again, it's like I'm just showing you that there's different ways of running this.

You can make it super obvious or you can try to hide it.

And even that, I didn't really hide it that much.

You could go a lot a lot.

You could do that a lot better.

And here I'm running in post-install, but if you are running, if you are building an NPM package, you could, if you wanted to hide yourself a little bit more, you could run it as when the package is imported and then used.

So when you create an NPM module, you can export default function, and here I call the use use ml.

If I was faking that, I was creating a react hook to do machine learning in the front end, and that would run as soon as you import and actually call the main function.

So that was for ransomware, but now the third one is kinda like my favorite.

It's reverse shells.

And what is a reverse shell?

It allows you to gain remote access to a machine by opening a tunnel between computers, and it allows an attacker to create, modify, delete, and execute files on your machine.

You gain remote access, so it means that as a victim, I install a package on my computer and I don't realize that I just opened a tunnel between my machine and an attacker's machine as well just by installing an NPM package.

How would you do this?

So there's, we're gonna use a tool called Netcat.

And again, by default, Netcat is a networking tool.

It is not malicious at all.

You could, if you're at home and you just want to communicate between two of your own computers, like your own machines, or if you wanna do stuff with friends, you can open a tunnel between both, and it doesn't have to be something malicious either.

But here we're going to do something malicious.

And what this comment does, it opens a connection.

So I'm the, so I'm the victim and I install it on my computer.

And the IP address here is the IP address of the attacker.

So that's like a fake IP address, but what it does is it opens the connection on two port, on port 80.

And then on port 53.

And in the middle you have bin slash sh and it means that as an at attacker, any command that I so I have my terminal open on port 80 and port 53.

Any command that I run on my laptop as the attacker on port 80 is gonna send it to the victim's computer, run it as a bash command, and then send me the result on port 53.

And then this exit means that it's just gonna run in the background.

So as a user, you're really not going to see what's going on.

Like maybe I have a real shell open on my computer right now, and I don't know.

So as as as somebody who just install a package for you, you would not see anything at all.

But to me, I would be able to run who am I and see your username.

I would be able to copy files, I would be able to, edit the name of file, remove them.

I could then create a shell script on your laptop, create somewhere you wouldn't, you have no idea what, what has happened.

So there's, you could run it this way, but you could also run it that way where again, you could have a shell script that has the same Netcat command.

So there's always different ways.

Either you could have a shell script on your repository.

You can run the command directly.

So that's why if you wanted to now have security measures that just, I'm just gonna filter for the n the NC command, like you, there, there's different ways to, run things like this.

And again, you can read it as a post install.

I'll show in the next section how to hide a malware.

But here I have a little demo, so I wanted to do it live, but I had issues putting, like setting that up this morning.

So here I'm gonna explain what the gif does and then when it comes back, you have a second to look at it.

So on the left, side of the terminal, so I hacked myself on a, with a Raspberry Pi.

So on the Raspberry Pi here I ssh'd into it, but you could think of it as like a victim's computer.

And I have a file in it where I just node test js is just opening the, connection.

And here on the, in the middle and right panels of my terminal, I have the connection open on port 80 and port 53.

And the commands that I run in the middle one are actually printing all the results on the third one.

So you can see that when I say, who am I, it prints 'pi' because all of a sudden, I'm on the Raspberry Pi.

I'm not in my own computer anymore and I can change the name of files and, things like that.

Again, when I do this stuff, it's it's not malicious.

I'm just trying things trying things out.

But you could definitely if you hide that into an NPM package, I would have access to people outside of my network, people I don't know and, things like that.

So I think it's super cool.

But it's just to know that this can be done and as a victim that's not super cool, but as an attacker it's fun.

So let's talk about hiding malware, because here I'm telling you what it does.

I'm telling you it's in script files, but there's ways that are actually like really interesting and I've been, I mean I've started researching this like on the side.

Obviously I'm not a cyber security researcher.

There's definitely other ways to hide that stuff, but alright.

So first I talked about installing scripts and packages json, so I'm just gonna move on to the next one.

You can use code obfuscation to make it really hard for people to actually see what your code is doing.

Again, by default, obfuscation is not necessarily a malicious thing.

You use it when you don't want people to understand what your code does, if you don't want them to steal it and things like that.

But you can also use it in a malicious way where if all of a sudden you decide that now you're gonna have security reviews that read the entire source code of every single package.

If you obfuscate it, it's really hard to know what it does, it's like by design, but used in a malicious way.

The next one is something that I tried a few days ago and it was really cool.

You can corrupt the resolved URLs in the package-lock.json.

So here I'm gonna try to demo it.

And okay, cool.

So if I op if I open that, so I have an NPM package.

I'm gonna close this and it's just my test package and here it's installing node fetch.

Cool, cool.

So you just run, and if you look at the package-log json, what does node fetch use, it uses dataURI to buffer, fetch blob, et cetera.

A lot of other things.

And again, by default, package-log json, it's not something bad at all.

It allows you to, everybody can have the same versions of packages and whatever the thing is.

Then if you look at this, that area to buffer.

It's called bytes now.

What happened?

So what happened is that I just went here and I just, instead of having data to buffer, I actually linked it to a separate package.

And when you've had PRs I'm pretty sure that you've had PRs with your team where sometimes there's so many changes in the package-log json, that you just like, forget it.

I'll just merge.

But the thing is I could do that.

Like I could just and here it's pretty obvious because I called it like, bytes I could do what it's called, the typo squatting, which is, I could call it something very, similar, just like one little difference.

I could do like data-uri-to-buffer and you, have to work fast.

You don't realize what's going on.

And then it actually you wouldn't even see really what's going on unless you go through every package and be like, which one is the one that is corrupted?

So that is like a fun one.

Yeah.

Okay.

Then something that I realized recently is called Bin script confusion.

So I didn't know, and when I tried it, it didn't work on me, but I trust the researchers.

It's like when you use bin to create an executable of your program, apparently you can call them Node and npm.

So it means that when you're gonna run in your package node-index dot js, instead of actually using NodeJS that's installed on your computer, it's gonna run these scripts there because it's going, is going to be confused–which node do you want to use?

It's gonna think that the node is come from your personal package as an, executable instead of going and using NodeJS.

So this is like another way.

And people also do that where you can use TSC for TypeScript, or anything that, that is popular.

If a tool becomes popular you can try to do that with bin script confusion.

And then finally VSCode extensions.

VSCode extensions, it's, I've tried to run a ransomware via, and actually it was a reverse shell.

I tried to run my reverse shell in a VSCode extension and it was also super easy because when you create a VSCode extension, there's something called onStartupFinished, which kind of is the same, thing as post-install.

VSCode extensions, you could think that if they go through the security process of like the Marketplace, then it should be all right.

But there's always things that slip through.

And there's also extensions that you can install via GitHub.

I'm, some of you might have tried to create your own Chrome extensions or VSCode extensions, and sometimes they're not actually available on the marketplace.

but they're available on GitHub and there's instructions on how to install them.

And if you don't check the code for that, there could be issues hidden in there as well.

Careful what kind of extensions you install.

Both.

Both for browser browsers and and VSCode as well.

So these are only the ones that, ways to hide malware that I thought about, but there's a lot of different ones.

As well.

There's something called stegware, which uses steganography to hide scripts inside PDFs or gif files, images.

And you do have PDFs that you can also that are part of open source repositories as well.

If you're reading research papers, they usually not usually, but when they are good research papers they're available on, GitHub and you might not realize again, you, you just open it and boom, if something happens and you have no idea what what's happened there.

So now how to actually protect yourself.

You don't actually I, did wanna say like you can't.

Really?

Yeah, you can't really again, I said a reverse shell.

It's really hard to know even if it's on your computer or not, and you're not gonna check every single connection that goes in and out of your computer.

It would be just impossible to have to validate everything.

It's yes, do I want this connection?

Do I want that one?

It would just be too much.

So this one is hard.

And ransomware, once it happened, you kinda lost everything.

So it, you can't really go back and be like, what?

What happened?

But I'm gonna try to, it's gonna be like a boring point list of what I could think of of ways to protect yourself.

So you can use security tools like Snyk or Socket.

They do different things.

Snyk has a VScode extension, Socket has like a, site where you can where you can check for, packages.

And they also have GitHub action that goes through your PRs, and they look for, certain things.

So I, from what I understand, but I'm not sure, Snyk reports what are the vulnerabilities that are known that have been reported to the NPM registry.

But Socket goes a little bit, a step further.

Where they actually parse the code and find things that might not have been reported yet.

So you could have a combination of both.

But another way is to integrate manual security checks in your workflow.

But that again, is like we all have to work pretty fast.

It's a little bit difficult to do this it's like you gotta try something.

There's something I wanted to show you that I realized if I go fast.

Okay.

This thing here.

So I was trying to, I was using Socket and I was trying to trick them.

I was like, can I do something that they're not gonna find?

And there is something that they found everything.

So it was really cool.

But there's one thing that I never actually thought about that I realized when I worked at Stripe, cuz somebody told me that somebody tried to do that to us.

It is like you could spend time with your team looking at code all you want, but sometimes you don't realize that you have to scroll horizontally and then you hide shit on the right.

So, yeah, that's something that you have to think about.

Now I do it now I scroll like down and then but it's just it would take so much time, but I would still if, you can spend some time looking at overall the kind of security checks in your workflow when you merge PRs, it's cool.

Don't install packages you don't need.

I think that in terms of even performance usually is like what you try to do.

There's so many packages on NPM that just are a function that you could have in your repository.

You don't have to like, go and fetch and it's like less maintenance.

And you have also, in terms of attack surface, you could reduce it if you don't you know, if you write your own utils and you don't install packages that are just like ease even npm package you can regularly update your dependencies.

So this one is hard because I, even myself, haven't found the right balance between updating too much, which means that if if a vulnerability had been supported, you take the risk of installing it on your computer.

But if you don't update enough.

You also have true like security fixes that are added to popular frameworks that you do need to install as well.

So I don't have the right balance on that one.

This one is a little bit more expensive.

So, using an air gapped computer.

So at Stripe I have two.

So I have this one that's it's not air gapped to have access to our VPN and stuff like that, but I have another, as an advocate.

We also have air gapped computer, which means that I don't have access to any, I don't have access to our Jira stuff or anything on the other computer.

And as an advocate, I have to, I try all the new tools.

I know that I'm taking the risk of installing something on, the laptop.

So we have two computers, one where I can run anything I want, and one that is actually connected to Stripe stuff.

You can also at least have a principle of least privilege.

I don't have access to any client data on Stripe, and I hope that if you work for a company that has access to some kind of sensitive data if you don't need it in your role, I hope that you have in place at least something that doesn't allow you to have access to anything or at least, preventing the installation of packages known to have vulnerabilities.

So on this laptop here, sometimes I think I was trying to just code with Remix and it actually blocked the installation because I think Remix was using a package that Stripe didn't so it means that I had the big popup that says You can't do this.

I was like, okay.

And that's a bit annoying, but I get it.

And again, I have my air gapped computer where I can install anything I want.

This one is interesting because the more I started thinking about this, the more I thought well, we work locally, which like it's, we're very vulnerable to any kind of attack.

And with that mean, there's platforms where you can work in the cloud with Code Sandbox and Stack Blitz and stuff like that.

And I know that probably for a big tool, you probably can't do everything on the cloud, but if you're building something smaller we it would be nice to be able to move and work on the cloud instead of locally.

Be careful of typo squatting.

So this one is like when you go too fast as I said before, like a lot of people are targeting popular packages, but just change a letter or forget a letter.

And when you're type fast, you instead of 'npm install react', you do 'npm install reac', and then that's it.

It's over.

And then finally I would say prepare a disaster recovery plan.

As I said, you can't really protect yourself that much because when somebody wants to attack you, they'll find a way no matter what.

Thinking about you have disaster recovery plans if your site goes down, but I think that we probably should have one as well if there's any kind of breaches.

I just I'm getting to the end of this talk, so I just want to say again that hacking without consent is illegal.

And I'm, again, I'm hacking myself.

You can hack with friends if you tell them in advance, but don't go to a cafe and be like, oh, I'm just gonna hack everybody.

Alright.

So I just have a list of resources that I read often.

I wrote a few blog posts about the attacks that I'm trying myself.

Otherwise there's security blogs that I read.

You have like a second to take a picture and then it's over.

And I'm gonna leave it for 1, 2, 3.

Oh, I'll just send it to you.

Anyway, I was just thinking recently, especially in Australia with Optus hacks and, Medibank, if you are trying to find if you work in a company where they don't really give you the time to maintain things and to think about security, I do hope that it's a bit sad that we have to wait for things like that to happen to then care about it.

But not only does it have cost in terms of money, but also in terms of, privacy and people's data, no matter what the project that you're building.

I, when I read that, I think in Medibank like hackers were leaking abortion details on the dark Web, I thought it was just like, disgusting.

And, but the thing is maybe you don't care about abortion details, but it's very private information and you're building something for the people and it's just, maybe if there had been more security practices, something could have been avoided.

But again you can't protect yourself entirely.

But what do you do?

Could these details have been encrypted in the way that couldn't have been just leaked like that?

But anyway.

What I, if you, there's something, one thing that you need to remember at the end of this talk is that it's not an if we get attacked, but more of a when especially through open source.

More and more hackers are looking at that as an avenue, because we don't really check what we install.

It's just oh, a cool new tool.

Sure.

npm install and, it's nice that there's not more attacks that are run this way, but it's not I think that trust-based system is not gonna last forever.

Anyway.

So on this, I'm really apologize for the slides.

But thank you so much.

I hope that at least you learn something in this talk.

And again, it's it's something that as developers we can help, but even people who are not necessarily product engineer, but they somehow interact with open source software.

If you can just share the news about how to protect yourself in the kind of attacks, then at least one more person that knows about it.

And then hopefully it will be like a, chain and things will get a bit better.

But anyway, thank you so much.