The security plus exam is filled with scenario questions. And there are plenty of scenario questions that talk about vulnerability impact. Now, in lots of episodes, we've covered all types of vulnerabilities and their impacts. But there's a few that I want to hit a little bit harder. So really, what I'm doing is I'm grabbing directly from the security plus objectives, some of the vulnerability impact scenarios that you're probably going to be seen. So we're just going to put them up on the screen here, and I'm going to come up with scenarios that you should be considering for the exam, you're ready, let's get started.
Embedded Systems. an embedded system is simply an immutable system that never changes. That can still be it's still a full system, it's going to have storage and a CPU and an operating system and input output. The problem with embedded systems more than anything else is because they're immutable. We tend to forget about them a lot. And we don't remember that they can can have situations where they can be patched.
So I guess, not totally immutable, but they are set aside and far away. They are the patches, they need anti malware, they need firewalls, they need everything that we would use with a regular system, but because they tend to be tucked away and forgotten, sometimes we forget that the danger with embedded systems more than anything else is we forget to take care of them the same way that we would take care of any regular device, lack of vendor support, okay? There's lots of vendors out there selling lots of kinds of different stuff. And lack of vendor support is a big issue primarily with hardware. There's some heart software situations too. If a vendor is no longer supporting whatever it might be, there's one of two reasons either a, the device or software has become obsolete and the vendor is trying to move on.
Or number two, the vendor is completely out of business. In either case, the biggest downside the biggest vulnerability Is that we can no longer patch these devices, we can no longer keep them updated. In some cases, we can no longer get parts if that is the particular case. So the impact there is that the device becomes open to potential problems. And in that case, usually the right answer is is we throw that stuff away. And we go ahead and get something new that has proper vendor support misconfigured or weak configuration.
Now to me, these are two very different things. So first of all, a weak configuration. Probably the ultimate configuration is a default configuration. So every piece of hardware and software out there have big list entire websites that tell us what the default usernames and passwords are for just about everything in there. So it's really important for us to provide the best possible configurations, we can change the usernames and passwords, but we configuration could also mean things like if I have four or five different types of wireless encryption, there's still plenty more wireless access points out there that still use WEP. And I did a recent personal study here in the Houston area discovered something like 8% of all wireless networks out there still run WEP that could be easily reconfigured to a stronger configuration.
The downside is, is you create some form of exposure to some type of threat actor who will take advantage of that weak configuration. Now misconfigurations to me is a different animal altogether. When we say mis configuration, that means we do have a configuration, but we have done something incorrect. So most the time when I'm thinking of this configuration is that we haven't turned on a service that we might be wanting to take advantage of. We didn't turn on a stateless firewall, for example, or it could also mean something like we failed to turn off default services. My home router has a wonderful SSH server built into it, but I don't want anybody using that it would certainly be in my opinion misconfigured To have that turned on.
So anytime we do a mis configuration, we're exposing that device or that piece of software to potential threats that shouldn't be there in the first place. improperly configured accounts. Okay? So an improperly configured account basically means that we have a user or a system account that isn't being provided the rights and privileges and permissions that it needs. From the permission standpoint, it's either going to mean that you're going to expose a particular account to far more than it should have. And the impacts there could be a regular user deleting a hard drive or something like that, to the opposite, where they don't have enough permissions.
And in those types of situations, they're unable to do their job. Also, keep in mind that we it's not just permissions, it's also rights. For example, if we were to accidentally turn off people's rights to access a system remotely, we might be preventing them from being able to do their jobs. So In either case, the impact is going to be the potential that they could do something far more naughty than they should be able to, or on the other side of it, they're not going to be able to do their job the way they need to do it vulnerable business processes. So a vulnerable business process. To me, every business process has some degree of vulnerability.
And you know, we could always have a meteor hit the building and those processes disappear. But what we're talking about are unconsidered business processes that leave us open to potential impacts from those vulnerabilities. So one might consider something like storing non essential information. So for every customer for our sneakers, we store not only their shoe size, and their address and their phone number, but we're also getting all kinds of information about their birthday and things like that and their Facebook account and things like that, that don't really affect our business directly. Anytime we're storing personal identifiable info And that could possibly be exposed, the impact could be massive in terms of the things that could go against us in terms of money and reputation to say nothing of legal. Okay, memory buffer vulnerabilities.
Well, anytime we use memory, we have lots of vulnerabilities in there. But the list basically they say, resource exhaustion, memory leak, integer overflow, buffer overflow, pointer difference, and DLL injection. And to me, there's really three different groups in here. First of all, resource exhaustion or a memory leak. In that particular case, what we're talking about is you're running out of memory. In that case, you got two choices.
Number one, you get more of that resource, or add more RAM or number two, you stop the thing that is doing this. So for example, a memory leak is because we have an application that isn't written properly, that it has some type of problem. This is talks about a recode or update And you're going to have to go through and dig it up memory leaks are one of the most notorious problems that we can get. The bottom line is, is that if you run out of memory on on a system, even with virtual memory, the system's going to lock up, you will be deprived of that service completely. Now, a little bit different than that is integer overflow, or a buffer overflow overflows will not necessarily turn the system off. But what they can do is they can make the system do weird things that it wasn't anticipating.
They're famous buffer overflows on a particular type of server, where if you forced a buffer overflow, you basically got yourself to a terminal prompt. So we're really putting ourselves in a lot of danger with these types of things, simply because it could allow a bad actor to take higher control of the system that we anticipated. Now, pointer dereferences and DLL injections to me those kind of fit into a different world in this particular case, the systems up and running fine. But we're sneaking behind a backdoor to do potential naughty things. So there's not a big clue with a pointer dereference or a DLL injection, that something bad's happened with an integer overflow or a buffer overflow, usually the service itself is turned off, suddenly the web server stops working or something like that. These other two can be more nefarious.
The bottom line is that we have to have good firewalling we're going to have to have good code that is robust against these types of problems, primarily input validation. And we're going to have to be watching these systems very, very closely, especially if we're using third party libraries for anything because that's tends to be where those types of problems come from system sprawl or undocumented assets. Wow, I can't even begin to start to talk about the impact of the vulnerabilities or something like that. Let's start with easy stuff. Number one, it's not under my control as an administrator, there is it being patched is it being is being properly be controlled? Is it being plugged into the right place?
It what are we using it for? What are the user accounts being used for on that? So at the very least, sprawling systems that are undocumented because system sprawl and undocumented assets tend to go hand in hand, meaning that there is stuff that's outside the umbrella of administration, that unless the person who's deciding to take care of it is just as good as I am, we can be left open to any type of vulnerability that you'd see with any individual host, or application or VM or whatever this sprawl device is and it could cause disastrous results.