 Welcome, y'all, and thank you for attending my talk today titled Collecting Cans, A Bridge Less Traveled. A quick note I'd like to share before we hop in. I've captured links to many of the resources mentioned in this talk as a slide near the end of this deck, and I'll paste them into the Discord chat as well. Quick overview of who I am. I am Pierce Berry from Austin, Texas. I am a former Metasploit developer and former manager of Metasploit development at Rapid 7. I find myself currently doing security research, which I'm enjoying very much. And in full disclosure, I'm also very much a newb when it comes to aerospace stuff, but I do enjoy flying and following the progress in spacing, technology, and travel. I also enjoy learning about how we've come to where we are with respect to things aerospace, reading books like Skunk Works and also Hidden Figures and dragging my family to both locations of the Smithsonian Air and Space Museum in Washington, D.C. And if you look closely behind the SR-71 Blackbird there, you can see the space shuttle discovery hiding tucked in the back. And that's me. So, cans. Cans is the controller area network bus, right? What's the deal with the bridge? Well, I'll tell you this much. The bridge we'll be talking about today is not any of these bridges. In actuality, the bridge we'll be talking about today is the Metasploit hardware bridge, which is actually software and is part of the Metasploit framework package. It acts as a conduit to connect Metasploit framework sessions to new and exciting places in the physical world. No longer bound to the world of traditional network connections. And you can have concurrent sessions connecting to different devices via the hardware bridge just as you do for your usual Metasploit shells. And fortunately, unfortunately, it is not actively and actively maintained portion of the Metasploit framework these days. But the beauty and promise of open source software, which Metasploit framework very much is, the code is available and usable still. It may contain vulnerabilities or brokenness. So use it your own risk and please don't pester the rapids of the developers to work on it. The post there at the bottom right was the announcement blog post by the hardware bridge creator himself, Craig Smith, or Zombie Craig, as some of you all might know him. Y'all also might know Craig through the car hacking village or some of his other work, such as his book on no starch press, the car hacker's handbook. And Craig's work with the open garages.org is also something he's noted for. Craig was the director of transportation, security and research rapid seven when he created the Metasploit hardware bridge. And I had the pleasure of working alongside him in a small capacity to help provide code reviews and testing. As you can expect, the primary focus of the hardware bridge was initially cars and car related things. Let's hold up just a second to make sure we're not getting ahead of ourselves and take a quick moment and answer the question, what is Metasploit framework? Metasploit framework is an open source penetration testing framework created in 2003, originally written in Pearl and ported over to Ruby a few years later. It runs on many operating systems and is included in some security focus distributions. It has a command line interface and it supports a handful of module types with the goal of making it easy for contributors around the world to craft new functionality, which can be easily integrated into the framework. For others to use. It even allows you to write modules and languages other than Ruby. Some module types help discover systems on a network. Others exploit a vulnerability on a target. And others can help elevate your privileges or exfiltrate data from a target. Modules can do many cool things. Many interactions with compromised targets are over sessions, which themselves can be thought of as a usable connection to a compromised target. The Metasploit instance can support multiple simultaneous sessions, allowing the user to switch between them as needed. And Metasploit remains, to this day, a popular tool for pen testing, red teaming, hacking, and research. And the Metasploit hardware bridge was added to the framework ecosystem to help provide a path to different targets in the physical world. As mentioned a few slides back, the primary focus of the Metasploit hardware bridge was initially cars and car related things. Like the brute forcing module targeting static key garage door opener systems or fuzzing data against specific can IDs of a vehicle's CAN bus or the pyrotechnical device deployment tool, PDT, which ultimately may not be quite as exciting as you think, but is still a personal favorite of mine. But how does the hardware bridge logic allow these Metasploit framework modules to exit the matrix into the real world? Let's do a quick rundown of the major aspects of the hardware bridge design. First of all, it's open source. Just like Metasploit framework is. The code is out there in public repos and available to all. Second, it uses modules. Again, capitalizing on the soul of Metasploit's coolness and looking to make it easy for others to create new modules themselves and add onto the bridge, as it were, by extending that pattern to include hardware. Being a part of the Metasploit framework, the hardware bridge uses many of the same commands and concepts that Metasploit users are already familiar with, looking to make it an easy lift for existing users to pick up and go. This usage familiarity also extends to sessions, as we discussed a few slides back, by providing the ability to have multiple devices connected to the hardware bridge simultaneously, allowing a user to switch between devices in the same fashion you would switch between shell or interpreter sessions in the Metasploit framework console. And for folks new to Metasploit, there are many resources out there for new users picking up Metasploit for the first time, just for what that's worth. And the hardware bridge follows a server client model, where the hardware device is used in the connection to the outside world rely on some relay service logic that presents a REST API interface, which the hardware bridge logic and Metasploit will connect with. This provides an abstraction, which is not centered around a usual required physical connection between your computer and the device you are hacking, rather more similar to how Metasploit can interact with compromised targets, whether they are local or remote in nature. Lastly, the hardware bridge makes it easy to utilize or leverage other open source software in order to work smarter, not harder, when adding new capability to the hardware bridge. Some examples of open source software that the hardware bridge modules currently use include Socket Can for CAN bus interactions, RF Cat for RF interactions, and Killer B for ZigBee interactions. Use of these open source libraries and tools makes it easy for Metasploit users to add support for any other of their hacking devices, which are already supported by these existing open source tools. And on that note, some of what we'll see today may not be plug-and-play ready for use with airplanes or other flight craft, but might be close and maybe someone here might be inspired to close that gap. So one technology the Metasploit hardware bridge provides connectivity to is the CAN bus. A few quick basics around the controller area network, or CAN bus. It was introduced in the 1980s by Bosch with a focus on automobiles. It has a simple two-wire implementation, which reduces both installation complexity and cost. And these days, CAN buses appear in many places, including aircraft systems, anywhere from in-flight entertainment to flight control systems. A quick little side note here. Patrick Kiley gave a cool talk here at the Aerospace Village at Defcon 27 about some CAN bus research he had been doing at the time. It's really worth checking out the YouTube recording of it, and there's also a detailed report of his research on Rapid7's website. Those links will be in the resource section of this talk. CAN bus is still really common in automobiles. In fact, it is part of the OBD2 standard plug connection that cars and trucks sold in the US have been required to have for the past 25 years, and required for the past 20 or so years for cars and trucks sold in Europe. And the Metasploit hardware bridge works with some of the most popular OBD2 reader or scanner devices, which include or are compatible with the Elm 327 chip. So let's see a demo that actually requires no special hardware to run. For what it's worth, I'm running this demo in a single OBD2-1604 VM instance, split across two terminals with a recent build of Metasploit framework. I don't necessarily recommend OBD2-1604 these days, as the official standard support for that release sunset of this past April, but it was something I had handy, and it was what the original testing that I did with hardware bridge was done under. I expect that what you'll see here today should work with newer and other Linux distros. In the lower window here, we'll first utilize the socket CAN driver to allow us to create a virtual CAN bus for our testing. This virtual CAN bus will appear as a network interface called VCAN 0. This module that we loaded was already present in my OBD2 installation. I did not need to go find it somewhere. It's very convenient. And once we have the network interface loaded and configured for their virtual CAN bus, we'll run a tool called CAN dump, which prints any traffic that appears on our new VCAN 0 interface to standard out. And in the upper window, we'll start up an instance of the Metasploit console. And first thing here, once we've got the console spun up, is that we'll use the local hardware bridge module to interact with our virtual CAN bus. This will act as the relay code that will relay messages and commands and data between our session, hardware bridge session we will create with our device. In this case, it's the virtual CAN bus. Now we will switch over to use the hardware bridge connect module to connect to that local hardware bridge relay service. And you'll see the disclaimer and warning here that you are about to leave the matrix, which is true, except we're just using virtual CAN bus, so it's not as impactful in this demo, less risk. We can see from our sessions that we have a hardware bridge type session and we can interact with it by specifying the dash I option and a 1 to tell it what number session we want to interact with. We get a hardware bridge prompt similar to the interpreter, if you all have used the interpreter before, and we can do help and see a list of our supported commands. And now that we've established a session between the hardware bridge and relay service, we'll run a sample module after we actually list the supported buses first. So we see that there is a V CAN bus that we can use. So now we'll run a sample module that floods the CAN bus with packets, which will make a 2006 Malibu's temperature gauge appear that the vehicle is overheating. Again, in this case, we're not actually connected to a 2006 Malibu's CAN bus, but if we were, we would see the temperature gauge saying it's overheating at this point. You can see those packets on the CAN bus or our virtual CAN bus in the lower window from that CAN dump output. Just a quick note on module types. A POST module, like the Malibu overheat module that we just ran here, is a type of module designed to be run after a session to the target or target device has been established, or put another way, POST exploitation, though we didn't need to actually exploit anything to gain access to our virtual CAN bus. Something else neat about using the socket CAN virtual CAN bus driver is that you can take packet captures via standard tools like TCP dump or wire charge. Here's a capture of the CAN bus traffic. Here's a capture of CAN bus traffic from the Malibu overheating module we just ran, as viewed in wire chart. This ability allows you to see what is going on on the wire, and can also be helpful when doing hardware bridge module development and testing. So that demo operated in a fairly safe space using the virtual CAN bus and all. When doing this sort of thing in real life, you'd follow the same steps I showed in the demo, but using an OBD2 scanner that contains an Elm 327 or compatible chip, and you'd swap the local bridge module step for running a script in the Metasploit tool slash hardware directory called Elm 327 underscore relay. The original PR for this code has a nice step by step for going this route, as well as the virtual CAN bus route I showed in the demo. And I've included a link to it in the resource links. For clarity here, both of the picture devices use an Elm 327 or compatible chip, and should both be supported by the hardware bridge. The one on the left uses a USB connection to your computer or laptop. Whereas the one on the right uses a Bluetooth connection. And disclaimer, I'm not a hardware guy. And my inexperience in aviation doesn't help me here. But I'd like to believe that there is an easy enough lift to either use existing devices, which are supported by the hardware bridge, like these pictured here, to connect into an airplane's CAN bus or to add support for other devices, which are better designed, better suited for connecting into an airplane's CAN bus to the hardware bridge. Another type of technology that Metasploit hardware bridge provides connectivity to is RF. And though I may be green to aerospace, I do know that aerospace does use radio communications. The Metasploit hardware bridge has a few RF modules which support the yardstick one device. As the website for the yardstick one states, the yardstick one is a sub one gigahertz wireless test tool controlled by your computer. It connects via standard USB and has capabilities as broken down there above, also taken from the website. The yardstick one is manufactured and sold by Great Scott Gadgets and can be picked up online from a number of retailers. Let's take a look at several ways the hardware bridge can work with the yardstick one to play in the RF space. The above screenshot shows what my Ubuntu VM kernel logs display when I plug in a yardstick one into my USB port. You can see the product and manufacturer data there align with our expectations of what we just plugged in. When using the yardstick one with the hardware bridge, we run the RF cat underscore MSF relay script in place of the local hardware bridge relay that you saw in the previous demo. As the name implies, RF cat underscore MSF relay is designed to relay commands from frameworks hardware bridge to a connected RF cat supported device like a yardstick one by setting up the locally listening rest endpoint that the hardware bridge can connect to and use for communicating commands and data to the connected yardstick one device. Sharp eyes here may have caught that this Ubuntu VM is an 1804 flavor. I had originally tried to get this working in my 1604 VM but discovered that the Python 3 version there was not current enough for all the required package dependencies of RF cat underscore MSF relay. So I moved to 1804. Sadly, I discovered that there now exists a type error in the message passing between the hardware bridge and RF cat MSF relay likely due to the industry shift over to Python 3. As I'm certain we were using Python 2 in the original hardware bridge development four and a half years back. While this might be an easy enough item to fix, I didn't leave myself enough wiggle room to dig in before the talk deadline. So I'll offer a screen grab here of the output on the hardware bridge side from my original testing. As you can see here, similar to the last demo, we use the hardware bridge connect module to create our connection to the relay, in this case the RF cat MSF relay. We are running from the previous slide. Once connected, we see a new session of type hardware bridge has been created and that it's related to an RF transceiver device, i.e. our yardstick one. We can then, same as the last demo, interact with that session using the sessions command with the dash i option to specify which session number we want to interact with. And from there, we get the hardware bridge prompt where we can request status and see what we are connected to. You see that we are connected to an operational yardstick one, as well as some firmware and hardware information about the connected yardstick itself. This screenshot is of some module documentation for the fairly simple, simple transmitter hardware bridge post module which landed with the original PR, which again is linked in the resource slide at the end of the deck here. This shows a next step that we could do once we've connected to the RF cat MSF relay had I had the messaging issue worked out in time for this recording. In the above, the hardware bridge transmitter post module options listed there can be used with the transmitter module to transmit on a given frequency for a given number of seconds. And you can see what an example run of that module looks like at the bottom there. Pretty straightforward little module which was ported over from code by Andrew Mohawk, I believe. Another post hardware module, post hardware bridge module related to RF is the RF ponon module, ported over from a utility of the same name that was authored by Corey Harding. This module is described as a generic AMOK brute forcer with PWM translations. And this code has been demonstrated to work against static key garage door openers. So one could say that successful execution of some metasploit commands could literally open doors for you. So a quick look at what hardware bridge post modules currently exist in the official Metasploit GitHub repo. Some of these we discussed today, some we did not, but they're all there in the public repo. And again, the Metasploit hardware bridge currently is an un-maintained project within Metasploit framework. So please don't heavily bother the Rapid7 Metasploit developers about it. But it's all open source and it might be of some interest for some of y'all to use or expand upon. And that's it for my talk today. I'd like to thank y'all for listening and to thank you to the Aerospace Village for having me. I'll be around in the Discord chat to answer any questions anybody has. And as promised, here's some of the links to resources I cited today. And hopefully I've already dropped these in the Discord chat here by now. But if I haven't, I should be doing that right this second. Y'all have a safe and fun rest of your DEF CON.