Hackfest - Level UP

Note
These vulnerabilities are currently awaiting disclosure, through the Carnegie Mellon CERT, as such I have redacted the device name in the talk outline however they will be made public within the next 30 days.

Description:

While many new cars are now shipping with built-in cameras to automatically record incidents, help in insurance claims, or to surveil driver awareness levels, not all do. Consequently, many car owners have turned to dash cams to help protect their vehicles. These small devices provide numerous benefits; they may help determine responsibility in the event of an accident, help fight traffic tickets, or catch crazy road incidents that get uploaded to YouTube and attract millions of views resulting in untold fame and fortune for the owner!

This presentation will detail my research conducted over a year on one of the highest end dash cams available on Amazon. Discovering over 20 vulnerabilities that affected not only this brand, but countless others because of white labeling, I will demonstrate how even "the best of the best" in consumer-grade IoT devices lack even the most fundamental security.

Talk Structure:

Introduction

• Who am I?
• What do I do?
  • Senior Penetration tester at Software Secured testing a wide range of products including mobile applications, web applications, cloud security reviews, and IoT devices.
• What have I done?
  • Background on some previous research including hacking the Furbo pet cameras to find 20+ CVEs, Meatmeet BBQ Probes, and other work.

Background

• What is the state of the consumer-grade dash cam market?
  • While many new cars are now shipping with built-in cameras to automatically record incidents, help in insurance claims, or to surveil driver awareness levels, not all do. Consequently, many car owners have turned to dash cams to help protect their vehicles.
  • According to market research firm Grand View Horizon, these concerns have been reflected in steady market growth with the dash cam industry in the Canada expected to grow at a rate of 9 percent a year over the next four years.
  • It was with this in mind that we decided to investigate the security of one of Amazon’s most popular high-end dash cams.

Our Target

• We would describe our target as the “Cadillac” of dash cams, providing 4K video, front, side, and rear footage and providing support for GPS tracking; as well as the seemingly mandatory inclusion of AI features found on almost everything these days. All of this coming in at a whopping $269.99.
• We also picked up the “little brother” of this high-end model, (the Camry of dash cams perhaps?) which was a bit more modest in pricing, only costing us $120 CAD.
• Given the aforementioned use cases, our research aimed to answer the following question, “Could we, as an unauthenticated attacker, disrupt the video communications in a temporary or permanent way?”

Communications

• While many dash cams these days come with a SIM card to support 4G LTE connectivity, our dash dash cams do not.
• This, of course, narrowed the attack surface and added some additional constraints to our research—any vulnerabilities exploited would have to be done within the range of the device’s Wi-Fi hotspot or Bluetooth.
  • Additionally, if we were to compromise the device in some way, we would be unable to receive a “call back” to a remote command and control server—these dash cams never connect to that big scary place we call the world wide web.
• In order to facilitate video upload and storage of footage in the cloud, and to receive firmware updates, the dash cam communicates with your phone—over an advertised Wi-Fi hotspot or BLE—and your phone in turn reaches out to the cloud.
• Through either of these mediums your phone can modify the settings of the camera, upload new firmware, watch the live video feed, and save clips.

Getting the Network Traffic: A Unique Problem

• Typically, when we would want to analyze an IoT device’s network communications, we would connect it to a network we control, using a tool like mitmrouter to easily capture inbound and outbound traffic.
• However, since the device never connects to an external network, it wouldn’t be possible to use mitmrouter since we cannot connect it to our attacker-controlled access point. Instead, we would have run tcpdump on our Android phone while it was connected to the dash cam, interact with the device, and then review the pcap file on our host.
• Once the pcap was pulled back to our phone, we were able to review the capture in Wireshark. We found that most of the communications were facilitated over a TCP connection on port 7878 which can be seen below. We also discovered that the video feed from the camera was streamed over RTSP.

Handling Authentication

• Each of these communication protocols has something in common, the use of the m2 parameter with a hash following it—the authentication token. By reverse engineering the mobile application we were later able to determine that this authentication token is tied directly to a hardware identifier on the mobile phone.
• So how are these assigned? During the initial setup, the phone connects over BLE, sends this identifier, the main binary then checks to see if it has seen this before (or if it is the first setup), if it is the first setup a prompt is presented on the dash cam screen which must be confirmed by pressing a button.
• This presented two problems for us, firstly we would need physical interaction to add a new phone or account to the camera, secondly it would be almost impossible to brute force this value. While that nixed the possibility of the unauthenticated exploit we set out to uncover, for now, we found that these tokens do not expire.
• After the initial setup process, the authentication token will remain valid until a factory reset is performed. This means that if an attacker were to be located somewhere nearby during the use of the dash cam, and could connect to the hotspot and sniff the traffic (since it is all unencrypted), then they can use that token themselves at any point.

Device Disassembly and Debugging

• Using a combination of acetone, to remove the adhesive under the glass and heat to loosen it further, we were able to pry up the glass screen (with minimal cracking).
• With the rest of the shielding removed, we were able to spot a set of pads which looked like UART and, with little difficulty, we connected our probes.
• Once powered on we were greeted with a pleasant surprise, verbose UART logs and we were able to drop right into the filesystem with root user permissions!

Firmware

• Our device was out of date by a few versions and would require a firmware update. This is the perfect situation since oftentimes we can capture the outbound request, copy the URL for ourselves, and pull down a copy to analyze. And sure enough, while monitoring the network traffic from the phone after initiating the update, we were able to capture an HTTP request to download the latest version. This was highly concerning because it meant that anyone between us and the firmware server could tamper with our image in transit.
• We were able to simply reconstruct the URL and based on the request and pull down a copy for ourselves. With a copy on our local file system, we ran binwalk -e on the image to extract it.

Reverse Engineering a Massive Binary. Where to start?

• To make sense of the enormous application binary and to focus our attention on the most pertinent components, it was vital to have a starting point. The most logical first step was to turn our attention back to the Wireshark logs we had previously captured in order to interpret the data flow between mobile application and dash camera.
• The first message sent from the mobile application, to the device over port 7878 lacks the previously mentioned authentication hash and returns some basic configuration information about the device including the product version, firmware version, serial number, and the status of various services. Each message includes several key value pairs: a key (j511), a length (len) of the message, a message identifier (msg_id), a message index (msg_index), and a token.
• The first task would be to determine how exactly the camera would authenticate the mobile phone on its first connection.

Authentication Flows

• By searching through the function names and analyzing each of them, I was able to determine that this was likely being handled by those starting with the name UIAppCmd. The first of which in this flow was UIAppCmdSocket_DataProcess.
• This function handles all inbound data over port 7878. When a request is received, UIAppCmdSocket_DataProcess is called, parsing the 32-byte header, {“key”:”j511”, “len”: “000…”}, with UiAppCmdMap_ParseCmd. This checks that the received version is j511, and then determines the length of bytes. The full message is then handed off to UIAppCmdMap_DoCmd which handles processing the second portion of the message, which contains the msg_id, msg_index, and so on.
• If the msg_id of the inbound message is 11, then it bypasses the authentication check, returning the configuration data. If the msg_id is 257 and the header contains an M2 hash it proceeds through the next steps.
• The message then hits UIAPPCmd_ProcCmd_StartSession to validate the incoming M2 hash with UINet_CheckConnectAuthSign. This function checks the flash memory for the hash, performing a 16-byte memcmp. This is important, and we will return to it later.
• If the hash has been seen before, the command executes.
• If the hash has not been seen before, then UIAppCmdNetCtrl_WaitSignature is called, creating a user prompt that is presented on the screen. This prompt requests that the user confirm the pairing of the camera to the new mobile phone. If accepted, the m2 hash is persisted and then associated with a token integer to authenticate the future requests.
• This is reflected in the UART logs. With a basic Python client, we were able to replicate this authentication flow with a list of known m2 hashes.

memcmp on an Authentication Hash

• Conceptually, memcmp will compare two strings on a byte-by-byte basis. It will compare the input against a known value, sequentially comparing the two as it iterates through, if a mismatch is found, the function will return early.
• This means that we as the attacker can use a timing attack to derive the value of the m2 hash by brute forcing each value, and analyzing the response time to determine when the function returned. To do so over Wi-Fi would be challenging but not entirely impossible. Once this hash has been derived, we can authenticate our future requests with it. This can only be done after the owner of the camera has completed setup of course, otherwise the prompt will be presented for the newly received hash.

“Me think, why waste time say lot word, when few word do trick.” - Kevin Malone, The Office

• Alternative title: Why use Timing Attack When Can Guess Token Int?
• What especially caught our eye from the Wireshark logs was the token integer sent on all requests following the initial authentication flow. This token is used to maintain the “active session” with the mobile application.
• Thus, we can negate the requirement of a valid m2 hash by simply guessing the token of a valid session. If another session is active when we are connected, our client will take precedence over the legitimate session and “ride” the token, allowing us to execute privileged commands, effectively bypassing the authentication flow.
• With the m2 hash bypassed, we were left with the next gate to our “unauth” exploit chain, to reach this we must be connected to the Wi-Fi network advertised by the dash camera.

BLE Baby!

• Using the same technique outlined in the Hacking Furbo blog series, I enabled the Bluetooth HCI Snoop Log in Developer settings on my jailbroken Android. Then, I went through the normal flow of connecting to the dash camera over BLE, this connection permitted only minor access. It allowed me to view the current device settings, including the Wi-Fi password…
• Once that was completed, I connected to the phone over Android Debug Bridge (adb) and pulled the log files by running: adb bugreport output The resulting btsnoop_hci.log file could then be parsed with tshark to easily analyze it over the command line.
• We can see several interesting pieces of information here including the firmware version (fw_ver), SSID, the serial number (SN), and an encrypted version of the Wi-Fi password (pwd2). Notably, none of this information was sent over an authenticated or encrypted BLE connection! But what can we do with this info?
• Let’s go back for a minute to what happens when you first receive a <TO BE DISCLOSED> dash camera. After plugging in the device, you must connect to it over BLE with the mobile application, and then it is added to your account. The default device Wi-Fi password is an 8 character string of capital letters and numbers.
  • That gives us half of the password, easy enough! We could simply guess the rest, however it gets better! The remaining characters are derived from the device’s Serial Number, which of course is disclosed by the device when we connect to it over BLE. If the default password has been left on the device we can simply walk up, connect to the device over BLE, grab the SN and SSID values, and successfully connect to the access point! Not too bad.
• However that still limits us, since surely some owners will change their default credentials. Well, how about that encrypted password which is returned?
  • Returning to the binary in Ghidra we can see that the FastConnect_GetApInfoW function handles this.
  • Sure enough, within the EncryptPassword function, we find two things: a hardcoded IV and secret key!
• With these, we can construct a decryption script which will decrypt any password leaked over BLE.

Pwning the Dashcam

• To sum up the work so far we now have the following chain:
  1. An attacker within Bluetooth range can leak the encrypted password.
  2. They can then decrypt the password and connect to the access point.
  3. Once connected, they can brute force a session token integer to execute privileged commands.
  4. With this access we can change settings but more importantly, upgrade the firmware achieving RCE!
• Live proof of concept demonstration, showing the attack chain.

What is the impact?

• One of the first things we noticed was that each dash cam’s SSID was unique, starting with VENDOR- followed by a short string of alphanumeric characters. This realization caused a light bulb to go off in our heads.
• Why not check Wigle to see how many of these devices have been seen in the wild?
• A quick search returned a modest 9700 devices—not nearly as many as we had expected for the Cadillac of dash cams!
• We would later determine that this is because when the vehicle the dash cam is installed in is parked, the Wi-Fi hotspot is deactivated to save on battery life. This means that the wardrivers who collect SSID data to upload to Wigle are quite unlikely to spot the devices unless the car the dash camera was installed in was turned on.
• While compiling our final results for the responsible disclosure, another thing popped into our minds. Earlier, we had seen in the UART logs, reference to a <TO BE DISCLOSED> chip.
• Based on the review of the main application binary, the data seen within UART and the Linux environment, and some previous <TO BE DISCLOSED> we believe that the firmware for the dash cam is likely supplied by <TO BE DISCLOSED> as a “white label” product. Unfortunately for us, very little information can be found online regarding the SDK, firmware, and which cameras use the <TO BE DISCLOSED> line of chips.

What does this mean for our research?

• It’s likely that the firmware on the dash cams would be deployed across countless other brands using the <TO BE DISCLOSED> chipset, with possibly some small alterations. Therefore, any vulnerabilities found on our dash cam likely apply to an unknown number of other cameras. Put simply, this dramatically increases the impact of any vulnerability we discovered.

Disclosure Process

• Navigating responsible disclosure when you can’t reach the vendor: working with Carnegie Mellon’s CERT.