 Hello and thank you all for coming. My name is Danny and I'm a co-founder and responsible for security at SNCC. We are a startup based here in Tel Aviv and in London and we're building security tools for developers to help them use open-source security. In my past I've been working in a bunch of different startups doing security and development work and most recently as a CTO and a security consulting company and focusing on research and crypto analysis and by now doing security research at work I do that for fun. I really enjoyed playing capture the flag games with my team as then and we had the honor to win the last CCC and Google capture the flag competitions last year. So I want to open up by saying that open-source is awesome and as a result its usage has exploded. So when we look at the different languages and then package managers of this we see these huge numbers of published packages with more than 100 packages 100,000 packages on Ruby Jams and PyPy, 200,000 packages on Java's Maven and leading them all NPM with more than half a million packages JavaScript packages that are mostly used in Node.js application and front-end JavaScript. So just last week more than 3 billion packages that's billion packages were downloaded from NPM alone. These are staggering numbers and they are keep on growing in an insane pace. So a typical application nowadays has somewhere between 100 to 1000 dependencies. Some of them are direct dependencies these dependencies that we bring in by choice we we pull them in but the majority of them are actually indirect ones those that are we pull in in an asted way by the direct dependencies going deeper. So it leads to a situation where this is our code the actual code we wrote and this is our app and the orange part here are the dependencies that we pulled in and this is actually a positive slide right because we can we can create all this orangeish value by focusing only on the core of our application. So with that of course comes a security risk. Do we even know what dependencies we use in our applications? Do we know if the developers of these dependencies of these packages had any security expertise? And most importantly do we know whether these dependencies has any known security vulnerabilities? Clearly this is a big risk and that's why using components with no known vulnerability is vulnerabilities is on the list of always top 10 most critical types of vulnerabilities. So now let's see three examples three recent examples of vulnerabilities and types of vulnerabilities and that affect open-source packages and later we will look into how we can prevent this. So let's start with Apache struts this is who here heard about the Apache struts vulnerability? Okay I see like half of the audience have heard. So Apache struts is a critical severity remote code execution vulnerability it was found and fixed in March this year but it got all over the news again in September when Equifox one of the biggest credit reporting agencies announced that they got breached and as a result 143 million customer records were exposed that's nearly half of the US population. So the vulnerability is actually very easy to exploit there is no authentication needed all the attacker that needs to do is send a single HTTP post request to the web application and instead of sending this the expected the standard and content types what the attacker does is basically sends an ONGL expression. ONGL stands from object graph navigation language it's an expression language for getting and setting properties in Java objects and it's actually a very rich language we can do all sorts of stuff with that. So in the code one of the parsers the one that handles file uploads when it sees this content length and this content is illegal in valid so there is an exception from and this is the part of the code that handles this exception we see that a function called built error message is called where the exception is passed as an argument and that message that exception contains our malicious ONGL code. So then inside the built error message we see that another function is called this is that find text function and this that's the point where the vulnerability is triggered that function the find text function is actually evaluating it's a non-functionality that you might want it's evaluates ONGL expressions so basically what happened is that in an attempt to generate a meaningful error message we ended up evaluating ONGL as an expression ONGL script. So this is the full payload what's interesting about this is basically what all it does is is create this process builder class which is a Java class to execute shell commands and just for that in the end it will be able to run any any shell commands so that's that was the Apache structs remote code execution vulnerability. What's interesting to see is the timeline this vulnerability was actually responsibly disclosed by Chinese researcher to Apache in earlier this year before a merge that all we know and on the 6th of merge Apache released the fixed they fixed the vulnerability they went out with a public announcement and two releases two minor releases were sorry two major releases were created and less than one day after the release we've seen exploits exploits script appearing both on github on exploit db on metasploits so less than one day and that's exactly when attacks were we're seen in the in the while exploiting this vulnerability then on May 13 it's more than it's about two months more than two months and until the end of July and that's when the aquifox bridge happened so that they didn't know exactly what going on even in the end of that period they just brought the servers down and that's when they brought in Mandiant Labs to investigate this breach and in September beginning of September they went out with a public announcement so the story here is that a normal ability that had a fix in in this in the 6th of merge was wasn't fixed wasn't addressed during all this period for more than four and a half month so that was a normal ability in Apache struts now let's look in another example these are malicious packages and so in August this year few months back 40 and malicious packages were found on npm and one month later same thing happened this time affecting violent packages so in both cases a technique called typosquoting was used to basically lure developers to install malicious packages and during their work so just like in the original typosquoting attacks for the main names and where the attacker would register a similar looking domain name for the original side this case in this case Google same thing happens for for malicious packages so this is an npm package cross dash and it's a simple package that basically helps you set and get environment variables and across different operating system and this is the legitimate package cross cross dash and but the malicious package appeared that was named cross and which is actually in a way more intuitive it's like it on npm you don't see much like you see more packages that has no dashes than those that do so very easy to do a mistake here so again this is one is the legitimate other than malicious same happened for jquery there was a package named jquery.js and if you look at the package JSON file of that malicious package we see that the name of the packages crass cross and but what it does is actually brings the original the legit cross and dependency so basically providing the new functionality for the developer and actually they were nice enough to credit the original author with the release but in addition we see this this line that I'm not sure you can see clearly but the post install no package setup thing this is a post install book basically this is a command to be a shell command to be executed as soon as the installation of the package is complete so looking at that script we see that what it does is collects all the environment variables and base 64 and codes them and just sends them in a simple post request to the to the attackers server so the idea here is to basically leak environment variables which might contain some credentials and authentication tokens both on the developers machine but I think more importantly on the build systems the Jenkins Travis machines were almost certainly you have some sort of credentials some sort of secrets that are used to pull the code from from source repositories or deploy the code to your servers Amazon or Google so that was malicious packages and the last example is has to do with no and no GS buffer implementation so no GS buffer it's a it's a simple data type it's a buffer and it has a bunch of different constructors one is from a string and this one is simple you just provide a string and it creates a buffer initializing that buffer with the provided string nothing fancy the other one he receives an integer basically a size so what you would expect if you generate a buffer with the length of 10 you would expect to see a nice clean buffer like so but what actually happens is that you get the buffer of length 10 but it contains some some data it's not zeroed out like we've seen in the previous example so first of all why why does it happen this is not about this is documented behavior and this is something that we typically see in in a lower level languages like C and C++ but definitely not expecting to see that on in JavaScript so the reason it happens is basically for performance when you ask to allocate a buffer usually the next thing you do is populate that buffer with some data so here the Node.js runtime basically trying to save some time and gives the responsibility of initializing the buffer to the developer because again like why initialize the buffer when the next thing you will do is copy that buffer with the data into that buffer and this data is basically previously used memory of the process that's what we've seen so this is again documented behavior and and this one thing this one behavior weird unexpected behavior in JavaScript in Node.js caused many many vulnerabilities in many NPM packages these are memory exposure vulnerabilities and sort of similar to Heardbleed and this is just a partial list of those vulnerabilities and for sake of this presentation I want to focus on one such example and this is the Mongoose package. Mongoose is a very popular NPM package for working with MongoDB database so let me now switch to the terminal in the browser and show you the display relay so all right just make it bigger okay so this is can you see that well okay so this is our our to-do app it's a demo application we can add some items like a good to-do app it lets us add items so I'll write bike meal by mimp here hopefully the Python holds okay so okay so whatever and just to look at it so okay so every to-do item here is stored in Mongo database MongoDB so the schema for for this item for to-do item is basically this we see that every to-do item is stored in a buffer and it has another field the date it got updated that's all hopefully you can see that yeah so that's all we know so now and as an attacker what I would want to do is somehow provide a number here right like send this number so that on the server side a buffer will be created but using the integer constructor not the stream here it didn't work I provided the number right but it was added as a string so let's try to see if we can if we can somehow send this value as a number and and see if we can click some memory from the server so I'll switch to a terminal here and what we'll do is begin with just sending a regular post request so I'll say fix bike I'll pipe it to the HTTP utility form let me just copy the URL this is the create endpoint and do that so we see that we submitted the post fix bike and if we refresh here we see that either so nothing nothing happened yet but this being an OGS application that uses a library called body parser we can submit the same request as Jason okay so this was an content type application form URL and code but if we change do the same thing and but send the string as Jason we then can manipulate the time so let me just show you if I switch it into a Jason thing this is let's make it a J bike and this and here we change the Jason so we see that this time we send this as Jason the content type with application Jason and if we look at our application indeed the item was added but the cool part is with Jason we can control the type so we can send this notice as a stream but do something like that and sending and we already can see that something different happened and when we go back to the application we see this so we cause to create a buffer to construct a buffer from an integer and again this is the way node behaves it just uses shows you uninitialized previously used memory and in that process and the cool part is that if we do that and we can basically just show and the return that the result then what the value that and of the item that is added and base 64 decode that so we see the memory coming we actually see some strings here this is might be part of the of the source code let's repeat that for say 100 times and pipe it into time man dump and in a different okay I need to do that I should have done that with them double things to it to a pen to a file yeah live demos so again let's do it like that and here let's tail man dump and yes so what we'll see is is the this is real memory coming from heroku servers from the node process of heroku servers and of course well first we can see some some actual recognizable string if we if we see here we see some string prototype thing this is parts of source code and but of course this memory can contain keys and anything as anything sensitive that the application holds okay so that was buffer let me just switch back to the presentation five minutes all right perfect cool so yeah that that application is also on on on the github you're welcome to look at it it basically shows different vulnerabilities coming from dependencies you can you can pull in into your application not having to do anything with the code you write yourself so now the question is we've seen this three real-life examples from recent vulnerabilities cv vulnerabilities and now let's see what we can do to protect ourselves so when it comes to dependencies basically there are two things two steps first is we want to bring our applications to a good healthy secure state we want to scan all the application find the normal abilities in the dependencies and then of course fix them by upgrading and upgrading the way to a non-voluntary version or when when it's not possible to patch this so after the first two steps we come to a point where our applications are in a secure state but now we need to make sure to so to prevent introducing new vulnerabilities to our code so this is something we we can do as part of our we should do continuously as part of our test security testing in CIA in in building systems and the idea here is for to look for every changes that the developers may make to look for the added dependencies during those changes and see if they introduce any normal abilities and lastly even when we don't change the code we would want to know about newly published newly disclosed vulnerabilities that affect our application so that's the last part the respond part and this is exactly where aquifax missed right because because they probably didn't change the code it was just a deployed application that was out there and one day there was this high severity vulnerability published so they didn't know well I don't know exactly what happened there but anyway there was a four month window of being exposed and not addressing this issue so the good news is that it all can be automated when we look at our dependencies this all the tests all the all the things I mentioned before this should be all completely automatic and there are tools there are different tools to do that a good place to start is is also dependency check it can help you find normal abilities no CDE vulnerabilities in your code and of course you're more than welcome to try sneak out it is also free for open source so that is that this year I think I have few minutes for questions right yeah and any questions yeah so at the moment well first there there is the tool tools that I mentioned so those typically you deal with high-level libraries okay and compile libraries you mean languages like C or or libraries that are for example bundled libraries so many of the libraries on npm have inside some compiled code like and binaries so again this is more challenging definitely that's it more challenging none of the tools I mentioned actually provides a solution for that and that's that's something that I can layer we'd love to to mention to talk about some tools that I know but there is no perfect solution at the moment certainly the tools I mentioned are better working for for higher-level languages because that's where you actually have the manifest files that you can traverse all the dependencies deeper right and yeah more questions oh so type of scoring and basically as soon as we've seen those malicious packages we just added them to our database so that's the idea basically this packages became kind of like packages with vulnerability right and those who use them and actually have them again haven't changed their code just have them as part of their dependencies somewhere deep were alerted and fixed pull request was open so very different and alerting methods that we do to help you know thank you