Hub detection?

[grymoire]

My USBValve is working. THANK YOU! But I have some questions. 1) Is it possible to detect if a USB hub (perhaps hidden inside a keyboard or cable) is attached to the USBValve?

2) A $40 product detects evil cables by monitoring power using a side channel. Is there some way to add this into a new revision?

[cecio]

Hey!

Happy to hear this :-)

Regarding your questions:

1. I'm not sure, I should check this. But I don't have very clear the use case here: what exactly are you trying to address? If you attach a USB HUB it is not detected, but then if you attach something to this HUB (like a BADUSB device) it is detected correctly. Do you have a specific use case?

2. what you mean with "evil cable"? If I google it I find something like https://cyborg.ksecsolutions.com/product/evil-crow-cable/ , but this should be detected as BADUSB. May be you are referring to something else?

Thanks!

[grymoire]

When I plug a hub or any USB device into a computer, the computer detects it (via system log, device manager, etc.) When I plug a data cable in, nothing happens and nothing is detected.

One of the attack methods suggested (in 2010, at defcon 18) was to attach a light sensor (or perhaps a motion sensor) on the device, so it waits for a period of inactivity before injecting keystrokes. He also suggested hiding the HID device inside something using a hub.

So, if I plug in a "cable", but it has a device that injects nothing when plugged in, would USBValve detect this? Or for instance suppose I modified the EvilCrow injection script to delay 100 seconds before entering keystrokes. Would USBValue tell me this before those 100 seconds elapsed? (I've ordered that cable, so I plan to test this when it arrives).

It seems to me that detecting the presence of new USB devices would be useful. I looked into the code of TinyUSB and I'm not sure how to do this.

[cecio]

A "pure" data cable is just a breakout of the 4 USB pins, prolonging the connections out of the box. When one of these is inserted, nothing happens from an "electrical" point of view, so nothing can be detected

If we speak about other USB devices (or "smart" cables with some "intelligence" in them) we are in a different field. In this case usually the device "presents" itself to the system where it is attached, so it can be detected for sure. USB HUBs usually do that, so they can be detected. We need to understand if we want to detect them.

So, if I plug in a "cable", but it has a device that injects nothing when plugged in, would USBValve detect this?

Yes, but: USBvalve has two kind of messages related to HID devices: one is about HID Device Attached and one is HID Device Sending Data. If the cable you attach presents itself immediately as HID and then wait 100 sec to send data, USBvalve will give you a message of HID Device Attached immediately and a HID Device Sending Data after 100 sec. If the cable is set to be completely off for 100 sec and then will present itself, the same will happen on USBvalve: you will see the HID Device Attached after 100 sec. If this is the case, I'm not sure if I can find a way to overcome this behavior.

Or for instance suppose I modified the EvilCrow injection script to delay 100 seconds before entering keystrokes. Would USBValue tell me this before those 100 seconds elapsed?

For sure it will not detect the HID Device Sending Data before the 100 sec, but depending on how the cable works it may detect the HID Device Attached. BTW, if you get one of these cables, I'm interested in the result of this test. Consider that I'll release a new version in a while, fixing some detection issues, so you may want to use this one.

Thanks!

[grymoire]

I will do so when the cable arrives. But it seems to me that a computer can tell the difference between a hub and a HID. It might be nice to have this ability. I wonder if a device can pretend to be a hub, and then change into a HID at a later time. I don't know enough about the protocol to know what can be done.

[cecio]

Thanks!

Without going into USB protocol details, I may say that:

• if a device is a HUB, it can pretend to have anything attached to it, so even and HID
• I think a device can just reset itself and pretend to be something else just representing itself

Yes, the HUB devices can be recognized, I think it should be feasible. I'll have a look into it after the release of 0.13.0

Thanks.

[stephankn]

I fear there is little to protect you from an an attacker hiding malicious functionality inside a modified cable with extra chips or manipulated devices, if the malicious activity is triggered on special conditions, like mentioned in that defcon talk, then you won't detect it by checking the device with USBvalve. You would need a firewall to allow only specific device classes on USB. For example, if you want to do USB Mass storage, it should not allow HID to prevent from typing as a keyboard.

There are some project around doing this like https://github.com/robertfisk/USG

or software: https://github.com/kochstefan/usbauth-all

USBvalve would detect relatively simple bad usb devices acting immediately. And it still has the initial functionality of checking what a host computer would do with your plugged in USB mass storage.

[Tz1rf]

I know this is an older issue. Sorry to resurrect it but I thought I would add some information as of version 17.

If the evil crow acts anything like a OMG cable, then I can confirm that the USBvalve does detect it. The OMG cable I tested waits X amount of seconds before executing malicious script. What the USBvalve shows is that the device initially connects. Then after X seconds passes and it attempts to send data the USBvalve shows DEVICE IS SENDING DATA on the screen. It didn't matter if I edited the script to wait less or more time before executing the end result was the same. Additionally I also tested the cable using its built in wifi connection to edit and send malicious code on the fly. The result was the same.

Now there are some additional features of the cable, which are more advanced and might be able to go undetected with a USBValve. Unfortunately I wasn't able to test all of its features as I had limited time with the cable before I had to return it.

[cecio]

Thanks for the info @Tz1rf