Let's say I've got a generic, cheap mouse.
It's a USB-device. Any USB-device may contain memory, so how to know if the manufacturer didn't embed any memory with malware software in a device? (on Linux preferably)
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this communityLet's say I've got a generic, cheap mouse.
It's a USB-device. Any USB-device may contain memory, so how to know if the manufacturer didn't embed any memory with malware software in a device? (on Linux preferably)
Watching your system and kernel log seem appropriate.
On linux:
tail -f /var/log/kern.log /var/log/syslog
before inserting device, then look output when inserting USB device... Care to stay watching for some minutes after plug.
When USB device is plugged, logs show what kind of device is recognized. Required drivers will be loaded, if needed.
If usb storage is recognized as a network devices, holding a full network, with upnp servers, who send automatically media. This could be something harmful.
If device trig your system to load many different drivers, when they are only simple storage device, this look abnormal.
If device trig your system to load only one driver, corresponding to device purpose, this look fine (Nota: A cheap mouse won't require specific driver!! If yes, this could look suspicious).
You even could use lsusb
before and after plug USB device, then look for differences. (Do this in a second console, while watching your logs as previously recommended)
On linux:
lsusb >lsusb-before.txt
Plug device
lsusb | diff lsusb-before.txt -
About your cheap mouse: If you see two devices: one mouse and one data storage, containing mouse driver, this could be ok, but if the mouse won't work on your system and you decide to install embed driver, you will do this at your own risk!!
But care!
Some bad device, like USB Killer v3, could burn your hardware at time they are plugged!!!
When plugged into a device, the USB Killer rapidly charges its capacitors from the USB power lines. When the device is charged, -200VDC is discharged over the data lines of the host device. This charge/discharge cycle is repeated many times per second, until the USB Killer is removed.
Addendum: Little reflexion about Failure to detect malicious functions does not prove their absence. and comment from user10216038:
Yes: I could imaging such malicious device:
root
and brute force password, for finally encrypt whole /home
(even run at 3AM, brute force may take a lot of time with 3 try every 5 minutes... This may become visible) orBut
All this seem very hard and expensive to create, require strongly experienced programmer (team)!
You have to use weak password (better if malicious device already know your password) or you have to enable upnp and accept automatic installation of drivers and networks.
But if you keep regular backups, saving syslogs too, and use read-only devices on critical hosts, with remote syslog,
at time the malicious process begin, they will be logged anyway and I think they will have poor chance to harm correctly protected system.
So yes this could be an issue, but very expensive for targeting home desktop without regular protections, with a very small chance to success.
Keep your backups up to date, on many different devices! (Make tests and verification against your backups)
Don't use weak password!!!
Disable automatic services like upnp on sensible hosts!
You cannot scan a device until you have access to it's storage or memory.
Ideally, USB/IoT devices comprise of flash based microcontrollers. In other cases, let's assume there's some sort of processing and storage entity present in them. In either case, the manufacturer certainly has an ability to backdoor the USB peripheral and it can achieved in the following ways:
In any case, this topic is not of interest unless it can steal your information and communicate it back to them (manufacturer) or cause some kind of harm to you or your computer.
If it was to harm you, you would have known it by now. In rest of the cases, it will have to communicate to your computer system to cause harm. The device can communicate via: 1. USB Cable 2. Bluetooth 3. NFC 4. Wifi 6. some "xyz" medium. Let's use a blanket term "channel" for them. Now, USB manufacturer can accomplish it's goal to cause harm (or steal information) in following ways:
For 1, USB manufacturer always has option to provide custom driver for USB peripheral instead of using a generic Windows USB driver. USB manufacturer can not choose to auto-install custom driver unless it is WHQL certified. Obtaining this certification, considering the fact that device software itself is malicious, is highly unlikely. In all other cases, it will have to exclusively ask for user permission in the form of a UAC prompt to install driver. Once installed, the driver will be loaded into the memory. This can solved if your antivirus solution supports scanning memory for both user and kernel space.
For 2, all device user software is usually checked for malware by anti-virus solutions. You can double check to be sure about your anti-virus solution.
For 3, the device firmware will interact with windows operating system based on the standard windows APIs. In order to exploit this behavior, it will have to find vulnerability in standard/windows software or the "channel" itself. This is highly unlikely but if this is the case, then trust me, Microsoft is in a bigger fix than you.
In any way, I know you do realize that above trouble can be avoided just by choosing a trusted vendor or manufacturer for the USB peripheral.
You might also would want to consider the possibility in which attackers can actually break into your system because of a security vulnerability in the manufacturer software. Here, the manufacturer does not necessarily need have a malicious intent. This kind of attack would mostly likely be the case if you get hacked because of a USB peripheral.
You can't!
At best you can discover that it is malicious or has other unintended functions.
Failure to detect malicious functions does not prove their absence.