CompTIA CYSA+ CS0-002 – Specialized Technology Part 3

6. Premise System Vulnerabilities (OBJ 1.5)

Premise system vulnerabilities. In this lesson we are going to talk about premise systems. Now, what is a premise system? Well, a premise system is a system used for building automation and physical access security. And these are a different type of network as well. Oftentimes you’ll have this as a third network in your organization. When you’re dealing with this and you go to your front door or your building and you try to get in and use your card and your Pin, that has to go through some kind of an access control system. That is a premise system, right, that is physical access security. If I look at the security cameras, those are part of your premise system as well. Now, when we deal with a premise system, a lot of these system designs are going to allow for monitoring to be available across the corporate data network or even directly from the Internet.

And this is really great from a monitoring perspective. It makes it really easy for us. But this is also dangerous, right, because when we have a connection to the corporate data network, that means that somebody can hack into your premise network, they can cross over into your data network and if you connect directly to the Internet, that might give them a way into that premise network. So these are things you have to think about when you’re dealing with security. Now, in addition to this, we also have building automation systems. Now building automation systems, they have components and protocols that facilitate the centralized configuration and monitoring of your different mechanical and electrical systems within offices or data centers.

Now, oftentimes you’re not going to be controlling the actual power generation, right? That would be ICS and SCADA. But you are going to have other ways to look at the information inside your building through these automation systems. For instance, at our offices we have a battery backup system. This is a whole building system so that if we lose power, we have that battery that can kick in and support us for about 24 hours. Now we have the ability to log into that battery remotely over the Internet so we can see exactly how much battery is left, how quickly our burn rate is and things of that nature. If you’re in a bigger building you might have elevators and you want to be able to figure out where the elevator is at any given time.

If you’ve watched any spy movie, I’m sure you’ve seen the idea of building automation systems where they turn on and off the ACS or they turn on and off the elevators or turn on and off the lights to a particular floor. That’s, that’s what a building automation system really is. Now, when you start dealing with all these building automation systems, they have lots of different parts that could bring up vulnerabilities to your network. So again, I like to keep these as their own segmented network. But when we start talking about these vulnerabilities. We have things like the process and memory vulnerabilities inside the PLCs because these building automations are going to use PLCs if you’re going to control elevators and lighting and water and fire mains and power. All of those things do have PLCs that you can control within your building.

Then we have to think about how we’re going to keep our credentials safe because oftentimes these things have poor security management. A lot of times people write their code with plain text credentials or keys inside the application code. That way they’ll say my password is password and they’ll put it right in the code and that could be exploited by an attacker. Another thing I often see occur is code injections against the web user interface. A lot of these building automation systems, the way that they are monitored is through a web interface whether locally or over the internet. So if there is a web interface presented that means an attacker could access that and then do a code injection doing something like an XML injection, an SQL injection, a cross site scripting injection, something like that. And so you got to keep that in mind.

This is an area that could allow for somebody to get into that network and then control your building. Now one of the things that we really have to worry about with these premise systems and building automation systems is that they can be used to create a denial of service condition in the real world. Now what do I mean by that? Well, let’s say I got a hold of your building automation system and I was able to do a code injection and take access over it. I could create a denial of service condition for you that could affect your entire building by turning off your HVAC, which is your air conditioner. If you have a server farm and I take away your air conditioner, that can overheat the systems and cause them to shut down.

Now I have caused an electronic attack against your servers by doing a physical attack, by taking away your cooling. These are the things you have to think about. Another reason to worry about these systems is often they’re not well secured. If you think back to 2015, there was a big case of this in the news with Target. Target is a big retail chain in the United States and they actually had one of their contractors who ran their HVAC systems. Their systems had gotten hacked and somebody went through their systems, through the HVAC at the Target stores and then down into the point of sale systems, the cash registers and started collecting credit card data. This was a huge breach and it was a huge black eye for the corporation.

So remember, these building automation systems could be used as an intrusion vector as somebody wants to pivot from that into a more dangerous attack against your corporate network. So you have to make sure the right protections in place. Now, the final thing I want to talk about in this lesson is the idea of PAX, which is the physical access control system. Now the physical access control system is all of the components and protocols that facilitate the centralized configuration and monitoring of security mechanisms within offices and data centers. So when we start talking about all those security cameras and the access control to badge in and badge out of your building, that is all part of your physical access control systems.

Now, PACs can either be implemented as part of your building automation system or as part of a separate system. Either way will work. It just depends on how your contractor sets it up or how your organization sets it up. Now, one word of warning here PACs are often installed and maintained by a third party external supplier. And because of that, a lot of times people will omit that from their risk analysis or the vulnerability assessments. So as you’re starting to think about your networks and you think, okay, I’ve got this Windows network here, I’ve got the server farm here, I might have this OT over here, they don’t think about the building network itself because it’s some third party contract.

So that’s okay if you’re going to exclude it from your scope. If you have that in writing, that that is part of their responsibilities. And they would probably have some kind of requirement to give you everything every quarter, every six months, every year, some kind of a vulnerability statement of what the network looks like. Because again, you can outsource the task, but you can’t outsource the responsibility. If their network is tied to your network in any way and there’s a vulnerability on their network, that means the attacker could get from them to you just like they did with Target. So keep that in mind.

7. Vehicular Vulnerabilities (OBJ 1.5)

Vehicular vulnerabilities. In this lesson, we’re going to talk about planes, trains and automobiles. Well, not really. We’re going to talk about automobiles and unmanned aerial vehicles and any other vehicular thing that could be controlled by some kind of a computer. Now these days, cars are getting smarter and smarter. For instance, we have cars like Tesla that drive themselves. They use sensors around the car, they take that information back to a centralized computer and then they adjust just your steering for you or your speed for you based on what they’re sensing. All of this is done by computers and by code, which means it’s dangerous, right? Because all of this stuff could have software vulnerabilities.

Now these car manufacturers are doing their best to try to keep these as safe and secure as possible. But a lot of things and a lot of older vehicles are extremely vulnerable. So we have to talk about that as we think about security at large, because you might have a corporate fleet of vehicles and they might have some of these vulnerabilities. Now, when we think about vehicles, these vehicles all have lots of different systems on them. These systems all have to connect some way. And so we take all these different subsystems like the HVAC and the steering and the cruise control and all of these different functions, and they all get passed over what’s called a controller area network or a can.

Don’t confuse this with the can you learned about back in network. Plus we talked about campus area networks. This is a controller area network. Now, when you talk about a controller area network, this is a digital serial data communications network that’s used within a vehicle. Now, if you look at an airplane, for instance, they have miles and miles of cabling and all that cabling connects together. That is a can in your car. The same thing, just not as large or not as a big of an extent. Now, when we start talking about how we can talk to this can network, how can we, as somebody in the car, reach and do it? Well, the primary method that we use is known as an OBD two, which is an onboard diagnostic module.

Now, this is something that was put in all cars starting in about the 1990s. And the reason for this was as we started having onboard computers in the cars and we got things like a check engine light and you want to know how do you check the engine? Well, you plug in something into the OB d two port and that’s going to end up coming back with a code that tells you what’s wrong. That’s what the port was originally designed for, but these days it can be used for a lot more. Now, when we look at a can bus, this operates a lot like Ethernet does. If you think back to the way I talked about Ethernet all the way back in network, plus we talked about the fact that ethernet was developed with the idea that everybody on there was trusted and so we didn’t have to have a lot of security.

And cans are built the same way. Again, they’re a contentious network where people are going to take turns talking and if not, there’s going to be collisions and they’re going to have to repeat. This is all very similar to ethernet the way it works. Now this is because the manufacturers essentially never thought that we were going to use these systems and cars to the fact the way we do them. Now these cans were developed in the did anyone think about self driving cars back in the? Probably not. And the things that we can do with cars these days is amazing compared to what we could do just 30 years ago. And so this is the idea of what we’re doing with these cars in this can network. Now, if the can is completely isolated, it’s probably pretty secure.

But the problem is, in a lot of modern vehicles, we’ve actually started bringing in other networks into these cars. Some cars have cellular built in, some cars have WiFi built in. And this is now bringing in the wan into our cars and bringing the outside world in, which could also bring in vulnerabilities. So essentially our cars have now become part of the internet of things. Now there is no concept of source addressing or message authentication within the can bus. And this goes back to the idea of security. So if there’s no way to authenticate a message, that means any message that goes on that can bus is immediately considered trusted by the computer. So if I can get a message into the can bus that says make the cargo 100 miles an hour, it’s going to do it because it’s going to trust that that message was real because it got to the can bus.

That’s the only way it knows that something is trusted. If the message got to the can bus, it must be trusted. That’s how it was designed. And so that is a big flaw that we have in these systems. Let me give you a good example of this. Here’s an article from a couple of years ago, and it was written by Andy Greenberg, who’s a journalist, he was a journalist for wired magazine. He reported on his driving experience while driving a jeep going at about 70 miles an hour outside downtown St. Louis when hackers decided to start doing an exploit. Now he was doing this as part of an experiment and the hackers were actually pen testers. But let me read you what he said. Though I hadn’t touched the dashboard, the vents in the Jeep cherokee started blasting cold air at the maximum setting, chilling the sweat on my back through the in seat climate control system.

Next, the radio switched the local hip hop station and began blaring ski loo at full volume. I spun the control knob, left and hit the power button to no avail. Then the windshield wipers turned on and the wiper fluid blurred the glass and it keeps going on with all the things the Pen testers were able to do as he was driving this vehicle 70 miles an hour down the street, and they were able to hack into it and do all this stuff remotely. So if you’re interested in seeing this article, if you just type in the name of this article, it’ll come up in Google, you can watch the video and actually see it happening. It’s pretty interesting and it gives you a good idea of what we’re talking about here with the vulnerabilities of a canned system. So how can an attacker get into a vehicle and modify it? Well, they have to get to the can bus and there’s really three ways to do it.

One is they can do it locally. They can attach an exploit locally to the OBD two. Now, you might think, well, that means they have to be in the car with you. Well, not necessarily. You can create a plug that plugs into the OBD two. And most OBD two s are underneath the dashboard where somebody doesn’t see it visibly. So let’s say you went to a local restaurant and you actually handed your car off to some valet while you were in there. He could have plugged in something to the OBD two and now he has a connection and they can run an exploit from. So again, this is vulnerabilities we have to think about. Now, another thing they can do is they can actually exploit over the onboard cellular.

If your car has a cell modem built into it, that means you have a connection to the outside world, which means they have a connection to you. Now, most cars have two networks. They have the entertainment network and the Vehicular can network and they are separated. For instance, I have a Tesla that I drive. It has a cell modem built in that runs through the entertainment system so I can listen to the radio, I can listen to songs over Pandora and Spotify and things like that. That is one system. And then there’s the system that controls the driving of the car. They’ve built that as two separate systems because of this vulnerability.

But if you have a manufacturer who doesn’t have a clear separation of the two, that could be an issue. And then the third, you can have an exploit over the onboard WiFi. Again, a lot of cars have onboard WiFi as a feature that was added within the last five to ten years. And so if I’m driving close to you and I can reach your WiFi and there’s a link between that WiFi and the can, I can then get messages near your can and cause issues. So again, this isn’t a big area that we’ve cybersecurity analysts are really going to work in except to know that this vulnerability exists for the exam. If you can remember these three vulnerabilities, you’ll do fine. When it comes to vehicle questions.

• Category: Uncategorized