Hacking: Modbus
Una delle sfide del pentesting in ambito OT/ICS è data dai protocolli impiegati che possono essere anche molto diversi da quelli dell'IT. Le installazioni ICS utilizzano un'ampia varietà di protocolli che spesso hanno ben poco in comune con gli standard Ethernet e TCP/IP.
Questa differenza è stata per anni il punto di forza delle installazioni OT, proteggendole attraverso il meccanismo della "sicurezza per oscurità". Ora che questi protocolli stanno diventando sempre più conosciuti e compresi, le preoccupazioni di sicurezza in queste strutture sono state accentuate.
In questo articolo vediamo le principali caratteristiche di uno di questi protocolli: il Modbus.
Lo standard Modbus
Il protocollo Modbus si caratterizza principalmente per il supporto fisico di connessione, che può essere su porta seriale o su Ethernet. Esistono diverse varianti del protocollo:
Modbus RTU
Modbus ASCII
Modbus TCP
Modbus over TCP/IP o Modbus RTU/IP
Modbus over UDP
Modbus Plus (Modbus+)
Secure Modbus
In questo articolo tratterò quelli più diffusi: Modbus RTU e Modbus TCP. Farò anche un cenno sul Secure Modbus, una versione del protocollo orientata alla sicurezza e che incorpora un layer per la cifratura dei dati.
Modbus RTU
Modbus RTU è stato sviluppato per la prima volta nel 1979 da Modicon (ora parte di Schneider Electric) per i propri sistemi di automazione industriale e PLC. È diventato lo standard de facto del settore. Modbus è un protocollo di dominio pubblico ampiamente accettato, è un protocollo semplice e leggero destinato alla comunicazione seriale. Ha un limite di dati di 253 byte.
Modbus opera al livello 7 del modello OSI. È una metodologia di comunicazione efficiente tra dispositivi interconnessi utilizzando un modello di "richiesta/risposta". Proprio perché è semplice e leggero richiede poca potenza di elaborazione. Basti pensare che esistono librerie di comunicazione disponibili per praticamente qualunque dispositivo embedded, a partire da una semplice scheda Arduino fino alla più sofisticata Raspberry.
Modbus è stato inizialmente implementato sulla tipologia fisica RS-232C (punto-punto) o RS-485 (multi-drop). Può avere fino a 32 dispositivi che comunicano tramite un collegamento seriale con ciascun dispositivo con un ID univoco.
Modbus utilizza un'architettura master/slave (client/server) in cui solo un dispositivo può inviare le richieste. Gli slave/server forniscono i dati richiesti al master o eseguono l'azione richiesta dal master stesso. Uno slave è qualsiasi dispositivo periferico (trasduttore, valvola, unità di rete o altro ancora) che elabora le informazioni e invia il suo output al master tramite il protocollo Modbus.
I master possono rivolgersi a singoli slave o inviare un messaggio in broadcast a tutti gli slave. Gli slave restituiscono una risposta a tutte le query indirizzate a loro individualmente, ma non rispondono alle query broadcast. Gli slave non generano messaggi, possono solo rispondere al master. La query di un master sarà composta dall'indirizzo slave (ID slave o ID unità), un codice funzione, tutti i dati richiesti e un campo di controllo degli errori CRC.
Modbus comunica utilizzando i Function Codes, codici funzione che identificano un'ampia gamma di comandi.
Modbus TCP
Modbus TCP è il protocollo Modbus incapsulato per l'uso su TCP/IP usando la porta 502. Utilizza la stessa richiesta/risposta di Modbus RTU, gli stessi codici funzione e lo stesso limite di dati di 253 byte. Il campo di controllo degli errori utilizzato in Modbus RTU viene eliminato poiché il livello di collegamento TCP/IP utilizza i suoi metodi di checksum.
Modbus TCP aggiunge un livello applicazione (MBAP) al frame Modbus RTU. È lungo 7 byte con 2 byte per l'intestazione, 2 byte per l'identificatore del protocollo, 2 byte per la lunghezza e 1 byte per l'indirizzo (ID unità).
L'utilizzo di Ethernet consente di realizzare architetture più complesse, anche di tipo ibrido facendo uso di appositi gateway.
Formato del pacchetto dati
Un frame Modbus consiste in un Application Data Unit (ADU) che incapsula un Protocol Data Unit (PDU), secondo questo schema:
ADU = Address + PDU + Error check
PDU = Function code + Data
L'ordine dei byte per i valori nei frame di dati Modbus è il byte più significativo di un valore multi-byte inviato prima degli altri. Tutte le varianti Modbus utilizzano uno dei seguenti formati di frame.
Formato del frame Modbus RTU
Nome | Lung. (bits) | Funzione |
Start | 28 | Almeno 3½ caratteri di inizio frame (con condizione del segno) |
Address | 8 | Indirizzo della stazione |
Function | 8 | Codice funzione, es. read coils/holding registers |
Data | n × 8 | Dati + lunghezza verranno riempiti in base al tipo di messaggio |
CRC | 16 | Cyclic Redundancy Check |
End | 28 | Almeno 3½ caratteri di silenzio tra i frames |
Note sul calcolo del CRC:
Polinomiale: x16 + x15 + x2 + 1 (CRC-16-ANSI anche noto come CRC-16-IBM, polinomio algebrico esadecimale normale essendo
8005e invertitoA001).Valore iniziale: 65.535.
Esempio di frame in esadecimale:
01 04 02 FF FF B8 80(CRC-16-ANSI calcolato a partire da01fino aFFgenera80B8, viene prima trasmesso il byte meno significativo).
Formato del frame Modbus ASCII
Nome | Lung. (bytes) | Funzione |
Start | 1 | Inizia con |
Address | 2 | Indirizzo della stazione |
Function | 2 | Codice funzione, es. read coils |
Data | n × 2 | Dati + lunghezza verranno riempiti in base al tipo di messaggio |
LRC | 2 | Checksum (Longitudinal redundancy check) |
End | 2 | <CR><LF> insieme (valori ASCII |
Formato del frame Modbus TCP
Name | Lung. (bytes) | Funzione |
Transaction identifier | 2 | Per la sincronizzazione tra messaggi di server e client |
Protocol identifier | 2 | 0 per Modbus/TCP |
Length field | 2 | Numero di byte rimanenti in questo frame |
Unit identifier | 1 | Indirizzo slave (255 se non usato) |
Function code | 1 | Codice funzione |
Data bytes | n | Dati come risposta o comandi |
Sicurezza del protocollo Modbus
Modbus deve la sua larghissima diffusione alla semplicità del protocollo e alla sua ormai storica presenza sul mercato. Ma proprio per questi due fattori offre il fianco a diverse possibilità di attacco, con numerose vulnerabilità note. Ecco come potrebbero essere eseguiti alcuni attacchi sfruttando le semplici funzioni che il protocollo stesso mette a disposizione, senza strumenti dedicati all'enumeration come nmap.
Un hacker può iniziare il suo attacco in fase di reconnaissance eseguendo lo scanning della rete per individuare i dispositivi Modbus usando i comandi di diagnostica del protocollo: Clear Counter e Diagnostic Register. Una richiesta inviata al PLC, con codice funzione 8 (0x08) e codice funzione secondaria 10 (0x0A), farà in modo che il server di destinazione cancelli i suoi contatori e il registro diagnostico. Questa funzione è in genere implementata solo nei dispositivi seriali.
Un altro comando di diagnostica che può essere utilizzato è il Read Device Identification come tentativo di raccogliere informazioni sul dispositivo Modbus: una richiesta con il codice funzione 43 di Read Device Identification farà sì che un server Modbus restituisca il nome del fornitore, il nome del prodotto e il numero di versione. Ulteriori informazioni possono essere fornite anche in campi opzionali. Un utente malintenzionato invia il pacchetto di richiesta Modbus con il codice funzione 43 a tutti i sistemi della rete e raccoglie informazioni che potrebbero essere utili per successivi attacchi.
Vulnerabilità del protocollo Modbus
L'implementazione del protocollo Modbus TCP contiene diverse vulnerabilità che potrebbero consentire a un utente malintenzionato di eseguire attività di enumeration o di inviare comandi arbitrari.
Mancanza di riservatezza: tutti i messaggi Modbus vengono trasmessi in chiaro attraverso il supporto di trasmissione.
Mancanza di integrità: non esistono controlli di integrità all'interno del protocollo e, di conseguenza, dipende da protocolli di livello inferiore preservare l'integrità dei dati.
Mancanza di autenticazione: non esiste autenticazione a nessun livello del protocollo, con la possibile eccezione di alcuni comandi di programmazione non documentati.
Framing semplicistico: i frame Modbus TCP vengono inviati tramite connessioni TCP stabilite. Sebbene tali connessioni siano generalmente affidabili, presentano un significativo svantaggio per via del punto successivo.
Mancanza di struttura della sessione: come molti protocolli di richiesta/risposta (es. SNMP, HTTP, ecc.) Modbus TCP è costituito da transazioni di breve durata in cui il master invia una richiesta allo slave che si traduce in una singola azione. Se combinato con la mancanza di autenticazione e la scarsa generazione del TCP Initial Sequence Number (ISN) in molti dispositivi embedded, diventa possibile per gli aggressori immettere comandi senza conoscere la sessione esistente.
Vulnerabilità "Illegal Function Exception" Queste vulnerabilità consentono a un utente malintenzionato di svolgere attività di ricognizione sulla rete di destinazione. La prima vulnerabilità esiste perché un dispositivo slave Modbus può restituire una Illegal Function Exception per le query che contengono un codice funzione non supportato. Un utente remoto non autenticato può sfruttare questa vulnerabilità inviando codici funzione predisposti per effettuare ricognizioni sulla rete di destinazione.
Vulnerabilità "Illegal Address Exception" Un'ulteriore vulnerabilità di ricognizione è dovuta alle molteplici risposte di Illegal Address Exception generate per le query che contengono un indirizzo slave illegale. Un utente malintenzionato non autenticato può sfruttare questa vulnerabilità inviando query che contengono indirizzi non validi alla rete di destinazione e raccogliere informazioni sugli host di rete dai messaggi restituiti.
Vulnerabilità sull'autenticazione Un'altra vulnerabilità è dovuta alla mancanza di controlli di sicurezza nell'implementazione del protocollo Modbus TCP. Le specifiche del protocollo non includono un meccanismo di autenticazione per la convalida della comunicazione tra i dispositivi master e slave. Questo difetto potrebbe consentire a un utente non autenticato di inviare comandi arbitrari a qualsiasi dispositivo slave tramite un master di attacco.
Vulnerabilità DoS Il protocollo Modbus TCP contiene anche vulnerabilità che potrebbero consentire a un utente malintenzionato di causare una condizione di Denial of Service (DoS) su un sistema di destinazione. La vulnerabilità è dovuta a un errore di implementazione nel protocollo stesso durante l'elaborazione dei messaggi di richiesta e risposta di input discreti.
Vulnerabilità di buffer overfllow Un altro attacco a Modbus può essere il pacchetto dati che supera la lunghezza massima. Il protocollo limita la dimensione della PDU a 253 byte per consentire l'invio del pacchetto su una linea seriale, es. interfaccia RS-485. Modbus TCP antepone alla PDU un'intestazione Modbus Application Protocol (MBAP) di 7 byte e il tutto, MBAP+PDU, viene incapsulato in un pacchetto TCP. Ciò pone un limite massimo alla dimensione del pacchetto.
Un utente malintenzionato crea un pacchetto appositamente predisposto di lunghezza superiore a 260 byte e lo invia a un client e server. Se il client o server sono stati programmati in modo errato ciò potrebbe provocare un overflow del buffer o un attacco denial-of-service.
Sniffing del protocollo L'attacco più semplice da usare contro Modbus è lo sniffing del traffico di rete, trovare i dispositivi connessi e quindi inviare comandi dannosi ai dispositivi.
Non avendo funzionalità di sicurezza o crittografia, è facile utilizzare Wireshark per raccogliere informazioni da pacchetti di dati che sulla rete da e verso una porta Modbus su un dispositivo e leggere il contenuto di tali pacchetti. Wireshark consente di vedere facilmente cosa è contenuto in questi pacchetti, esaminare gli indirizzi IP, vedere i codici funzione delle richieste e alterare il corretto funzionamento dei dispositivi.
Secure Modbus
L’approccio più comune alla protezione dei protocolli OT è quello di incapsularli all’interno di un protocollo TLS (Transport Layer Security) e utilizzare l’autenticazione reciproca. Molti organismi di standardizzazione pubblicano linee guida per farlo a seconda dei protocollo, ad esempio:
ODVA specifica come applicare la crittografia TLS al protocollo EtherNet/IP.
Schneider Electric ha recentemente lavorato per creare una versione Secure Modbus, che prevede anche l’aggiunta dell’estensione X.509 per la definizione delle autorizzazioni (read-only o read-write).
IEC 62351-3 definisce come utilizzare TLS per il settore dell’industria energetica sui protocolli basati su TCP.
Nota importante
Lo scopo di questo articolo è unicamente didattico e informativo. Ogni azione non autorizzata verso qualunque sistema di controllo presente su una rete pubblica o privata è illegale! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore.
Stay safe, stay free.
Last updated
