How to Exploit Real World Vulnerabilities

Hey, guys, thank you for joining my session. We're going to just an overview of what we're going to do. We're going to go over some slides just to understand open source, why it's awesome, how it saves us time and everything, and then we'll actually jump and actually hack an application. So let's get started.

My name is Noa. I'm a solution engineer at Snyk. And obviously, if you have any questions throughout the workshop, you have the question, the Q&A messaging system if you want to be kind of anonymous or you can ask me in the chat. I'll be looking there as well. And if you haven't already done so, please go to github.com slash Snyk slash exploit workshop, that's where the actual hands-on session is going to be and fork our Node.js booth app, which is going to be connected with the first repo.

Cool, so starting off, isn't open source awesome, saves us a lot of time, it gives us, you know, makes us less frustrated, we don't have to actually write the code ourselves sometimes, we can just bring it from outside. And just kind of a question to ponder upon, what is the future of open source software security? Is it going to be, are we going to have more open source, less open source, you know, because sometimes it can bring vulnerabilities, and we're going to touch that very soon.

So as developers, you know, we write code, we debug code, we get over the code, and obviously, we, we get excited over the code when we fix issues. However, the code we actually face every day is very small compared to applications. So it's just the tip of the iceberg. And for those who actually looked at the code, were you able to find any security issues. And this I'll give it a second, if anyone wants to try out. I'll send the workshop links over here in the chat. There we go. So exactly. Yeah, the inputs are not sanitized. And we kind of just send them straight without checking what it is first. So that's the security issue. Good job. Great.

So when we think of code, as we said, we just looked at the tip of the iceberg. But actually 80 to 90% of the code base is open source. And 80% of vulnerabilities are actually found in transitive dependencies. So it's even the dependencies we're not aware that are in our code. So let's say I bring a dependency. But I don't know what dependencies they're bringing in.

So 80% of vulnerabilities are in the transitive dependencies. So here I have for an example of an open source package, Dust.js LinkedIn. And I see that it has a vulnerability. So I may not know where the vulnerability is. But at least I should be aware of it. And that's where we need to, you know, we need to be aware of what we're bringing into our code.

So we can use tools like Snyk, which later on, during the workshop itself, once we get to the hands on, we're actually going to create a login, like a user at Snyk. So we can actually find vulnerabilities. And later on after we exploit it, we can actually fix them and prevent them from happening. So again, I don't know where the issue is, but I know there's an issue. And I know the version that I'm at in this, in this dependency and I know what I want to fix it to, to get rid of the issue.

So let's visualize this, I guess, in our, in our head, this is our application, right? You're working on an application, you write the code. So this may be what you guys are thinking of, you know, some lines of code. However, as we said, the picture is a lot larger. So our application is built on a lot more than just our custom code. And that is why. Sorry, no questions. And that is why we need to be aware of it.

So we can also see that open source is heavily used. There is new packages created by ecosystem per year. It just keeps growing and it doesn't stop. Because again, it saves us so much time. It saves us a lot of frustration and it is super useful for us. So so the fact that we're using open source is great and fantastic and it helps us. But we shouldn't be surprised, you know, when new vulnerabilities are being added to our projects. So open source is great, bringing in new vulnerabilities as well. So there's kind of this like, is it amazing? Or is it not amazing? So again, awareness is key here. So how well do you actually know what's inside your dependencies? How well do you know them? And there's actually a supply chain security issue in 2018. I know it happened again in 2019. And again, I think pretty much we hear of like one big deal every year.

And open source supply chain security is kind of always a buzz word in the security world. So what happened is that there was a package called event stream. And with like hundreds of thousands of people brought this dependency and used it and then the next version, they the next version they published actually had a deadly dependency, transitive dependencies that event stream brought in. So the people who updated, you know, upgraded their dependencies without looking at what they're bringing in, were actually becoming very vulnerable to this. And that is why when we bring something, we really need to be aware of those transitive dependencies, especially them, because, you know, we can't fully know we need to actually search and see what those dependencies are bringing in.

So open source has been a really hot topic, even the US government is actually trying to find some sort of solution, you know, we need to understand how this issue can be solved. So there's a cyberspace solarium commission who was in charge of those open source issues. And then going back to this question, that how much do you really know about your dependencies? So for anyone who wants to write in the chat or maybe answer, what do you guys do when you download a dependency that you want to use? Do you search? Is there any or do you just say, oh, I know this library, I'm going to download it without checking the version? I'm going to wait. Don't think about it that much. Most people don't. So that's totally fine. Cool. So it really is like there's no we have a limited OCA solution. Cool. Checking contributors is also really important. Awesome. Thanks guys for answering. That was awesome. So to understand what's inside our code. So obviously the community to check how many contributing developers are there. You know if it's one and if it's one person we can't be too sure about it. So Snyk actually has an advisor. So the Snyk advisory. I'm sure if you guys are using something else that's fine too. This is what it would look like for example we have the package moment and over here we check the popularity. So how many downloads it has. You know so it has a lot of downloads means people are using it. It's great. So it's bringing up the package health score maintenance for example if it's not maintained you shouldn't use it just because if an issue is found no one's going to fix it later on in term of security. If it has vulnerabilities you know sometimes moment doesn't have vulnerabilities but it's using another dependency that does have vulnerabilities which will make moments vulnerable.

And lastly community really understanding like those contributors to the open source repo. So really got to check all of those. And again touching that the vulnerability is coming from direct dependencies versus indirect dependencies. I know this is a Node.js conference so NPM is actually very let's say if this was a contest it would be winning the most vulnerable indirect dependencies in the game. So we really because open source is such a big deal now. You know we have to have tools that even automate to keep updated. For example a new version came up and we found out that the old version is vulnerable. We need to have some tool that can even automate those upgrades. So we're actually going to use this today and we're gonna use Snyk and you can see how you can use it to upgrade it.

So I know this is like the fun part. So let's get started on that on that application. Have you guys forked the the repo? Did you get it to run? If anyone is having trouble, let me know. I'll give like two minutes for you guys to set it up and then we can I'll explain how it's going to go.

Yeah, so actually, we scan normal dependencies. The dev dependencies, we can scan them, but we need to add a flag for it, just because we know that sometimes we don't really care for those dependencies. So, we can scan them. It's another flag in the scan. Excuse me. My dog is right on cue. Cool. So, I'm going to assume you guys have the application running. It should look something like…something like this. Yeah, so…can you send the…yeah, I can send the repo again. So, sneak checks for those open source vulnerabilities. Specifically, you know, NodeJS, the Package Manager MPM. We look at the package.json file, and we look at the dependencies over there. And then, we actually run those against our database. And then, according to what you have in your project and the version, we actually give you…we tell you which ones are vulnerable and if you can actually fix them with an upgrade, for example. So, for those who do have the app running, you can go to sneak.io. Definitely gonna send it here as well.

We have a free version that you guys can use. No need to add your credit cards like some companies. You can use it for free and you can actually integrate with your GitHub account or wherever you, if it's Bitbucket, or anywhere else. And you can actually scan it. And then you will, after a few seconds, you will get the vulnerabilities. And I guess while you guys do that, I'm just going to explain how it'll work.

So, once you get everything up and you scan Goof with Snyk and get the vulnerabilities, the workshop is, we'll have different tasks, and I'll go over them soon. But for each task, for example, you actually will, for example, we have direct traversal. And you need to hack using this vulnerability. So, you can actually look at Snyk to understand what the vulnerability is. And then you'll get hints of steps of how to do this. I mean, if you know how to do it, amazing. Can even go straight to the last one. But I think it's better if we do step by step. And I think the best way to do it is once, like, we give like 10 minutes for each one. Go over the solution together, and go to the next one.

So, the first issue we're tackling, let's imagine, I mean, I'm pretty sure for those who just got, who saw it, and for those who didn't, imagine someone changed the context of your application. So, that's something that can happen with directory traversal, and that's actually the first challenge. So, with a Docker, you would go, sorry, yeah, you need to, oh, you would just unzip it, go to that file, and then do docker compose, the exact, so I would download it, and then these are the commands, yep, maybe later, yeah, so these, docker load, minus i snkdemo2goof.tar, and then, also the mongo, and then docker-compose-up, great, so for those who have the project up, over here, and you can actually write, you know, hello, it's a to-do app, it's great, we can go to the about page, the bestest to-do app ever, I mean, if you really want, you can play with the, the CSS, but you're not gonna get very far, our team will not, accept those PRs, so going back to my to-do, I have hello, I can remove it, and play around with it, and then in terms of sneak, once you've scanned it, you can actually see, our super, super, super vulnerable app, we actually have 88 issues in this app, where we see that, a lot of them are high, and we have some critical as well. Cool. So, for those who have it up and running, in our goof, start playing around with it, and then, as we said, our first issue, is a denial of service issue, so we will go, sorry, I didn't mean denial of service directory, traversal, and it's going to take us over here, we can actually read about it, this is a screenshot that you can find at SYNC as well, you can read about it, the issue, we can see an overview of it, and then we can actually try to exploit this vulnerability. Directory traversal. Most, how would you, you know, when you think of, especially in the command-line, right, when we go to a different file, we would just go, you know, cd, and then if I want to go backwards, I can do that. If I want to go back to my Goof workshop, I'm going to go back to it. So the dot-dot is really an option here. So if you go to Goof, we kind of try, you know, doing the dot-dot, nothing really happens, right? So maybe it's just a browser issue. So let's be real hackers and go to the command-line. And I'm going to cheat a little just because I'm too lazy to write out the website, so I'm going to copy it. I actually want to see if I can get the website's content over here. Okay, so I got the about.html content here.

So now I'm going to try to do the same or maybe go up you know, one directory. And I'm getting something strange over here. You know, the best kind of the goof to do which is the main page. So let me try to do one more. Go up one more directory. And I'm actually getting the same result. So for those who already got there or those who haven't but still want to answer how can I bypass the dot-dot period over here. Any ideas? Yep, exactly. Not how to defend yet against it. We want to first hack and then defend. So URL encoding, which does anyone know what they are? What are the URL encodings for periods? Yep, exactly. So we need two of those, right? Now we are going to go up one. So be moved, okay, what does that mean? We moved one and we actually, let's just do this. Oh, one second. Curl, instead of going back key by key. Okay, so we moved back from public. And now we can go around and actually find things. For example, if I look at package.json, I can actually see all the dependencies that are in this project. And by knowing the dependencies in this project, I can actually find where those vulnerabilities are. Right. So, for example, I'm not kind of spoilers, but marked is the next exercise that we will exploit. So, actually, by knowing that they're using mark 0.3.5, we know it's vulnerable and we know that we can exploit it. So the directory traversal actually lets me get to places that I shouldn't get to. And, for example, if they even have like right permission, I can override files and, you know, get passwords and usernames and really confidential stuff if needed. So I'm going to clear this. And we're going to go back to here, present. I'm going to give you the next scenario, and you guys are going to tell me what issue that could possibly be. So if one of your users was given a malicious link by your website, what would have like, what is that? How would that happen? Cross site scripting. Exactly. So that's our next issue.

And I'm going to give you like five minutes to to go over it again. Again, all the steps are here. You can go to the next one.

This. Up next one is this one. Cross-site scripting. I kind of skipped one and we're going to go back to it. So cross-site scripting. And you have over here. Explanation. What cross-site scripting is. And of course, the hint. How to hack this.

So I'm going to give you five minutes and we will go over the solution. So if there's no volunteers, I'm going to go over the solution. So in a simple way that when we think of cross-site scripting, we actually think of, you know, adding and JavaScript script. So using something like this, and I'm not typing it out just because when I click on it, you'll see all the answers. So we're going to do it step by step.

So for example, if I try using scripts and add like some sort of an alert, nothing is going to happen. And the reason for this is that when this application was built, it's using the package. So if we actually, we can play around and, you know, make it bold and beautiful. And that's actually coming from this. We see Mark over here. And we're actually using a sanitizer for Mark. And that sanitizer is looking for some specific things about JavaScript. So, for example, it sees the script, alert1. Because it sees the script, it knows some sort of JavaScript and it just creates it as a string. And that's why we see it like this. So, if we read about Markdown and what it actually lets us do, we can actually use Markdown links. And those Markdown links are being used like this, for example.

And if I do it, I can click on it and it's going to take me to the syncUI, which is cool. And if I go, like, let's say I want something else. So I can actually do something that looks like this maybe. If I try that, you know, I have my JavaScript alert over here and my bad link. And I'm praying that it's going to work. Okay, but it still didn't work. And the reason for this is that Mark sanitizer is looking for this JavaScript word, you know JavaScript, and then the colon. So, it has regex behind the scenes that is actually looking for this and if it matches it won't let you won't let you post it. So we can be smart, and maybe try again with some encodings, and represent the semi colon bracket, like this. So, hopeful again that this will work. Okay, so this didn't work as well. And the reason for that is same concept, the reg x is also looking at JavaScript semi colon, and JavaScript and sign, hound sign, 58, so it's actually looking for all of this. And it's saying, well, I know that's that's the representation of the semico of a colon, so I'm not going to let that pass as well. So, thinking again thinking again. Okay, what if I add this. Adding this. So this trick. Actually works. Does anyone know the reason why this works for us. So, in a way, specifically this is used to confuse the browser. So the browser is saying, well this, the word this doesn't really match here, but they probably meant like it was probably a mistake and they meant to have it without this. So in this specific use case, the browser is actually ignoring this, but the regex since there is a this doesn't catch it. So the browser is actually the reason we're able to exploit it.

And actually another issue with open source community is that no one is really responsible for anything. And if I go over here, this was actually an issue that was brought up specifically that if we use documents or this, it's going to cause a cross-site scripting issue. And this was brought up September 2015. Sorry, May 2015. And it was actually closed a year later. So in terms of using open source, you know, there's no responsibilities. It's just a community that does it. And if the community doesn't maintain it, it could be exploitable.

Instead of this alert. Let's try that. I'm not sure actually. Let's try. This. Delete. Nope, did not work. If I'm sending the GitHub link. Cool so that was prostate scripting. Go.

And now Another case for you. So, it's Christmas time and you own a very nice sweater shop, and people want to buy to shop online, and something's blocking the user from getting onto your site. What is it could this be. Very denial. Yep. Denial of service. So, again, same concept. We have, we have the steps over here. And I want you to create some, you know, use the command line use whatever you need and kind of block your website freeze it. This issue is actually coming from my direct dependencies that are bringing. It's called M.S. and M.S.

is actually bringing a transitive dependencies dependency called I got the exact name of it. Have an open over here. So yeah ok. So M.S. is their direct dependencies and this is actually brought in by my humanized M.S. So this specific issue that's brought in by transitive dependency.

So we're going to again be good hackers and go to the command line and we're actually going to use that command. Use the M.S. package and we're going to you know we're just going to you want to add another another thing in my to do list I want to buy milk in five minutes. I'm going to enter that and we see that the finished and if I go over here and I refresh the page I see my milk five minutes. Cool.

So I'm going to do that again. So five right a lot of fives. Let's see what happens. OK. I'm going to refresh my page again. Still works fine. So now instead of manually writing all those fives I'm actually going to use this command which prints fives a lot of times. So I'm going to do that. And we see we're starting to see that there is a tiny bit of a delay between each one. So let's do the same thing and add another zero. OK, so we were starting to see that delay So I'm going to do it with one, two, three, four zeros. That's four. Yes, I'm blind. Yep. Four zeros. And. OK, it's taking a bit longer and I want to remove stuff and add things. Adding my name a lot of times and nothing is really happening. So behind the scenes, something that's called catastrophic backtracking is.

Sorry, I completely forgot that. I actually. OK, apologies for this. I skipped a step in my explanation and I totally forgot. So what happens here in this specific package is that we're looking for some kind of number. And then with using reg ex and then using and then looking for the word minutes or hours or anything like that, really. So. This is what we're looking for now in reg ex.

There is something that's called catastrophic backtracking, which is saying. It's it's trying to look for a match. OK, so what I did that caused the denial of service is that I actually change the S at the end. To an A. So if we go back to my the last command that I ran, you see over here, I switch to the S to an A. And that's the reason that causes the catastrophic backtracking. So what it does, it's looking, you know, it's it's going through all those numbers, you know, like a lot of fives looking through all of them finally gets. It's like, OK, I found in them. Great. I found an I. Great. All the way. I found an amazing last letter. Oh, no, it's not an S. What I do. So then it's it's starting to panic. The record starts to panic. So it goes back and it really, really tries to find that match. So this is a smaller example and a smaller scale because we don't have time to go for hundreds of examples.

So this example, we have a and then B or C plus. So a lot of C's, at least one C needs to be there. And then all of this expression needs to happen at least once and then it has to have a D at the end.

So the way it would look for this is something like this. This is steps. OK. Now, if we remove the D over here and we actually change it to something else. We can see it from nine steps. It jumped to thirty eight steps and this is just five letters. So now it just really panics and tries to find back that match. And that's actually what's happening with that minutes with an A at the end instead of S.

So now we see that after the time passed, it did eventually add all my Noah's. And milk. Any questions about this? Did that make sense? I'm sorry. Totally skip that super important step.

Cool so so now that we actually exploited. How do we get that right to see but I can send it to you over here. I just it's online it's a breaks one on one calm. I just like to, for those who love reg x this is a really nice website to to find matches and all that. Almost like Tinder. Just kidding. So now we have you know we exploited. We exploited the application now we actually want to fix it. So if you if you go to sneak and actually have them all been already those specific issues. So each one. This is the mark we're looking for. So each one has you know it has for example SD the first issue we we we exploited. So we can actually see all this information about it. We see that where it's introduced from from version zero point two point four and where it's fixed. So if we upgrade it only you know zero point zero one version up it's not vulnerable anymore. And actually if you want to learn more about this directory to results you there is a whole learning module that you can do over here that really teaches you kind of hands on what this issue is even though we just did it. So you guys are all experts now. And also, kind of an overview of what this issue is.

So it would prevent for for this to happen you won't be able to deal with it. So of course, additional information like the common vulnerability scoring system you know which is an industry standard and of course, if you want to learn more about this specific library then you can read it all about over here. So with an easy, you know, click of a button.

I'm just gonna access vulnerability. But it's going to do it's going to now take me to a page where I can add if I want to fix more vulnerabilities, for example, I have a directory traversal over here by Adam's if. But I don't want to fix it right now I just want to focus on on St. So I'm going to open a fixed PR.

Now sneak behind the scenes going to write a commit message and open a new branch for this issue. Take a little time. I open my github and go to my goof app. I can see it isn't this one. OK, so my Internet is a bit slow. But in general, once you open that fixed PR, it's going to look like this. It's going to look like this. And you're actually have you're going to have that commit message with all the information about this issue. If it has a fixed or not the CBS or what kind of issue it is. So this one actually is an out of service one as well. But it's coming through mime it's a different issue.

So in addition to that, sneak will actually run additional tests on your on this branch to make sure that you're not adding any new vulnerabilities into your application. Because we have some sort of, you know, beginning phase where we just want to clean our application from vulnerabilities rather than adding new ones. So we're actually making sure that we're not adding any open source security issues, any license issues, and any static code analysis issues on the free plan, I believe that you will only see this one. So we're making sure we're not adding any new vulnerabilities into this. Did anyone get to try it out? Were you guys able to try to use the fixed PR? Anyone? Let me try to fix marked. I think it's maybe an issue on my side. But once you fix them, you can run your application again. After you obviously rebuild it. And once you do that, try to hack it again. Try to exploit the application again. And see that the version really matters. So in that terms here.

There we go. So we got marked. So we're able to do a pull request for mark and we actually upgraded a version. And we see that all checks passed. Great. And I can actually merge it and knowing that actually fixed the cross site scripting issue. So now when I when I merge it and rerun my application, I won't be able to exploit it using the marked library. So wasn't that fun, guys? What can you do about this?

So takeaways for today's session is connect your source code repository to continue to continuously scan them. And obviously know your sources. If you're bringing in new dependencies, you can use Snyk advisory to check them out before. That way you'll know which version is vulnerable, which one you're waiting for the test to pass. Awesome. So you can use advisory to really understand what you're bringing into your projects before you actually download the package. And, yeah, if you guys can use Snyk for, you know, for free. Right here.