How to Exploit Real World Vulnerabilities


This workshop will lead you through installing and exploiting a number of intentionally vulnerable applications. The applications will use real-world packages with know vulnerabilities, including:

- Directory traversal
- Regular expression denial of service (ReDoS)
- Cross site scripting (XSS)
- Remote code execution (RCE)
- Arbitrary file overwrite (Zip Slip)
- These exploits exist in a number of applications, most of which you will need to install either locally or on a cloud instance.

You can do this workshop in 2 different flavours:

- Using the prepared Docker images OR
- Install everything on your local machine.


Hey guys, thank you for joining my session. We're gonna just an overview of what we're gonna 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 Noah, 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 slash Snyk slash exploit workshop. That's where the actual hands on session is going to be and fork our node.js 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 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 frustrated 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 application. So just the tip of the iceberg. And for those who, 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 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 transit of dependencies. So it's even the dependencies, we're not, 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 transit of dependencies. So here I have for an example of an open source package, duster s, 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, need to be aware of what we're bringing into our code. So we can use tools like sneak, which later on during the, the workshop itself, once we get to the hands on, we're actually going to create a login, like a user at sneak, 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 no questions. And that is why we need to be aware of the vulnerability. No questions. And that is why we need to be aware of it. So we can also see that open sources is heavily used, you know, there's 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's super useful for us. 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 a great bring 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? You 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 buzzword 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 dependencies 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. We're 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 the US, government is actually trying to 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 is in charge of the 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 to write in the chat, or maybe answer, what do you guys do when you 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. Wait, don't think about it that much. Most people don't. So that's totally fine. Cool. So, so yeah, so it really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it's really, it is a really 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, we're gonna use sneak 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. Um, have you guys forked the the repo. Did you get it to run. If anyone's having trouble with that let me know. Think 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. 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 for those dependencies. So we can scan them, it's another flag. My dog is right on cue. So let's assume you guys have the application running. It should look something like something like this. Yeah, so I can send the repo again. So, sneak checks for those open source vulnerabilities specifically, you know, no JS package manager npm. We look at the package dot 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 that I own. 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 while you guys do that I'm just going to explain how how it all works so once you get everything up, and you scan goof with sneak and get the vulnerabilities, the workshop is will have different tasks and I'll go over them soon, but for each task for example, you actually will for example we have direct reversal. And you need to hack using this vulnerability so you can actually look at sneak 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 you 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 we 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 for those who just got who side, 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 the, with a Docker, you would go. Yeah, it's you need to. Oh, you would just, you would just unzip it. Go to that file and then do Docker compose the exact say we're downloading it, and then these are the commands. Yep. Maybe later. Yeah, so these Docker load minus I sneak down to do goof.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 css, but you're not going to 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 a D issues in this app, where we see that a lot of them are high, and we have some critical as well. So, for those who have it up and running in our booth, 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 to know 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 it sneak as well. You can read about it, the issue we can see an overview of it. And then we can actually try to 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 different file, you would just go you know CD and then if I want to go backwards. I can do that. I want to go back to to make a quick workshop I'm going to go back to it. So the dot dot is really an option here. So if you go to to goof. You kind of try you know I'm doing the dot dot. Nothing really happens. Right. Um, so maybe just a browser issue so let's let's be real hackers and go to the command line. And I'm going to change 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. 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 results. So, for those who already got there, or those who haven't but still wanna wanna answer how can I bypass the dot dot the period. Over here. Any ideas. Yep, exactly. I'm not have to defend yet against it. We want to first hack and then defend. So, you're encoding, which does anyone know what they are. Exactly. Um, so we need to have those right now we're gonna go up one. So, be moved. Okay, what does that mean. We moved one, and we actually just do this. Curl instead of going back. You make key. And now we actually can, you know, we can go around and actually find things for example if I look at package JSON. 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 point five, 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. And I'm going to go back to the directory. And I'm going to go back to the directory. Exactly. So that's our next issue. And I am going to give you like five minutes to to go over it 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 hints 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 in 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 marked. 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 alert one because it sees the script and knows some sort of javascript and it just creates it as a string. And that's why we see it like this. So, let's, 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 sync UI, 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, the 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, it won't let you post it. So, we can be smart and maybe try again with some encodings and represent the semi colon and the 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 regex is also looking at javascript semi colon and javascript and sign pound sign 58. So, it's actually looking for all of this. It's saying, well, I know that's that's the representation of the semi colon 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. So, I'm adding this. So this trick. 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 saying, well this, the word this doesn't really match here, but they probably meant like it was probably a mistake and they, and they meant to have it without without this. So, in this specific use case, the browser is actually ignoring this, but the regex since there is this doesn't catch it. So the browser is actually the reason we're able to exploit it. And, actually, the problem with 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 document 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. 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. I'm going to try to get rid of this alert. Let's try that. I'm not sure actually, let's try this. Did not work. Yep, 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 issue 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. So, this issue is actually coming from my direct dependencies that are bringing it's called Ms, and Ms is actually bringing a transitive dependencies dependency called, forgot the exact name of it. Open over here. So yeah, okay so Ms is, is our direct dependencies. And this is actually brought in by my humanized Ms. So this specific issue that's brought in by a transitive dependency. So, we're gonna, again, be good hackers and go to the command line. And we're actually going to use that command. Use the Ms package and we're gonna, you know, we're just gonna, 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, that it finished and if I go over here and I refresh the page I see buy milk five minutes. Cool. So I'm going to do that again. So five. I'm going to write a lot of fives. See what happens. So I'm going to refresh my page again. Still works fine. So now, instead of manually writing all those fives. I'm actually gonna 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's a tiny bit of a delay between each one. So let's do the same thing and add another zero. Okay, so we were starting to see that delay. So I'm gonna do it with 1234 zeros. That's four. And. Okay, it's taking a bit longer. 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. Okay, 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 X 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 X. There is something that's called catastrophic backtracking, which is saying it's trying to look for a match. Okay, so what I did that caused the denial of service is that I actually changed 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 switched 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 an M. Great. I found an I. Great. All the way. I found any amazing last letter. Oh, no, it's not an S. What I do. So then it's it's starting to panic. The reg starts to panic. So it goes back and it really, really tries to find that match. So this is a smaller example in 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 looks for this is something like this. This is the amount of 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 38 steps and this is just five letters. So now it just really panics and tries to find that that match. And that's actually what's happening with that. Minutes with an A at the end instead of the 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? I can send it to you over here. I just it's on mine. It's a break. One on one dot com. I just like to for those who love reg excesses, 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 bend already, those specific issues. So each one, this is the mark we're looking for. So each one has, you know, it has, like, for example, Esty, 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 upgraded 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 Russell issue, 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. And of course, additional information like the common vulnerabilities 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 going to this vulnerability and what 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 to Russell over here by Adams. But I don't want to fix it right now. I just want to focus on on esteem. So I'm going to open a fixed PR. And I'll sneak behind the scenes is going to write a commit message and open a new branch for this issue. I take a little time. If I open my GitHub. And go to my Google app. You can see this. OK, so my Internet is a bit slow, but in general, once you open that fixed PR, 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 fix or not, the CVSS or what kind of issue it is. So this one actually is. It's now service one as well. But it's coming through my mind. 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. So we're making sure we're not adding any new vulnerabilities into this. Did anyone get to to try it out? Are you guys able to try to use the fix here? Anyone? Let me try to fix marked. I think it's an issue on my side. But once you fix some, if if you. If you do fix some, 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 knowing that I actually fixed the cross a 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, your source code repository to continue to continuously scan them and obviously know your sources. If you're bringing if you're bringing in new new dependencies, you can use sneaks, sneak 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 to really understand what you're bringing into your projects before you actually download the package. And, yeah, if you guys can use sneak for, you know, for free. We're here. And stay safe in your journey.
47 min
17 Nov, 2021

Watch more workshops on topic

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career