 I'm Penetrator Gensbeck, we, so we just presented on the main stage a framework for interfacing with the vehicular ad hoc network rather for, oh true, I'm sure we get one of these guys. We just presented a framework built on the mainline Linux kernel for interfacing with connected vehicles, so this concept of V2V V2X using by make modifications to the drivers for cheap accessible consumer off the shelf hardware such that you can do this now with a $20 Wi-Fi card rather than a $5,000 DSRC radio. We're going to jump around the slides here a little bit more. We're going to skip a lot of the sort of high level theoretical things. The concept of V2X just to reiterate a little bit for those of you who weren't at the talk. The rapid high throughput exchange of safety information between participants of this vehicular ad hoc network to enable, you know, enhanced safety and behavioral optimization functions within a highly dense traffic environment. So what this means is cars and infrastructure points are exchanging state information constantly in order to optimize things like traffic flow. Sure. So, okay, so some of the critical features or aspects of this stuff is to, you know, I mean, first and foremost it's safety to actually allow the cars to provide information to each other that they can't get through the normal sensors. So, you know, you can't see inside the car, you can't see inside the engine and the ECUs and all that stuff. So they have to encode that into, you know, over the air radio message so that other cars in the vicinity can actually decode it and get an understanding of where the network status is and kind of route their traffic around that and, you know, coordinate. So, you know, it has major impacts on the, on every aspect of the transportation network and really this reaches out into most every aspect of society as we know it. The transportation infrastructure and especially the connected transportation infrastructure will touch all the other sectors of critical infrastructure systems from energy and power distribution to financial to medical, etc. So the impact of having these connected vehicle technologies is that you enable unprecedented levels of safety functions that are simply not possible with the sensor networks on board one specific platform. It has, let's see, we're going to skip around a little bit. There are already some deployed technologies using VitaX, so these are rolling out already in commercial automobiles for the last couple of years like cooperative of that cruise control. I mean, you see a little picture of here where the members of the network exchange state information and do some math in order to, you know, reduce the amount of stress and breaking and to really smooth out the behavioral flow of these vehicles. We have, you know, collision avoidance, advanced driver assistance, automated ticketing and tolling is sort of to be implemented almost unquestionably in the future. This we might not like so much, but it is unavoidable. So you want to take this one? Sure. So our, our approach to kind of developing these things is to create an open source software solution that allows you to use commodity hardware, particularly, you know, specifically the Atheros 9K chipset on Linux to actually do this 5.8 to 5.9 gigahertz transmission in OCB mode and, you know, do V2V to allow people, to allow anyone to develop their own systems to test, to validate and to kind of further development of the V2V systems and vehicular ad hoc networks in general, so that the future standards can build upon, you know, the cooperative data collection that anyone can, you know, buy into essentially. So I have a particular taste for this because I spent about two years before I brought him on it, it was one year, digging around the depths, the solus chasm that is Linux kernel trying to understand the attempts to integration so far. And what we come to realize is that pretty much every group that has gone out to develop an open source framework for doing V2V has failed, has orphaned the project partway through a gone closed source and produced an incomplete and now obsolete implementation that is being considered for deployment. It's simply unacceptable. So what we've done is modify the mainline Linux kernel and, you know, a set of standard Linux network and drivers that enable you to interface with VAnet using a $20 Wi-Fi card and any computer that runs Linux. So, right, lessons learned, everybody sucks, sharing is caring except for herpes. Standards committees are, need some serious assistance developing these kinds of, you know, highly complex safety systems that require the participation of the security community. Hence, this goes back to motivation for developing this framework, giving every member of the security community, every person here and worldwide the ability to sit down and start developing applications and understanding fundamentally without, you know, doing an analysis of the protocols and the standards. What? I got a question. Is it a really good question? Because otherwise, I'm kind of wait, or if it's a really good question, I mean, yeah, come on up. Yes. Well, because the standards committees aren't really being engaged by a whole lot of the security community. I mean, I know the, so I know those that were, in fact, were part of the committee for, or the distribution that's developing the security layer, very much incomplete, very much lacking, in fact. So, right, V2V systems are being deployed without any existence of a functional 16092 layer that to me says that these people need some help developing them, right? And that's, and that's the standard is incomplete and still under revision as it is today. So, I mean, you know, one of the examples, one of the examples in 16092 that raised some concern for me was the actual generation of certificates, right? I think that they're supposed to be refreshed every day, right? I mean, that was the current, that was the scheme, I believe, no? So, I mean, no. But look, let's talk about this after we got about 20 minutes left. I'd be happy to have this discussion with you and we can come over some of the distributions of the committee. So, hey, hey, check your privilege. So, we're going to do a stack overview, right? We go from the physical layer 8211P. Actually, I think we'll go back a couple years. So, the physical layer is comprised by, and the MAC layer by IEEE 8211P, the management plane by IEEE 1609, and the application layer by SEJ2735. So, just to go over these quickly, 8211P. So, multicast ad hoc mesh networking mode that specifies no use of authentication, encryption, or association. Over 5.8 to 5.9 gigahertz ITS bands, ITS intelligent transportation systems. They use five and 10 megahertz with subcarriers within these channels. And this modulation scheme called OFDM, which is a standard, you know, standard Wi-Fi modulation scheme. Okay. So, all right, moving on to 1609. So, we have the definitions for the security services in 0.2, or in 0.2, the networking services, and the, you know, the sort of encoding dictionaries in 0.3. 0.4 is the multi-channel operation. And 0.12, I believe, is the identifier allocations for provider service IDs, which are kind of unique strings issued by IEEE to identify particular service types. All right. And then J2735 is the application layer grammar message dictionary that specifies the safety messages that will be used, you know, in interoperable V2V systems. So, basic safety message is the one that has been most developed so far. Messages that will be continuously transmitted at periodic intervals between all members of the VA net that include state information, things like the dimensionality, the heading location of the car, such that you can perform, you know, behavioral optimization, dispatch, reactionary, reactionary actions to the vehicle bus to augment the behavior. So, they have been under development since 2005, 2006. The, you know, NITS has been drafted in documentation, I think, since about 2004 on this. There's been a lot of talk, has been many major overhauls to the standards without really, without a deployment of a fully complete and compliant implementation. Still today. So, the development is very much still in flux. All right. So, some major changes to the standards. The actual message encodings have encountered some slight modifications, but significant enough that the actual parsers wouldn't work between, you know, going from I believe WSB 1 and 2 to 3, I believe. And the message dictionaries in J2735 have changed dramatically in the actual entire scheme. The encoding CMS changed. So, they're completely in compatible. Aversionally using this thing called DER and then to VR and then to UPR. So, three completely different, semi-related but incompatible encoding formats that change sequentially through each major revision of the standard. So, you have ASN1 specifications that are entirely incompatible. And in fact, the most recent one that was published doesn't actually compile and also uses type systems that are non-standard in ASN1 processing utilities. So, basically, I even went so far as to buy the spec, which is something I try to, I try to never do. And what, you know, it doesn't actually compile and you can't actually use it or parse it. So, what we did is take this cobble work of a broken standard and implement some of it in C so that it's digestible and functional and we'll show that in a little bit here. You know, there's some question in our heads about the development of the standards. So, there's been a lot of ambiguity that's being introduced. There's, you know, things like the message CRCs, the verification codes were removed in the most recent revision of J2735 from the roadside alerts, from the emergency vehicle alerts. The rest were the same, but you take out the error checking code. It's kind of weird, right? After 15 years of reservation for these, for the ITS bands for use in intelligent transportation systems, now suddenly they're up for sale to the, to the telecom, talking about being used for LTE. And we just described the overhauls of ASIN 1 and 2, a non-standard format. And then furthermore, there's just a, there's a lot of ambiguity that existed previously in the standards. She'll talk about it. Oh yeah, sure. So, I mean, these, these aren't necessarily designed flaws. These are just issues that can potentially lead to some implementation fuzziness. They're, the way that the information elements are packed, they're variable length, and the specification in a couple places, you know, waste, like a byte encoding the length. And in other places, there's actually a bit of ambiguity as to whether or not there should even be a byte there to begin with as to whether, you know, indicating whether a certain block would be there or not. And that just, it leads to some issues that could go further down in the pipeline, not in the standards, not on the standards level, but on the level of implementation where you could have someone develop buggy implementations that cause issues. And, you know, that's undesirable, definitely. So, I want to get into the code here since we're, since we're pretty short on time. I just went over a lot of this. But this is, this is important real quick. I mean, big attack surfaces, so right the, the nature of the VA net is that it's accessible from a single endpoint. From one, compromising one endpoint, you can propagate a message over the entire network. In this distributed mesh networking fashion, such that you can say, store information on a vehicle that does not get distributed until it goes, I'll say, across like a certain border. And, and you can propagate it further. You know, within the, the, you know, still being compatible with the standards. So, not only, it's not just malformed DSRC messages, it's compliant, compatible DSRC messages that you can store, you know, deliverables in and propagate at an arbitrary point throughout the entire network. You can perform privilege escalation in the public key infrastructure to hijack, say something like an emergency vehicles certificate, you know, cause cars to move out of the road or, you know, execute something like a platooning service to disabled vehicles. And, and, you know, probably the most obvious one maybe we should have started with is it acts as an entry point to isolated systems. So, the DSRC radio is hooked into the vehicle control bus and, right, so if you can send reactionary actions based on, you know, proximal network activity, that means that you can also send malicious actions based on your desires, right? So, there's active and passive adversaries. Can, can you wait ten minutes? Pretty please. Pretty please. So, I've spent two years, hey, check your privilege, buddy. All right. Please don't interrupt me during a talk. Please don't interrupt me during a talk. I mean, you, you get a goon or something? I mean, just like quiet for a minute, please. I'm plenty happy to argue with you when this is over. So, yeah, the, we're going to go up to our solution and how you use it, right? So, how to interface. I mean, so this talk, really, is about providing interface or a framework for interfacing with connected vehicles. Using Linux. So, right, it's never been easier, right? Just use Linux. We modified the Linux networking subsystems, MAG AT211, CFGA AT211 to support AT211P and then developed 60, developed a kernel driver, which we're, which is being integrated into the mainline kernel for the, all the 1609, you know, data elements and, and, and members such that you'll be able to use a J2735 networking utility, much like IW, which we provide to dispatch DSRC messages from the standard Linux wireless interface. Where we start is, so, bottom of the stack, modify the regulatory domain ad definitions for the intelligent transportation systems channels to the atheros wireless drivers or, you know, to the, to the arbitrary wireless driver right now. While it is built into the mainline Linux kernel, manufacturers of hardware specify a specific regulatory domain that hardware can operate in. So, you have to make a few slight modifications to each wireless driver, which are rather analogous and, and, and pretty much equivalent. We, it looks the same in the RTL and will release support for a wide set of standard drivers. You modify the regulatory domain in the kernel and in the user space utilities. So, in the net wireless interface and also in the CRDA and wireless REGDB at the, at the user space layer. And then modify the regulatory domain of the wireless driver as shown in the second picture there. And then you just, you define the filtering mechanisms for the 8211P frames. So, you, you know, there's, it, it is defined that 8211P frames that are compatible are data QS and action and specifically the types that are listed here. And you just enforce the use of multicast addressing. So all messages there are transmitted from 8211P and you need to use this broadcast BSSID, wild card BSSID, 6 octets of all Fs. And then in order to implement this in the user space, you, we made some simple modifications to the IW utility, which I'm sure everyone here has used Linux is quite familiar with. You add a definition to, to join and leave the OCB channels. You add compatibility for 5 and 10 megahertz with subcarriers within the channels. You, and then you can run this command, which we'll provide an example of in our GitHub repo to, I mean, it's that command right up there. And the result is that you're able to successfully join a 5 gigahertz channel in OCB mode using exclusive use of the channel and 10 megahertz subcarriers. So this is 8211P implemented. Next we're going to talk about implementing WAVE. Okay. So the implementation of WAVE is mostly to do with the actual messaging coding all the way up from the, the short message and, you know, the constituent fields in there. And, and that's primarily to do with actually just making really big parsers, or really big parser in a really big encoder, and encoder and decoder to actually allow you to turn these structures into a byte stream that goes and inject it into the wireless interface to go over the air. And then along with that, there's also the channel switching capabilities that need to be done to switch between the service and the control channel, which are handled through IW, just dispatching of IW set Chen, right? And then some user space links that allow you to use stuff like P-CAP inject to just send it off to the wireless interface directly and handle it all in user space and not worry about any kernel messiness. Still you? Let's go to the structs real quick. Okay, so here is the WAVE short message struct. I mean, this is a pretty simple definition, right? So you have subtype version, TPID, you know, then we have the end header information element extension, which is just a block of extra information regarding like things like location and heading or RF information like transmission power, data rate, that kind of thing. Moving on is the actual information element block, which contains these optional fields for the RF parameters, the routing, you know, external DNS's and various services that are provided potentially by the actual peer. Here are the sort of ancillary structs that are filled in there. We got the routing advertisements, service advertisements, and then the channel information and service information. I mean, these are all just, they encode the, I mean, more particular information for the advanced functions provided in the higher level, higher layer services that are built on top of this. Yeah. So then J2735 is, is analogically easy to implement, so we pulled some, some specification from the, from the broken ASN1 files, J2735 provided. So we, here's the struct, say for one of the messages, the basic safety message, which is one that most compatibility has been added for. We fill each of the fields up with data elements that are within the, the accepted range as specified by the standard. And then we take one of the structs that Nick just described. We fill it up with data and pack the basic safety message just into the, into the data field, serialize it using an encoding function that we wrote. And then dispatch it to the wireless interface using PCAP injects. And we can see, when we pulled up in Wireshark, it recognizes that a WaveShort message was transmitted. The Wireshark plugin for 69 is incomplete and, and doesn't recognize all the, all the types of packets and stuff yet. But we provide, you know, means to, to do this, to do testing and injection. What you can see here is that we have successfully using a nine, atherous 9K, $20 Wi-Fi card injected a DSRC message into the VANET spectrum. And the same thing you can do with other kinds of safety messages, emergency vehicle alerts and roadside advertisements. These are just simple examples of the same thing. And they're just as easy to transmit and inject. And then when you examine, right, the, the capture from Wireshark, you see all the data is there with all the proper padding. I mean, it's not really going to be too easy to see here, but. So what can you do with this, right? What, we have described so far as a means to, as we said, transmit and inject into the, into the, the wave spectrum, the intelligent transportation channels to interface with the VANET. So you want to be a master, see if you can hone like these. These are five, five sort of levels of increasing complexity. You can perform denial of service on, say, single antenna. Well, you can perform denial of service on the PKI infrastructure. The example here we give is on single antenna systems where you can actually cause a collision attack by transmitting out of sync with the rest of the nearby network. On top of that there, I mean, so you can enumerate over, so the actual nature of the, of the network is such that you can enumerate over the actual services provided just by observing the traffic across, and that allows you to characterize a great number of the architectures in the cars that are along the road. And if you can gain information about the architecture, specific stuff, the implementation specific stuff on the car, you can actually fingerprint that and say that, oh wow, you know, this car is running something that I know is vulnerable and I want to inject and mess with it in some particular way. You can, as we described earlier, hijack or perform privilege escalation in the public key infrastructure to hijack a certificate for an emergency vehicle or some other kind of privileged user that's allowed to execute built-in services like platooting which drives, which makes a vehicle come to a stop on the side of the roadway or, you know, et cetera. And if anyone would ever want to do that, right, you can also become a mobile toll booth. Sure, I mean, if the compromise, it requires, you know, the exploitation of these privileged users to actually gain access to their certificate. And if you're able to do that, you can swipe their privileges and actually start masquerading around along the road and do things you're not supposed to, right? So, I mean, that's the idea in terms of these exploits, or, you know, not exploits of these particular attack vectors. Yep, yep. So, and there's, you know, this also introduces other types of, of putting a potential for exploitation of vulnerabilities that exist today. Right, you can easily, you know, the point about having, you know, network access from one single entry point and being able to probably get a message, that means you can probably get things like malware across the entire network from one entry point. And moreover, if an entry point has a vulnerability that is implementation specific, not even one that exists at a theoretical basis and the standards, that provides you the ability to compromise all other systems that are compliant that might not harbor the same vulnerability. You can reverse engineer, wirelessly now, reverse engineer vehicular architectures the same way that you would reverse engineers say a vehicle control bus by performing enumeration of built-in diagnostic services in the DSRC protocol. You can, let's see, you wanna talk about that? I mean, so I mean, some of the nature, or the nature of this, of the vehicular ad hoc network in V2X particularly is that these vehicles communicate to each other right, but the vehicle also bridges out to external networks, be it through Wi-Fi access points or LTE. So if the vehicle's able to be compromised by messages going across DSRC, then you can actually use that LTE, the card, the cell phone chip on the card to actually pipe data up to wherever you want and potentially even get data back down and plug in backdoors, whatever the hell you want. I mean, that's the idea. Yep, and even more than pining, the whole point of this, while it is, it is neat to showcase, right? These kinds of attacks, it's more about providing a platform that allows everyone homogenously to participate in the development of these standards and of these future architectures. The state of them today very much reflects the need for participation by the security community to develop these to a point where they are resilient and robust and ready for deployment in safety critical infrastructure systems that are gonna involve more network traffic than we've ever seen before in this kind of system. So you get to participate. This code, we've released our framework on GitHub and we're going to continue development and contribution to it, to extend support to a wide range of wireless drivers and to continue developing the J2735 interface as the standards become developed further and eventually integrate 1609 when the full family is complete and ready. So, unfortunately we don't have more time to do, well we'll be doing some stuff over in the Cracking Village you can come and ask us questions and we can show you stuff. I wanted to thank these guys, especially that one there in the middle for helping us get through this over the last couple years. So here's the GitHub link, here's some references and thank you very much.