Un prototipo de malware expone los peligros de compartir dispositivos USB

I make a living designing and selling USB controllers and I can say this article is very sensationalist and it is only telling a half-truth. Yes, some USB devices rely on firmware for fundamental operation and yes, the device firmware of *SOME* USB devices can be field-upgraded or otherwise updated, but to claim that USB itself is fundamentally broken due to this limited attack vector is nonsense.

There are three things that make this attack very specific and difficult to execute:

1) Most USB device controllers are ASIC's, or Application Specific Integrated Circuits. They are usually highly optimized to perform their intended function very well, and they usually do not have extensibility to become other devices. For example, one of my company's products is a USB 3.0 to SATA Bridge, which is used in USB 3.0 external drives. Our USB 3.0 to SATA bridge contains USB endpoints for USB Mass Storage Class and that's it. Even if you re-programmed our device firmware, all it could be is a USB Mass Storage Class device since the USB endpoint number and types are fixed in hardware. We did this to make the chip as lean as possible. It is impossible to program our chip to become a functional networking controller or a keyboard device since we don't support those features on the silicon.

>>>> Not All USB Devices can be infected! Even if you managed to infect the device, chances are you'd brick it rather than make it into something malicious. Manufacturers are usually cost sensitive and they find ways to trim costs everywhere they can ~ releasing general-purpose controllers for commodity devices is, by definition, wasteful.

2) Device manufacturers are generally very protective of their device firmwares, since the device firmwares usually contain stuff device manufacturers don't want other people to know about such as work-arounds for bugs in the silicon, or proprietary algorithms which may enhance performance or reliability, etc. The source code for most device firmwares are never published, and even if they are, there is very little documentation or active support. Finally, device manufacturers often have at least rudimentary checks in place within their controllers to check if the firmware is "valid" though these checks can vary between cryptographic hashing to simple checksums to length checks.

>>>>> Getting access to and mucking around with a device's firmware is hard. Many ASICs use customized MCU cores and without published register/programming guides, it is very difficult to reverse-engineer.

3) Assuming that you've found a USB device controller that for some reason can be programmed arbitrarily to support other USB classes and endpoints and assuming again you found the firmware source code or otherwise reverse-engineered the device's firmware, you still need to be able to program the device. The vast majority of USB 2.0 and 1.1 devices have fixed firmwares that cannot be updated. The firmware code is often stored on a metal layer in the silicon itself, and there is no way for it to be changed. If the firmware is stored on an external memory device, you still need to find a method to reprogram it, either using (undocumented) vendor commands or using a dedicated hardware.

>>>>> Most USB device controllers don't support being reprogrammed at all, even if they run on firmware. Some ASIC's don't have an MCU and instead rely purely on a logical state machine so that entire subclass is immune. Many IC's have a MASK ROM such that the firmware program is stored in some type of unwritable read-only medium and they are totally immune to this attack as well.

blackmasquerade escribió:Lo que quiero saber es por que demonios el firmware de un teclado o disco USB necesita ser reprogramable en primer lugar.

Edito: bueno, aparentemente la mayoria no son en efecto tan faciles de "reprogramar":

Vamos, que si este tio esta en lo cierto, para hacer ataques dirigidos y especificos, puede valer. Para hacer ataques e infecciones masivas no tanto.

Djalma83 escribió:Yo la verdad que no guardo ningún tipo de información relevante en mi pc, pero desde luego, el que lo haga, no debería de meter alegremente un dispositivo cualquiera. Esto no hace más que certificar lo que muchos suponíamos.

pacotator escribió:lo mas facil? no tener nada en el ordenador, manda huevos.

blackmasquerade escribió:Lo que quiero saber es por que demonios el firmware de un teclado o disco USB necesita ser reprogramable en primer lugar.

Edito: bueno, aparentemente la mayoria no son en efecto tan faciles de "reprogramar":

I make a living designing and selling USB controllers and I can say this article is very sensationalist and it is only telling a half-truth. Yes, some USB devices rely on firmware for fundamental operation and yes, the device firmware of *SOME* USB devices can be field-upgraded or otherwise updated, but to claim that USB itself is fundamentally broken due to this limited attack vector is nonsense.

There are three things that make this attack very specific and difficult to execute:

1) Most USB device controllers are ASIC's, or Application Specific Integrated Circuits. They are usually highly optimized to perform their intended function very well, and they usually do not have extensibility to become other devices. For example, one of my company's products is a USB 3.0 to SATA Bridge, which is used in USB 3.0 external drives. Our USB 3.0 to SATA bridge contains USB endpoints for USB Mass Storage Class and that's it. Even if you re-programmed our device firmware, all it could be is a USB Mass Storage Class device since the USB endpoint number and types are fixed in hardware. We did this to make the chip as lean as possible. It is impossible to program our chip to become a functional networking controller or a keyboard device since we don't support those features on the silicon.

>>>> Not All USB Devices can be infected! Even if you managed to infect the device, chances are you'd brick it rather than make it into something malicious. Manufacturers are usually cost sensitive and they find ways to trim costs everywhere they can ~ releasing general-purpose controllers for commodity devices is, by definition, wasteful.

2) Device manufacturers are generally very protective of their device firmwares, since the device firmwares usually contain stuff device manufacturers don't want other people to know about such as work-arounds for bugs in the silicon, or proprietary algorithms which may enhance performance or reliability, etc. The source code for most device firmwares are never published, and even if they are, there is very little documentation or active support. Finally, device manufacturers often have at least rudimentary checks in place within their controllers to check if the firmware is "valid" though these checks can vary between cryptographic hashing to simple checksums to length checks.

>>>>> Getting access to and mucking around with a device's firmware is hard. Many ASICs use customized MCU cores and without published register/programming guides, it is very difficult to reverse-engineer.

3) Assuming that you've found a USB device controller that for some reason can be programmed arbitrarily to support other USB classes and endpoints and assuming again you found the firmware source code or otherwise reverse-engineered the device's firmware, you still need to be able to program the device. The vast majority of USB 2.0 and 1.1 devices have fixed firmwares that cannot be updated. The firmware code is often stored on a metal layer in the silicon itself, and there is no way for it to be changed. If the firmware is stored on an external memory device, you still need to find a method to reprogram it, either using (undocumented) vendor commands or using a dedicated hardware.

>>>>> Most USB device controllers don't support being reprogrammed at all, even if they run on firmware. Some ASIC's don't have an MCU and instead rely purely on a logical state machine so that entire subclass is immune. Many IC's have a MASK ROM such that the firmware program is stored in some type of unwritable read-only medium and they are totally immune to this attack as well.

http://arstechnica.com/civis/viewtopic. ... #p27319665

Vamos, que si este tio esta en lo cierto, para hacer ataques dirigidos y especificos, puede valer. Para hacer ataques e infecciones masivas no tanto.

Djalma83 escribió:Yo la verdad que no guardo ningún tipo de información relevante en mi pc, pero desde luego, el que lo haga, no debería de meter alegremente un dispositivo cualquiera. Esto no hace más que certificar lo que muchos suponíamos.

minish97 escribió:Pero que no bastaria con desactivar el autorun con programas que crean autorun.inf que no sirven y no pueden ser sobreescritos como usb vaccine?

blackmasquerade escribió:Lo que quiero saber es por que demonios el firmware de un teclado o disco USB necesita ser reprogramable en primer lugar.

Edito: bueno, aparentemente la mayoria no son en efecto tan faciles de "reprogramar":

I make a living designing and selling USB controllers and I can say this article is very sensationalist and it is only telling a half-truth. Yes, some USB devices rely on firmware for fundamental operation and yes, the device firmware of *SOME* USB devices can be field-upgraded or otherwise updated, but to claim that USB itself is fundamentally broken due to this limited attack vector is nonsense.

There are three things that make this attack very specific and difficult to execute:

1) Most USB device controllers are ASIC's, or Application Specific Integrated Circuits. They are usually highly optimized to perform their intended function very well, and they usually do not have extensibility to become other devices. For example, one of my company's products is a USB 3.0 to SATA Bridge, which is used in USB 3.0 external drives. Our USB 3.0 to SATA bridge contains USB endpoints for USB Mass Storage Class and that's it. Even if you re-programmed our device firmware, all it could be is a USB Mass Storage Class device since the USB endpoint number and types are fixed in hardware. We did this to make the chip as lean as possible. It is impossible to program our chip to become a functional networking controller or a keyboard device since we don't support those features on the silicon.

>>>> Not All USB Devices can be infected! Even if you managed to infect the device, chances are you'd brick it rather than make it into something malicious. Manufacturers are usually cost sensitive and they find ways to trim costs everywhere they can ~ releasing general-purpose controllers for commodity devices is, by definition, wasteful.

2) Device manufacturers are generally very protective of their device firmwares, since the device firmwares usually contain stuff device manufacturers don't want other people to know about such as work-arounds for bugs in the silicon, or proprietary algorithms which may enhance performance or reliability, etc. The source code for most device firmwares are never published, and even if they are, there is very little documentation or active support. Finally, device manufacturers often have at least rudimentary checks in place within their controllers to check if the firmware is "valid" though these checks can vary between cryptographic hashing to simple checksums to length checks.

>>>>> Getting access to and mucking around with a device's firmware is hard. Many ASICs use customized MCU cores and without published register/programming guides, it is very difficult to reverse-engineer.

3) Assuming that you've found a USB device controller that for some reason can be programmed arbitrarily to support other USB classes and endpoints and assuming again you found the firmware source code or otherwise reverse-engineered the device's firmware, you still need to be able to program the device. The vast majority of USB 2.0 and 1.1 devices have fixed firmwares that cannot be updated. The firmware code is often stored on a metal layer in the silicon itself, and there is no way for it to be changed. If the firmware is stored on an external memory device, you still need to find a method to reprogram it, either using (undocumented) vendor commands or using a dedicated hardware.

>>>>> Most USB device controllers don't support being reprogrammed at all, even if they run on firmware. Some ASIC's don't have an MCU and instead rely purely on a logical state machine so that entire subclass is immune. Many IC's have a MASK ROM such that the firmware program is stored in some type of unwritable read-only medium and they are totally immune to this attack as well.

http://arstechnica.com/civis/viewtopic. ... #p27319665

Vamos, que si este tio esta en lo cierto, para hacer ataques dirigidos y especificos, puede valer. Para hacer ataques e infecciones masivas no tanto.

sonyfallon escribió:Solución ... Venga que nos vendan antivirus para los USB !!!

Perfect Ardamax escribió:...

gallegovitoriano escribió:Señores/as, estamos ante un fallo crítico del nivel del HeartBleed de SSL, que hará necesario revisar los protocolos de Handshake de USB, sistema que usan billones de dispositivos... si se propaga con esa facilidad... abrochense los cinturones!!!