Introduction

La fonctionnalité AutoRun (présentée à la sortie de Windows 95) est un mécanisme d’automatisation de lancement d’applications lors de l’insertion d’un périphérique de stockage. Cette fonctionnalité, bien que pouvant être utile (installation de logiciels présents sur CD-ROM commerciaux par exemple), présente un aspect sécuritaire potentiellement dangereux (l’AutoRun peut être utilisé pour exécuter des programmes malveillants lors de la connexion d’un périphérique).

Depuis, cette fonctionnalité a été supplantée par l’AutoPlay qui informe l’utilisateur du type de contenu présent sur le périphérique inséré. Libre choix à l’utilisateur, à ce moment, d’activer l’AutoRun ou d’effectuer toute autre action. Il est également possible de le désactiver en modifiant certaines valeurs au sein de la base de registre (procédure décrite sur le site de support Microsoft [1]).

Cet article présente un vecteur d’attaque plus évolué, et qui ne se limite pas uniquement au système d’exploitation Windows.

Présentation

Lancée en 2010, la clé USB « Rubber Ducky » [2] n’était à l’origine qu’un simple PoC (Proof of Concept) pour démontrer l’impact des attaques par Social Engineering. Aujourd’hui, devenu un produit commercial, la « Rubber Ducky » est utilisée par les hackers et les professionnels de la sécurité informatique (et probablement bien d’autres) lors de tests d’intrusion physiques.

rubber ducky lexsi 1La quasi-intégralité du parc informatique actuel (comprendre les ordinateurs, tablettes tactiles, smartphones, etc.) reçoivent des saisies de la part de l’utilisateur et ceci généralement par l’intermédiaire d’un clavier (ou HID pour Human Interface Device). Ainsi, si une clé USB prétend être un clavier, alors celle-ci sera automatiquement détectée et acceptée en tant que tel.

Qu’importe le système utilisé (Windows, Mac, Linux ou Android), la « Rubber Ducky » va profiter de la confiance aveugle qu’ont les OS envers les claviers afin de lancer des payloads à une vitesse de mille mots par seconde.

Ces payloads sont en réalité une succession de commandes écrites en mode texte (langage de script « Ducky script »), puis transformés en binaire et chargés sur la carte SD de la clé USB.

Exemple de payload « Hello World »

 Il existe plusieurs dizaines de payloads prêts à l’emploi disponibles sur le repo git de Hak5 [3], dont voici quelques exemples :

  • Création d’un « reverse shell »
  • Local DNS Poisoning (changement du contenu du fichier host)
  • Désactivation de l’antivirus
  • Suppression du contenu d’un disque ou du système entier
  • Téléchargement de mimikatz via HTTP, ouverture d’une invite de commande Administrateur, récupération des mots de passe puis envoi par mail.
Rubberducky lexsi 4

Création du binaire (payload.bin) depuis le fichier texte (helloworld.txt)

De manière générale, tout ce qu’il est possible d’effectuer par l’intermédiaire d’un clavier sera réalisable par le biais de la « Rubber Ducky ».

Note : Le site Duck Toolkit [4] permet la création de payloads en ligne en sélectionnant différentes catégories (reconnaissance, exploitation et reporting).

Challenges by Lexsi

Pour l’édition 2014 de la Nuit du Hack (NdH2k14), Lexsi en tant que partenaire et sponsor, a créée 2 challenges à l’attention des professionnels de la sécurité et des hackers présents lors de cet événement.

Rubberducky lexsi 5Cet article se concentre sur le challenge UnderstandMe (répartit en 3 niveaux) et qui, comme son nom l’indique, consiste à comprendre le comportement de 3 payloads placés sur une clé USB « Rubber Ducky ». Nous voici donc en possession de nos 3 binaires :

Listing des 3 binaires

Listing des 3 binaires

  • Niveau 1

Afin de comprendre ce qui est effectué par le script, la plus simple des solutions serait de brancher la clé USB à un ordinateur. Cependant, ne connaissant pas la nature du payload, cela reste une très mauvaise idée. Heureusement pour nous, il existe un script écrit en perl (ducky-decode.pl [5]) qui permet de retrouver les commandes saisies en mode texte depuis le binaire. Essayons cela sans plus attendre :

Contenu du fichier inject1.bin

Contenu du fichier inject1.bin

Nous constatons que le script fonctionne parfaitement et que le binaire a pour fonction d’afficher le message « Hello There » en leet speak (« H3LLO_TH3R3 »)

  • Niveau 2

Pour le second niveau, la même technique est utilisée (l’usage du script decode-ducky.pl) et force est de constater que cette fois le contenu est bien plus long. Cependant, un « motif » semble se répéter encore et encore (cf. captures ci-dessous).

Exemple de "motif" récurrent

Exemple de « motif » récurrent

En somme le payload semble écrire une suite de 4 chiffres (de manière incrémentale), pour finir par une validation (le mot-clé « ENTER »). La valeur de départ étant « 0000 » et non « 0 » indique qu’il s’agit très probablement d’un script de brute-force du code de déverrouillage d’un smartphone ou d’une tablette.

  • Niveau 3

Pour le troisième niveau, la technique utilisée précédemment fonctionne, cependant le texte résultant est encodé en QWERTY ce qui ne facilite pas la lecture. Ainsi une modification du fichier source du programme « decode-ducky.pl » s’impose.

Voici le résultat obtenu après modification du fichier source :

Extrait du fichier inject3.bin

Extrait du fichier inject3.bin

On comprend que le payload est chargé d’ajouter un nouvel utilisateur sur le système, au sein du groupe Administrateurs (Login : « lexsi », mot de passe : « 5748595f53305f535353 »).

Se prémunir des attaques par Rubber Ducky

Nous l’avons vu précédemment, les systèmes font confiance aux claviers (mais également les appareils qui prétendent l’être), et les humains utilisent des claviers. Mais alors, comment se prémunir de telles attaques ? Ne plus utiliser de claviers ?! Heureusement une alternative est possible et nous présentons ici une preuve de concept pour Unix/Linux).

Règle UDEV

Le système UDEV remplace le Device File System (DevFS) à partir des séries 2.6 du noyau Linux. Ce système permet la création de règles permettant le filtrage de périphériques selon différents attributs et d’effectuer plusieurs actions (assigner un nom de périphérique, ajouter un lien symbolique, déclencher un script, etc.). C’est ce dernier élément qui va nous intéresser.

Contenu du fichier /etc/udev/rules.d/99-ducky.rules

Explications

Cette règle spécifie qu’à chaque nouvelle insertion (ACTION== »add ») d’un périphérique USB (ENV{DEVTYPE}== »usb_device », SUBSYSTEM== »usb ») sur le système, le script prevent-ducky sera appelé avec les paramètres suivants :

  • %k – Le kernel name de l’appareil
  • %E{DEVNAME} – Le devname de l’appareil
  • $attr{manufacturer} – Le constructeur du produit

Déport d’affichage

Afin de déporter l’affichage vers la session X de l’utilisateur courant (sans quoi la fenêtre de confirmation ne s’affichera pas), il est nécessaire d’ajouter la ligne suivante au fichier .bashrc de l’utilisateur.

Ajout au .bashrc de l’utilisateur

Script « prevent-ducky »

Script « prevent-ducky » - première partie

Script « prevent-ducky » – première partie

Script « prevent-ducky » - seconde partie

Script « prevent-ducky » – seconde partie

Ce script est disponible en cliquant ici

Explications

Ainsi, pour chaque nouveau périphérique branché, ce script sera appelé (qu’importe le périphérique). Le premier avantage est bien évidemment de pouvoir choisir au cas par cas, si on souhaite autoriser ou refuser un appareil (cela fonctionnera aussi bien avec la « Rubber Ducky » qu’avec une simple souris USB).

Le second avantage (inhérent à l’usage de règles UDEV) est que tant que l’exécution du script n’est pas terminée, le périphérique ne sera pas monté. Ainsi, même si vous n’êtes pas devant votre poste lorsque l’appareil est branché, vous ne risquez rien.

Enfin, l’intégralité des périphériques acceptés/refusés est loguée dans le répertoire de votre choix, permettant d’avoir un historique des appareils branchés à votre machine.

Exemple

Pop-up de confirmation

Pop-up de confirmation

Extrait du fichier de log

Extrait du fichier de log

 

Automatisation ?

Une des améliorations possibles serait de modifier le script pour rejeter automatiquement un appareil possédant les spécificités d’une « Rubber Ducky ». Le traitement deviendrait ainsi complétement transparent pour l’utilisateur, et celui-ci n’aurait plus à se demander quels appareils il doit autoriser ou refuser. Cependant cette automatisation poserait un problème de sécurité majeur : lors d’un changement hardware/firmware le script deviendrait totalement inefficace. En effet, de nombreux matériels proposent des fonctionnalités équivalentes aux « Rubber Ducky » : teensy, arduino, etc.

D’autre part, il serait possible de modifier le firmware pour falsifier les champs « idVendor », « idProduct », « iManufacturer »… et ainsi usurper l’« identité » d’une souris ou d’un clavier légitime et autorisé…

On ne le répètera jamais assez mais attention à ce que vous branchez sur votre matériel!

Références

[1] http://support.microsoft.com/kb/967715/fr
[2] https://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe
[3] https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads
[4] http://www.ducktoolkit.com/ScriptSelection.jsp
[5] https://code.google.com/p/ducky-decode/source/browse/trunk/ducky-decode.pl?r=123