Well, it's another great day here in the INFOSEC Skills learning path, we're talking about the 2021 OWASP Top Ten. And this video is risk number six, vulnerable and outdated components, so let's hop into this thing and see what's going on. All right, to start off, we're going to talk about a vulnerability, what is a vulnerability? You can see here from the common vulnerabilities and exposures, the CVE, which we've talked about many times in the previous videos. Vulnerability is a weakness in the computational logic, the code, found in software and hardware components. That whenever it's exploited, it results in a negative impact to the CIA triad, confidentiality, integrity availability, right? And then mitigations of the vulnerability in this context involved code changes, but they could also include specification changes, specification deprecation zones, like removing affected protocols, that kind of thing. So the vulnerability, may be simpler stated, it's just a weakness, it's a way that that you can get after something, it's a way that code in this case, has a soft spot in it, sort of a thing. And so when you talk about a vulnerability, just because you have a vulnerability doesn't necessarily mean that you're going to be attacked via that vulnerability. And that's where the exploit comes in, so what attackers will do is, let's say you have an application that has a vulnerability in its code. And then, they'll figure out, okay, hey, if I do, xyz actions, then I can exploit that vulnerability, I can take advantage of that weakness. And I can get into that application, or I can make that application do something that it was not designed to do, or hat it's not supposed to do, right? So anyway, so when we talk about this security risk, then it's good to know the term vulnerability and what we mean by that. Okay, so let's look really quick here at the factors, this is an interesting one, because there was only three CWEs mapped to this specific security risk. And you can see there the incidence rate, and the max and the average is not that high, especially compared to other ones that we've looked at in the past. And then the exploits of, yeah, the average weight of exploiting the average weighted impact, are right at five. And in fact, those were there because, if you look all the way right there, where actually no CVEs' tied to the CWEs. And so the OWASP organization, the group that did all this stuff, they said, hey, we're going to just give it a default five for exploit on impact score, just to give it a score, right? And then you can see the coverage, the actual applications that were tested against those CWEs, 51.78 was the max and the average was 22, just over 22. Then there was 30,457 total occurrences of these CWEs, based on all of the applications that were tested. So, this is one that by the numbers, it's like, hey, why is it, it's obviously not ranking as high, right? Now 30,000 occurrences is a big number, but remember there were a total of 500,000, just over 500,000 applications tested. So it's not a huge number, like what we've seen on some of these other ones where it's 250, 300, 1000 plus occurrences on some of these other exploits. So anyway, that's a breakdown of the factors for this specific risk, and I just wanted to kind of highlight those, and show you where this falls from the data collection and all that standpoint. Okay, so when we talk about a web application, we talked about vulnerable outdated components, that kind of thing. When you think about a web application itself, just look at this, www.example.com. You type that into your internet browser and hit go, and you're going to see a page that has maybe a log in, a password field, or maybe it's some kind of a transaction that you can interact with the page. Or maybe you are going to transfer money, or maybe you're going to upload a document, or you're going to do any number of things, right. Well, the truth is that on the backend of that website, of what that application is, there are multiple components and libraries. Operating systems, APIs, all kinds of stuff on the backend, that make that thing do what it does, right? And so if you just look here, I just made a little bit of a list, let's just say that in this example application, that it includes different Java libraries. That the code relies on let's say that there's .NET libraries, let's say that it was built using Apache Struts Framework. Let's say it has a MySQL database and then it's got its operating system, whatever that is that's running the web, or the application server. There's a variety of APIs, there's all these different components, and I put in parentheses up there for the specific ones like Java and .NET, Apache, and MySQL. I looked up in the in the CVE and the CVE database, the CVE website just recently and I just typed in Java, and .NET, and Apache and MySQL. And you can see how many CVEs there are, associated with those different components, right? And so that's a lot of vulnerabilities that exist for those different libraries or frameworks or databases, that kind of thing. And so, whenever you talk about building an application and using components that are vulnerable or that are outdated, then this is what we're getting at, this is what we're talking about. And to be fair as well, it's virtually impossible, I would say it is impossible frankly, to build an application that has absolutely no vulnerable components to it, I mean, it's going to happen. And so, when we talk about protecting yourself against this, there's a bit of a, hey, we just need to manage the risk here a little bit. We need to understand what we've done when we built this application, and we just need to be aware of the vulnerabilities that are out there. That we might be exposed to, and so we need to try to mitigate those as much as we can, right? Okay, so I just wanted to highlight that, that again, when you think about a web application, it's more than just, you type in the web address, and then all of a sudden some kind of page pops up. Or you navigate to a variety of pages within that application, there's all these different components that are used in order to build that application, and those components of what we're talking about. So okay, let's just talk for a quick second about CVE, this is the common vulnerabilities and exposures, I know we've talked about this. Especially as we've gone through the factors of these different security risk along the way. But this one right here, I just typed in Apache Struts for example, and you can see there, that there are 81 CVE entries that match the search. And in fact, if you look kind of up there to the top right, it says total CVE entries, there's 123,153, that's a lot of vulnerabilities for. That's their entire database, right. It's not just Apache Struts, but Apache Struts, you can see here has a lot of different CVEs, that are listed in in this CVEs database. And the CVE, I think I've mentioned this in previous videos as well, but the CVE database is managed by an organization named Mitre and M-I-T-R-E, Mitre. Those professionals look at all the different vulnerabilities and exposures to different libraries and frameworks and operating systems and all kinds of software. And they keep a database of all of that, right. And so whenever, let's, we'll just use this Apache Struts for example, let's say that. And for a number of reasons, maybe the Apache Struts team, security team is doing some sort of code review and they figure out, hey, during this review, we found a problem in our code. We found a vulnerability in our code, we meant for it to do this one thing, but it can do, you can take advantage of it and you can make it do something else. And some problems are really significant where you can take over a machine and conduct remote code execution, things like that. And so those are really big problems and then there's other vulnerabilities that are like, I mean it is a vulnerability, but it's not going to be this devastating thing, right. And so that gets to some of that impact score, right. Versus the, and also how easy is it to exploit this thing? I mean, do you have to have some kind of PhD in computer science or is it like, no, there's, you can just a couple of strokes of the keyboard and you're in this thing, right. So there's a kind of a, variety of ways to do that, right. There is kind of the spectrum of how hard is it? Okay, but you can see here in the CVE listing that the CVEs are very specific to a particular framework or operating system or library or that thing, it's a very specific targeted vulnerability. And so just look at the first one up their CVE 2018-1327 which by the way, the nomenclature is the CVE obviously, and then the dash and then that number next to it 2018, that's the year 2018. And then the next-1327, that's the 1327th SVE that came up in the year 2018, so that's kind of the way that those things work. Okay, so, but anyway, but if you look at that, it talks about Apache Struts rest plug in is using extreme library, yada, yada, all that stuff. But if you look kind of on that second line, it says upgrade to the Apache Struts version 2.5.16 and switch to an optional Jackson XML handler, right. And then they even describe it there. And so, basically what they're saying is, hey, for the Apache Struts REST Plugin,, using that specific, XStream library, all of that, this deals with a DoS attack, that could happen. A denial of service attack. Then you need to upgrade to a different version of Apache Struts, right. 2.5.16 and you can see as you read down through the other ones that are listed there, the very next one. Apache Struts version 2.32, 2.3.34 and 2.52, 2.5.16 suffer from a possible remote code execution. This is a really big one, right. And so, anyway, you can see that it's very targeted to a version number of a software code, specific to in this case Apache Struts. And so that's what you're going to get with the CVE listing, right. You're going to, get the specific type of code, you're going to get the specific version. You're going to get exactly what the vulnerability is and that's what you're going to get with a CVE listing, right. What you're not going to get on the CVE is, has anyone done any research to figure out how hard is it to exploit this thing or what would the business impact be if this thing were to be exploited, right. Well CVE in the minor organization, they don't necessarily know that because they don't know your organization. They're just going to tell you, hey this is what was found whether it was again maybe an internal security audit was done on the code or maybe some external security researcher found it and notified. Maybe they called up, Apache and they were hey man you guys got a problem here, right. And that happens that totally happens. And so for any number of reasons the vulnerability was discovered and now it's listed here as an actual CVE that will be in this database kind of forever if you will. Okay, so that's what you're going to get with the CVE. So on the next page I'm going to go over the NVD. This is the national vulnerability database. And we actually looked at this again on a previous video but the national vulnerability database you can do a search and you'll see there. I did a search for Apache. If you can kind of look on the left side there keyword text search Apache. And so you see over there on the left the vulnerability ID. So there's some CVEs that were that are listed, right. And then there's the summary which is the the CVEs summary. It gives you the published date and all that. But if you look over there on the right the CVSS severity. And there's two different, there's a couple different versions of the CVSS that's like a scoring system basically. There's a version two and then there's a newer version 3.x. And so if you look on that 3rd 1 listed down there, the CVE2022-23181. Talking about the fix for bug CVE blah introduced a time of check, time of use vulnerability. So there's actually a bug fix that intro introduced another vulnerability, right. So it's kind of crazy. I mean, hey, that's the world of code, right. But if you look all the way on the right on that one you see that the CVSS this actually gives it a score, right. So this is where it's more of a hey I'm not necessarily going to just tell you what it is in the form of the CVE. But now I'm going to tell you like how severe is this thing, and this is on a rank of of one to ten, right. So they give you the actual score, but then they also categorize it and there are different, threshold cut off points that hey, if it reaches this number than it is. It goes from medium to high and then from high to critical that kind of a thing or as you go down medium down too low and that kind of thing, right. And so anyway, so you can see there that based on version 2.0 of the CVSS the scoring system. Then this particular CVE was ranked a 4.4 medium. But using the characteristics or the scoring system of the version 3.1 which is a little bit more involved. It's a little bit better frankly the CVSS version 3.1 ranks this a 7.0 high. So it's actually now the the CVE hasn't changed. And that's the interesting thing. It's still the same CVE, you're using a different scoring criteria. Version 2.0 versus version 3.1 on the CVSS score. So, anyway, I say all of that to say that the national vulnerability database is a place where you can come that's a little bit more of a one stop shop if you will, that shows you based on your search. I mean, you can do searches for all kinds of stuff in this database. And so you can go here and it tells you the CVE number. Tells you the summary of like what it's found and it also gives you the score. So you can see like how big of a deal is this right? Anyway, so I wanted to just highlight the CVE and the national vulnerability database the NVD right? So there's all kinds of acronyms going on, but it's good to know, kind of what's on these different databases. Okay, so let's move on and look at a scenario here right? So here's something that could happen, and this was taken off the OLS spam website for this particular risk. Components typically run with the same privileges as the application itself. Right, so again you build the application and then you start to bring in these external, these 3rd party libraries or these 3rd party components right? All right, so flaws in any component can result in serious impact right, flaws can be accidental or they can be intentional. Right, so it could be a coding air someone just typed in the wrong thing. Or someone could legitimately consciously be saying, hey, I'm trying to create a backdoor here. Right, and so anyway again, if you can imagine the application is built, it has certain privileges that have certain access control capabilities or permissions, that kind of thing. But then if you reach out and you say, hey, I need to use this third party library, this other third party component this external component as it were. Then if you're running those external things at the same privilege level as you do the application itself, then now you're just inviting kind of these. I won't necessarily say unknown, but in a sense unknown or certainly an invited guest to the party as it were. Not the owner, you're inviting them in and you're saying you have all of the permissions that the application itself has. So again, if that third party library, that third party component has a problem and suddenly some vulnerability pops up with that thing. Based on, again, security research or maybe they're running their own internal security audit scans or whatever. Then now your application has suddenly become just as vulnerable as that thing it has brought in that vulnerability, like that's the idea here. Right, okay, so you can see there are a few different bullets on how this thing, may play itself out, you can see their CVE-2017-5638 right. Stretch to remote code execution enables the execution of arbitrary code on the server that's been blamed for significant breaches. What has happened there is this is Apache struts, in fact, that's why I use that example earlier, we were looking at CVE, but this is a remote code execution vulnerability, which is a really big deal. That basically means that there is someone else, some other attacker that is not, sitting on your server, can remotely access your application and start to remotely execute commands on your application server. Right, which is not a good thing at all. Not that you don't want someone else executing commands on your application server. Right, and so specifically the Apache struts two framework is used as a framework to build a variety of different applications. Well, if you can imagine, you can think of it like as the foundation of a house. If you're building your house on the foundation and then the foundation itself has a bunch of vulnerabilities in it or in this case this very significant vulnerability. Then any house that is built on that foundation is going to have that vulnerability, you're going to have a big problem. And so that is exactly what's happened here. Applications that have been built on that Apache struts two framework are vulnerable to this remote code execution vulnerability because it's part of the Apache struts two framework. Right, and so that's where you need to update the framework that you're on or upgrade to the next version up of Apache or whatever the fix would be the Apache would have come out with. Right, okay, the second one there, while the internet of things the IOT right? This is all of your connected cameras and toasters and whatever right? All the things that are connected to the internet today it's you can see there is frequently difficult or impossible to patch. You should patch as much as you can right, this of the Mirai botnet. I know I talked about a different botnet in a previous video that these botnets tend to come after those internet of things connected devices because they're just easy targets. So to the extent that you can patch those things up, keep them up to date, again change passwords where you can if you see a vulnerability. Or if the manufacturer announces of vulnerability, then update to the next version of software that they recommend updating to right? Because what will happen in cases that vulnerability is found and the manufacturer actually supports that code and they come out with a fix. Most of the time what will happen is the manufacturer will say, okay yeah we wrote the code that runs that thing, let's call it an internet connected camera again, I'm picking on the cameras whatever. But they're I guess they're an easy target right? So let's say the manufacturer that wrote the code that runs that camera and connects it to the internet and all that stuff. Either they found some big vulnerability or maybe some security researcher found the vulnerability and alerted the manufacturer. The manufacturer looks at it, they're like, man, you're exactly right. This thing is totally it totally is broken, whatever and it's vulnerable to this problem. I mean it works as a camera, it's just vulnerable to whatever problem was discovered right? And so then the manufacturer will say, okay because we still support that version of code on that device. Our application development team is going to go in and rewrite the code and they're going to fix that bag, they're going to fix that vulnerability, right? And they're going to fix it because they now they know what the problem was that allowed it to be open to be vulnerable and then they're going to figure out. All right, well how how can we rewrite the code and redo things so that it totally shuts that door like like closes that vulnerability, right? So they'll go in, they'll write new code, they will test it, they'll make sure that, they'll try to attack that new code in the same way that the old code was attacked. And they'll say, hey it's not it's not vulnerable anymore, like you can't do you can't get in this new code, right? But the new code still runs the camera, I mean it's still an operational camera. So then the manufacturer will say, hey now we all of our customers that have this camera, we recommend that you upgrade to version, 1.2 or 2.0 or whatever it is, right? And so then it's up to you as the customer to say, they've come out with an update. Am I going to update or not right? And so, that would be on you to say, hey, here's this vulnerability that was found. They have fixed it in a new software version. I need to update or upgrade to that next version. And a lot of times, especially for these little IOT kind of devices, it's literally just download the new update or, update or whatever it is. Software update and then you may have to restart the device or whatever. And then that's it, like that's it's not that hard. Now I understand it's much more difficult when you're talking about a huge, you know, enterprise kind of organization that has to update all kinds of stuff. And it's, there's change Windows and all that's a more difficult process. But the idea is exactly the same right, so that's kind of what happens. All right. And then you can see there on that last one, there's automated tools to help attackers find unpatched Michigan figured systems. There's a showdown as a search engine that looks for IOT devices that suffer from vulnerabilities and so attackers can use that. Or you could use showdown to see, hey, I'm I vulnerable to these things. In fact, let me go to the next slide here and I'll just show you, I did a little show Shodan screen grab here and I just typed in struts, I mean we're on kind of the apache struts bandwagon here a little bit, right? And so you can see there, there's a lot of different countries that have struts, vulnerabilities that are listed there. There's different organ list organizations by name at list, different ports that are used that would have vulnerabilities against that specific keyword search. So in this case struts. People use this a lot back several years ago when the Heartbleed of vulnerability was discovered and it was this massive thing, Heartbleed kind of shut down a lot of stuff. I mean people are really freaking out over that when and rightly. So I mean it was it was a big deal in terms of like encryption and being able to read what you thought was encrypted, they could actually be red and that kind of thing. But there was a ton of IOT connected devices that were vulnerable to that, right? And so you can use this showdown site or showdown report to find out if you're vulnerable to a variety of different types of vulnerabilities, right? So anyway, so that's just another search tool that you can use to check out vulnerabilities especially for IOT connected devices. Alright, so this brings us to our you vulnerable, Is your application vulnerable to these vulnerable and outdated components, right? And so you can ask yourself, if you don't know the versions of the components you use, then you may be vulnerable, right? So you need to know all of the different versions and you can see there its components you use directly as well as nested dependency. So, do a good search of your code base to say, hey, what are the components I use? And then at that point you can use some of these tools that I just showed you, whether it's the CDE database or NVD or showdown. Or, I mean there's a there's a lot of different searches that you can use. You can contact the manufacturer just stay in touch with them. They will typically have some kind of security reporting, mail list that you can subscribe to. There's all those kinds of things you need to be aware of what's going on, right? Okay. So are you vulnerable with the software? Obviously if the software is vulnerable then you're vulnerable? If it's unsupported or out of date, this includes all the different components, the operating system, the server, the database, the APIs and all that stuff, right? So this kind of gets to the heart of, remember I said it's impossible to build an application that is not vulnerable at all, right? And that just does not exist. So frankly you are going to be vulnerable not to be pessimistic here in this little chat, this part of the discussion, but you are going to be vulnerable. The question is, how vulnerable are you and to what extent are you vulnerable? And how much do you know about it? Do you know exactly where the holes are and you can keep a close eye on those things or do you have absolutely no clue, right? So that's kind of where we're trying to get out with this, is you need to have a clue and you need to know where the vulnerabilities exist, right? And so that brings us to that next one. If you don't scan for vulnerabilities regulars subscribe to these security bulletins like I said, so you need to be doing those things, right? The next one, if you don't fix or upgrade the underlying platform, the frameworks dependencies, right? In a timely fashion and you can see there's environments where patching is a monthly or quarterly task, there's these different maintenance windows, change control processes. And so if that's the case, I guess the worst case scenario, let's say that you're on a quarterly patching cycle, right? And let's say that you patch on patch day on quarter one. And then the next day there is a big vulnerability that's exposed or that's released or whatever. Then the question is, do you have to wait like three months basically until you patch for that thing? And the answer may be yes, depending on your business needs and all that stuff. But if that's the case, then you need to know, hey, we need to keep a really close eye on that thing. And then look for indicators of compromise and just ways that people are getting in, right? And you can work with the manufacturer, you can work with the developers of that code to say, hey, what do you recommend? Are there any little like band aid kind of fix actions? I can do in the meantime, before I actually do the big update patch type action, right? Anyway, so that's another thing to just kind of keep in mind there, right. You can see the next one there. If software developers don't test the compatibility of libraries, this is you want to make sure that if you're bringing in third party external libraries, are they going to work properly with your applications? So you need to check that and then if you don't secure the components configurations this I mean it really gets back to what we've talked about before. So those are just some things you can look at. You can ask yourself, am I vulnerable to this security risk. And then to talk about a little bit maybe better topic because how do you protect yourself, right? So you can see there should be a patch management process in place, right? So if that's not in place, you need to sit down and say, hey, let's develop a patch management process. Go on if you have no idea where to start, then go on google and just type in patch management process and start to look at. Other organizations that have done this and you figure out, hey, this is what works this is what does not work or maybe you do have a good idea, you just don't do it, right? So you need to sit down and say, okay, we need to actually pull the trigger on this thing and actually do the patch management process that we've developed. You can see there in the patch management process, remove unused dependencies, unnecessary features. We talked about this in previous videos as well that if you don't need a component, if you don't need a feature, just get rid of it because if you don't get rid of it, it opens up the door for a potential vulnerability, right? Continuous inventory of client side server side components. This is another one of those like, hey, you got to know yourself. Going back to some of the art of war kind of stuff, know your enemy, know yourself, know your enemy kind of thing, but you need to know yourself and what you what your application includes. So that you can know what to defend or what is vulnerable, right? You can see they're continuously monitors stuff like CVE, NVD, all that stuff I've talked about. Your software composition analysis tools automate the process, right? So again, if you have an organization of any size at all, then automation has got to come into play on these things because you cannot possibly manually just sit down and say, hey, testing team, guess what you get to do. It's Monday morning and you get to just start looking for vulnerabilities manually. That's there's, it's never going to work. So you have to automate as much as you possibly can. And then you can see down there, subscribe to email alerts. Stay as connected as you can to the different manufacturers of the code or the different organizations that put out this code. And so as soon as they an alert pops up then you'll get an email about it or search social media. I mean, look on twitter and LinkedIn and Facebook and maybe they're making Tiktok videos about their new vulnerabilities. Now whatever it is, right, whatever you gotta do to find out the information. And then you can start to formulate the plan to to patch or upgrade or update whatever it is, right? And then a few other things here, only get components from official sources, secure links. So don't go to uncle Bob's software shop dot com that does not have HTTPS encryption and whatever and you have no idea where this component came from, don't do that, right? So just go to the official download source of whatever that would be. So, I mean if we go back to Apache, Apache Struts, whatever get that from Apache, don't get it from some other who knows? Place, right? You can see there the next one monitor for libraries and components that are unmaintained, that don't create security patches for older versions. So, you can see they're patching is not possible. Maybe look at deploying a virtual patch to monitor, detect that kind of thing. So sometimes there's kind of band aid mitigation actions you can take without actually applying the patch if for some reason that's not possible for you. And then also, that first part monitor libraries and components that are unmaintained or don't create security patches. This is where you start talking about code that an organization has created or written that's now, I'll just pick a number, let's say it's ten years old or something like that, right? And you're still running on that same version of code because who knows why? I mean, there's 1000 different business reasons you may have to run on this really old code. But you need to be aware that it's like, hey, that code is unsupported, which means that if a security researcher or the organization themselves find a problem with that code, then they're not going to create a fix for it. They're not going to get their development team together to say, hey, let's fix a problem with this code that's ten years old. I mean, they've already moved on to probably five or six or ten or 12 versions beyond that by now. And that's where they're going to dedicate their resources, right? As an organization. And so anyway, so you've gotta stay a little bit up to date with code that is supported, right? So that's one of those things. And then you can see there the last thing, every organization must ensure that there's an ongoing plan for monitoring, triage, applying updates all that for the lifetime of the application. And so this is, again, it's kind of saying the same thing a little bit here that you need to have a plan for keeping your code as up to date as patched, as monitored and all that as you possibly can, Right? So know what components you have in your application. Know, the status of those. Know the vulnerabilities that are currently associated with those. And then have a plan in place to update those, to patch those, to upgrade, whatever the fixed action would be. Try to do that as quickly as you possibly can. And in the meantime, there's going to be a time between when you find out about a vulnerability and when you can actually fix the vulnerability. And you need to to have a plan in place for what that delta, of that amount of time looks like between discovery of vulnerability and fix of vulnerability. So just, that's where you gotta just kind of stay alert, everybody keep their eyes on those different components and say, hey, are we being, are any attackers exploiting that vulnerability that we now know about but we have not fixed, right? So it's one of those things. Okay, so with that let me list a couple of resources here. This again comes off the OWASP site but you can see there the ASVS, the application, security verification standard. This is that standard that you can use to use against the actual code that you're using to create and build your application, there's a dependency check. This is a really good when you can run this OWASP dependency check. And that basically we'll scan your application, look at different dependencies and third party libraries and frameworks and all that are connected to your application or used by your application. And then it will scan and say, hey, you're using this third party library and by the way, that library has a lot of vulnerabilities in it. So you need to know about that. So, that dependency check is a really good tool you could use against your applications. You can see different testing guides, best practices for patching and then of course CVE and NVD, are two great places to look as well. So, the components with outdated components, vulnerable components, that's the world we live in. These things happen, they happen all the time. And again, you're not going to have an application that is completely free of these things but you can do your best to mitigate these and to be as secure and up to date as you possibly can. And so having those plans in place, having those processes in place to know what you're going to do when vulnerabilities are discovered then the better off you're going to be. And so, let's stay safe out there with our applications, right? So with that, let me say thanks for hanging in there and watching this video with me today,. And I look forward to seeing you in the next one.
