Watch Me Run Malware From NPM

Hello, everyone. I'm here to show you how I run malware directly from NPM on my machine so that you don't have to. Well, that's not the full story, but let's not get ahead of ourselves. Right?

Okay. So, who am I? Hello. I'm Zebe. If you type nauter into any text box anywhere online and you get any results, it's probably going to be about me. I'm into JavaScript. I've been doing Node and JavaScript for many years now. And I switched to more focus on security a few years back. Now I'm working on Labemote, which is the logo in the middle that's protecting Metamask, which is the cute fox. And I'm also running a Meetup and conference group called MeetJS.

Okay. But this presentation is going to be a fairly chaotic take on some security things you might not be aware of yet. And I like to compare it to the TED Talk by Clifford Stahl. If you haven't seen it, I recommend it. Clifford Stahl is the first ever incident responder in security, in computer security overall, before it was called computer security and incident response. Very cool story. Anyway, I digress.

So, let me start with my favorite question. Would you take a string from me and without reading, put it in your source code that you then build and send out to production in your web application? Be it the server side, client side, anything. Would you do that? Okay. Now, would it help convince you to do that if I put it in a tar.gz file? Well, that's exactly what NPM packages are. And don't get me wrong, they're glorious. We love them. But at the same time, they're just unsanitized input from random people online that you put in your application and run in production without reading, aren't they? So yeah, it would be great to just consume NPM packages the way we do. I like consuming NPM packages, but what if some of them are not great, right? And I don't mean lousy packages. I published a fair share of lousy packages and nothing bad happened. But I mean malicious packages. We've heard about malicious packages.

I'm not going to do a news brief on malicious packages. You've seen all of it.

Okay. So how did I get here? Well, I was interested in supply chain security for a while. I started where everyone starts, vulnerable dependencies, scanning for vulnerable dependencies, and then noticing that it's way too tedious to respond to all of it. So I need a structured way to ignore them and so on. And that's how NPM Audit Resolver got created. I switched my focus to malicious install scripts afterwards. And there's a bunch of tooling that I explored and a bunch of hacks that you can see in my earlier presentations. And then focused on defending from malicious packages that are actually becoming part of the application after all of the previous defenses failed already. And this is what we're going to talk about today. Another rendition of that.

And then also there was a defensive coding workshop that you can possibly attend on some other occasion in the future. And those talks and everything are available on my website. But I promised you I'm going to run malware, right? So let's focus on that. So first, where do we get malware? If you want to get malware, you rarely get to download this malware straight from NPM knowingly, because before you learned that the package was malicious, NPM probably already removed it. So if you want to explore a malicious package, you can go to Socket Dev, where they have a package contents explorer on the website. And they don't remove old versions. So you can look at the contents of the package and download bits, which is what I did. Worth mentioning, the package in question was obfuscated. And the story is, I tried to obfuscate it manually, because I find weird things fun. But it had four layers of obfuscation and everything. At some point, I was just like, I'm working on a thing that can protect my code at runtime. Why don't I just use that instead of the obfuscating code? And that's what I did.

So now, let's switch to watching me run actual malware, okay? I'm going to skip the setup. This is my lab. It's an experimental toy project. And here on the left side, you can see that the malware file is not very readable. And it's fairly long, as you see in the miniature. And now if I run LavaLab, just a terminal, I run it on the LoffyGang malware sample.

This is just JavaScript, right? The thing you're seeing on the left. Running this. Just checking if I'm safe. And then, obviously it's a demo, so I'm going to be cheating. This is a history of what I run. And so what we're doing now is going through the evaluation of the thing that unpacks and turns this mess you see on the left into something that can actually be run as JavaScript. So we need to allow it by some trial and error. We need to allow it a few calls to eval to actually get things going. And then after some eval, regex and parsint, the code actually starts doing things.

So this is a malware that's dedicated to running in Node.js. That's what we learned by seeing requirefs, okay? It also requires HTTPS. We're not going to let it require the actual things. So what you see above is a list of things it was trying to reach. And then I'm making decisions here synchronously as the program is paused, if I want to give it that reference or not. Isn't that fun? So we're denying it access to everything it wants to require and instead giving it fakes.

And now we're being asked what we should give to the program as type process.exec, okay? So let's give it a fake function. Now it requires some more stuff and it reaches for process. That's fairly common. Another proxy. Okay. Process.env. Yeah, that was easy to predict. Okay. And now we can see that it's reading the local app data and variable. This is how we learn this is a Windows malware, okay? And we're returning a string that's going to be easy to recognize elsewhere instead of the actual value. And then we see that it tries to read the directory and it passes that recognizable string to read your sink. Okay. We're learning how it works without ever deobfuscating the package, right? So now it iterates over the folders and collects some information. Then another indication of this being Windows malware, it runs task list. Nice.

And then it posts to a Discord webhook so that the teenagers who actually wrote that malware can collect the data they captured in their favorite online platform without having to set up any server infrastructure. Isn't that convenient? And that's what the malware does. Fun, right?

Okay. So why stop at obfuscation? Did you know that some malware can be delivered as a pre-compiled bytecode? The code on screen shows you how. VM script in Node.js doesn't actually check if the code that we're trying to compile matches the cache specifically. It just checks if the length of the code seems to be matching the cached bytes from the bytecode, which makes it easy to deliver a bytecode payload without having to deliver the readable code for that. Okay. So, yeah. I can... Side note, don't publish malware to NPM even if you have good reasons and you're doing white hat and everything.

But before we go there, let's take a look at another tiny example of some code that I then compiled. And now I can run it with Lava Lab C, which is a Lava Lab that can handle compiled bytecode. So the platform has to be matching and everything, so it's not that easy to get compiled bytecode from someone and run it on your platform. But we can see it actually works from the compiled file. This is JavaScript bytecode, and it's going to ask me if I want to give it console. As you can see, this is matching the code to the left. And then it's reaching for URL. And there's some artifacts of the compilation itself, so there's some mapping going on inside. That's interesting, right?

And then require is accessed. We run read file sync on a payload. We return a fake, and then eval is a function. And now the payload that we returned is turned into JSON, even though it's not visible in the code. But that's the operation that this code compiled to, interestingly. Fun, isn't it? And then we run the result of that, to which I gave an object with a proxy to see if there's any other methods being called on it. And that's it. So eval of something empty didn't do much. All right, but this works on compiled bytecode as well. Moving on to defenses, because I'm actually on the defending side of things. So we're not going to talk about the defenses that are based on existing information about packages. So there's npm audit that's going to check whether your dependencies have known issues and let you know.

And that is two months into that dependency existing that some humans got through the process of reporting on it. There's socket that can do it within hours with some heuristics, but then you have to verify if the warnings are correct. What we're after is after you've ignored or failed to apply all of those protections, and malicious code is already in your application running in production, we want to stop that.

And as you saw, I can do that, right? If we can control malicious code at runtime, let's use the technology behind it to make our applications more secure. And that's where Hardin JavaScript comes in. You can go to hardenjs.org and watch a beautiful video about it where my favorite open sourcer wizard is explaining what's going on. So in short, JavaScript happens to be designed well for security. It's an unexpected statement, yes. Look at how it's being standardized. There's ECMA that works on the language itself, which has barely any powerful APIs in it. And then every powerful API is coming from either the browser or node or any host environment you're running in. So that's standardized elsewhere. So take Conway's Law that says communication infrastructure of the people building software is going to shape the software itself. We end up with very good separation between the language itself and the powerful APIs. Power is only reachable through scope. You can either reach for a global or require slash import something. And Hardin JavaScript is there to control the scope and the import mechanisms. And that's already implemented as SESS-SHIM. So we can use it while we wait for it to be standardized. Yes, there is a process going on to eventually get it into the standard of JavaScript. So Hardin JavaScript provides two things that are worth explaining here.

One is compartment, which gives a scope isolation that we can apply to any code. The other is lockdown that prevents any sort of prototype pollution and hardens the JavaScript intrinsics themselves. So any global things in JavaScript, like object prototype and array prototype, you cannot break anymore. So this is the very simple lockdown. The actual lockdown is like 5,000 lines of code or so. And that's what we use behind the scenes in Lavamote. So Lavamote is the tool that I'm working on that takes Hardin JavaScript and applies it in your technology stack to make your runtime more secure from malicious packages. And we apply it specifically to your dependencies. So this is a supply chain security tool that works at runtime.

What does it do? It takes each package and puts it in its own compartment. So all of the files from one package are going to share a global, but they're not going to share the global reference with any other packages or your app code. Sounds impossible? Yeah, it sounded impossible to me too. It can be done. And we also control the structure of the dependency and we allow dependencies to call each other. It all happens in the same thread, in the same window, whatever platform you're using. And we also deliver tooling to help you create a policy to decide which package can access what. I could explain it and wave my hands even more, but I would rather show you. So it's time for the final demo.

Let's first take a look at the sources. So we have a silly little application here that I need more room to display. So this is a tiny application where we set a cookie so that we have something valuable to protect. And this console log is to just document that it's there. And then we call some dependencies. And one of our dependencies is a package called CookieMonster, which I note didn't publish to NPM because it's a malicious package. And what the CookieMonster is doing is, yes, it's giving us a random quote from CookieMonster. Lovely. But it's also stealing our cookies. Well, what did you expect? It's CookieMonster. And now we have a Webpack build that can build this application in two ways. One is the most usual Webpack build you can imagine. The other is the same but extended with a Lafamote plugin. This is a plugin that's currently in beta. By the time you hear it, it might already be 1.0. We are definitely releasing 1.0 before the end of the current year.

And now App.js gets built and we can run it in the browser. So let's take a look at this app running in the browser. So this is the build where no Lafamote was applied. So what's happening in the console, if you take a look, there's the console log that says localhost is our domain and name equals chocolate chip is our cookie. And then we get a quote from CookieMonster, the response from the TypeScript file that's there to prove Webpack is doing its thing.

And then we get errors from trying to send the stolen cookie to example.com. Because cross origin prevented it but it's a server setup thing, right? But CookieMonster had access to our cookies and our fetch and everything, which I don't really like. I don't want that.

So in here, you can see that in the same situation with Lafamote applied, we're getting an error that says fetch is not a function. How did that happen? I'm going to show you. So we have a Lafamote folder here where we have generated a policy that says these are the things that the package seems to be using. This is just for you to review and allow or not. And then we have a policy override file that you can manually create and deny everything if you want to. Or deny it selectively. So if we still have time, I might try allowing for this and rerunning the build. Gets... Gets... Nope. Okay. Okay. Rerunning the build and we can now see the same app but with fetch being allowed. So fetch is allowed but access to document global is not allowed. So while fetch works, it sends undefined slash undefined because these global values don't exist for our CookieMonster package. Isn't that fun?

And with that, I want to tell you that limited time offer, I can help some people set up their project with Lafamote. There's a bunch of tools there. But you should start with allowscripts which is a tiny thing that you can set up in five minutes and prevent most attacks from malicious packages that are known to us. And yeah, there's more to Lafamote. You can read about it and explore all the tools and features. Thank you all and I hope you have a safe experience developing your web apps.