 It's like a light spot on my face. That's great. And I'll switch to the crowd. I'll switch to the crowd of you so it's not your face when someone pops in. That's cool. Do I have like a giant head on the screen up there? I thought that's weird. So I guess we'll get started. So yeah, thanks everybody for coming. Tonight, Adam Baldwin is going to talk about note security. And pretty much his only qualification to talk about it is the fact that he does it. He's not very good at it or very knowledgeable, but he's one of the people that actually just wanted to do it. And yeah, he's part of or the runner of the note security project. He knows a lot about the different modalities and common end modules and different versions of notes or how you can monitor them. It's infecting, you know, whatever your deployment happens to be. And with that terrible lead in, I'm going to turn it over to you about Adam. Turn it over. All right. Can everybody hear me? Yeah, confirmation. All right. And let's see. Let's make sure that we can share some slides here. And you can see that wonderful lucky business. So as soon as I press play on this on my presentation, I will no longer see all of you, but hopefully you'll have the mic on if you want to interject something. Since we're doing this live, we might as well just ask questions live. So if you do want to interrupt me, go ahead. We'll try to answer a question or get things addressed in the middle. Otherwise, you can wait till the end and we'll do some Q&A at the end. So let's see. Let's find a slide deck. And can somebody confirm they can see that? Yep. Cool. All right. Well, thanks, everyone. This is a note security. I'm Adam Baldwin. I am definitely not that Adam Baldwin. I'm this Adam Baldwin. This is where you can find me on the internet. Adam Baldwin on Twitter, Evil Packet on GitHub. I worked for a wonderful company called And Yet, where I run the lift security team, as well as I run the Node Security Project. And today, we're going to talk about basically today, I've put together some content from various sources that I've talked about before and some things that I basically wanted to talk about and that I enjoy talking about with the hopes that you'll gain some new perspective when it comes to security. This talk may not be that technical. So if you're looking for technical in depth, we probably have to hash that out in the Q&A. Most of my talks, you all are smart people. You can gain technical knowledge fairly easily on your own. What I bring to the table is a perspective from the attacker's point of view from the security mindset. And that's what I've been doing within the Node community for the last four years is applying that perspective, trying to find vulnerabilities and figure out how to make things better. And I also hope to impart some curiosity on your part when it comes to where the dev world and the security world or the ops world and the security world intersect, whatever your flavor may be. So to start off, I'm going to tell you a story about how I got into Node security. And it was probably four years ago, I sent an email to Isaac Schluter that all of the Shaw hashes for every user within NPM was exposed. Now today we call that a breach. But back then, specifically for Couch, which the registry ran on and runs on, Couch had exposed those hashes and that was just the way that it came by default. And so that was also sort of the registry's foray into kind of its first, one of the first security incidents and having to deal with that. If you can crack that Shaw on the screen, you can figure out whose password that was. I know it's somebody very infamous in the Node community, but I won't tell you who. I'll just leave that a little while longer and I'll give you the slides afterwards if you want to have fun. So we're going to talk about three things. We're going to talk about your code. We're going to talk about a third party code and specifically we're going to talk, and then first we're going to talk Node core. Because I think those are the sort of three interesting areas within Node. And so let's break down Node core a little bit. Node core, you know, most of you, again, this is a Node, you know, Node Bitburg. It's probably the fact that it's Node. You all know about Node core. You all know the details of the inner workings, but I thought I'd go through a little bit anyway. And the fact that, you know, Node core, you know, it's built on V8, right? It's, you know, has this IO layer between it and the operating system. And then it's got all this interesting modules that it also includes, right? Net module, HTTP. And this is an interesting surface area to me with Node core from a security perspective, right? You don't have a lot of control over Node core. You have to trust all of the Node foundation to do its best job to keep vulnerabilities out of Node core or to respond to them, as well as you have to, you know, trust that there's no malicious operators within that as well and all the contributors, right? They make up and they secure this, you know, this I'm gesturing, but you can't see me, which is silly, is they make up, you know, all the patches and things for these modules. So I'm going to talk about something that's interesting to me that's part of a story of Node core security over this last year. And the logo is there for my own amusement because it's very similar to the Heartbleed vulnerability that came out. For us in Mathintosh, recognize that there was an interesting API problem with Node core and that it was something that a lot of developers didn't realize is that buffers would return uninitialized memory if not zeroed out. And it's very similar to Heartbleed, but different. And so basically if you had, say, you know, we all, you know, if you know the new buffer syntax in a new buffer X and you provided an integer, it's going to give you a buffer of that size. Well, one common thing within Node frameworks and Node applications is take a base 64 string, say when you're passing along data in a web socket or something and then passing it into a function like this where it's new buffer X. Well, if that X happens to be an integer and you return that back to the user, you return them back uninitialized memory. And it was an interesting problem because it's sort of the fault of JavaScript not being super type safe. It's just a quirk of that API and API that's been around for quite a while. And something that the, I don't think most developers understand about core is that this, there was a real discussion, a real, you know, arguments and back and forth with regard to how to address this, right? Because you had the zero fill option. You could fill your buffers. But the thing about it is, is that JavaScript developers came in like JavaScript because they don't have to handle that crap. And they have to, you know, they don't have to handle this memory management minutia that you get with, you know, C and assembler and whatever. They want that taken care of. That's something that a lot of people knew about. So core worked through this particular issue. And what we got out of it was a couple of options. We got some new APIs, right? So within core, we had some new APIs that help you handle buffers better. And it would be a great deal if you're dealing with buffers in your code to go check out this documentation and go work your way towards these new buffers that are a more safe implementation. And for legacy, we also have, if you want to make very sure that your buffers are zeroed out for a performance hit, you have this node zero fill buffers option as well. And make sure you put the option before your index, otherwise it won't actually work. Your app will still run, but it won't zero fill them. I freaked out when I was testing that because I switched those around index and zero fill and it was still working. I was like, was there a regression? What happened? And so that's kind of an interesting thing about NodeCore is that we don't have a lot of control there. And we also don't have the same problem. So we have an interesting thing where we're bringing a lot of VA vulnerabilities, open SSL, as those are found. And then we've also got a lot of other... The pain points that have been mostly HDDP is where the vulnerabilities have been identified in the parser there. What's interesting is that the vulnerabilities in Core often don't necessarily mean an exploitable situation for your application necessarily. You have to have the right pattern for that particular API, just like this buffer one, just like some of the HDP ones. But it's a good idea to keep sort of your NodeCore up to date as well as keep an eye on for security vulnerabilities. And here are those resources. Here are the places that you're going to want to attune to so that you... Or if you find a security vulnerability or think you've found something, you can report it to security at NodeJS.org. And that's pretty much the situation with Core. I think now the foundation has taken over Core. We've really seen the security story improve with regard to communication and new releases such as for open SSL and things that have stagnated in the past. I think that's drastically improved. So on to the next section. Your code... We'll get a little boat there. I like that little boat. Your code is the place where you're going to interject bugs. As developers, we are bug-creating machines. They launch from our fingertips into our terminal and that's where they live. But what's nice about the code that we write and the bugs that we create is that you have the most control of the code that you actually write versus, say, NodeCore. You control the data input. You control where that data flows to and how it flows throughout your application. You have great control over that. And one thing that I think is important about your code is also nothing is ever secure as a code that you never wrote, the surface area that you never created. There's a tweet that I tried to find. It's really great. It says, it talks about a junior developer. It's so excited about the number of additions in code. Wrote this feature and the regular sort of mid-level developer is excited about the code that they deleted. They got excited about the code that they deleted. And the senior developer, which, of course, is junior, mid-senior, just BS, but senior is excited about the code that they never wrote. The code that they prevented getting written. And I think that that's very valid when it comes from a security perspective is that if you don't add that API feature, if you don't add that extra option or that weird clever call that you need, that you don't need in there by doing just a little bit more designer and a little bit more thinking about the problem, you eliminate surface area and therefore enhance security. With, let's see, I had a thought that I ran off. Okay. And so let's say your code. One of the things I want to talk about with your code is my methodology for finding flaws. So when I look at an application, it's taken me many, many years to distill this down into this basically one slide of how I approach finding vulnerabilities within an application. And really, it's understanding the most you can about the technology being used. How do we understand the threat model of Node? How do we understand what data comes in and out of our application? Are we using HTTP? Are we using DNS? Are we using just TCP? What technologies are we using? Then understanding those common weaknesses. Understanding what are the possible attacks against those technologies? If you're using FS as an example, a directory traversal is a thing. Being able to put an absolute path or a dot dot slash dot dot slash up to a relative path up to another file location. And then from there, it's really about finding inputs to your application, working the users to provide input. How is that data flowing throughout your application and then where is it headed to? Is it coming from a web browser and ending up in a SQL database? Is it coming from a web browser going into a controller and then going back out to a web browser and being rendered where you'd have something like cross-excripting or the first you'd have SQL injection or no SQL database, right? Where you have a different type of injection possibility. And then you have to have curiosity and persistence. And I want to show you one interesting thing where, you know, one example where I've gone over and found a vulnerability in a module as we were auditing modules. And this is a regular expression in our service vulnerability. And regular expression in our services is when you take user input and you pass it in a regular expression and you get a catastrophic backtracing situation. And because NodeCore has this wonderful thing called the event loop and we only have one of them, if you ever block it, blocking is bad, right? So if you don't fully understand the event loop I suggest my coworkers talk what the heck is event loop anyway but Phillip Roberts, go there, look at that, you'll understand more about the event loop than you did before. And so what this example that I'm going to show you is the MS module. It's probably a 100 line module and it has this regular expression in it. And when you pass user input into it it's a particularly, you know, 5555 space, minute A. It will block the event loop and I wanted to show that here. Let's see if I can, of course, this is going to break. Should be able to see a screen. Hopefully that's big enough. Somebody give me any indication if that's big enough or not. Yep, looks good. Cool. Okay, so let's see. So MS. The Node MS module is very simple, right? And people know our license free index. It's all in the index file. There's no dependencies, no nothing. It's one of the top 100 modules. And it really, it doesn't do a whole lot, right? It takes a value in some options and based on those value and options it calls parse. And parse really just does some magic but ultimately, right, you see this particular match right here. We're doing a match right off the bat. So if our user input ends up in that string you will end up with a block, right? And I'll show you what that looks like in terminal here. Here's our particular case, right? Here's a really crappy function to generate a string. And if we pass in say an integer it'll generate, you know, a bunch of fives, space and then this. So what happens is it's basically a giant tree of potential paths for success. And then because it actually has a failure here at the end it's trying to find the best way to match it. It has to check every single one of those possibilities to see if it's got a potential match. So if we do a time on this, I can't type, 1,000, right? We get, you know, just a few seconds. If we do 10,000 it's like, or it's a what, 0.8 seconds. If we do 40,000, right? It's blocking more. See if that actually finishes. Should block for 11 seconds. So you see that if you happen to have, if you happen to be using this server side you have a potential blocking catastrophic situation. Denial service situation. The fix was really simple that Guillermo did and that fix was to just limit the input. So in, let's see, I still have it here. I'll see, you know, and have a string over 10,000 characters. So you still get a minor block, but that's all he did to fix that particular issue. They could actually fix the regular expression, but instead took that route. So you still get a minor DOS, but it's, you know, fairly limited. Oops, it's not in there anyway. So that's that. Let me play this again. So in just thinking about your code, again, your responsibility, you know, there is to understand the technologies being in use, understand what those potential flaws are against those. And there's a really good resource, you know, that's often cited as the OASP top 10. It's a great place to start, especially if you're building web applications. It's a great resource to see if I get it up here. It's got a list of basically all of the common, common flaws, right? The injection flaws, the authentication flaws, cross-excripting. And the thing to remember is that these aren't, these are generic, right? They're not specific to Node. Because we really stand on the shoulder of giants here in terms of all these flaws that we're, you're going to find in your Node applications, your Node apps. You're going to be finding those in other apps, ProLabs, PHP apps. And so we can really learn from those other environments on those other languages, those other, you know, frameworks on flaws. So don't, you know, limit yourself. You're looking into this stuff. Don't limit it to Node-specific type, type research. So let's see, that, those are, those are a couple of interesting spots. The most, the most interesting to me, and probably the most meat of this, this whole talk is about third-party code. When I, when I got into, into Node, you know, four years back for, you know, four plus years, you know, I started, we were building a product, Andy was building a product in Node, and we were also consulting with customers. And so I was trying to figure out where, where are the flaws going to be with the applications? Right? We have control of the code. We write, we can peer review that. We can do a good job of, of policing that. You know, we have to trust Node core a bit. And then we've got, we've got all of, we get this culture of tiny modules, right? Back when I started, there was probably, oh, 10, 12,000 modules in the registry. And, you know, looking at the surface area, you know, the apps we were building, it was probably a percent, a percent, maybe less of code that we were writing was actually our code. And we were instead bringing in all this code from all these other people, like 99% of the code that we, that our app was running was literally other people's code. And so that's what got me interested in researching NPM and researching sort of the threat model there. And that'll be the rest of the, the rest of the talk here. So when you look at, you know, our package JSON, this is what we get, right? We got the dependencies that we, that we require. And those are the, those are the ones that we have in our package JSON, right? But there's this giant sort of nesting that happens because obviously dependencies can have dependencies and all the way down, right? And this is what it looks like. And so it's important to understand that that is the case and to be aware of what you're bringing into your application. So that's, that's what we're going to talk about. Specifically, we've talked about scripts, authors and dependencies, the most sort of risk inducing areas of a particular module. Of course, you know, we wouldn't have this wonderful module ecosystem without NPM, right? All of these modules are hosted on NPM. And so one interesting way is to actually compromise NPM, right? So, so we'll talk a little bit about the NPM now. And every so often it's sort of discovered that, you know, malicious code can be hosted on NPM, right? And that we can put up the, the rim reform module and post attacker news and try to get people to, you know, RMRF their drives, which, you know, somebody did. And this is all, this is all, it's discovered time and time again, right? It's been this way for years and years. And we have an option, we have this option dash dash ignore scripts. You can run ignore scripts if you want to just pull down the tar ball module, you know, without running the scripts and then take a look at it, right? Or you can pull down the tar ball and take a look at it, right? Which would probably be more safe. But this is because of install scripts, right? And you can find out more about install scripts, but there's basically these hooks as you, as the life cycle of a package installs and uninstalls, you know, or builds. There are these install scripts that, you know, let packages do fun things when they get installed, right? So if you install, you know, MPMI totally not a virus trust me, I'm a dolphin. It just puts a picture of itself up on your terminal. But it's an example of that it could do other, you know, malicious things if it wanted to. And that's where this sort of story about a worm, this big blow up earlier this year got started that, you know, we could have a worm situation within MPM because my totally not a virus trust me, I'm a dolphin module could take your MPMRC file, which you, you know, you've authenticated if your module authored to MPM. And it could grab that token then, and then try to try to pull down and publish to the modules that you have access to. Thus, you know, creating a worm like situation, whoever depends on those modules, you know, and so forth and so forth. But we have an interesting, we have an interesting problem because I have to get you to install totally not a virus trust me, I'm a dolphin first. And now there are some stubborn people out there that will just, that will just install this module. But the reality is, is that you're going to be like, yeah, no, no dude, I'm not installing that module. You know, or you might go look at it first. And to start off that plus, you have to maybe be some type of prolific author to have, you know, a number of packages out there and, you know, have to have that worm like effect, right? And so it got me thinking, because this isn't new to us. This is a conversation we had years ago about this particular phenomenon. And so I thought, I was like, okay, what's interesting? How, how do we get you as a developer as a module author to install, to install modules? Well, it turns out that humans make mistakes, right? Humans are bad at typing. And sometimes we just, we just type the wrong thing. And so what, what I did was I did an analysis of the HTTP logs of the NPM registry at the time Isaac provided those to me. And I looked at the typos. I generated typos for the top, I think top thousand modules at the time. And then I looked for 404s in the logs to see who tried to install that version of that typo. And turns out that there is a really, really good vector here and that punctuation causes confusion. Punctuation causes us, you know, because we don't know if it's Socket.io or Socket.io or CoffeeScript or Coffee Dash Script. So, and I published CoffeeScript, which is not the real module probably a few years ago. And it did nothing. And it lasted about a week in the registry and about 200 downloads before it got captured. But still then, like, was it enough to create a wormhole situation? I don't know. So that's an interesting, you know, interesting stat. This is what I have from there. You know, what else stops me from publishing modules, right, as you? Well, passwords. And passwords, I blurred this on purpose because I didn't want to embarrass the person that did it. We did a scan across the registry of people who use usernames as passwords. And it turns out that a number of people did and some of those people had packages that had dependent, that they were dependent on all the way up into some very popular packages. And so even though your little simple module, you know, might not be that important to you, if it starts getting used by something else, you all of a sudden have this responsibility to have good security practices, right? And that sort of brings us to the people of this problem. And I mean, when was the last time you changed your MPM password? I can't see a show of hands because I can't see you. But chances are it's not been that recent because MPM conveniently sticks in a configuration file for you, right? So you have to have some diligence on your part into changing your MPM password. I highly suggest that everyone do that on a regular basis. They don't enforce it yet. But, you know, it's a good practice. So the people of this is that, you know, we've got a couple of different actors, right? We're assuming up to this point sort of, you know, we've got malicious actors where they could be trying to compromise MPM and actually modify those modules. And we've got, you know, non-malicious actors that make mistakes and the malicious actors can take advantage of. You know, just to kind of talk about the people of MPM, you know, one person of the, you know, can influence the 20 of the top 100 modules. That person happens to be the CEO of MPM, so it's probably in their best interest to not do anything there. But, you know, it just shows that, you know, small modules can also have, these modules can have wide-ranging impacts. One person can have, was what I meant, one person can have a lot of impact across the ecosystem. If you look at things like Express, Express has four people that can be a core contributor. But when you look at, when you install Express, you install a bunch of other crap as well, right? Actually, it's what, something more like 40 people are actually shipping code just for Express, right? When you look at Happy, it's just Aaron Hammer, Aaron, you know, it's a, it's, this is probably outdated and there's probably more people than that. But you get sort of this, this, this social graph that, you know, do all of these people have good, you know, good ethics probably? Do all of them have good security practices? Maybe, do all of them have uncompromised laptops? Maybe. You see that the thing is, is that as an organization or as a, as a user of these modules, you, you inherit the, the, you know, behaviors of the users that are, you know, behind these popular modules or not so popular modules. This is one as an example I found, I don't remember what module it is now, but this is one module in the registry that's the most people behind it. It's not a very popular module, but it's just sort of for demonstration purposes that this can, you know, that, that sort of, like the number of people shipping code into your production app can become ridiculous, right? Then we got this, this last sort of thing that came up this year as well. And that's sort of the change of control, you know, what happens, so the background here is that a module got unpublished, it was a fairly unpopular module, along with like a couple hundred other modules. And what's interesting is that it is in, pre this situation, it was a land grab. So just like your domain expiring, you know, Microsoft.com expires, and you snipe it up, well, guess what, you're now Microsoft.com. The same situation was true about these modules. And so, you know, while some people built tools to sort of detect if you're dependent upon those, what our team was doing was monitoring those to see if they were being used for malicious purposes. So as, as they were being re-registered by people that were like, ah crap, we're dependent on this, we'll just republish the, you know, the last release up there, just so it works for people. You know, we were monitoring for, for, you know, sort of malicious things in nature. And so now the new rules are if you, if you unpublish, if it's less than 24 hours old, you can unpublish it, and it will be completely removed from the registry. If it's older than that, it will fail and you have to actually contact support. And it's at their discretion that they will either unpublish it or, you know, do something else. Now, they have a policy or a policy in the process that they should follow, you know, for that. And that's the best way to do that. Let's see. So that's where, you know, so we leave it there. Let's say we do have a malicious module in the registry, kind of bouncing around here. We, I was going to show you a really interesting demo, but my demo SEG faults, I fired it up and a particular dependency SEG faults, and I can't get it to work on any machine or VM that I have. So I'm not going to show you, basically, we've got the ability now to instrument, you know, with tooling instrument Docker containers to look at what modules do uninstall. So we can look and see, did it access MPMRC? Did it talk to a server other than MPM? And maybe that's an interesting flag. And so we're trying to work out a system or a way to sort of get an early detection for modules that may be, you know, RMRFing, everything, or that may be, you know, trying to open a reverse shell up to a remote server or something. As well as we tried, I tried an experiment, this is an old slide. You know, Docker Diff is a great tool as well if you ever want to know what something is doing after install. It'll tell you anything that's added, modified or deleted. And this is an example from the RMRFAL module. You can see that it deleted 137 files when we had it run just by using Docker, just running in Docker container and then doing Docker Diff on it. Nothing special there. But it showed that it was, you know, malicious. So that's interesting maybe from a security team perspective, somebody that's doing the auditing of those. So, you know, that was a lot of like sort of historical, you know, security issues with the registry, you know, and sort of problems. You know, MPM, you know, the thing that I don't think it's talked about enough is that MPM does quite a bit to sort of have our back when it comes to that ecosystem. I just like core does a lot with, you know, their discussions and their, you know, arguments and, you know, making sure that the APIs are great for us going forward and that they try to have our best interests at heart and do so in an open way. MPM doesn't talk about the things that they do with the registry. You know, for the last four years I've been working with, you know, Isaac and the registry, you know, pointing out vulnerabilities and making that better and, you know, more recently they've turned MPM into, you know, and PM Inc. and they've gotten funding to, you know, make the registry more stable and a lot of people complain that the registry is, you know, you know, slow or whatever, but the fact is that it's not down for 16-hour periods of time and then it does serve up a lot of content and does so very quickly for us. They're handling a massive amount of load and donating most of that to open, the open source ecosystem and open source. We do, so every piece of code so to understand a little bit more about what MPM does for the ecosystem. MPM Inc. pays to have every pull request that ships to an MPM product internally or externally that goes through our team. So we do a code review of that before, you know, to identify flaws as well as, you know, penetration testing and, you know, just general guidance. They have, you know, a security process in place to sort of field those, you know, questions and they're working to add features, right? They're working to add two-factor auth and they're, you know, every time these things get brought up, somebody in the room, you know, sort of shouts, you know, code signing, well, that's good and that's, you know, that solves some of the threat, but it doesn't solve everything, right? It doesn't solve the typo condition and so they know about these things and they're juggling the, you know, the need to, you know, keep things going forward so that we continue to have the registry plus, you know, make things secure, performant, usable, you know, all those things. So I wanted to, you know, sort of get a soapbox and mention that as well because I don't think that gets talked about enough. And finally, I'm going to, you know, I'm going to talk about some of the stuff we're doing at the Node Security Project that you can do for your apps from a known security vulnerability, right? So, you know, I talked about your code and sort of the methodology that I used to, you know, that you can use to find, you know, problems in your old code, but, you know, what are some of the resources that you have from the Node Security Project? I think the first here, you know, is the advisories. You know, just some of those, you're going to go look through those. That's a great place to start too, to just familiarize yourself with some of the different flaws that we found in different vulnerability classes that, you know, technically savvy with some of those vulnerabilities. There's a lot of XSS across that scripting vulnerabilities here because we had an intern this summer churning through a list of 24,000 GitHub issues that were flagged with having potential security impact that were potential vulnerabilities that were reported to, they're reported and basically, you know, could have vulnerabilities. But now, just sort of going through those and validating and vetting those and getting those to the authors, so you'll see a lot more of those coming through. And she was basically focused quite heavily on SQL injection and cross-it scripting. And if you're not familiar with it, you can use NSP, so you're going to PMI NSP and just do NSP check. It will actually test your application for sort of known flaws, right? And so this is great to sort of add a simple, you know, it's got a couple of, you know, dependencies in there. And if we run NSP check, it'll, you know, sort of just dump those out and give us a link to more information and tell us, you know, here's the vulnerable versions, here's, you know, here's what's patched. And so you can update that. And that's great for, you know, you want a one-time check, things like that, but we've been working on making that platform a little bit better. So I'm going to talk about this now, is our NSP live, which is, you know, sort of our effort to, you know, on the one aspect to fund, to fund the project, right, to keep those vulnerabilities flowing. It's free for open source. And so you can just go hook up your GitHub repos and have them checked. And so what happens is we run that same NSP and NSP check process behind the scenes whenever you submit a pull request. Let's see, let's get into one of our private demo here. And so every time that you, you know, submit, every time you submit a pull request, right, it's going to tell you that you've got these vulnerabilities. And if we do, let's see, if we've got one, we have Knightly. So the other thing too is that with NSP check, the command line, if you just go wedge that into a Travis script or, you know, a Circle CI or something, and you you're reliant on that being checked when code is pushed. Sometimes advisors come out, but you'll have a stale repository, right? So we also check Knightly or Daily, right? We just check to make sure that you know, no new advisories have crept in that haven't been introduced into your project. You also can add exceptions, sort of just new, this is a cool bug. So you can add exceptions for vulnerabilities that, you know, let's say there's a vulnerability in Algify.js, it's probably not exploitable for your app and it's probably going to bug you and break your builds. And so you can add an exception for that right in the UI. In fact, let's let's see, I can probably push to this if this actually works. Passwords okay, so it's there. I don't know what I'm doing. This is where you watch a security guy try to code and it feels horribly this is something that our team is pretty darn proud of. Let's just do yeah, that's not good of private. All right, cool. Fair pull request. Let's hope this works. There's live demos that are unplanned to really work. As a side comment, if I try to leave for the next slide right now, I get an engine party live. You might want to consider a different name. Yeah, we've had the name for quite a while. We might reconsider the live part. Yes. That's a good point. So this is cool. This is where okay, so it finally finished. Basically, it said found four vulnerabilities, right? We've got details. Details are going to bring us into the app where you're going to see the different, you can go look at sort of the different here's details about this vulnerability. But the one thing that we've really worked hard on is the sort of how to fix, right? It's going to tell you the exact the exact minimum version you need to go to. No matter where that is in the tree. So if it's like really nested down, it'll tell you what top level dependency to bump to to fix that bulb, right? So it'll tell you, you know, this is for happy, but it would tell you, you know, some sub dependency would tell you bump happy to this version. And so you can either just mash the button to fix it or we can select all of them and then we can hit fix selected. And so it's going to retry it, but it's also going to it's going to push a commit onto there and rerun that. So hopefully your tests are going to run your security checks are going to run and that's one of our one of the newest features we pushed on there. So we're pretty proud of that. And other than that, let's see yeah, if you ever find a vulnerability particularly if you're a module author, you know, please, you know, self disclose, you know, let us know this this gets us into the hands of the community and let's let them know that there's a vulnerability that they need to update. You can also add deprecation warnings to your old versions. Yeah, there's a guy standing on a Lego sort of the standing on the shoulder of giants and that's really all the security babble that I have for you today and I hope that there's some questions and I can answer sort of anything that I can. Yeah, thanks. Sure. So what do you do about like there's like a lot of like starter packs or like pre built setups that don't really have control over the versions of things that they use. When you get a scan of your project let's say you built something that like wraps express or whatever, what do you is your own course to bother the original author there? Well, so that's not the only course. I mean, you could patch in your no modules and check in your no modules directory and there's tools to do that. I don't particularly agree with that approach because I don't know the behavior that that patches in inducing or introducing. You know, we tend to try to get module authors to fix the vulnerabilities, but you're right there's a problem of the dependence of that module getting things fixed. We're trying to figure out a way, a good way of doing notifications or some type of you know, hey you need a version bump, but we don't want to be we don't want to be annoying if we just go make some bot that just trolls around to get our repos and throws in a pull request or throws in an issue, that tends to get people pissed off. So we've been trying to figure out a way of opt in or some some way of doing that notification. Your best bet is to though get them to version bump that, right? Get them to get that new version in there. It's annoying too because sometimes those subdependencies or those, you know, you can add exceptions as well, right? Because sometimes those subdependencies just don't create a vulnerable situation for you because you may not be using that module in that certain way. It's kind of an annoying problem right now. The Gulp authors and maintainers are kind of dealing with that right now where there's a they get triggered on sort of this false positive where it's not really vulnerable they don't have a vulnerable situation but because it could be in some situations that advisory triggers and so it's kind of annoying, right? We're trying to solve that. If anyone has any good ideas please throw them in our general direction. Adam, what are your impressions of the Node.picture library that it sees in OpenSSL and OpenSSL? Not a crypto expert so I'm not a lawyer. I think most of that relies on OpenSSL. I think that they've done a good choice in selecting the good cypher suites and things like that to use as default but nothing's perfect and I think you'll see some things in this space coming soon but that's all I can say about that but so while I can say that I think I don't know I'm not a crypto expert but I do know that they've done a good job of picking the for us to sell of TLS the good cypher suites and things like that. It's the best answer I can give you. We talked a lot about the potential of malicious package updates. Is this actually an issue in practice so far and are there any means to detect those more or less automatically? Yeah, we've found we have found modules that open reverse shells. Those particular modules are not in registry anymore and we found though we found other modules that were non malicious but had 400 meg of credit card data and things like that so there is ways specifically the malicious ones there is ways to detect it. We're working on it through instrumentation through the standard practice of instrumentation and machine learning we will have a solution we're trying to solve it but it's really we can't scale with NPM the best solution is to audit all the crap that you're using which is a very very tedious process. We're trying to expose the audit efforts that we've done through a verified module program where we're very explicit that it doesn't mean that it's secure but it means that a human looked at it and did at least a thorough audit which is more confidence than just saying well this thing has no known vulnerabilities and it's so you're running against the clock on updates right because it's on a lot of sites yep it is an absolute nightmare to keep up with. It is an impossibility to keep up with so you know on the one hand like looking do you do any of your you know to start out we break it down from a subset or break it down to a subset we say does any of your modules actually use startup scripts there's a rather small percentage of modules in the registry that use startup scripts so if we say we're going to audit all of them well we just ignore anything that doesn't have startup scripts or insult scripts that becomes a more obtainable process from a human but yeah there's no current automated solution that I'm aware of and the startup script as soon as your modules loaded pretty much all of them yeah right you can hook require and do whatever you want really and that's the thought there the most obvious is you're in a backdoor your module your backdoor your startup scripts but and that's the behavior but yeah you can just backdoor your module yep and there's native modules right so you can have a native module that builds and introduces a small backdoor or something a lot easier to hide beginning to hide it not get a JavaScript was a lot easier to hide it and see obviously get it see so I think I think it's a real threat right if you're not something that actually is security sensitive and that you're not auditing that dependency tree we're having somebody audit that dependency tree I do think that there's potential for abuse but you know we've seen it it's been limited I've probably seen six modules in the course of six seven modules in the course of my experience with Node that have been actively delicious there might be other ones out there I'm specifically talking about ones that did something nefarious on startup run install how do you you've said you've found or we've found or we see how do you find stuff do you just like poke around the registry just randomly so if you could imagine a child in a sandbox and then picture me in that sandbox instead splashing around that would be about what it looks like and to be frank that's pretty much what we do so we started out as an example we found we found the MS vulnerability by taking all of the the modules in the registry parsing their AST sending any regular expressions that we found through a library by sub-stat called safe regex that gives you it's not perfect it's actually very false positive and that one says hey this one might be vulnerable and then we took we took those and put them in a list and then from there we took those and there's a java tool out there that further tells you that it's able to be vulnerable and we ran all of those through those and then we split that out into a list and said okay it might be vulnerable and then once we've confirmed that we have a vulnerable regular expression like the MS one we'll take that regular expression then and we'll create a job queue across all of the modules and say did we find this string anywhere else in the registry and sort of just keep doing it turn that over and over again right and then we have a job queue that we can push a button and audit all those modules or run jobs against that's sort of my methodology is I start with a pattern right I look for child process.exec and I look for an interesting pattern and then I I use wonderful tools like grep to say okay which ones use child process and which ones use exec and point those out and then I look at those and I say okay well here's 600 things I need to look through to get input from the user right and that's an interesting problem because you know is this module supposed to be used by web servers it's supposed to be used by some command line you know is it for CLI or something and then you have to look at the common case right so what we tend to do is if we're going to report an advisory we look at the common case and say is this commonly used in this way yes okay it's a vulnerable condition create an advisory otherwise we sort of just implement that warning and move on that's kind of my methodology anyway no security project advisory's list is it available in a machine readable format or is it just yeah if you hit api.notescurity.io slash advisories it'll dump out all that Jason we basically basically our constraints on there is you know you want to use it internally and digest it you want to build an open source tool on it cool you know you want to do something commercial like you know we'd love to sort of partner on that so we sort of like limit commercial use of it just you know or license that data we license that data a number of other tooling vendors that want to integrate that data basically so we can afford we've got seven people on the team we have three full time developers and so we try to you know keep the open source side of it that information basically always trickles downhill it always eventually gets into the community via the advisory list and a couple other information streams that we're working on making open I'd love a RSS feed yeah we do have so there is a notification feed we can do RSS there is a notification feed slack integration on the Node Security IO app so you can email or slack and what we're trying to do there instead of just having like this this fire hose of vulnerabilities which it currently is we're trying to have the notification options to say tell me in slack when there's an advisory that affects one of my projects or that's above a certain severity level or you know is do some of those combinations to make it a little more interesting than just a fire hose right now there's not a lot of feed so the fire like the fire hose isn't that bad but yeah that RSS feed is it was there it got killed when we retooled the project and we just haven't put it back so yeah do you have like elevated access into the MPM registry or is everything you're able to do just through huh yeah we're normal people when it comes to we have one repository that we have one communication channel that we share with MPM because we are a vendor and so we use that repository in that communication channel to collaborate but anything and we do have I guess private access to code repos just to do for request reviews for that private code but other than that like I don't have access to fastly right the CDN or I don't have access to production servers that would be a horrible idea but you know use it for good surely that would never be a problem hmm everyone has their price I'm just kidding did you um yeah I don't know nobody else is asking anything it was the liability to sleep oh there's one thing that I didn't mention in the presentation that I wanted to mention in that sort of in your code section of the best thing that you can do to make my job suck is to have good input validation we see this time and again with express apps having vulnerability where happy apps don't because happy apps have a good story for joy validation within the route handlers and express leaves that up to you to apply that validation again you know just being strict about okay this is an integer this is a string it's you know an email address it it makes my job horrible so I noticed that a lot of your examples used to happy is that just is that because and yet is like a happy shop or just because what you are with I like happy I have no bias against I mean we do and yet it's a happy shop we build stuff and happy there's no there's no question that but you can I have no problem with express I have no problem with restify I think that they both for their purpose they also their purpose right they're different patterns that work well for different teams right so I like happy I mean happy has a security true option you just turn that on you're good right I interrupted somebody sorry you're correct that you also work on lift security yep I'm the founder of lift so oh wow cool living the brand living the brand alright so I need any cross-fertilization there any lessons going one way or the other why don't you do it this way yeah so the note security team is made up of three developers from the and yet team and four researchers from the lift team so that's sort of the how that works our our research there's basically no boundary there other than we flow our advisories you know we as we do assessments for our clients as at lift you know we're auditing dependencies and things like that those end up flowing into the pipeline of advisories for the note security project right and then they trickle downhill right we don't just keep them in our back pocket for like you know secret oh days plus most of them are not that exciting anyway um and you know other than that we you know so as we audit things for you know npm or any client so that's how that works so are there any plans for like an npm transparency list something that actions on npm you get published do so people can view them and I can't speak to that um that would be pretty cool I think having that uh I definitely think that would be a fantastic feature and you should totally bug uh cj and uh lower the I mean those are things that we talk about and things that we can help influence internally and that's definitely something that you know is on our sort of like rah rah you know but we have to sort of pick and choose what we fight for as well because they only have so many resources right so that would be fantastic I don't know if we could actually do that externally I mean could we we've got kind of a feed but we don't see things like the registry reader added um that might be in the jason data you know that's provided in the registry we might be able to just kind of fire hose that and figure that out but I think that would be better to come from within it all did maybe like the uh specific authorities were building the transparency list yeah I mean I could see something being you know collaborative but technically they're paying us we're not an independent entity at this point right so like if we uh you know we're trying to be um you know but I could see them maybe do something with the foundation I don't know I think I think they could do a good enough job you know providing that data um any other thoughts questions I know I have a lot like it was all over the place I apologize it was good but all over uh transitions were horrible um any other questions you know you can always find me on the internet yell at me on twitter make sure to put the underscore under in there on twitter otherwise you're going to yell at the actor and it's really fun to for people to do that I think you actually quit twitter but yeah anyway any more questions nope alright well thank you very much Adam appreciate it awesome well have a good evening everyone you know thanks for the invite I uh uh appreciate it see ya