Dagli irrigatori alle moto: Cosa abbiamo violato

Nella cybersecurity, i test sono fondamentali. I nostri pentester simulano attacchi reali per identificare i punti deboli prima che lo facciano i criminali. Eseguendo il reverse-engineering di sistemi e prodotti, scoprono i difetti critici. Questo fornisce ai clienti le informazioni necessarie per risolvere i problemi e ridurre i rischi.

In questo articolo, abbiamo suddiviso quattro progetti in tre domande: Perché abbiamo fatto l'hacking? Che cosa abbiamo trovato? Qual è stato l'impatto?

PROGETTO

Centralina per irrigatori con supporto BLE e applicazioni mobili

preoccupazioni del cliente

Con l'aggiunta del supporto Bluetooth Low Energy (BLE), i programmatori aggiornati del cliente sono stati progettati per consentire agli utenti di controllare il sistema in remoto tramite applicazioni mobili. Il cliente doveva assicurarsi che questa nuova connettività non introducesse vulnerabilità, che avrebbero potuto esporre i dispositivi dei clienti ad accessi non autorizzati.

LA MISSIONE: PERCHÉ L'ABBIAMO VIOLATA

Il cliente stava integrando BLE nel suo programmatore di irrigatori IoT di nuova generazione. BLE è una tecnologia comune nei dispositivi IoT, ma è anche un bersaglio frequente per gli hacker, a causa delle sue errate configurazioni di sicurezza.

Il cliente doveva assicurarsi che la nuova connettività non aprisse agli aggressori la strada per compromettere i dispositivi, manipolare le impostazioni dell'irrigatore o ottenere un accesso non autorizzato alle reti degli utenti. Il nostro obiettivo era quello di individuare tempestivamente qualsiasi falla nella sicurezza, assicurando che le case e i giardini dei clienti non fossero a rischio di minacce informatiche.

LA RIPARTIZIONE: COSA ABBIAMO TROVATO

Abbiamo affrontato la revisione della sicurezza utilizzando due metodologie:

• OWASP Top 10 per le applicazioni mobili: Ha valutato l'applicazione mobile per vulnerabilità come l'archiviazione insicura dei dati, la protezione insufficiente del livello di trasporto e l'autenticazione impropria.
• Test IoT per la configurazione BLE: Ha esaminato il modo in cui BLE è stato implementato e configurato per garantire che non ci fossero configurazioni errate comuni, come la mancanza di autenticazione o la trasmissione di dati non criptati.

DURANTE I TEST ABBIAMO SCOPERTO DIVERSI PROBLEMI CRITICI

• Difetti di progettazione nel processo di accoppiamento BLE: Meccanismi di accoppiamento deboli hanno reso più facile per i potenziali aggressori l'intercettazione o l'interferenza.
• Vulnerabilità nella gestione dei dati dell'app mobile: I dati sensibili venivano memorizzati senza un'adeguata crittografia, rendendo possibile a un aggressore con accesso al dispositivo di estrarli e utilizzarli in modo improprio.
• Comandi del dispositivo esposti: Diversi comandi BLE utilizzati per controllare le impostazioni degli irrigatori non erano adeguatamente protetti, lasciando spazio a manipolazioni non autorizzate.

RISOLVENDO QUESTI PROBLEMI, IL CLIENTE È STATO IN GRADO DI

• Proteggere il processo di accoppiamento BLE, assicurando che solo gli utenti legittimi potessero controllare il dispositivo.
• Implementare metodi di archiviazione e trasmissione sicuri per le informazioni sensibili all'interno delle app mobili.
• Bloccare i comandi del dispositivo, riducendo la probabilità di manomissione da parte di malintenzionati.

Di conseguenza, i programmatori di irrigatori supportati da BLE del cliente non solo erano più sicuri, ma offrivano anche tranquillità agli utenti finali, che potevano fidarsi della solidità dei loro sistemi intelligenti contro le potenziali minacce informatiche. Questo security testing proattivo ha permesso al cliente di andare sul mercato con fiducia, trasformando un rischio potenziale in un vantaggio competitivo.

PROGETTO

Reverse engineering del sistema di controllo dell'accensione (ICS) di una motocicletta

PREOCCUPAZIONI DEL CLIENTE

Il sistema di controllo dell'accensione (ICS) di una motocicletta regola la fasatura della scintilla per accendere la miscela carburante-aria del motore. Il cliente aveva bisogno di capire se il sistema poteva essere sottoposto a reverse engineering per modificare le prestazioni della moto, come ad esempio aumentare la potenza dei cavalli regolando la fasatura delle scintille o alterando i limiti di giri.

LA MISSIONE: PERCHÉ L'ABBIAMO HACKERATO

Il sistema di controllo dell'accensione di questa moto, una Suzuki Katana, era in fase di studio per una potenziale messa a punto delle prestazioni. Il sistema era incorporato in una scatola sigillata e controllava la fasatura delle scintille di accensione tramite un microcontrollore. Il cliente voleva fare il reverse engineering del sistema per modificare le prestazioni del motore. L'obiettivo era di saperne di più sull'ICS e di determinare se poteva essere riprogrammato per aumentare le prestazioni senza compromettere l'affidabilità.

LA RIPARTIZIONE: COSA ABBIAMO TROVATO

Abbiamo affrontato il processo di reverse engineering in base a:

• Decostruzione dell'hardware: Tentativo di accedere fisicamente e sondare la scheda di circuito all'interno del sistema di controllo dell'accensione sigillato per capire come funzionava.
• Identificazione del microcontrollore: Ha identificato il microcontrollore che governava il sistema, nonostante le difficoltà causate dalla sigillatura protettiva, e ha cercato le interfacce di debug o di riprogrammazione.

DURANTE I TEST ABBIAMO SCOPERTO DIVERSE CRITICITÀ

• Meccanismo di protezione del sigillante: Il sistema era pesantemente sigillato con materiali progettati per impedire il reverse engineering, il che ha comportato alcuni danni quando si è cercato di accedere alla scheda.
• Nessuna interfaccia di debug: Nonostante i test approfonditi delle potenziali interfacce, non c'era un metodo diretto per riprogrammare il microcontrollore o estrarre il firmware.
• Accessibilità limitata al firmware: Il microcontrollore utilizzava una ROM a maschera, il che significa che il firmware era codificato in modo rigido e non poteva essere estratto senza tecniche avanzate come il decapping.

RISOLVENDO QUESTI PROBLEMI, IL CLIENTE È STATO IN GRADO DI

• Orientare l'approccio ai test Black Box: Simulando gli ingressi e misurando le uscite (ad esempio, la posizione dell'albero a camme e l'acceleratore), il cliente è riuscito a dedurre gli algoritmi di fasatura dell'accensione.
• Costruire un simulatore personalizzato: Il cliente ha creato un sistema di microcontrollori personalizzato per imitare il comportamento dell'ICS ed esplorare le possibilità di regolazione delle prestazioni.

Di conseguenza, il cliente ha acquisito una comprensione più profonda del modo in cui l'ICS controllava le prestazioni del motore e ha potuto iniziare a costruire un nuovo sistema programmabile per migliorare la potenza e l'efficienza. Anche se non era possibile una riprogrammazione diretta, l'approccio black-box ha fornito preziose indicazioni su come modificare la fasatura dell'accensione per migliorare le prestazioni.

PROGETTO

Sicurezza dei dispositivi medici

PREOCCUPAZIONI DEL CLIENTE

I dispositivi medici automatizzati che si connettono alle reti ospedaliere e ai servizi cloud presentano sfide di sicurezza uniche. In questo caso particolare, l'obiettivo era un sistema incorporato che consentiva al personale ospedaliero di autenticarsi alle postazioni di lavoro tramite Bluetooth Low Energy, che eseguiva il rilevamento attivo della presenza e il tracciamento dell'utente. Il cliente era preoccupato che le potenziali vulnerabilità potessero consentire il controllo non autorizzato del dispositivo o della postazione di lavoro, la manomissione dei dati o l'esposizione di informazioni sensibili sui pazienti. L'obiettivo era valutare la resilienza del dispositivo agli attacchi informatici e garantire la conformità alle normative del settore.

LA MISSIONE: PERCHÉ L'ABBIAMO HACKERATO

Bureau Veritas Cybersecurity è stato incaricato di valutare il software, l'hardware incorporato, le connessioni di rete e le pratiche di gestione dei dati del dispositivo medico. La missione era quella di identificare le lacune di sicurezza che potevano essere sfruttate per compromettere la sicurezza del paziente o interrompere le procedure mediche.

LA RIPARTIZIONE: COSA ABBIAMO TROVATO

Il nostro assessment di sicurezza ha riguardato:

• Test di vulnerabilità della rete: Valutazione delle connessioni alle reti ospedaliere e al cloud per individuare i punti deboli che potrebbero consentire un accesso non autorizzato.
• Analisi dell'integrità dei dati: Ha valutato le modalità di archiviazione e trasmissione dei dati dei pazienti, concentrandosi sulla crittografia e sulla prevenzione delle manomissioni.
• Simulazione di attacchi hardware: Ubertooth One e NRF51 sono stati utilizzati per sniffare il traffico BLE tra i componenti target dell'hardware e dell'applicazione del cliente. Gatttool è stato utilizzato per scoprire, leggere e scrivere sulle caratteristiche BLE disponibili.
• Simulazione del controllo del dispositivo: Ha simulato potenziali scenari di attacco per verificare se fosse possibile il controllo remoto del dispositivo.

I RISULTATI CHIAVE COMPRENDONO

• Crittografia dei dati insufficiente: Si è riscontrato che alcune trasmissioni di dati erano protette in modo inadeguato, con il rischio di intercettazione e manomissione.
• Caratteristiche BLE senza restrizioni: Le impostazioni insicure del Bluetooth Low Energy (BLE) rendevano il rilevamento di prossimità vulnerabile alla manipolazione, consentendo il monitoraggio non autorizzato dell'attività dell'utente e l'interferenza con le operazioni previste.
• Autenticazione difettosa: Le interazioni e i protocolli intercomponenti erano insicuri, consentendo potenzialmente un attacco di disturbo che avrebbe eluso l'autenticazione del sistema.
• Attacchi Piggybacking: Il MITM sulla connessione Bluetooth permetteva di catturare gli UUID, i MAC e altri valori per aggiungerli a un'altra applicazione senza consenso.
• Percorsi di accesso non autorizzati: Sono stati identificati percorsi che potrebbero consentire agli aggressori di ottenere il controllo del dispositivo o di accedere ai dati del paziente.
• Lacune normative: Ha evidenziato aree in cui le misure di sicurezza non erano in linea con le normative del settore, con un impatto sulla conformità.

PONENDO RIMEDIO A QUESTI PROBLEMI, IL CLIENTE È STATO IN GRADO DI

• Migliorare la crittografia dei dati: Implementare standard di crittografia completi per salvaguardare i dati dei pazienti.
• Proteggere l'accesso alla rete: Chiudere i percorsi di accesso non autorizzati e rafforzare le misure di autenticazione.
• Ottenere la conformità: Allineare i protocolli di sicurezza del dispositivo agli standard del settore per soddisfare i requisiti normativi.

Questi miglioramenti hanno aumentato in modo significativo la sicurezza e l'affidabilità del dispositivo medico, garantendo la sicurezza del paziente e la protezione dei dati.

PROGETTO

Aspirapolvere robot

PREOCCUPAZIONI DEL CLIENTE

Gli aspirapolvere robot connessi introducono rischi legati all'esposizione dei dati e all'uso improprio del dispositivo. In questo caso, il dispositivo utilizzava Bluetooth e servizi basati sul cloud, con funzioni di controllo collegate a un'applicazione mobile. Il produttore voleva capire se gli aggressori potessero abusare del sistema per tracciare i movimenti, manipolare le azioni del dispositivo o estrarre dati sensibili. L'obiettivo era valutare i rischi tecnici e identificare i punti deboli del progetto.

LA MISSIONE: PERCHÉ L'ABBIAMO HACKERATO

Ci è stato chiesto di esaminare il dispositivo su tutti i livelli: hardware, firmware, applicazioni mobili, protocolli di comunicazione e archiviazione locale. La missione era quella di scoprire i problemi che potevano essere sfruttati per accedere ai dati o ottenere il controllo del dispositivo.

LA RIPARTIZIONE: COSA ABBIAMO TROVATO

Il nostro team ha utilizzato diversi strumenti, script personalizzati e metodi di test collaudati per esaminare il dispositivo.

Le attività principali hanno incluso:

• Convalida del firmware e degli aggiornamenti: Esame delle procedure di aggiornamento e verifica dell'uso improprio.
• Test dell'app mobile: Ha valutato il modo in cui gli utenti hanno interagito con il dispositivo e ha cercato funzioni nascoste o non protette.
• Test di comunicazione: Ha analizzato il modo in cui i dati venivano inviati tra il dispositivo, l'app e i sistemi backend.
• Esame dell'archiviazione dei dati: Ha esaminato come e dove venivano archiviate le informazioni a livello locale.

I RISULTATI PRINCIPALI INCLUDONO

• Sicurezza della comunicazione debole: Alcune trasmissioni non erano ben protette, consentendo l'acquisizione dei dati di localizzazione e dei registri di pulizia.
• Rischi di aggiornamento del firmware: Il processo di aggiornamento mancava di controlli della firma digitale, aprendo la porta all'iniezione di firmware alterati.
• Funzioni dell'app senza restrizioni: I difetti delle app mobili esponevano funzioni di test interne e potevano consentire un uso improprio delle funzioni del dispositivo.
• Rischi di accesso remoto: Gli aggressori potrebbero sfruttare questi problemi per controllare il vuoto o osservare il comportamento degli utenti.

PONENDO RIMEDIO A QUESTI PROBLEMI, IL CLIENTE È STATO IN GRADO DI

• Migliorare i controlli di accesso nell'app mobile per bloccare l'uso improprio delle funzioni interne.
• Risolvere le lacune nella comunicazione per evitare l'intercettazione del traffico.
• Applicare modifiche crittografiche per proteggere i dati memorizzati e trasmessi.
• Introdurre una forte verifica per gli aggiornamenti del firmware.
• Aggiungere salvaguardie contro l'uso improprio automatizzato dell'app mobile.
• Formare i team tecnici sulle pratiche di sviluppo mobile e IoT sicure.

Queste azioni hanno aiutato il produttore a ridurre il rischio su tutta la linea e ad avere una visione più chiara di come gli aggressori potrebbero avvicinarsi al sistema. I risultati hanno supportato miglioramenti del prodotto a lungo termine e una postura più forte per i dispositivi futuri.