Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
quoideneuf1.over-blog.com

BadUSB: La faille de sécurité USB rendue publique

8 Octobre 2014 , Rédigé par nicko Publié dans #informatique

Deux chercheurs ont publié les correctifs et les détails d'une faille capable d'endommager n'importe quel périphérique USB, qui a fait l'objet d'une démonstration lors de la conférence Black Hat.

BadUSB: La faille de sécurité USB rendue publique

Le débat sur le moment où les chercheurs peuvent révéler les failles de sécurité qu'ils ont trouvées vient d'être relancé suite à la publication d'outils destinés à colmater une faille présente dans les lecteurs flash USB. La semaine dernière, deux chercheurs, Adam Caudill et Brandon Wilson, sont parvenus à retrouver plusieurs méthodes d'exploitation de la faille et en ont publié les résultats en accès libre sur le site Github (ou en bas de page). Ces travaux ont été effectués deux mois après la démonstration d'une attaque exploitant cette faille par le SR Labs de Berlin à l'occasion de la conférence Black Hat de Las Vegas (video ci-dessous et PDF en bas de page)

SRLabs n'a pas souhaité s'exprimer sur les correctifs publiés ni sur les détails de de cette faille permettant de corrompre n'importe quel périphérique USB. La société de conseil et de recherche spécialisée en sécurité a juste fait savoir que ce type de malware ne pouvait pas être facilement corrigé.

Cependant, Adam Caudill et Brandon Wilson ont conclu que la réplication de l'attaque et la publication de leur code, constitué des patchs corrigeant le firmware, des téléchargements et de la documentation, était nécessaire pour obliger les constructeurs de périphériques USB à réparer cette faille.

« Votre niveau moyen de compétences ne sera jamais en mesure de pouvoir colmater cette faille », a indiqué Adam Caudill, dans un billet de blog. Seul, un petit nombre d'utilisateurs pourraient faire le travail nécessaire pour la retirer », a-t-il ajouté.

Manque de réaction des fabriquants

« Ces personnes ont déjà pu le faire avant que nous ayons publié ce que nous avons fait. La menace de ce qui se passe est similaire à ce qu'elle a toujours été ». Cette faille USB est présente dans les contrôleurs conçus par Phison Electronics, une société taïwanaise qui vend ses appareils à un très grand nombre de fabricants de lecteurs USB.

Cette attaque du SRLabs de type Proof-of-concept et surnommée BadUSB, oriente le profils du lecteur USB vers le clavier, de sorte qu'il puisse envoyer des séquences de touches à télécharger et installer des malwares. Le profil peut également être modifié pour émuler un contrôleur de réseau et détourner les paramètres DNS.

La modification du firmware du contrôleur se fait à partir du système d'exploitation de l'ordinateur. Paul Henry, instructeur après du SANS Institute, a été gêné par la publication de ces correctifs, en dépit du manque de réaction des industriels. « Quelle que soit l'origine de la faute, c'est la communauté au sens large qui va devoir payer le prix ultime, lorsque cette faille sera exploitée », considère t-il.

« Exercer des pressions sur les fournisseurs en publiant un correctif et en affichant des détails sur une faille n'est pas quelque chose de bien nouveau. De nombreux chercheurs ont utilisé cette tactique contre Microsoft lorsque des vulnérabilités ont été détectées dans ses logiciels », a-t-il souligné.

A. Caudill et B. Wilson, qui ont publié leurs correctifs lors de la conférence des hackers DerbyCon, espèrent contraindre les constructeurs à mettre à jour leurs firmwares pour contrôleurs USB afin d'éviter des modifications non autorisées. L'autre option est de désactiver la capacité de changer de firmware avant que la sortie d'usine des périph
ériques.

Cependant, même si ces modifications sont mises en oeuvre, les lecteurs USB qui sont actuellement sur le marché sont susceptibles de rester vulnérables à cette faille pendant des années, selon les experts.

Source: lemondeinformatique

publication sur gitHub


Phison 2251-03 (2303) Custom Firmware & Existing Firmware Patches This repository contains the following items: DriveCom -- PC C# application to communicate with Phison drives. EmbedPayload -- PC C# application to embed Rubber Ducky inject.bin key scripts into custom firmware for execution on the drive. Injector -- PC C# application to extract addresses/equates from firmware as well as embed patching code into the firmware. firmware -- this is 8051 custom firmware written in C. patch -- this is a collection of 8051 patch code written in C. Releases have the following items: patch -- this is a collection of 8051 patch code written in C. tools -- these are the compiled binaries of all the tools. CFW.bin -- this is custom firmware set up to send an embedded HID payload. Take note that the firmware patches have only been tested against PS2251-03 firmware version 1.03.53 (which is for an 8K eD3 NAND flash chip). They may work for others, but be careful. As long as you are using the correct firmware image for your controller version and NAND chip, there is no harm in downgrading to an earlier version (such as from 1.10.53). WARNING: This is experimental software. Use on unsupported devices, or even on supported devices, may cause loss of data, or even permananent damage to devices. Use at your own risk.

Getting Started

See Known Supported Devices for information on supported devices; use on an unsupported device may cause permanent damage to the device. To get started, you'll need to obtain a burner image, which is the 8051 executable responsible for flashing firmware to the drive. See Obtaining a Burner Image on the wiki for more information.

Build Environment

To patch or modify existing firmware, you must first set up a build environment. See Setting Up the Environment on the wiki for more information. At a minimum, SDCC needs to be installed to C:\Program Files\SDCC.

Dumping Firmware

Run DriveCom, passing in the drive letter representing the drive you want to flash, the path of the burner image you obtained, and the destination path for the firmware image:
tools\DriveCom.exe /drive=E /action=DumpFirmware /burner=BN03V104M.BIN /firmware=fw.bin
where
E
is the drive letter,
BN03V104M.BIN
is the path to the burner image, and fw.bin is the resulting firmware dump. Currently, only 200KB firmware images can be dumped (which is what the Patriot 8GB Supersonic Xpress drive uses).

Flashing Custom Firmware

Run
DriveCom
, passing in the drive letter representing the drive you want to flash, the path of the burner image you obtained, and the path of the firmware image you want to flash:
tools\DriveCom.exe /drive=E /action=SendFirmware /burner=BN03V104M.BIN /firmware=fw.bin
where E is the drive letter,
BN03V104M.BIN
is the path to the burner image, and
fw.bin
is the path to the firmware image.

Running Demo 1 (HID Payload)

Create a key script in Rubber Ducky format, then use Duckencoder to create an inject.bin version of it:
java -jar duckencoder.java -i keys.txt -o inject.bin
where keys.txt is the path to your key script. You may notice the delays are not quite the same between the Rubber Ducky and the drive -- you may need to adjust your scripts to compensate. (These tools are available from https://code.google.com/p/ducky-decode/.) Once you have an
inject.bin
file, embed it into the custom firmware with:
copy CFW.bin hid.bin
tools\EmbedPayload.exe inject.bin hid.bin
where
inject.bin
is the path to your inject.bin file, and
hid.bin
is the path to the HID payload custom firmware. (Notice that the firmware image is copied, and the payload is embedded into the copy -- this is because the payload can only be embedded once, so the original
CFW.bin
must remain intact.) You can now flash the firmware to your drive with:
tools\DriveCom.exe /drive=E /action=SendFirmware /burner=BN03V104M.BIN /firmware=hid.bin
where E is the drive letter representing your drive, BN03V104M.BIN is the path to your burner image, and hid.bin is the path to the HID payload custom firmware. Huge thanks to the Hak5 team for their work on the excellent USB Rubber Ducky!

Running Demo 2 (Hidden Partition Patch)

First, determine the number of logical blocks (sectors) your drive has with the following command:
tools\DriveCom.exe /drive=E /action=GetNumLBAs
Go into the patch directory and modify base.c to disable all other patches, and enable the hidden partition patch:
//#define FEATURE_CHANGE_PASSWORD

#define FEATURE_EXPOSE_HIDDEN_PARTITION
Then modify the
NUM_LBAS
define to the number of logical blocks on your drive:
#define NUM_LBAS  0xE6C980UL //this needs to be even! (round down)
Make sure you round down to an even number, and it couldn't hurt to subtract a few first, in case a few blocks go bad over time. (For example, if the number of LBAs was
0xE6C981
, you might reduce it to
0xE6C940.)
Place the firmware image you want to into the
patch
directory and name it
fw.bin
. Go to the patch directory and run
build.bat
. It will produce a file at
patch\bin\fw.bin
-- this is the modified firmware image. You can now flash this file to your drive. After flashing, Windows may be confused, as it now only sees half of the partition it once did -- it may ask you to format the first time you view either the public or hidden halves of the drive. This is normal.

Running Demo 3 (Password Patch)

Go into the patch directory and modify base.c to disable all other patches, and enable the password patch:
#define FEATURE_CHANGE_PASSWORD

//#define FEATURE_EXPOSE_HIDDEN_PARTITION
Place the firmware image you want to
patch
into the patch directory and name it
fw.bin
. Go to the
patch
directory and run
build.bat
. It will produce a file at
patch\bin\fw.bin
-- this is the modified firmware image. You can now flash this file to your drive.

Running No Boot Mode Patch

Go into the patch directory and modify
base.c
to disable all other patches, and enable the no boot patch:
//#define FEATURE_CHANGE_PASSWORD
//#define FEATURE_EXPOSE_HIDDEN_PARTITION
#define FEATURE_PREVENT_BOOT
/ Place the firmware image you want to patch into the
patch
directory and name it
fw.bin
. Go to the patch directory and run
build.bat
. It will produce a file at
patch\bin\fw.bin
-- this is the modified firmware image. You can now flash this file to your drive. Once flashed to your device, it will no longer act on the command to jump to boot mode. To update the firmware again will require shorting pins on the controller. To make it impossible* to update, after flashing this patch coat the device with epoxy. Within reason; it may be possible to get to boot mode via an exploit or other non-standard method.

Converting to Mode 7

You can run the
ModeConverterFF01.exe
application (see Useful Links) to split the drive into public and secure partitions, or restore the original (mode 3) functionality. After converting to mode 7, you should be able to set, change, or disable the secure partition password with the
USB DISK Pro LOCK
utility.

Building From Source

Modify the C files in the
firmware
directory for custom firmware, or the
patch
directory for the firmware patches, then run the
build.bat
file in the appropriate directory. Once it has built successfully, use DriveCom to flash the resulting file (
bin\fw.bin
) to your drive:
tools\DriveCom.exe /drive=E /action=SendFirmware /burner=BN03V104M.BIN /firmware=firmware\bin\fw.bin
...or...
tools\DriveCom.exe /drive=E /action=SendFirmware /burner=BN03V104M.BIN /firmware=patch\bin\fw.bin

Questions? Comments? Complaints?

Unfortunately this isn't the most straightforward process at the moment, so if you have questions, open an issue and we'll do our best to help (and update the readme/wiki).

Partager cet article

Repost 0

Commenter cet article