Punto di errore: Hacking di un dispositivo POS con WHIDBOARD

DALLA CASSA ALLA SHELL ROOT

Qualche tempo fa stavo facendo acquisti in città quando mi sono imbattuto in un interessante POS (Point Of Sale). Mentre il cassiere preparava la busta della spesa, ho rapidamente preso il mio telefono e scattato un paio di foto per riferimento futuro…

Una volta a casa, ho iniziato a esaminare più da vicino le etichette sotto il POS e mi sono subito reso conto di una cosa interessante… un ID FCC era chiaramente visibile (ovvero SEKMA512)! 😎

RECON passivo – È ora di OSINT!

Grazie a quell'informazione, sono riuscito a ottenere rapidamente maggiori dettagli su questo nuovo DUT (Dispositivo Under Test) anche senza possederne uno (ancora).

All'interno della banca dati FCC sono riuscito a ottenere maggiori dettagli sui PCB interni, sul funzionamento del dispositivo e sull'eventuale presenza di funzionalità anti-manomissione in grado di impedire tentativi di hacking dell'hardware.

In particolare, durante la lettura del manuale, ho potuto confermare che effettivamente questo POS (come qualsiasi altro dispositivo simile che gestisce i dati delle carte di credito) dispone di alcune contromisure per impedire agli autori delle minacce di manomettere fisicamente il circuito stampato, come mostrato nelle immagini sopra.

Tuttavia, non mi sono arreso e ho continuato a esaminare i documenti della banca dati FCC per comprendere meglio l’intero dispositivo in prova (DUT) e completare il mio modello di minaccia iniziale, alla ricerca di potenziali punti di accesso.

Come si può vedere dall'immagine sopra, il PCB principale presenta una serie di punti di test. Alcuni di essi hanno catturato il mio interesse, soprattutto perché sembravano accessibili dall'esterno senza aprire l'involucro del POS, il che significa che potevano essere sondati senza attivare i meccanismi anti-manomissione che avrebbero cancellato la memoria del dispositivo.

Ora che avevo individuato alcuni potenziali punti di accesso, era giunto il momento di acquistare alcuni campioni online…

RECON attivo – Enumerazione dei pin con WHIDBOARD

Pochi giorni dopo sono arrivati i campioni DUT e il primo passo è stato sondare i punti di test con un multimetro per identificare quali fossero elettricamente rilevanti. Dopo averli selezionati, ho quindi utilizzato la funzione Logic Analyzer integrata in WHIDBOARD per verificare se il POS stesse emettendo dei dati.

Dopo aver provato diversi pin, come potete vedere dallo screenshot qui sotto, alla fine ho trovato la linea TX di un'interfaccia di debug UART. 😎

Ora è il momento di attivare la funzione Pin Enumerator di WHIDBOARD per individuare anche il pin RX!

Lasciare che il DUT completasse il processo di avvio ha portato a qualcosa di veramente inaspettato…

Non solo questo POS ha esposto un'interfaccia UART perfettamente funzionante al di fuori dei propri confini di sicurezza anti-manomissione – indicando un fallimento sia nella modellazione delle minacce durante la fase di ricerca e sviluppo che nella convalida della sicurezza prima della produzione – ma questa interfaccia di debug è approdata direttamente in una shell root. 💥🤯

Mettiamoci all'opera – Interagire con il DUT come root

A questo punto, la situazione si è rapidamente aggravata. Utilizzando WHIDBOARD avevo identificato un'interfaccia UART esposta che portava a un ACCESSO ROOT COMPLETO E NON AUTENTICATO…

Quello che è seguito è stata l'esplorazione del file system del dispositivo, l'ispezione dei processi in esecuzione e la comprensione dell'architettura interna del DUT.

Alla fine, ho estratto l'intero firmware tramite una chiavetta USB utilizzando i seguenti comandi…

E per dimostrare che ero in grado non solo di leggere il filesystem, ma anche di manometterlo… ho apportato alcune modifiche… 😎

RECON attivo – Scansione della rete

A questo punto, per curiosità, ho verificato anche la presenza di servizi di rete aperti sull'interfaccia Ethernet del DUT. I risultati sono stati allarmanti: la porta Telnet 23/TCP era APERTA… 🤯💥

E sì… era possibile accedervi (come root) SENZA password!

A questo punto ho deciso di verificare su Shodan se qualcuno di questi POS fosse esposto a Internet. Il risultato: almeno 61 di essi erano esposti su Internet… 🙊🙉🙈

Conclusioni

Questo DUT è stato una vera sorpresa: in oltre un decennio di ricerca sulla sicurezza dei POS, non avevo mai incontrato un dispositivo con così tanti errori cumulativi. Analizziamo cosa è andato storto e perché è importante.

Mancanza di più livelli di difesa in profondità. Questo dispositivo presentava almeno quattro vulnerabilità distinte e sfruttabili indipendentemente l'una dall'altra:

1. Punti di test di debug accessibili dall'esterno che aggirano le protezioni fisiche anti-manomissione;
2. Una console UART attiva e non autenticata che consente l'accesso alla shell di root;
3. Telnet sulla porta 23/TCP con accesso root senza password sull'interfaccia della rete;
4. Almeno 61 istanze individuabili tramite Shodan, esposte direttamente a Internet.

Ciascuna di queste sarebbe di per sé una scoperta critica. Insieme, rappresentano un fallimento sistemico nel ciclo di vita della sicurezza del prodotto – dalla modellazione delle minacce e dalla progettazione sicura, fino all’implementazione e ai test di pre-produzione.

Implicazioni per l'infrastruttura di pagamento. Un terminale POS con accesso di livello root in lettura/scrittura al filesystem – raggiungibile sia fisicamente che tramite la rete – apre la porta a backdoor nel firmware, all'intercettazione dei dati di pagamento e all'installazione di malware persistente. In ambienti in cui è richiesta la conformità allo standard PCI DSS, questa classe di vulnerabilità non rappresenta una lacuna marginale: essa mina l’intero modello di fiducia. Il fatto che questi dispositivi fossero esposti a Internet amplifica il rischio, trasformando un attacco fisico locale in uno scalabile da remoto.

Il contesto normativo: CRA e oltre. Con l’entrata in vigore del Cyber Resilience Act (CRA) dell’UE, i prodotti con elementi digitali immessi sul mercato europeo dovranno soddisfare requisiti essenziali di sicurezza informatica per tutto il loro ciclo di vita, tra cui configurazione sicura per impostazione predefinita, superfici di attacco ridotte al minimo e obblighi di gestione delle vulnerabilità. Un dispositivo commercializzato con accesso root non autenticato sia tramite UART che Telnet rappresenterebbe uno scenario di non conformità da manuale. I produttori e gli importatori dovrebbero considerare risultati come questi come un'anteprima di ciò che le autorità di regolamentazione andranno a verificare.

Punti chiave per i professionisti. Non sottovalutate mai le informazioni OSINT disponibili pubblicamente. La sola banca dati della FCC ha fornito informazioni sufficienti per costruire un modello preliminare di minaccia, identificare i confini anti-manomissione e individuare potenziali punti di ingresso, il tutto prima ancora di acquistare una singola unità. Per i membri del red team e i ricercatori di sicurezza, questo è un promemoria del fatto che la ricognizione passiva sui documenti normativi può accelerare notevolmente le valutazioni dell’hardware. Per i produttori e i membri del blue team, è un promemoria del fatto che le vostre presentazioni alla FCC, le analisi di smontaggio e i manuali di assistenza fanno parte della vostra superficie di attacco.