Based on the work completed by , following is my summary and review on the USB counter measures. I completed these notes as part of work in Oxford University and towards GCHQ accreditation. All comments are my own.
A number of countermeasures are mentioned as part of the presentation, in general authors have indicated no effective countermeasures are currently implemented.
The superglue notion is only mentioned in the video presentation and not directly noted in the presentation slides provided . By taking the blacklist approach to the nth degree would be akin to supergluing USB ports, effectively saying USB is not allowed. Benefits appear obvious in that this prevents external USB peripherals from having the ability to infect the host computer. From an external peripheral perspective this would appear to prevent Bad USB exploit. However, internal USB devices might be in use e.g. an internal webcam could be using USB technology, so this superglue approach will protect attack from external peripherals, the root of the vulnerability is not being addressed. As the root of the exploit is not tackled the exploit is still possible against internal USB devices (e.g. internal USB webcam), at least two opportunities come to mind for an adversary.
One - even if the internal USB webcam is not initially infected, the web cam may need replacement at some time providing an opportunity to apply the Bad USB exploit directly.
Two - as the authors have demonstrated they were able to reprogram the firmware of a clean USB once a computer has been affected, by leaving some malware from a previously infected USB device. An attacker could use some other method to deploy a malware to affect these internal USB devices. i.e. the adversary is not using Bad USB to deploy the initial malware in this case (because the ports are blacklisted / superglued!), instead a separate deployment method is used, this second deployment method is leaving the malware to infect internal USB's. It is possible anti-malware program could pick up on this deployment method.
The drawbacks, of this superglue/blacklist approach appear similarly obvious. As USB technology has been well adopted over the past two decades; supergluing prevents all external peripheral devices from being used, while blacklisting prevents listed USB devices from being used. Any of the use cases for USB built up since 1996, are now shifted to IT departments and the user to solve, the financial implications would be considerable, IT departments and individual users would now have to determine alternative approach’s to all the USB use cases in place. The USB bad exploit is not limited to personal computers, it can be applied to smart TVs, Smart phones etc., i.e. extending the possibilities to exploit and therefore the use cases to resolve if superglue approach is applied.
Firmware code signing, this method is a well established approach for confirming software has not been tampered, the code signing process using cryptographic approaches to verify the code is the original or valid patch version from the vendor. Before applying a patch to the firmware, the USB device would validate the signature before flashing the new patched firmware.
As noted by the authors, some microcontroller chip vendors provide this as an option, but the uptake is low, the most likely explanation is the additional financial costs associated with this approach, in addition to lack of a PKI infrastructure for USB vendors to utilize. Even though the design of the code signing mechanism can prevent unauthorized firmware being installed. The additional complication associated with the size of the microcontroller chip being small, it can be difficult to implement this approach, the implementation may have errors and be subject to vulnerabilities. Even if the code signing approach is well adopted, it does not tackle any of the existing USB device in operation today i.e. all existing devices would not benefit from this approach.
An additional option suggested relates to disabling firmware updates from within the hardware, this approach is suggested as 'simple and effective'. I would not agree with this statement by the authors, again as noted with the code signing approach, this disabling of the firmware would also mean all existing devices remain vulnerable. Furthermore, its unclear at least to me, how updates are applied it seems all firmware updates are not allowed. When firmware updates are not allowed, does this assume no bugs exist in the firmware, what if a firmware bug did exist, does this mean the user has to replace the physical device to get a firmware update, this was not addressed in the presentation.