Rapid7 Blog

Car Hacking  

Building a Car Hacking Development Workbench: Part 1

Introduction There is a vast body of knowledge hiding inside your car. Whether you are an auto enthusiast, developer, hobbyist, security researcher, or just curious about vehicles, building a development bench can be an exciting project to facilitate understanding and experimentation without risking possible damage…

Introduction There is a vast body of knowledge hiding inside your car. Whether you are an auto enthusiast, developer, hobbyist, security researcher, or just curious about vehicles, building a development bench can be an exciting project to facilitate understanding and experimentation without risking possible damage to your vehicle. This is a perfect project for people of a wide range of ages and skill levels. Even if you have never worked on a car before, or you do not feel like your Electronics-Fu skills are strong, there are dozens of blogs, training videos, and reference guides on the internet that can supplement the information in this guide. This the first part of a three-part series. Part one covers how to build the physical bench. Part two will discuss how to read wiring diagrams and serve as the primer to part three, where we will re-engineer common circuitry. A car hacking workbench consists of the critical electronics that control the vehicle, plus bits and pieces of the electrical harness. This is like a neurosurgeon operating on a heart, brain, and spinal cord outside of the human body, except more accessible to the squeamish. Within this guide, we will explore: Finding a suitable vehicle Extracting the critical components Building and powering a workbench Re-engineering circuits and sensors Experimenting with your bench You can adapt the following steps to any vehicle. We chose a 2006 Dodge Stratus, 2.7L, four-door sedan. This vehicle has a Controller Area Network (CAN) Bus interface accessible through the On-board Diagnostics (OBD-II) port. By reassembling the electrical components, we can connect to the vehicle's “brain” through the OBD-II port, and experiment with traffic on the CAN Bus. Note: Some vehicle manufacturers do not share standards between production lines, or even between builds of the same make or model that are a year apart. Find information, such as wiring diagrams and parts, that are specific to your vehicle. For example, If you are working with a heavier class of vehicle, it may interface with the CAN Bus through a J1939 diagnostics port instead of an OBD-II connector. You may also find that newer hybrid vehicles have different power voltages that you need to be aware of while constructing your bench. Tools This project is going to take more than just a simple screwdriver and a pair of clippers. This is not a complete list, but here are some tools that you may want to have on hand: Phillips and flathead screwdrivers in assorted sizes Loppers and/or wire cutters Basic set of standard and metric socket wrenches, plus extension bits Wire strippers Safety equipment (gloves, goggles, light-weight face mask) Voltmeter (a cheap basic model is fine) Multimeter Flashlight Important Note: When working in an old and dirty car or environment (such as a vehicle in a junkyard), WEAR A DUST MASK! Removing an electrical harness can expose you to heavy amounts of dust and bacteria. When the electrical harness is out of the car, wipe down all the components and cables with a small amount of a mild soap and water to reduce the risk of illness. Time Requirements Anyone with a moderate amount of mechanical or electrical knowledge could complete this project over a weekend (16-20 hours). Those with more limited knowledge of these two key areas may need two weekends: One to remove the physical components and a second to reassemble and test. Part Requirements No two vehicles are identical; however, all vehicles possess some commonalities. Your build may not require every component mentioned in this guide, but you should be at least familiar with the following terms: Power Distribution Center (PDC) – Channels power from the battery into the rest of the vehicle. Junction Box (also known as a fuse panel) – Fuses protect the wiring system. If a component faults and causes a power surge, the fuse will sacrifice itself to protect the wires in your vehicle from melting and causing severe damage. Powertrain Control Module (PCM) – Controls input and output to over a hundred various sensors placed on the engine and throughout the vehicle, then injects data into the CAN Bus, the vehicle information network. Generally, the PCM is a combination of the Engine Control Unit (ECU) and Transmission Control Unit (TCU). This is important to know, as wiring diagrams can introduce confusion by using PCM, ECU, and TCU interchangeably. Instrument Cluster (IC) – Located in the dash, this device is monitored by the driver and contains indicator levels, speedometer, RPM gauge, etc. Immobilizer (sometimes referred to as the skim module) – Connected to the ignition switch in the steering column, the immobilizer authorizes the key in use while starting the car. If the immobilizer is missing, unpowered, or the wrong key is in use, then the car will not start. Body Control Module (BCM) – Controls the functions associated with various circuits of the vehicle's accessories and communicates via the CAN Bus. May share a housing with in junction box. Ignition Switch & Key – The keys, tumbler, and power feed that start the vehicle. In order to source a vehicle to use for this project, we recommend that you call junkyards in your area and ask if they have any wrecked vehicles that still have all their components, electrical harness, and keys. Yes, it is that simple. Pro Tip: make friends with the working professionals at the junk yards. I am not saying have them over for dinner or invite them to your weekly poker game, but explain your project and what you are looking for. Vehicles regularly come into junkyards following an accident. So, let the junkyard know what you're looking for in a vehicle. If they don't have what you're looking for, they may call you when something arrives. As for the type of vehicle that you are looking for… that is completely up to you. If you just want a workbench to train on, then any vehicle newer than 2005 will do. Just remember that larger-class vehicles, such as class 3 or 6 , may use a J1939 connector instead of an OBD-II. Step 2 – Removing the Electrical Harness First, and most important: DO NOT CUT ANYTHING! At least not yet, anyway. Before you grab the clippers and go to town hacking into wires, I suggest taking the time to identify and label components, connectors, couplings, wires, and sensors. This will save an incredible amount of time in the long run. If you skip this step now, when everything is out of the vehicle and you're building your workbench later, you get to play a not-so-fun game called, “Where Does This Go?” (You may notice there aren't any pictures supporting this process) I played the game, and it's not fun. I can positively recommend: label everything before you begin! Even if you don't know what every piece under the hood is, marking items with a simple A, B, C pattern now can significantly reduce confusion in the future. Second, take detailed pictures of connectors while they are still connected. If you choose to forego pictures, don't worry. Most connectors are designed to fit in only one socket and in only one direction. Also, for the ease of maintenance, engineers use couplings to attach wiring extensions from sensors and components to the main electrical harness. After completing the labeling and identification process, start to remove the components and wiring harness. There are two practical ways of removing everything that you need. The first way is to simply unbolt and disconnect everything from the front of the engine compartment and unbolt anything in your path until you reach the steering wheel, then remove everything in one long piece. There is a tiny hiccup in this course of action: getting the cables out in one piece may require passing everything through a hole in the vehicle's firewall, which may be smaller than some of the major components. To make this process simpler, disconnect any unit that will not fit before passing the cables through the hole, pull the cables just far enough, and reconnect the unit when the last connector is through the other side. This way you won't forget how something was connected in the first place. The second way is to cut the entire system into two large pieces: one consisting of everything under the hood and a second made up of everything within the vehicle. This method makes it easy to remove all pieces from the vehicle, but will require that you reconnect two pieces with electrical caps or other types of connectors. Now, grab your safety gear and tools, roll up your sleeves, and get to it. Just a heads up, do not wear something that you will want to wear ever again. This can be an extremely dirty job. Mike Rowe would be proud. Furthermore, if you cherish your health, even just the tiniest bit, wear a dust mask. Step 3 – Initial Testing Now that everything is out of the car, make sure that it can receive power. If you cut the harness into pieces, you will need to reattach the cut wires. Reconnect the harness to the instrument cluster, PDC, PCM, BCM, and ignition systems. At this point, you can just lay everything out across a large flat surface. Powering your harness is different from normal power management in a vehicle. Some components can be directly powered from the battery and others wait until the car is running. Plus, when the car is running, everything is powered from the alternator, which is an AC circuit. Instead we will need to use power from an outlet, which is a DC circuit. Luckily, we are not powering an entire car, so we can replicate the battery's DC connection through the Power Distribution Center (PDC). Car batteries generally hold approximately 12.6 volts (or slightly higher) when the vehicle is not running, and will shoot up between 13.7V to 14.7V when running (except for hybrid or electric vehicles, which are completely different ball games, and too much detail for this section). If you have a variable power station, you are good to go, but portability and expense can become an issue. During this project, I used a generic variable DC power adapter cranked up to 12V at 1.2 amps and did not experience any trouble powering the harness and components. You may have to strip the ends of the adapter and either solder the wires (safe option) or like me, clamp down partially stripped wires with alligator clips (not recommended, but okay for initial testing only). Screw terminals are also a safe option, and perhaps the most versatile power management utility if you are unsure how you want your bench to look at the moment. To complete the power connection, find the positive terminal on the PDC, usually indicated with a red plus symbol. Inside the PDC there should be a metal bar that transfers current to the various fuses and relay circuits, and in turn to the rest of the vehicle. Connect the negative (grounding) wire of the adapter to a vehicle ground. If you are unsure if the circuit is complete, check for continuity with a voltmeter by connecting one probe on positive and the other on cables (which we recommended that you label earlier) to ground. Keep changing the probe from one ground point to another until the voltmeter shows continuity and/or holds a tone indicating the completed circuit. Finally, plug in the 12V DC power adapter to the power source (i.e., a wall outlet). Provided the ignition system was hooked up, power is available, the immobilizer is connected, and the keys are in the ignition switch, when you turn the key, the instrument panel should light up. Just about every sensor available through the instrumentation cluster will indicate there's a problem. Take a deep breath, it's normal: obviously, a missing car engine will cause warnings! If you didn't get power, check connectors, couplings, and fuses first. If power still isn't going through the system, grab your handy-dandy multimeter and check all available grounding wires. If you have never used a multimeter to check volts, resistance, amps, or continuity, then I suggest watching this video from Ratchet and Wrenches. Switch your multimeter into continuity mode and touch each prong to the positive and grounding (negative) wires of your adapter. If you do not hear a beep, the circuit is incomplete. Move the negative prong of the multimeter around to various grounding points until you hear a beep. Now move your grounding (negative) wire from your power source to that new location. This should correct the problem. Important Note: When power is available, and the instrument cluster is active, disconnect the DC power adapter from the power source, THEN the PDC and grounding point. Failure to do so could create a spark, shock you, or possibly start a fire in a worst-case scenario. Step 4 – Unwrap & Thin Out the Electrical Harness Now that you have power to the main components, start removing the black electrical tape and fire barrier from all wires in the harness. I recommend wearing gloves, as the stickiness of the tape can tear into your hands after a while. You may be tempted to cut into the tape surrounding the wires, which is fine, but make sure that you do not cut any of the wires during the process. After stripping the tape from the wires, spread the electrical harness and connected components as far apart as possible. Examine the harness for any connectors that are not plugged into any equipment. These connectors are not needed to complete the bench, and can be removed. While clipping connectors, leave a 6-8” pigtail. You do not want to clip the wires at the base of the connectors; depending on how you develop your workbench beyond this guide, you may need one of those connectors in the future. Now that unnecessary connectors are gone, remove excess wires that are not connected to anything. This will help thin out the harness and keep the cable management process clean. Step 5 – Design & Build Your Workbench This step in the process is COMPLETELY YOUR OWN! That said, you may have space requirements. While I was building my workbench, I wanted it to be portable and not too bulky, so I could ship it across the country for peers to learn from and practice on. Pictures available online through web searches show that some people have the system stretched out on a lab table, a large board, or even the garage floor. Others have used Lego and Erector sets to build vertical mounting racks.  My entire bench had to fit inside a large travel case, so there were height, width, and length requirements. No matter how you choose to build your workbench, leave enough physical space between components that both hands can easily work inside without a struggle. Design, build, and then re-power the unit. If the instrument cluster lights up after turning the key to the start position on the ignition switch, you are good to go. Ready for part two? Read it here.

Metasploit Framework Valentines Update

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features.…

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features. Everyone Deserves a Second Chance Meterpreter Scripts have been deprecated for years in favor of Post Exploitation modules, which are much more flexible and easy to debug. Unfortunately, the Internet still abounds with blogs and other advice still recommending their use, and it is clear the word still hasn't gotten out. In a previous Metasploit release, we attempted an experiment removing all of the scripts that already had Post Exploitation modules. Unfortunately, this caused even more confusion since it looked like Metasploit was broken. Now, Metasploit will kindly suggest that users explore the vast world of Post modules instead. For now, all of the built-in Meterpreter scripts you know and love are back for one last dance, but you should really look at dumping those guys. Remember, there are many more Post modules in the sea! Traverse your Way into my Life With this release, we have a number of directory traversal updates, both offensive and defensive. First off, we have added a module for exfiltrating arbitrary data from a Cisco Firepower management console. The default credentials are also documented, so if you run into one of these in the wild, there is a good chance you can make a special connection. And in the "it's not you, it's me" department, Justin Steven has been busy finding and fixing a number of directory traversal bugs in Metasploit's session handler, that can be exploited if you interact with a rogue Meterpreter session. Of course you should practice "safe sess(ions)", but if you can't, update your Metasploit Framework and get protected. You Stole my Creds, my Phone, my Car, and my Heart If you're looking for credentials to add to your little black book, Metasploit release also adds credential extraction modules for Advantech WebAccess, Metrocontrol Weblog, and Cisco Firepower Management Console. And once you have filled your cred list, you can now manipulate them in a more powerful way thanks to improvements in credential management. Android Meterpreter adds a number of new features sure to make keeping up with your bae even easier (that doesn't sound creepy at all does it!) Android Meterpreter now supports stageless HTTPS, which makes it easier to keep your payloads secure, fast, and reliable. If you have trouble with your Android sessions falling asleep after you connect, keep them going all night (and day) long with the new wakelock command. Metasploit makes its first foray into car hacking with a new hardware bridge session type, along with a number of new modules for administering and exploiting OBD-II / CANbus networks in modern vehicles. But, it's not limited to just these, you can add your own hardware devices by implementing the HWBridge specification. Don't let your car spoil your next date, hack back! There are many more improvements and modules to enjoy as well, and they are all available now. So why not update your console with someone special, and make everyday a very special Metasploit Valentines day. For full details, see the latest detailed Metasploit release notes: https://community.rapid7.com/docs/DOC-3575

Car Hacking on the Cheap

Metasploit's HWBrige comes with an automotive extension. This works out of the box if you happen to have a SocketCAN compatible CAN sniffer hanging around. However, if you don't have one, there is a decent chance you have a cheap sub $10 vehicle dongle in…

Metasploit's HWBrige comes with an automotive extension. This works out of the box if you happen to have a SocketCAN compatible CAN sniffer hanging around. However, if you don't have one, there is a decent chance you have a cheap sub $10 vehicle dongle in a drawer somewhere. If not you can probably pick one up on ebay super cheap. Metasploit supports the ELM327 and STN1100 chipsets that are very popular in these dongles. Metasploit comes with a tool to connect these devices provided your device uses a USB connector or is Bluetooth. Here is a sample of an inexpensive ELM327 Bluetooth dongle: These devices are not very fast and are only meant to query diagnostic services. However, it is possible to transmit raw CAN packets with these devices. These devices are not good for sniffing, but Metasploit can use them for transmission just fine. Both the USB version and the Bluetooth version speak serial. So you will need to get the ruby gem ‘serialport' $ gem install serialport Once that is installed go ahead and plug in your device. If it is a bluetooth device you will need to configure your system to connect to that as well: $ rfcomm connect /dev/rfcomm1 "00:0D:18:AA:AA:AA" Once your device is up and running and you know what Serial port it is connected to (check dmesg if unsure) then you are ready to start. First you must run the elm327_relay.rb program: $ cd tools/hardware $ ruby elm327_relay.rb -h Usage: elm327_relay.rb [options] Specific options: -b, --baud <serial_baud> (Optional) Sets the baud speed for the serial device (Default=115200) -s, --serial <serial_device> (Optional) Sets the serial device (Default=/dev/ttyUSB0) -h, --help Show this message As you can see it takes only two parameters, the serial port and the baud of your device. Specify any changes you need from the defaults then start the relay. $ ruby elm327_relay.rb -s /dev/ttyUSB1 Connected. Relay is up and running... If you see a message that the relay is up and running then you are all set! Currently the relay's port is hard coded to port 8080. So now from your local machine or another machine on your network with Metasploit you can connect to this relay msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > run [*] Attempting to connect to 127.0.0.1... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-01-31 13:32:40 -0800 [+] HWBridge session established [*] HW Specialty: {"automotive"=>true} Capabilities: {"can"=>true} [!] NOTICE: You are about to leave the matrix. All actions performed on this hardware bridge [!] could have real world consequences. Use this module in a controlled testing [!] environment and with equipment you are authorized to perform testing on. [*] Auxiliary module execution completed msf auxiliary(connect) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- 1 hwbridge cmd/hardware automotive 127.0.0.1 -> 127.0.0.1 (127.0.0.1) That's it. You can run all the same post modules like post/hardware/automotive/getvinfo. Currently only the CANbus interface is supported on the ELM327s but additional protocol support maybe added. Also do not expect great speed from one of these devices. If you have a post module that floods the bus, it probably will not work very well using an ELM327 chipset.

Exiting the Matrix: Introducing Metasploit's Hardware Bridge

Follow the white rabbit... Metasploit is an amazing tool. You can use it to maneuver through vast networks, pivoting through servers and even embedded OSes.  Having a single interface for your team and yourself to control a web of servers and networks is extremely powerful.…

Follow the white rabbit... Metasploit is an amazing tool. You can use it to maneuver through vast networks, pivoting through servers and even embedded OSes.  Having a single interface for your team and yourself to control a web of servers and networks is extremely powerful.  But sometimes you want to do more than control the virtual world. You want to control the physical world. You need to exit the Matrix. We recently announced a new addition to Metasploit to help you do exactly that: the Hardware Bridge API. The Hardware Bridge API extends Metasploit's capabilities into the physical world of hardware devices. Much in the same way that the Metasploit framework helped unify tools and exploits for networks and software, the Hardware Bridge looks to do the same for all types of hardware. From within Metasploit you can now branch out into a Metasploit compatible hardware device to remotely control and use it for your penetration testing needs. How does it work? There are two ways to connect a physical device to Metasploit: Build support directly into your firmware to make your device Metasploit compatible, or Create a relay service. A relay service is required if your device does not have a way to naturally communicate on Ethernet. Many useful hardware tools such as Software Defined Radio (SDR) devices are controlled solely through a USB port. In order to connect an SDR device like this to Metaslpoit then the machine that SDR is connected to would run a relay service. This uses a REST API, the details of which can be found here: Metasploit Hardware Bridge API. Why REST? There are trade-offs with any solution. Embedded systems typically don't support REST because that would require they run some types of mini-web server. Newer embedded systems, especially IoT devices, have no problem running web servers locally but if you have hardware that doesn't have WiFi or Ethernet capabilities we make it easy to create relays for your device. We will provide several examples in the Metasploit tools section demonstrating how to leverage the Metasploit framework to handle all of your http/web needs so you can focus on serial, usb, or whatever communication channel your device uses. We also plan on providing libraries for common microcontrollers and embedded systems to quickly allow your device to support Metasploit. So what can the Hardware Bridge do? Technically, anything. The API provides some core functionality that you should support, although most of commands are optional. These core features mainly watch power, and get versioning information and the devices capabilities. There are certain "specialties" the device can support that will trigger extra capabilities on the Metasploit end. At launch, this will include the Automotive extension. Getting out of your dreams, getting into your car If your device supports CAN, Metasploit will automatically provide several interactive vehicle-related commands. This will also mark your Hardware Bridge (HWBridge) session as an Automotive session that can be viewed in your session list or via modules that are designed to work only on automotive systems. This allows exploit developers to focus on writing automotive tools without having to worry about the attached hardware. It also provides internal Metasploit APIs to make common automotive calls easier, such as getting the vehicle speed or requesting a security access token from the Engine Control Unit (ECU). Hardware devices can teach Metasploit new tricks! You don't have to wait for Metasploit updates or specific support for your new device. Hardware devices can expose any functionality they have to the Metasploit Framework. This is typically something that is unique to your hardware device. It could be as simple as exposing the LEDs, or as complicated as a series of commands that run on MIL-STD-1553 bus systems. When functionality is taught via the API to Metasploit, they show up as interactive commands in the HWBridge session. This allows for support of specific hardware support without forcing the developer to the strict rules of an API, and these commands can also be used by post exploitation modules. How can I use it? If you have read this far I can assume you are ready to take the red pill. This first release comes with support for SocketCAN. If you have a Linux system and a CAN bus sniffer that support SocketCAN you can get started without anything else. The local_hwbridge module is provided as an example of a simple relay system. You can run the relay locally or on a remote machine. msf > use auxiliary/server/local_hwbridge msf auxiliary(local_hwbridge) > run [*] Auxiliary module execution completed [*] Using URL: http://0.0.0.0:8080/6xOv7GqFs3YTeIE [*] Local IP: http://10.1.10.21:8080/6xOv7GqFs3YTeIE [*] Server started. msf auxiliary(local_hwbridge) > The local_hwbridge defaults will automatically detect any SocketCAN interfaces you have and should just work without having to type in any options. A relay service does not have to run within Metasploit but can be its own service, or if the REST API is supported by the hardware itself, you can skip this step. Next you need to connect to a relay or a supported piece of hardware to establish a HWBridge session. msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > set rhost 10.1.10.21 rhost => 10.1.10.21 msf auxiliary(connect) > set targeturi 6xOv7GqFs3YTeIE targeturi => 6xOv7GqFs3YTeIE msf auxiliary(connect) > run [*] Attempting to connect to 10.1.10.21... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-01-17 11:02:34 -0800 [+] HWBridge session established [*] HW Specialty: {"automotive"=>true} Capabilities: {"can"=>true, "custom_methods"=>true} [!] NOTICE: You are about to leave the matrix. All actions performed on this hardware bridge [!] could have real world consequences. Use this module in a controlled testing [!] environment and with equipment you are authorized to perform testing on. [*] Auxiliary module execution completed msf auxiliary(connect) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- 1 hwbridge cmd/hardware automotive 127.0.0.1 -> 127.0.0.1 (10.1.10.21) Once connected, a HWBridge session will be established. If you are familiar with using meterpreter you will feel very at home using a hwbridge. Jumping on a session you can see a list of commands by typing help or run a post module such as the supplied getvinfo (Get Vehicle Info) module. msf auxiliary(connect) > sess 1 [*] Starting interaction with 1... hwbridge > supported_buses Available buses can0, can1, can2 hwbridge > run post/hardware/automotive/getvinfo CANBUS=can2 [*] Available PIDS for pulling realtime data: 46 pids [*] [1, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 24, 25, 28, 31, 32, 32, 33, 44, 45, 46, 47, 48, 49, 50, 51, 60, 61, 64, 65, 66, 67, 68, 69, 70, 71, 73, 74, 76] [*] MIL (Engine Light) : OFF [*] Number of DTCs: 0 [*] Engine Temp: 48 °C / 118 °F [*] RPMS: 0 [*] Speed: 0 km/h / 0.0 mph [*] Supported OBD Standards: OBD and OBD-II [*] Mode $09 Vehicle Info Supported PIDS: [2, 4, 6, 8] [*] VIN: 1G1ZT53826F109149 [*] Calibration ID: UDS ERR: {"RCRRP"=>"Request Correctly Received, but Response is Pending"} [*] PID 6 Response: ["00", "00", "C4", "E9", "00", "00", "17", "33", "00", "00", "00", "00"] [*] PID 8 Response: ["00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00"] Feel free to look at the source to post/hardware/automotive/getvinfo.rb to see how to use Metasploit's Unified Diagnostic Service (UDS) API to make modules like these very simple. There are a lot more automotive modules and other services coming. How can I help? This is the initial release of the HWBridge. We are looking for feedback from both hardware developers and exploit writers. If there are automotive features you would like to see, let us know. If you're a hardware developer who wants to be Metasploit compatible, let us know how we can help you.  Metasploit condensed a slew of independent software exploits and tools into one framework and now we want to do the same for hardware. As you exit the Matrix, please watch your step!

Hacking Cars is Sexy

Five years ago, if you wanted to publicly demonstrate a car hack it usually meant you would (at the very least) get a series of cease and desist letters.  Of course this made it very hard for researchers to report problems.  If a security researcher…

Five years ago, if you wanted to publicly demonstrate a car hack it usually meant you would (at the very least) get a series of cease and desist letters.  Of course this made it very hard for researchers to report problems.  If a security researcher found something that they were concerned about and wanted to see it addressed, they would turn to the vendor to try and get it fixed.  Unfortunately, automaker's websites didn't have a place to report security findings.  You could try contacting support or talking to a dealership but that would almost never get to corporate, and when it did, it just meant you were about to be threatened with a lawsuit. What's a researcher to do if they reach out to a vendor and they vendor never gets back to them?  Researchers tend to get concerned that an issue is being ignored, so they often would go to the press or give a talk at a conference -- effectively trying to raise awareness or shame the vendor into taking action.  Of course when that happens, you are bound to get the hate from the auto industry.  This creates a viscous cycle that is hard to break from. To make matters worse, hacking cars is sexy!  It must be, the media loves covering car hacking.  The good thing about this attention is that it gets more researchers interested into looking at automotives through a security lens.  The auto-industry tends to still hate this kind of press but it's mainly because of the tone of many of these articles take.  And honestly, I hate fear mongering articles just as much as they do. In the last two years we have seen many automotive companies participating in security events and even participating in the Car Hacking Village at Defcon.  A few have security specific contact pages and even bug bounty programs.  This has created a great feedback cycle. Let's take a recent security finding by Keen Security Labs.  Keen had done excellent research recently by successfully remotely exploiting a Tesla and gaining low level CAN bus controls.  For those not familiar with CAN bus, it's a bus network that grants low level controls to a car.  What those controls are vary on the vehicle and bus you have control over.  The full details of the attack are not public at the time of this writing, however here is their demonstration video: Car Hacking Research: Remote Attack Tesla Motors by Keen Security Lab - YouTube It appears Keen did some thorough research but what is the most exciting thing about this is what they did with the finding.  They contacted Tesla through Tesla's collaborative disclosure methods.  Tesla assessed the probability of exploitation to the customer base and determined it was relatively low due to the specific conditions necessary to perform the attack.  However, they still pushed out a patch to their customers in under two weeks of being notified of the vulnerability.  Keen worked with Tesla and once the issue was address they released their demo. THIS is the news story.  While the hack is cool and all (and sexy!) the real proof is that a significant finding was received and quickly addressed by the auto industry.  When I first started in automotive security five years ago, I thought this day would never come.  Hopefully the media will soon start to showcase the handling of findings so we can showcase to those industries still catching up that, this is how the system is suppose to work.  All software has bugs, cars are software, the question is: What do you do about it once one is discovered?

Rapid7 Supports Researcher Protections in Michigan Vehicle Hacking Law

Yesterday, the Michigan Senate Judiciary Committee passed a bill – S.B. 0927 – that forbids some forms of vehicle hacking, but includes specific protections for cybersecurity researchers. Rapid7 supports these protections. The bill is not law yet – it has only cleared a Committee…

Yesterday, the Michigan Senate Judiciary Committee passed a bill – S.B. 0927 – that forbids some forms of vehicle hacking, but includes specific protections for cybersecurity researchers. Rapid7 supports these protections. The bill is not law yet – it has only cleared a Committee in the Senate, but it looks poised to keep advancing in the state legislature. Our background and analysis of the bill is below.In summary:The amended bill offers legal protections for independent research and repair of vehicle computers. These protections do not exist in current Michigan state law.The amended bill bans some forms of vehicle hacking that damage property or people, but we believe this was already largely prohibited under current Michigan state law.The bill attempts to make penalties for hacking more proportional, but this may not be effective.BackgroundEarlier this year, Michigan state Senator Mike Kowall introduced S.B. 0927 to prohibit accessing a motor vehicle's electronic system without authorization. The bill would have punished violations with a potential life sentence. As noted by press reports at the time, the bill's broad language made no distinction between malicious actors, researchers, or harmless access. The original bill is available here.After S.B. 0927 was introduced, Rapid7 worked with a coalition of cybersecurity researchers and companies to detail concerns that the bill would chill legitimate research. We argued that motorists are safer as a result of independent research efforts that are not necessarily authorized by vehicle manufacturers. For example, in Jul. 2015, researchers found serious security flaws in Jeep software, prompting a recall of 1.4 million vehicles. Blocking independent research to uncover vehicle software flaws would undermine cybersecurity and put motorists at greater risk.Over a four-month period, Rapid7 worked rather extensively with Sen. Kowall's office and Michigan state executive agencies to minimize the bill's damage to cybersecurity research. We applaud their willingness to consider our concerns and suggestions. The amended bill passed by the Michigan Senate Judiciary Committee, we believe, will help provide researchers with greater legal certainty to independently evaluate and improve vehicle cybersecurity in Michigan.The Researcher ProtectionsFirst, let's examine the bill's protections for researchers – Sec. 5(2)(B); pg. 6, lines 16-21. Explicit protection for cybersecurity researchers does not currently exist in Michigan state law, so we view this provision as a significant step forward.This provision says researchers do not violate the bill's ban on vehicle hacking if the purpose is to test, refine, or improve the vehicle – and not to damage critical infrastructure, other property, or injure other people. The research must also be performed under safe and controlled conditions. A court would need to interpret what qualifies as "safe and controlled" conditions – hacking a moving vehicle on a highway probably would not qualify, but we would argue that working in one's own garage likely sufficiently limits the risks to other people and property.The researcher protections do not depend on authorization from the vehicle manufacturer, dealer, or owner. However, because of the inherent safety risks of vehicles, Rapid7 would support a well-crafted requirement that research beyond passive signals monitoring must obtain authorization from the vehicle owner (as distinct from the manufacturer).The bill offers similar protections for licensed manufacturers, dealers, and mechanics [Sec. 5(2)(A); pg. 6, lines 10-15]. However, both current state law and the bill would not explicitly give vehicle owners (who are not mechanics, or are not conducting research) the right to access their own vehicle computers without manufacturer authorization. However, since Michigan state law does not clearly give owners this ability, the bill is not a step back here. Nonetheless, we would prefer the legislation make clear that it is not a crime for owners to independently access their own vehicle and device software.The Vehicle Hacking BanThe amended bill would explicitly prohibit unauthorized access to motor vehicle electronic systems to alter or use vehicle computers, but only if the purpose was to damage the vehicle, injure persons, or damage other property [Sec. 5(1)(c)-(d); pgs. 5-6, lines 23-8]. That is an important limit that should exclude, for example, passive observation of public vehicle signals or attempts to fix (as opposed to damage) a vehicle.Although the amended bill would introduce a new ban on certain types of vehicle hacking, our take is that this was already illegal under existing Michigan state law. Current Michigan law – at MCL 752.795 – prohibits unauthorized access to "a computer program, computer, computer system, or computer network." The current state definition of "computer" – at MCL 752.792 – is already sweeping enough to encompass vehicle computers and communications systems. Since the law already prohibits unauthorized hacking of vehicle computers, it's difficult to see why this legislation is actually necessary. Although the bill's definition of "motor vehicle electronic system" is too broad [Sec. 2(11); pgs. 3-4, lines 25-3], its redundancy with current state law makes this legislation less of an expansion than if there were no overlap.Penalty ChangesThe amended bill attempts to create some balance to sentencing under Michigan state computer crime law [Sec. 7(2)(A); pg. 8, line 11]. This provision essentially makes harmless violations of Sec. 5 (which includes the general ban on hacking, including vehicles) a misdemeanor, as opposed to a felony. Current state law – at MCL 752.797(2) – makes all Sec. 5 violations felonies, which is potentially harsh for innocuous offenses. We believe that penalties for unauthorized hacking should be proportionate to the crime, so building additional balance in the law is welcome.However, this provision is limited and contradictory. The Sec. 7 provision applies only to those who "did not, and did not intend to," acquire/alter/use a computer or data, and if the violation can be "cured without injury or damage." But to violate Sec. 5, the person must have intentionally accessed a computer to acquire/alter/use a computer or data. So the person did not violate Sec. 5 in the first place if the person did not do those things or did not do them intentionally. It's unclear under what scenario Sec. 7 would kick in and provide a more proportionate sentence – but at least this provision does not appear to cause any harm. We hope this provision can be strengthened and clarified as the bill moves through the Michigan state legislature.ConclusionOn balance, we think the amended bill is a major improvement on the original, though not perfect. The most important improvements we'd like to see are Clarifying the penalty limitation in Sec. 7;  Narrowing the definition of "motor vehicle electrical system" in Sec. 2; andLimiting criminal liability for owners that access software on vehicle computers they own.However, the clear protections for independent researchers are quite helpful, and Rapid7 supports them. To us, the researcher protections further demonstrate that lawmakers are recognizing the benefits of independent research to advance safety, security, and innovation. The attempt at creating proportional sentences is also sorely needed and welcome, if inelegantly executed.The amended bill is at a relatively early stage in the legislative process. It must still pass through the Michigan Senate and House. Nonetheless, it starts off on much more positive footing than it did originally. We intend to track the bill as it moves through the Michigan legislature and hope to see it improve further. In the meantime, we'd welcome feedback from the community.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now