Recentemente è stato scoperto un software nascosto in grado di registrare ogni lettera digitata su un laptop HP. L’impatto è di vasta portata, con molti modelli attuali di laptop HP che sono affetti dal problema. In questo post analizzeremo prima il problema del key-logging, quindi discuteremo un metodo migliore per impedire che ciò accada in futuro.
Un ricercatore di sicurezza informatica Michael Myng ha trovato del codice di keylogging nei driver software preinstallati sui laptop HP per far funzionare la tastiera. Ha scoperto il codice keylogger durante l’ispezione del software Synaptics Touchpad, mentre cercava di capire come controllare la retroilluminazione della tastiera sul portatile HP. Mr Myng ha dichiarato: “Il keylogger era disabilitato di default, ma un utente malintenzionato con accesso al computer avrebbe potuto abilitare la registrazione di ciò che un utente stava digitando.”
Secondo HP, è stato originariamente integrato nel software Synaptics per aiutare a correggere gli errori. HP ha riconosciuto che questo software di debug potrebbe essere sfruttato per provocare una “perdita di riservatezza”, ma ha affermato che né Synaptics né HP hanno avuto accesso ai dati dei clienti a causa del difetto.
Includere in fase di sviluppo del software come il keylogging è una pratica comune e viene inizialmente creato per aiutare gli sviluppatori a eseguire il debug del software. Questo codice può anche essere chiamato “codice di debug”. Tuttavia, quando il codice viene inserito nel software di rilascio ed esiste un semplice meccanismo per attivarlo, diventa un potenziale rischio per la sicurezza. Il codice di debug, una volta scoperto, verrebbe normalmente registrato come CWE (Common Weakness Enumeration). CWE è un dizionario online universale di punti deboli che sono stati trovati nel software per computer. Il dizionario è gestito dalla MITRE Corporation e può essere consultato gratuitamente su base mondiale.
Tuttavia, a causa della possibilità che possa essere sfruttato sul campo da alcuni software dannosi, è più che probabile che sia registrato come CVE (vulnerabilità ed esposizioni comuni). CVE è un catalogo di minacce alla sicurezza conosciute. Il catalogo è sponsorizzato dal Department of Homeland Security degli Stati Uniti (DHS) e le minacce sono suddivise in due categorie: vulnerabilità ed esposizioni.
La sfortunata ironia è che meno di 7 mesi fa un identico exploit è stato identificato nel driver audio HP (CVE-2017-8360). In questo caso, è possibile utilizzare anche il codice di registrazione debug nel driver audio per tenere traccia delle password.
Mr Myng, fa un’analisi dettagliata del problema con il codice keylogging più recente qui, vale la pena leggere per chiunque sia interessato all’approccio e ai dettagli tecnici relativi all’identificazione del problema.
Figura 1 – Questo è il modo in cui KeyboardHookCallback appare dopo aver applicato una decompilazione – (Credit Michael Myng)
Guardando il codice di debug mostrato nella Figura 1, si può vedere che è il tipico caso di codice di debug che quasi tutti i programmi software potrebbero utilizzare durante i test o problemi di individuazione dei guasti.
L’uso di tecniche di registrazione come questa è un modo semplice per controllare cosa stia facendo un’applicazione. Discutiamo varie tecniche come questa in un precedente post “Illuminating System Integration”. Il problema critico qui è che il codice è stato lasciato nell’applicazione dopo il rilascio, quindi è vulnerabile a qualcuno che potrebbe voler sfruttare il sistema per rubare i dettagli di login / password. Questo ci porta alla domanda successiva, c’è un modo migliore e più sicuro per raccogliere questo tipo di informazioni di debug, senza il rischio di lasciare potenziali exploit nel software dopo che è stato spedito?
C’è un modo migliore?
Una delle sfide riguardanti la ricerca dei difetti in un sistema completamente integrato è come acquisire i dati necessari per comprendere la causa principale del problema. L’uso di un debugger spesso modifica i tempi del sistema in modo tale da mascherare il bug o impedire il corretto funzionamento del sistema.
Se facciamo un passo indietro, diamo un’occhiata al concetto di copertura del codice. La copertura del codice è la misura del codice che è stata eseguita, con un obiettivo di qualità ideale per garantire che tutte le linee di codice siano eseguite prima del rilascio del nostro software. Come misuriamo la copertura del codice strutturale? Il processo è molto semplice, prendiamo il codice su cui vogliamo misurare la copertura del codice, lo strumentiamo con marcatori che registreranno alcuni dati per mostrarci dove l’applicazione è stata eseguita. Nella Figura 2 vediamo un esempio del codice originale e il codice strumentato fianco a fianco.
Figura 2 – Codice originale e codice Instrumented (copertura delle istruzioni) affiancati
Utilizzando uno strumento per instrumentare il codice per la copertura, ogni volta che il codice originale viene modificato, è possibile rieseguire l’instrumentazione e ottenere una nuova versione del codice instrumentato. Questo significa anche che il codice originale NON ha MAI bisogno di avere alcuna logica di instrumentazione al suo interno, poiché l’Instrumenter può automaticamente ricrearlo. In questo modo non è MAI possibile che il codice strumentato venga rilasciato accidentalmente.
Questo stesso approccio e tecnologia ci può aiutare a implementare una soluzione di registrazione più sicura, proprio come HP ha tentato di fare sopra. Siamo in grado di affrontare questa sfida utilizzando la tecnologia di instrumentazione di codice esistente per rendere il processo di aggiunta del codice di traccia il più semplice possibile. Ci sono due parti fondamentali di cui abbiamo bisogno per costruire una soluzione di registrazione migliore:
- La possibilità di inserire un blocco di codice in qualsiasi punto del nostro programma e assicurare che sia sintatticamente corretto per la regione in cui è inserito
- Avere la possibilità per la logica inserita di “seguire” automaticamente la regione di codice in cui è stata inserita, in modo che se il codice cambia, non è necessario passare attraverso il processo manuale di spostamento del codice di debug
Possiamo chiamare questo codice di debug inserito un “PROBE POINT“. Un esempio di questo è mostrato usando lo strumento VectorCAST / Probe ™. Nella Figura 3, possiamo vedere un editor di codice che ci consente di selezionare la linea di codice in cui vogliamo inserire la nostra logica di tracciamento.
Figura 3 – VectorCAST / Probe – Selezionare la linea di codice per inserire il Probe Point
Una volta identificato il punto in cui vogliamo inserire il codice, lo strumento (come mostrato nella figura 4) ci consente di inserire il nostro Probe Point sopra o sotto l’istruzione.
Figura 4 – Inserisci il Probe Point sopra o sotto l’istruzione
Non solo possiamo utilizzare questo meccanismo per verificare i valori dei dati nel nostro sistema, ma inserendo il nostro Probe Point prima di un’istruzione, possiamo anche utilizzare questo meccanismo per impostare o manipolare i valori dei dati nel nostro codice. Questa funzionalità ci consente di attivare comportamenti difficili da replicare, o anche di provare una potenziale soluzione dei problemi prima di apportare effettivamente una modifica al codice sorgente originale.
Infine, tornando al problema originale che HP ora affronta, i Probe Point vengono inseriti nello stesso modo automatico con cui viene eseguita la strumentazione di copertura. Quindi il codice originale non ha MAI bisogno di essere modificato con questi hook di debug. Invece, ogni volta che viene apportata una modifica al software, eseguiamo di nuovo il tool di copertura, che in questo caso possiamo chiamare un ‘Probe Instrumenter’ e ricreare il Probe Point con il codice di debug appropriato.
Conclusione
In questo post abbiamo esaminato ciò che è considerato un grosso difetto di sicurezza nei computer portatili HP che è stato determinato dalla necessità per gli sviluppatori del software per il laptop di poter eseguire il debugging. Il problema principale è che il software di debug è stato rilasciato nella versione finale e lasciato aperto al possibile sfruttamento. Questa è stata la seconda volta che quest’anno HP si è imbattuto in un problema come questo. Per evitare ciò, abbiamo proposto un approccio migliore per l’inserimento del software di debug nel nostro codice. Il concetto di Probe Point ha molti vantaggi:
- Instrumentare dinamicamente il software per isolare i difetti
- Inserire Probe Point durante Unit, Integration o System Testing
- Catturare valori di dati interni
- Registrare il flusso di controllo dettagliato
- Iniettare problemi e fault per testare la gestione degli errori
- Fare il debug con difficoltà per attivare le condizioni di gara
Più criticamente, l’approccio proposto fornisce una garanzia che il software di debug potenzialmente sfruttabile NON viene rilasciato nell’applicazione reale.