Linux forensics in the form of tracking the connection history of USB devices. Linux forensics in the form of tracking the connection history of USB devices Displaying connected USB devices

When connecting a USB flash drive or any other USB devices and a set of files is created on the computer with which you can access them. When you work in file manager everything is simple enough, but once it comes to the console everything becomes much more difficult.

It is important for every beginner to be able to identify connected devices, be it USB flash drives, SD cards or hard disks so as not to write something in the wrong place or format the wrong disk. In this article we will look at several ways to view Linux USB devices connected to a computer.

In the operating room Linux system a special management philosophy is used. All objects, including devices, are considered files. When a device is connected to the system, a file is created for it in the /dev/ directory.

Usually, after you connect any USB flash drive or other storage device to a system with desktop environment installed, the device is automatically mounted in the /media/username/device_label/ folder, and then you can access the files from the device in this folder. However, there are situations when you need to manually mount the USB and then this option will not help.

All device files are located in the /dev/ directory. Here you can find the sda, hda files, which are HDD, as well as sda1 or hda1 files, which allow you to access disk partitions. We have already discussed all this in detail in the article. You can see a list of all devices in the /dev/ directory using the command:

Now it remains to understand which of these device files belong to USB devices and which devices exactly.

How to view Linux USB devices

To find out more detailed information about each device connected to your system and see a list of linux devices, you can use the df command. It is used to view free disk space:

By the total size and occupied space, you can determine which device is your flash drive, but this way to view Linux devices is not very convenient and it only works with an already mounted flash drive; there are several more that provide more accurate information.

The lsblk command displays a list of all block devices connected to your computer. The utility displays not only their size, but also their type (disk/partition) as well as the major and minor device numbers. Here it’s a little easier to find a flash drive, we see two disks, and if the first with a size of 698 gigabytes is a hard drive, then the second is definitely a flash drive:

There is another way, this is the fdisk utility. It allows you to view the partition table on all block devices connected to the computer. But the utility must be executed as a superuser:

You can also find out about the connected USB device by looking at the kernel message queue dmesg. Information about all operations that occur in the kernel is stored here. The name of the flash drive just connected to the computer will be displayed here. To view kernel messages, run:

To see which of the sd devices are USB, use the following command:

ls -l /dev/disk/by-id/usb*

USB support has been included in the kernel since version 2.2.7 and we can say that this technology has already been tested and there should be no problems when connecting such devices. You just need to connect a camera, flash drive, printer or any other device, and it will be automatically recognized. Whether the printer will work, for example, depends on the availability of drivers.

To make it possible to assess the situation, let’s look at how USB support is implemented and where to look for information about connected devices, although everything said about partially applies to USB. Implementing USB support in Linux Linux USB Project (www.linux-usb.org) is where you should go for information. In today's computers you can find three types of controllers, differing in the interface for interacting with devices. These are OHCI (Open Host Controller Interface), UHCI (Universal Host Controller Interface) and EHCI (Enhanced Host Controller Interface). The first two implement support for USB version 1.1, the last 2.0 providing transfer speeds of up to 480 Mbit/s. UHCI controllers are somewhat simpler and cheaper, but require complex drivers and place more load on the processor. Finding out your controller type is still very simple:

$lspci -v
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) (prog-if 10)

Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11
Memory at fe02f000 (32-bit, non-prefetchable)
Capabilities:

00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) (prog-if 20)
Subsystem: Biostar Microtech Int'l Corp Unknown device 3405
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 5
Memory at fe02e000 (32-bit, non-prefetchable)
Capabilities:

As you can see, I have both types of controllers: OHCI and EHCI. If you are using a self-assembled kernel, enable the required driver in the “USB Host Controller Drivers” item. I won’t burden you with all the options; all the parameters that are available in the kernel can be viewed by typing “cat /usr/src/linux/.config | grep -i usb".

You should also remember that working with USB is carried out by SCSI emulation, so you need to activate the parameters related to SCSI support.
To directly work with USB devices, a directory /proc/bus/usb is created in the virtual file system /proc, which is mounted via /etc/fstab:

none /proc/bus/usb usbfs noauto 0 0
If there is no such line in your file, this may mean that the developers have saved you from unnecessary thoughts and are mounting usbfs in the startup scripts. In which specific script this is done, you will find out by entering “ sudo grep -iR "usbfs" /etc/*". For example, in KUbuntu a script is responsible for mounting USB /etc/init.d/mountdevsubfs.sh. You can manually mount the file system for USB to /proc/bus/usb like this:

$ sudo mount -t usbdevfs none /proc/bus/usb

After this the command " mount | grep usbfs" should show the presence of the line:

procbususb on /proc/bus/usb type usbfs (rw)

And the conclusion " lsmod» loaded modules usbcore, driver module ohci_hcd, ehci_hcd, uhci_hcs, as well as a module corresponding to the driver of the connected device like scanner.o, printer.o, usb_storage.
Information about connecting a USB device can be obtained from /var/log/dmesg and directly from /proc. If the directory /proc/bus/usb empty means the USB virtual file system is not mounted. Inside the directory there should be several files with names like 001, 002 according to the number of controllers and a devices file that “knows” about all devices:

$ cat /proc/bus/usb/devices

T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=10
B: Alloc= 0/800 us (0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub) Sub=00 Prot=01 MxPS=64 #Cfgs= 1

S: Manufacturer=Linux 2.6.20-15-generic ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:02.1

E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh=10
B: Alloc= 0/900 us (0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.20-15-generic ohci_hcd
S: Product=OHCI Host Controller
S: SerialNumber=0000:00:02.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1307 ProdID=0163 Rev= 1.00
S: Manufacturer=????????y
S: Product=USB Mass Storage Device
S: SerialNumber=9fe1ad57805553
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 80mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=16ms

It's easy to decipher the output, look for details in the documentation ( /usr/src//Documentation/usb/proc_usb_info.txt). Let me just say that the letter T indicates the topology, Bus And Level show which bus the device is connected to and the level, Spd shows the speed, MxCh- how many other devices can be connected to it, Driver- driver. For example, Driver=hub shows that this is a hub, and Driver=usb-storage is a USB device for storing information.
In the KUbuntu repository you can find several utilities that will help you understand USB. So, by using lsusb you will get even more information about USB devices, and if you don’t like the console, use usbview.

That’s basically all I wanted to say about connecting hot devices to a computer with Linux, I hope from today you will no longer have problems with this.

As part of my immersion in one of the disciplines (during the course of my studies in the Compeza specialty), I worked on one interesting project that I would not want to simply bury in the depths of the “Univer” folder on an external hard drive.

This project is called usbrip and is a small open source console utility for Linux forensics, namely for working with the history of USB device connections. The program is written in pure Python 3 (using some third-party modules) and does not require dependencies other than the Python 3.x interpreter and a few lines from requirements.txt, resolved in one line using pip3.

In this post I will describe some of the capabilities of this software and leave a short manual with a link to the download source.

Cut! (...I mean Cut!)

Screenshots

Getting connection history of removable USB devices:

Search additional information about a USB device by model identifier (PID):

Description

As is known, OS GNU/Linux-based systems are very sensitive to logging various kinds of events, and connecting/disconnecting USB devices is no exception. Combined with one of the UNIX philosophy's "text streams as universal interfaces" information about the artifacts of such events (in varying degrees of detail) depending on the distribution can be found in one or more of the following files:

/var/log/kern.log* ;
/var/log/syslog* ;
/var/log/messages* ;
/var/log/dmesg* ;
/var/log/daemon.log* .

FORENSIC-PROOF even shows us this picture on this matter (a little incomplete, but no matter):

For its work, usbrip finds universal ones for all Linux builds based on Debian (Ubuntu, Linux Mint etc.) and RPM (CentOS, Fedora, openSUSE, etc.), log files, namely: /var/log/syslog* or /var/log/messages* , parses them in search of necessary information and transforms the found traces of USB device connections into beautiful plates (or lists - whatever you like).

USBrip can also:

create lists of authorized (trusted) devices in the form of JSON files;
search for “offending events” based on the list of trusted devices: events (USB connection/disconnection) that involved USB devices that were not marked as trusted;
look for additional information about a USB device by its VID (Vendor ID) and/or PID (Product ID).

Reference

Get a list of available modules:

$ python3 usbrip.py -h
Get a list of available submodules for a specific module:

$python3 usbrip.py<модуль>-h
Get a list of available options for a specific submodule:

$python3 usbrip.py<модуль> <подмодуль>-h

Syntax

$ python3 usbrip.py banner $ python3 usbrip.py events history [-q] [-t | -l] [-e] [-n NUMBER OF EVENTS] [-d DATE [DATE...]] [-c COLUMN [COLUMN...]] [-f LOGFILE [LOGFILE...]] $ python3 usbrip.py events gen_auth<ВЫХОДНОЙ_ФАЙЛ.JSON>[-q] [-e] [-n NUMBER OF EVENTS] [-d DATE [DATE...]] [-f LOGFILE [LOGFILE...]] $ python3 usbrip.py events violations<ВХОДНОЙ_ФАЙЛ.JSON>[-q] [-t | -l] [-e] [-n NUMBER OF EVENTS] [-d DATE [DATE...]] [-c COLUMN [COLUMN...]] [-f LOGFILE [LOGFILE...]] $ python3 usbrip.py ids search [-q] [--vid VID] [--pid PID] [--offline] $ python3 usbrip.py ids download [-q]

Options

Options supported by the "events history", "events gen_auth", "events violations", "ids search", "ids download" submodules: -q, --quiet omit the display of banners, information (green) messages, and do not ask questions during execution ############################################### ###################################### Options supported by the "events history", "events gen_auth" submodules ", "events violations": -e, --external search only for removable USB devices (that have disconnection information) -n NUMBER OF EVENTS, --number NUMBER OF EVENTS the number of latest events by date that will be displayed -d DATE [DATE. ..], --date DATE [DATE...] list of dates by which events will be filtered when searching -f LOG_FILE [LOG_FILE...], --file LOG_FILE [LOG_FILE...] list of log files ( if not specified, the event history will be searched using the default log files: /var/log/syslog* or /var/log/messages* depending on the OS version) ############# ################################################## ###################### Options supported by the "events history", "events violations" submodules: -t, --table generate output in the form of a table (if the size the terminal window is not enough to display the table correctly, the output will be automatically generated in the form of a list; when specifying the -t flag, the output will be generated in the form of a table forcibly) -l, --list generate the output as a list -c COLUMN [COLUMN...], --column COLUMN [COLUMN...] list of columns that will be used when building a table (has effect only when generating output in the form of a table); allowed keys: "conn", "user", "vid", "pid", "prod", "manufact", "serial", "port", "disconn". ################################################## ################################### Options supported by "ids search", "ids download" submodules: - -vid VID vendor ID or USB device manufacturer ID (usually 4 hexadecimal digits) --vid PID product ID or USB device model ID (usually 4 hexadecimal digits) --offline if specified, search for additional information about the USB device in the database identifier data will be produced without first updating it (the database)

Examples of using

Show the connection history of all USB devices, omitting the banner, informational (green) messages, and also without asking questions during execution (-q, --quite), generating the output in the form of a list (-l, --list), including in it contains the 100 most recently found events (-n NUMBER OF EVENTS, --number NUMBER OF EVENTS):
$ python3 usbrip.py events history -ql -n 100
Show the connection history of removable USB devices (-e, --external), generating the output in the form of a table with fields (columns) “Connected”, “VID”, “PID”, “Disconnected” and “Serial Number” (-c COLUMN [COLUMN...], --column COLUMN [COLUMN...]), filtering the search by dates (-d DATE [DATE...], --date DATE [DATE...]), taking the information from external log files (-f LOG_FILE [LOG_FILE...], --file LOG_FILE [LOG_FILE...]):
$ python3 usbrip.py events history -et -c conn vid pid disconn serial -d "Dec 9" "Dec 10" -f /var/log/syslog.1 /var/log/syslog.2.gz
Build a table of the connection history of all USB devices and redirect the output to a file for further analysis. In the event that the output stream is not standard stdout ("|" or ">" for example), special ones will not be present in the output data. characters responsible for the font color in the terminal, so text file will not be littered with unreadable characters. It should also be noted that usbrip uses some UNICODE constants, so it would be a good idea to immediately convert the encoding of the created file to UTF-8 to display them correctly (for example, using encov), and also use Windows-style newline characters for better portability ( for example using awk):
$ python3 usbrip.py history events -t | awk "( sub("$", "\r"); print )" > usbrip.txt && enconv -x UTF8 usbrip.txt
Note: get rid of special characters responsible for color are also possible if the output has already been sent to stdout. To do this, you need to copy the received data to a new file usbrip.txt and add another awk instruction:
$ awk "( sub("$", "\r"); gsub("\\x1B\\[*[ -/]*[@-~]", ""); print )" usbrip.txt && enconv -x UTF8 usbrip.txt
Create a list of trusted devices in the form of a JSON file (trusted/auth.json) containing the first three devices connected on September 26th:
$ python3 usbrip.py events gen_auth trusted/auth.json -n 3 -d "Sep 26"
Search for “violating events” among the connection history of removable USB devices based on the list of trusted devices (trusted/auth.json) and generate the output in the form of a table with the “Connected”, “VID” and “PID” fields:
$ python3 usbrip.py events violations trusted/auth.json -et -c conn vid pid
Finding additional information about a USB device based on its VID and PID:
$ python3 usbrip.py ids search --vid 0781 --pid 5580
Download/Update USB Device ID Database (source

This project is called

usbrip

and is a small open source console utility for Linux forensics, namely for working with the history of USB device connections. The program is written in pure Python 3 (using some third-party modules) and does not require dependencies other than the Python 3.x interpreter and a few lines from

requirements.txt

Resolved in one line using pip3.

In this post I will describe some of the capabilities of this software and leave a short manual with a link to the download source.

$ python3 usbrip.py ids download

Links and postscript

You can get the utility from

GitHub

All dependencies to run and correct operation indicated in

requirements.txt

Thank you for attention!

P.S.

yes, the style of the banner and information messages is inspired by the project

sqlmap

USB - Universal Serial Bus was developed by a consortium of companies with the goal of providing a single, simple bus for connecting peripherals.

USB design allows devices to connect on the fly using standard jacks for connection. USB devices include: keyboards, mice, printers, scanners, hard drives, flash drives, cameras, modems, network adapters and columns, and their list is constantly growing.

Linux support for USB devices is quite comprehensive, but some devices require special drivers, and others, mainly printers and scanners, may not be supported or only partially supported.

Computer systems may contain one or more controllers or hubs designed to USB connections devices or other (external) hub. The hub can support up to 7 devices, which, in turn, can have additional hubs. Hub inside system unit called root hub. Each star topology can support up to 127 hubs or devices.

Speaking USB port, we mean the ability to support USB in the computer and the socket for connection, not internal address port used by the device.

Multi-layering USB systems Allows the host to determine the characteristics of a USB device, including class, manufacturer name, device name, voltage requirements, speed, USB support level, and other features.

Linux USB Device Support Module

USB devices are currently fully supported on Linux. Most of the changes appeared in the 2.6 kernel branch, although there was some support even in the 2.2 kernels. Linux supports both USB 2.0 and earlier specifications. Due to the hot-plug nature of USB, support is typically done through kernel modules that can be loaded or unloaded as needed.

The lspci command allows you to display USB devices:

Root@localhost:~:# lspci | grep -i usb 00:03.0 USB Controller: Silicon Integrated Systems USB 1.1 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems USB 1.1 Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems USB 2.0 Controller

The command output shows that there are 3 USB controllers in the system.

Using the lsmod command you can display loaded USB modules:

Displaying connected USB devices

A summary of currently connected USB devices is contained in the /proc/bus/usb/devices file. You can display it with the following command:

Root@localhost:~:# cat /proc/bus/usb/devices T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 3 B: Alloc= 0/900 us (0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 2.06 S: Manufacturer=Linux 2.6.29.6 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=0000:00:03.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt = 0 #EPs= 1 Cls=09(hub) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 3 B: Alloc= 28/900 us (3%), #Int= 2, #Iso= 0 D: Ver= 1.10 Cls=09( hub) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 2.06 S: Manufacturer=Linux 2.6.29.6 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=0000:00: 03.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub) Sub=00 Prot=00 Driver=hub E: Ad =81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=045e ProdID=00db Rev= 1.73 S: Manufacturer=Microsoft S: Product=Natural� Ergonomic Keyboard 4000 C:* #Ifs = 2 Cfg#= 1 Atr=a0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr =03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID) Sub=00 Prot=00 Driver=usbhid E: Ad=82(I) Atr =03(Int.) MxPS= 8 Ivl=10ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us (0% ), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 2.06 S: Manufacturer= Linux 2.6.29.6 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:03.3 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs = 1 Cls=09(hub) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms

In the listing, Spd=480 corresponds to the USB 2.0 bus, and Spd=12 corresponds to USB 1.1 devices. Further in the list you can see that there is currently 1 USB device connected to the system - Microsoft Natural Ergonomic Keyboard 400 (Spd=1.5).

Naturally, I type this text on this keyboard.

The hierarchy of USB device connections can be seen using the lsusb command with the -t option:

Root@localhost:~:# lsusb -t Bus# 3 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Bus# 2 `-Dev# 1 Vendor 0x1d6b Product 0x0001 `-Dev# 2 Vendor 0x045e Product 0x00db Bus# 1 `-Dev# 1 Vendor 0x1d6b Product 0x0002

Information about a specific USB device can be obtained with the following command:

Root@localhost:~:# lsusb -vd 0x045e:0x00db Bus 002 Device 002: ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x00db Natural Ergonomic Keyboard 4000 V1.0 bcdDevice 1.73 iManufacturer 1 Microsoft iProduct 2 Natural Ergonomic Keyboard 4000 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationV alue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 ** UNRECOGNIZED: 09 21 11 01 00 01 22 3c 00 Endpoint Descript or: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProto col 0 None iInterface 0 ** UNRECOGNIZED: 09 21 11 01 00 01 22 56 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered)

Connecting a USB device on the fly

New systems have support for connecting USB devices on the fly (hot plugging), which means connecting the device to a running system, which must:

determine the type of USB device, find the driver and run it;
associate the driver with the device;
notify other subsystems about the USB device.