12 hours 9 minutes
everyone. Welcome back to the core. So in the last video, we wrapped up our lab on broken access control.
In this video, we're gonna talk about security, Miss Configurations.
So a quick pre assessment question here, Rhonda knows that the security Miss Configurations can happen across the application stack.
Which of the following is not one of the levels of a common application stack?
All right, so if he answered d cabling, you are correct. So network service is databases, frameworks, custom code, things like preinstalled, virtual machines, container storage, et cetera, et cetera. All these are things that can be commonly found across the application stack cabling. We're talking about the physical cabling there. So you're not gonna be seeing that across the application staff
arts are learning objectives for this video will talkto as we normally do. We'll talk about the risk rating will take a glance at that loss. We're gonna figure out what security Miss configurations are. But you can pretty much tell from the name what those are. We're gonna talk about ways to check for it as well as ways to prevent or mitigate against it.
So we see here that it's a pretty bad thing, which is The name implies it is a bad thing. So we see it's pretty easy to exploit. We see that it's a pretty common thing on then. We also see that it's pretty easy for an attacker Thio to detect that there's some kind of this configuration or, you know, something like that in place.
So then they can go attack you
so insecure. It's configurations, as I mentioned is
were the kind of the main keep. The main points is for a security miss consideration. So, um,
and we're talking about insecure default configurations here. So, for example, I take I take a piece of software out the box. I don't do anything with it. I just basically plug it into my network, and I feel like I'm good to go,
but I need to secure it better. We see this a lot with, like, Amazon AWS buckets. Excuse me. Um,
a lot of organizations don't have anyone that's like, actually skilled in AWS on staff. And so what happens many times and you see this in various preaches is that
an attacker can easily get the information and easily exposed the information in the database more than Lisa being stored in that cloud. Davies.
So this is definitely something that's, you know, prevalent. We are seeing it way we do see a tax on it quite often, and we definitely need to take it a little more seriously as organizations.
So other other things that can cause it, you know, open clock stories, Miss Configured http http Headers air messages as well that are very verbose. So things that are their message that are spinning out a bunch of information about, like, the operating system and use or, you know, particular servers or I p addresses and use.
We'll take a look at that in our lap for this particular module.
So prevalent as I mentioned, it's pretty common is pretty much one of the most common things. A cz I mentioned. We see it with a cloud a lot. Now the deep analytics, a deeper analytics breach. If you remember, that was a few years back and that was that Voting one. I've got links to that article as well as one for the Dow Jones and the supplement resource is so feel free to click on those
and explore those a little more.
but deep Root was where voter information was exposed to with the Republican National Committee. Voter data was exposed. And then the Dow Jones one. As of the time I'm filming this video, uh, it actually occurred back in 2017 but it was ah ah.
Brought up this week this week being like early March
2019 s. So basically what happened is there was a Miss configured Amazon bucket Ah, database that Dow Jones was using And you're a security researcher. Found the information
out there on the web. And from there, you know, let them know, of course, say they fixed the issue, but, uh, number one like, why? Why did it take so long to kind of come to the forefront on the number two? You know, why wasn't that configured properly? Because, you know, daddy owns it's a larger organization.
So how do we check? Well,
does our our application? Is it allowing us to use improper permission? So, for example, as we have talked about before with broken out broken access control and also broken authentication, are we able to do things that we shouldn't be able to do as a user.
Do we have unnecessary features turned on you? Are they enabled? Are they installed? Also, you know are, you know, so things like our ports, you know, Are we using unnecessary reports? We have those, you know, turned on. Or are we going to disable those? Service is, you know, accounts. Do we have certain pages that we don't really need? Can we turn those off
default credentials? Right. So are we still using default usernames and passwords? If so, we definitely need to change that air handling messages. As I mentioned, being too for both. So
I'm an attacker. I try to get your Web server to throwing error. It does. And then it sends me back this message that tells me like everything I need to know to actually attack your company.
Are we disabling security features? Right. Are we doing that aside? Application servers, you know, or are the application like libraries, databases, et cetera. Are they not set to secure values?
And then, of course, old software, Right. So for using out of date software, that's ah, key indicator that we're more than likely vulnerable to security, Miss configurations,
so impact so they can affects functionality of the system itself or even, you know, off the data on then. You know, of course, the data loss and the corruption, et cetera financial lost is well,
how do we prevent against it? So what do we need to do? What steps to do we need to take. So we need a hardened systems and we need that to be a repeatable process. So we need a repeatable hardening process so that we would continue with. As technology evolves, we continue making it the more most secure system that we can.
I mentioned for removing unnecessary features so we don't need any of that stuff. So, for example, with like a port, we can just close that porter disable a port. And that way we don't have to worry about any malicious traffic coming across that particular port.
Patching, of course. Regular patching, regular updates, segmentation.
So we can segment our network so that if I get into one component as an attacker, I can't get everywhere else.
And then finally, verification as well
we could verify that everything we're doing, like hardening systems, you know, patching that sort of stuff, verify that everything is actually working as expected, or if we need to make more adjustments.
I just want quick post assessment question here. What's the following is a way to prevent against security, Miss Configurations. Which one of those is
All right? So if he said Answer, see segmenting application architecture's so again we talked about that. The segmentation now installing a necessary features using data software and using default credentials are all away for an attacker to try to exploit Soviet security. Miss Configurations. But they're not a way for us as a defender in this particular course,
It's not a way for us to prevent against security, Miss Configuration.
All right, So this video we talked about security, Miss Configurations, and the next video, we're gonna jump into our lab on securities configurations, and then we'll move into our next module, which is gonna be on cross site scripting