The following IVI, AVN, HMI, HU, don’t be confused, they all refer to the same thing.
IVI: In-Vehicle Infotainment, car infotainment system.
AVN: Refers to audio, video, and navigation.
HMI: Human Machine Interface.
Attack analysis methodology
What is the nature of the attack? I wonder if you have ever thought about this issue. It is actually IO. Input and Output.
Only when you can interact with the target IO, is it possible, you can perform testing and security testing. Understand this essence, and then analyze the attack of any target, it will be easier to understand.
We input data (In), and judge whether there is a problem or whether the poc in the data is executed correctly based on the feedback (Out). Understand this essence, then all attacks can actually be summarized as the process of searching for In. From all the paths of In, filter out the one with the possibility of attack, and then launch the test.
However, it should be explained here that the search for an attack and the confirmation of a vulnerability are two different links. One is the beginning and the other is the end.
With the above methodology as the foundation, and then analyze the HU attack, the idea is actually very clear. It is to find a way to interact with HU. According to the interaction distance, I am used to divide it into the following categories:
- Contact attack: HMI/touch screen: When you use a touch screen, it is actually an IO process. Hardware equipment and interfaces: such as usb, OBD, etc.Near-field attack: HU system and HU application usage, such as wifi, Bluetooth.
Long-range attacks, remote attacks from vehicles and machines are not common, and mobile apps interact with Tbox in most cases. I won’t say much here for now.
HU cracking process of C
I won’t go into details about how to obtain laboratory equipment, etc. In short, in the laboratory environment, we have a HU of C, a matching display, and a usb interface from the HU harness.
After the HU is lit, the interface looks very cool. It’s actually harder to judge what system it is just by looking at the interface. However, the common HU systems are nothing more than Android, QNX and inux.
But how to determine the system version in the black box state? I personally prefer to use the method of network packet capture analysis.
Build a WiFi that can capture packets, or use your mobile phone hotspot, provided that you can capture packets.
Open the app that can be used online in the HU.
Look for functions that require networking and trigger network requests, preferably http requests, such as pictures. I generally like to select the version to check for updates, log in, register, pictures, etc.
Open the captured data packet, look for http request, and check User-Agent.
The following is an http UA we captured
Dalvik/1.6.0 (Linux;U;Android 4.4.2;X4xxAUTO-MX6Q Build/A3.02.09208)
This UA can draw the following conclusions:
Using Android 4.4.2.
X4xx AUTO is the model information.
MX6Q is information related to hardware devices.
Build/A3.02.09208 should be the version number of the software initiated by this request.
4.4.2 Android vulnerabilities should be quite a lot, but the premise is that you need to have a data input channel and an entrance. This is the difference between audit and penetration. Auditing is to find out all the problems and tell you that most of them may not be directly used. And penetration is to find out the vulnerabilities that can be exploited and verify the availability.
This UA judgment may not be completely accurate, so you can look for a few more app requests. After all, all http headers can be customized.
Android HU penetration ideas
Many car manufacturers are responsible for the Tier1 of HU, and the systems used are relatively old, and there are more of 4.4. I have never understood the reason. Basically, it is easier for us to use this system as long as we find the entry point and raise the rights, because there are still more vulnerabilities available. But how to find the entry point?
System upgrade/app upgrade vulnerability
System built-in application vulnerabilities
The bug of the car-machine system itself
There may be three groups of people to install a HU: the installer, the general software manufacturer, and the automaker’s own software outsourcing team. Then there will always be work omissions.
The C HU is relatively good. The system can be upgraded locally and on the network. If you want to upgrade locally, you need to download the upgrade package. If the network is upgraded, after connecting to the Internet, directly match the version through the network, and then download the upgrade package. Unfortunately, the upgrade packages are all encrypted.
The individual app upgrade was directly cut off. A single app can only be upgraded through a major version upgrade.
This road is nowhere. Let’s look at the next one.
Through the previous packet capture analysis, there are many http requests, but not many trigger webview analysis, and many of them are json data. Serialization vulnerability? Hmm, good idea.
In a private information, I found a url that can be clicked. It seems that clicking will open a browser-like thing. Only the domain name is fixed. This must not bother us. dns hijacking is fine. Feel free to write an alert page to test whether js can be executed, disappointed, and there is no popup. We researched and found that there were no exploitable loopholes and gave up.
However, at this step, it is not all without gain. We have transformed a black box traffic analysis tool by ourselves to realize automatic saving of http, hijacking of dns, hijacking of pan-domain names, and routing hijacking.
This road doesn’t work, so look down.
There are few built-in applications in the main HU interface, and there is not much room for use except for the regular ones such as maps and music.
When I was a little frustrated, there was a funny discovery. When the USB receiver of the wireless keyboard and mouse is plugged into the USB port of the car, the system will respond to some keys on the keyboard.
Under a certain system theme, the system will respond to the attribute keys of the keyboard, and a menu will pop up in the lower right corner, including wallpaper, management applications and system settings. I have a hunch when I see this, it should be done here.
What do you remember? The input method of windows 3389 bypasses the login interface to pull up the use of cmd? Or is it possible to bring up the system settings menu for early Android TVs?
After testing, I finally found that the configuration interface of a certain input method can be called up in the management application.
Note: The attached image is not the original image, and it is confidential. The original image cannot be released to help everyone understand the process.
The setting button of this input method can pull up the “voice and input method” interface, and then click on the “voice and input method” to return to the system setting interface.
Here it is stuck, the application interface does not have an install button.
I definitely can’t give up here. I found that there was an option for the main screen in the setting interface. After entering, I saw several launchers. Select the launcher whose name is “Launcher” and return to the main interface. Haha, the main interface has become blank, and the long-lost button representing the application appears on the right.
The program button in the red frame. Click.
All the installed applications of the system are here.
There are three applications that have caught our attention, one is called “Engineering Mode”, one is ES File Manager, and the other is called “Install”.
The ES file manager version is not high, there are loopholes, but the permissions are not enough to install the application.
The engineering mode, when pulled up, looks like an application for internal testing. In one of the menus, I found the connection to ADB, clicked, connected to the USB, and adb came out as expected. What’s worse is that it is root.
Through adb, we pulled down all the apps in the HU for analysis. Fortunately, we found a decrypted upgrade package. Now you can perform static analysis.
At this point, it’s almost there, and there is another “installation” I haven’t seen.
The student in charge of mobile security looked at the reverse “installation” app, and found that as long as the application is in a specific directory of the u disk, it can be installed. The installation of the application is also done.
Near field attack
The idea of the near-field attack is relatively clear. The car has no Bluetooth but only WiFi. Connect to the WIIF hotspot of the car or let the car connect to my controllable WIFI. Then perform a port scan. Through port scanning, only a limited number of two ports are open.
After the contact getshell, the jar with the two ports opened was analyzed, and it was found that the socket protocol can write files, and the file name was not checked. The rest is relatively simple:
Restore the socket protocol format.
However, it is not enough to only write files. In the case of non-contact, we hope that the backdoor for writing can be automatically pulled up and run.
We analyzed the boot process of Android 4.4, and PMS is responsible for the installation and uninstallation management of applications. among them:
This file records the enable or disable information of the application.
After analyzing the relevant Android source code, a suspected 0day vulnerability was found. By writing/modifying files in a specific directory, the written application can be pulled up after the system restarts.
In fact, the safety of the C HU is fairly average in the cars and machines we have seen. Compared with those HUs that can be connected via remote SSH, it is already considered very good.