 So hi, I'm Patrick Kiley, Senior Security Consultant at Rapid 7, and I did some research on Canbus and Avionics. So I'm going to skip over the Avionics primer. I can go over that over there. Everyone knows kind of the components of an airplane. If you don't, I'd be happy to educate anyone that wants to. I'm just going to go into Canbus. So Canbus is a shared medium. Typically seen in transportation, so automotive, it's insecure design by design. The idea is you want it to be fast, you want it to be lightweight, you want it to be resistant to interference. But once you have access to the Canbus, you can do anything that any other device on the Canbus can do. And I had the idea a couple of years ago when I was at an aviation event, they were talking about some modern avionics they were putting in a system and how it used Canbus. It was really easy to hook up and only used two wires. I had already done some research in automotive. I knew the problems with automotive Canbus. And I said, I have a pretty good idea that this is going to be subject to the same vulnerabilities that exist in Canbus itself. It's the nature of how Canbus is created. And basically what it means is once you have physical access to the Canbus, you can do whatever you want. Incidentally, the other thing when I was doing the research, I was like, okay, has anyone done any research on Canbus in avionics with regard to security? There's very little written about it. In fact, I couldn't find any really good security documents about any of the aviation protocols. So another thing that we wanted to come up with and show is that if this exists in this medium, what about the other protocols? Let's get some security researchers involved. Let's get the community to look at the other protocols that are out there. Airing 429, 629. There's Ethernet used all over the place in aircraft. Let's get the community involved, the people that are actually attacking stuff, instead of just the engineers designing it. So we can have the engineers design it. We can have our types, the hackers do bad things, and then the engineers will be able to go back and make the systems more secure. And hopefully we won't have any bad things happen on the aircraft that are out there. Yeah. There's Rob. So, jumping right in, hacking avionics via Canbus. So, yes, you have to have direct physical access to the Canbus, or you have to compromise the device that's on the Canbus. Now, the vectors that people have exploited to get into the cars, they've gone in through the infotainment systems. They have Wi-Fi, Bluetooth, LTE. Well, the avionics kit that I've built actually has Bluetooth and Wi-Fi, so there's one particular access vector there. And then there's physical access. The whole point is physical access should not be our only control. Because if that's your only control, that's a single line of defense, it's not defense in depth. And we want something that's flying in the sky to have more than just one physical control around the bus that's controlling everything in the aircraft. So, the idea is like you get something small like a Raspberry Pi or a car loop that has some telemetry interface. And then you wait for, you either transmit messages to it wirelessly, or you wait for a particular event to occur. So you're already on the bus, you can read data, you wait till you're at a particular altitude or a particular airspeed or over a particular location, and then you trigger an event and bad things happen. You know, if a bad guy were going to do something really horrible on an aircraft, I would think that this type of attack would be very difficult to detect. Whereas, you know, the more kinetic effects are much more obvious and are going to generate a different kind of investigation. Well, we want to get ahead of this, and that was kind of the purpose of all this. So, we have some example CAN bus messages right here. If you see on the right, we have the arbitration ID that's like your network address for CAN bus. And we have a preamble of in hex of D4714. That identifies on this particular system that I have back here, the oil pressure. And it's in little Indian, so the most significant byte is on the right instead of on the left. And as the oil pressure decreases, the value goes up. It's backwards. I had to throw this in there. So as our oil pressure is going down, the value of the oil pressure is actually going up. And the reason why is because it's inverted. Anyway, fuel level. This one is actually increments normally. So, same arbitration ID, 103, 4, 2200. Same first two bytes, D47, but now it's 11 instead of 14. So, 14 controls oil pressure. Same controller, 11 in the preamble controls fuel level. And the same thing. We can actually hack both of those. We'll do the demonstration of this right after. So how do we spoof messages? Normally this is where I jump into a demo. This is a particular piece of software called Vehicle Spy. Once you've actually reverse engineered the message, all you have to do is inject those messages onto the wire. And now you'll either show a higher fuel level than what you actually have, or a lower fuel level. Same thing for oil pressure. You'll actually be giving incorrect results to the instruments. And there's no real way I did a tech that. It'll show a false signal. Autopilot. Something a little bit more substantial and immediate. The autopilot servos on the system back there use a different arbitration ID. And there's just one single message with three bits that DC0103 turns them on. DC0100 turns them off. And then there's a steady state message of DC0C. That just basically means nothing's changed. And that's all you need. You do that and it'll actually engage the servos. Now, any aircraft that I've seen that has an autopilot, you press one button, it's autopilot disconnected, flashes a warning. But with this, you can continuously send these messages on the wire and that disconnect would not do anything. You'd actually have to physically pull the breaker that's connected to the autopilot and sit there and try and manually fight the servos. And oh, and by the way, we can actually control the amount of torque that's going into the servos as well. That's also sent over the CAN bus. And you could potentially make it, depending on how the particular aircraft is designed, make it very, very difficult to try and overcome. Okay, so this particular system had a really unique way of handling complex messaging. We have the AHRS. That is the instrument that indicates the aircraft's attitude and flight. It's called Attitude Heading Reference System. It's basically like the old gyros. So when you're straight level, it'll show on the glass panel that you're straight level. You pitch up, it'll show as in the artificial horizon, it'll pitch up. There's one instrument that controls that. It also has the inputs for the airspeed, the static and angle of attack if you decide to configure an aircraft with that. This one is different. It uses a single arbitration ID as a header, and it's easier to show you over here. So we have arbitration ID 10242000 with the fifth byte over 3C being the message size. Then another arbitration ID 1024200 and then 60 bytes of payload as a bunch of separate CAN messages. This is very non-standard for CAN. But the point is, even though there's some obfuscation here, I was able to figure it out and reverse engineer it. All the messages for heading, for altitude, for airspeed are hidden in this message that comes on every so often. So how would you attack this? You read the header in, store the message size variable, read the subsequent data frames in as an array, modify the bytes that you're going to change and dump it immediately back out into the wire. The nature of CAN bus in any type of telemetry system is the last message in is the most relevant and is the one that will be displayed. So if you're beating the actual instrument with messages on the wire, it's going to be your value. The one that you've injected is the one that's actually going to display on the instrumentation. So I'm in the process of actually having, of reverse engineering this. I figured out what the parts of the message are. I just have to write some custom software to inject it back out there. And this type of attack is the really dangerous one. If you're talking about someone who's an IMC and you don't have a backup instrument that you're immediately referencing and noticing, you could be flying at a different altitude than what you actually think you are. You could be pointing at a different attitude than you are. And it really makes the attack scenarios pretty scary. So set of recommendations. Don't rely solely on physical controls. You introduce a single point of failure here. There's a secure Canvas specification that's out there. It's pretty new in the automotive industry. But since autonomous vehicles are becoming a thing, it's getting a little bit more traction. In avionics, this is what we should have defaulted from the standard. It's a specification of secure underwater communication. It's not a perfect protocol, but it makes the attacks that I presented here orders of magnitude more difficult for an attacker to pull off. Because now you have crypto involved. You have authentication of the payloads. If a device receives a message that doesn't have the proper authentication token with it, it's not actually going to do anything. And then implement a security gateway. That's already present in cars today. Separate your attack surface area, your Wi-Fi, your Bluetooth, your LTE from your Canvas. And have a security device in between those two. On a vehicle that's called a security gateway. It's already designed to operate real time. So the car is not affected by this being in the mix. And then separate your functions of Canvas. Put your autopilot on a separate bus from your engine controls. Your engine controls are in something that's more accessible. It's easy to open up an engine compartment and tamper and get into that. Whereas your autopilot, it's more difficult to get at those servos or anything else. And those are two separate functions that are entirely different. So if you separate those, you've got them on separate buses. And overall, you have more to attack to actually conduct a successful attack against a system like this. Okay. Thank you. I know that was really brief. We only had 15 minutes here. So at this point, I'm going to go to questions. Anyone have any questions? The stuff I talked about here. So implement a system. So kind of the whole point of this is Canvas, it doesn't appear to be widely adopted yet. It's in the system that I have built out there. There are some other systems because we looked at two separate manufacturers. They both suffer from the same issues. Don't rely solely on those controls. Put some additional security controls on your Canvas. Migrate to this. The existing hardware is supposed to support SECOC. And implement a security gateway. That's something that can be retrofitted into existing systems. You have your devices that actually have Wi-Fi and cellular. Separate those from the flight critical components of the system. Okay. Any other questions? All right. Thank you. For those who want to join me, I'll be right behind you with the avionics. And I'll actually demonstrate some of these techniques.