Alfonso Maruccia

SCADA, nuove falle italiane

Un ricercatore del Belpaese individua e pubblica una nuova serie di vulnerabilità nei sistemi di controllo automatizzato sparsi per ogni dove. La "disclosure" è la cosa che più conta, dice il ricercatore.

Roma - Luigi Auriemma ne ha fatta un'altra delle sue: lo smanettone italiano, già noto per aver scovato vulnerabilità software per ogni dove, ha ora dedicato la sua capacità di "bug hunting" ai sistemi SCADA (supervisory control and data acquisition) e scoprendo, neanche a dirlo, una nuova sequela di bug utili a "bucare" le macchine per il controllo numerico di dispositivi elettrici ed elettronici.

Argomento sempre "hot" e sulla breccia delle cronache informatiche, quello della vulnerabilità di macchine SCADA e PLC (sistemi di controllo numerico programmabili), e che Auriemma affronta dalla sua peculiare prospettiva di cacciatore di bachi interessato alla mera ricerca di errori nel software.

L'hacker italiano ha scovato 14 nuove vulnerabilità "zero-day" (per cui al momento non esiste "cura") nelle macchine SCADA prodotte dalle seguenti aziende: Beckhoff, MeasureSoft, Rockwell, Carel, Progea, AzeoTech e Cogent.
Auriemma spiega in dettaglio i bachi con tanto di codice per lo sviluppo di eventuali exploit utili a colpire con successo le macchine coinvolte, e piuttosto che interrogarsi sulla possibilità di ritardare la diffusione delle informazioni (come altri suoi colleghi hanno già fatto nel recente passato) l'hacker scarica la colpa del problema sui programmatori del software originale: sono loro che creano indirettamente i bachi e quindi la responsabilità è loro, dice Auriemma.

Alfonso Maruccia
Notizie collegate
  • SicurezzaAuriemma: vulnerabili Doom3, Quake4, PreyRivelata dal bug hunter italiano la falla che colpisce un celebre motore videoludico. E che potrebbe consentire l'esecuzione di codice malevolo. Gli sviluppatori sono al lavoro per risolvere
  • SicurezzaSCADA e PLC, sicurezza colabrodoI sistemi computerizzati distribuiti sono vulnerabili a ogni genere di attacchi, dicono i ricercatori. Gli impianti industriali possono essere messi fuori gioco, così come i sistemi di controllo delle prigioni USA
35 Commenti alla Notizia SCADA, nuove falle italiane
Ordina
  • Lavorando solo per Enti Pubblici è inevitabile che il sofware creato sia del tipo scada ente.
    (oggi so' spiritiso)Deluso
    non+autenticato
  • Ricercatori del calibro di Auriemma ne esistono pochi, è grazie a loro che la sicurezza aumenta in modo preventivo di una possibile catastrofe.
    Abbiamo dovuto scontrare le nostre teste incredule contro virus come STUXNET prima di comprendere il reale pericolo che corriamo dal momento in cui uno stato si mette contro un'altro, attaccando proprio quei sistemi SCADA che tutti ritenevano sicuri in relazione al loro intrinseco isolamento... E non è così. Centrali nucleari Iraniane prese sotto attacco.
    Grazie Luigi.
    non+autenticato
  • Centrifughe di arricchimento dell'uranio, non centrali nucleari
    non+autenticato
  • Accanto alle (purtroppo ovvie) considerazioni che il cliente (ma anche e sopratutto il management interno) vuole software pronto per IERI e che il cliente vuole pagare sempre il meno possibile , ci sono anche altre Importanti considerazioni, che rendono sballato il post del Monorchio. E in parte anche di tal "Nome e Cognome".

    Le argomentazioni riportate sono
    A) al cliente non interessa/non e' prioritaria (la sicurezza sw), deve essere semplice (per metterci mano = password sul post-it)
    B) il 99% di quei sistemi sono installati in posti dove non c'è collegamento ad internet e che quindi il rischio di essere bucati dall'esterno sono esattamente zero.
    C) la sicurezza = la programmazione sicura, costa. Ergo si risparmia
    D) io programmo sistemini scada/plc, e lo so

    La A) ha un certo fondamento di verita' ,ma ovviamente e' anche compito di chi vende/programma, far capire i potenziali pericoli della fretta...
    Ma andiamo oltre... e leggiamo anche B) C) D).. uniti ad A) fanno capire xche e' sballato quell intervento.

    I software che ha violato auriemma (l'articolo e' su quello! non sullo scibile dei plc ) NON SONO sistemini custom sviluppati per uno specifica aziendina, NON solo funzionano via TCP/IP (altro che il plc custom, con la rs422) ma sono specificatamente pensati per essere usati via internet.

    Tra i piu buggati c'e' il software della Cogent... il sito web,del client, dice questo :
    New Silverlight web HMI
    DataHub WebView is a Silverlight application running in your web browser, allowing you to access your data from anywhere on the Internet.(...)

    Unlimited data and client connections
    When you purchase a WebView license you get unlimited data connections and unlimited web client connections

    Addirittura hanno scomodat silverlight... blah

    Infine, ok non riuscire/poter vendere la sicurezza come standard o come feature aggiuntiva.... ma alla decenza c'e' un limite... usare moduli sw (dll ecc.. uno degli exploit attaccava un demone IPC che non serviva a una mazza, e infatti hanno poi tolto) magari programmati da terze parti sconosciute (e che operano su ip) o peggio ignorare completamente i fondamenti delle problematiche di sicurezza sul tcp/ip , all'ALBA DEL 2011, e' un pochettino criminale imho. Se lo fai nel tuo progetto homemade e/o collegato a una rs232 e' un conto... ma qui, mi sembra, siamo molto oltre. Il giocattolino della cogent si exploita (anche) col directory trasversal sul webserver e usando "comandi" ufficiali pensati per aggiungere degli script... mi pare un po troppo.
    non+autenticato
  • - Scritto da: bubba
    > Accanto alle (purtroppo ovvie) considerazioni che
    > il cliente (ma anche e sopratutto il management
    > interno) vuole software pronto per IERI e che il
    > cliente vuole pagare sempre il meno possibile ,
    > ci sono anche altre Importanti considerazioni,
    > che rendono sballato il post del Monorchio. E in
    > parte anche di tal "Nome e
    > Cognome".
    >
    > Le argomentazioni riportate sono
    > A) al cliente non interessa/non e' prioritaria
    > (la sicurezza sw), deve essere semplice (per
    > metterci mano = password sul
    > post-it)
    > B) il 99% di quei sistemi sono installati in
    > posti dove non c'è collegamento ad internet e che
    > quindi il rischio di essere bucati dall'esterno
    > sono esattamente
    > zero.
    > C) la sicurezza = la programmazione sicura,
    > costa. Ergo si
    > risparmia
    > D) io programmo sistemini scada/plc, e lo so
    >
    > La A) ha un certo fondamento di verita' ,ma
    > ovviamente e' anche compito di chi
    > vende/programma, far capire i potenziali pericoli
    > della fretta...
    >
    > Ma andiamo oltre... e leggiamo anche B) C) D)..
    > uniti ad A) fanno capire xche e' sballato quell
    > intervento.
    >
    > I software che ha violato auriemma (l'articolo e'
    > su quello! non sullo scibile dei plc ) NON SONO
    > sistemini custom sviluppati per uno specifica
    > aziendina, NON solo funzionano via TCP/IP (altro
    > che il plc custom, con la rs422) ma sono
    > specificatamente pensati per essere usati via
    > internet.
    >
    > Tra i piu buggati c'e' il software della
    > Cogent... il sito web,del client, dice questo
    > :
    > New Silverlight web HMI
    > DataHub WebView is a Silverlight application
    > running in your web browser, allowing you to
    > access your data from anywhere on the
    > Internet.(...)
    >
    > Unlimited data and client connections
    > When you purchase a WebView license you get
    > unlimited data connections and unlimited web
    > client
    > connections
    >
    > Addirittura hanno scomodat silverlight... blah
    >
    > Infine, ok non riuscire/poter vendere la
    > sicurezza come standard o come feature
    > aggiuntiva.... ma alla decenza c'e' un limite...
    > usare moduli sw (dll ecc.. uno degli exploit
    > attaccava un demone IPC che non serviva a una
    > mazza, e infatti hanno poi tolto) magari
    > programmati da terze parti sconosciute (e che
    > operano su ip) o peggio ignorare completamente i
    > fondamenti delle problematiche di sicurezza sul
    > tcp/ip , all'ALBA DEL 2011, e' un pochettino
    > criminale imho. Se lo fai nel tuo progetto
    > homemade e/o collegato a una rs232 e' un conto...
    > ma qui, mi sembra, siamo molto oltre. Il
    > giocattolino della cogent si exploita (anche) col
    > directory trasversal sul webserver e usando
    > "comandi" ufficiali pensati per aggiungere degli
    > script... mi pare un po
    > troppo.

    Concordo pienamente, ma per molti da queste parti la cultura informatica vera, qualla che trascende dai video giochi dall'iPAD arranca molto.

    Premesso che gli SCADA sono sempre stati usati con terminali remoti su rete seriale (tipicamente 485 o addirittura Modem per le lunghe tratte), nell'ultimo decennio si sta puntando ovviamente su Ethernet ma non certamente come mezzo di collegamento in rete, piuttosto come mezzo di trsporto. Quindi si parla di lan isolate con router e server (di solito QNX o Montavista) controllati e ovviamente ridondati o addirittura sistemi a dati distribuiti (che è un po`il concetto base dello scada).

    La questione che il cliente non vuole la sicurezza per i sistemi mission critical è una panzana enorme, in realtà quando si parla di sistemi critici per la vita umana, (per esempio per i sistemi di controllo delle centrali di produzione di energia aeroporti, treni eccetera), sono di solito soggetti a certificazione di tipo militare e costano diverse centinaia di migliaia di euro. Le linee di collegamento remoto per esempio per sono spesso linee ISDN riservate basate sul concetto di callback, con timeslot precisi. Figuriamoci se si può pensare di collegare questi sistemi Internet ...

    Quelli di cui si sta parlando sono i controlli ispirati al modello SCADA che tipicamente si esercitano con software per il WEB, usati in ambienti differenti, dove magari una azienda decide di telecontrollare o semplicemente eseguire teleletture di alcuni impianti remoti.

    Il livello di sicurezza si limita ad un hash di accesso e a qualche weak password perché si dà per scontato che la rete sia protetta a monte e comunque che sia più utile che chi sta dall'altra parte abbia un rapido accesso al sistema nel caso qualcosa non funzioni, piuttosto che dover stare ad aspettare che qualcuno recuperi la password o sblocchi il sistema di sicurezza.

    Così come nessuno metterebbe il proprio server aziendale con le cartelle condivise su Internet a maggior ragione, nessuno sano di mente penserebbe di collegare gli impianti senza passare su una VPN ... se poi uno ha accesso non autorizzato all'edificio o addirittura all'impianto ... i problemi di sicurezza non sono sicuramente imputabili allo SCADA.
    non+autenticato
  • Commento sul riepilogo che faccio prima

    - Scritto da: bubba
    > A) al cliente non interessa/non e' prioritaria
    > (la sicurezza sw), deve essere semplice (per
    > metterci mano = password sul
    > post-it)

    Non credo che il problema di sicurezza sia di accesso sulla macchina fisica, ma da remoto...

    > B) il 99% di quei sistemi sono installati in
    > posti dove non c'è collegamento ad internet e che
    > quindi il rischio di essere bucati dall'esterno
    > sono esattamente
    > zero.

    Sempre di meno. Oramai chiedono sempre di più l'accesso remoto tramite web e lo scambio dati su altri pc della rete (se la rete e' fatta bene il tutto non e' detto che sia accessibile dall'esterno, ma non e' sempre cosi')

    > C) la sicurezza = la programmazione sicura,
    > costa. Ergo si
    > risparmia

    Le licenze degli scada mica costano 100 euro! Visto il costo la sicurezza dovrebbe essere delegata al sistema stesso, e non rifatta da zero. Altrimenti prendo qualcosa che costa un centesimo!
    harvey
    1481
  • Chiaro che un sistema come quello che descrivi, con accesso web al sistema e chissà cos'altro deve avere un livello di sicurezza più elevato, ma quello dipende anche dalla criticità di ciò che è sorvegliato.
    Se l'accesso web avviene unicamente su una LAN allora la sicurezza non è così importante.

    Sono d'accordo sul fatto che "basta spiegarlo al cliente" e lo abbiamo fatto, ma quando poi gli presenti il preventivo per migliorare la sicurezza del sistema ti risponde che sono su un LAN e che il sistema ha sempre funzionato bene così.

    Bisogna anche considerare altre problematiche purtroppo. Uno SCADA ha molti punti di accesso, chiaramente c'è l'interfaccia che è la parte più visibile, ma tutte le informazioni arrivano da vari tipi di connessioni che vanno dalle interfacce seriali, a carte di acquisizione e da sistemi comunicanti via TCP/IP sulla LAN stessa.
    Ognuno dei punti di accesso è un possibile punto dove il sistema può essere attaccato.
    Non è sufficiente assicurare l'interfaccia.
    Un audit completo della sicurezza di un tale sistema con la correzione che si impone richiederebbe anche una revisione di tutti i sottosistemi. Il che aumenta i costi in maniera spropositata. Senza contare che spesso e volentieri i sottosistemi sono molto vecchi e che non è possibile rinnovare per vari motivi, primo fra tutti quello che a volte le ditte che li avevano fabbricati sono ormai out of business.

    I costi risultano sempre eccessivi e nessuno vuole pagare! Quindi non si fa.

    Ma come hai ben notato, forse stiamo parlando di sistemi diversi. Quelli su cui lavoro io sono software abbastanza specifici e non molto diffusi, e non sono mai stati dichiarati sicuri per essere utilizzati su internet.
    Un sistema che viene venduto a centinaia o migliaia di esemplari e che viene dichiarato sicuro per l'uso remoto via web deve essere concepito in maniera sicura e verificato regolarmente. E li, il costo di quella manutenzione viene di solito incluso nella licenza e non pagato a parte.
    non+autenticato
  • Gentile Maruccia,
    credo che allarmare senza contraddittorio il mercato in crisi dell'automazione industriale non mi sembra proprio il caso.
    Al nostro simpatico ricercatore del bel paese, gli sfugge il concetto dove operano i PLC.
    I PLC, macchine a controllo numerico, programmate per funzionare in ambienti semplici, quando utilizzano un sistema di controlli sw evoluti, dove si cerca la conferma dell'assorbimento elettrico dell'attività svolta, di solito lo SCADA si utilizza dove esiste un concreto pericolo per la vita umana. In uno scenario di Droni o di controllo areo, ferroviario o sistemi simili e con collegamenti in rete, effettivamente uno scenario di pericolo a causa di errori nel sw, dove la causa viene individuata nella maggior parte dei casi, dal tipo di elettronica che si usa o Hw.
    Senza difendere i produttori citati, che non ne hanno bisogno: Beckhoff, MeasureSoft, Rockwell, Carel, Progea, AzeoTech e Cogent, che lo stessa cosa accade per qualsiasi produttore.
    Questo significa che se devo arare un campo di terra mi serve un normale trattore, chi passa osservando da lontano, sicuramente dirà che se nel trattore mettiamo degli stabbilizzatori particolari oppure un sistema antiribaltamento è una cosa fatta bene.
    Sicuramente, sono consapevole che questa ipotesi è migliore, ma non bisogna dimenticare che è il committente che ci chiede cosa vuole, il programmatore vorrebbe fare molto, dare anche l'anima, ma il committente di solito anche se l'anima viene regalata, purtroppo quando si presenta il conto economico ci chiede di togliere tutto il superfluo oltre al necessario.
    Il confronto tra chi pensa e chi opera, sicuramente farà crescere la qualità dei nostri prodotti made in Italy, che in questo settore sono tra i migliori.
    Comunque vada, grazie al nostro amico ricercatore e ai nostri amici di Punto Informatico, abbiamo tutti la possibilità con argomentazioni costruttive di fare rete di impresa con idee migliorative.

    SATBOX SRL
    engineering solution
    Geom. Giovanni Monorchio

    informaticaindustrialeitalia@inwind.it
    non+autenticato
  • Giuro, ho letto tre volte questo post e non ho capito che cavolo voglia dire, leggo solo delle frasi sconnesse, non c'è filo logico.
    Qual è il messaggio che vuole comunicare, Geom. Giovanni Monorchio?Perplesso
  • - Scritto da: Matteo Italia
    > Giuro, ho letto tre volte questo post e non ho
    > capito che cavolo voglia dire, leggo solo delle
    > frasi sconnesse, non c'è filo
    > logico.
    > Qual è il messaggio che vuole comunicare, Geom.
    > Giovanni Monorchio?
    >Perplesso

    Praticamente da quel che si capisce in mezzo agli strafalcioni il discorso sarebbe "realizzare programmi sicuri ci costerebbe troppo". A bocca storta
    non+autenticato
  • - Scritto da: Lorello Cuccarino
    > Praticamente da quel che si capisce in mezzo agli
    > strafalcioni il discorso sarebbe "realizzare
    > programmi sicuri ci costerebbe troppo".
    >A bocca storta

    Non è quello che dice. Quello che ha detto è "realizzare programmi sicuri costerebbe troppo al cliente".
    Lo so perché anch'io lavoro nel campo e programmo sistemi SCADA (anche se per nessuna delle ditte citate). Ogni volta che si propone al cliente una miglioria per la sicurezza la domanda è "quanto ci costa?" e una volta fatto il prezzo la risposta è "non ci è utile per la produzione, magari un'altra volta".
    Quale programmatore vorrei sempre fornire il meglio del meglio, ma purtroppo non posso. Passi gli errori che si compiono sempre quando si programma un software, ma spesso e volentieri il problema è il cliente che stringe sul prezzo per avere un prodotto più buon mercato e quindi meno sicuro e il capo-progetto che si trova costretto a ridurre i tempi di produzione a causa di problemi di budget.

    Bisogna anche ricordare che il 99% di quei sistemi sono installati in posti dove non c'è collegamento ad internet e che quindi il rischio di essere bucati dall'esterno sono esattamente zero. Il rischio di essere bucati dall'interno invece esiste. Nel mio caso i clienti hanno le password e gli accessi a tutte le macchine e il 90% dei dipendenti sono a conoscenza delle stesse o sanno dove trovare i documenti contenenti l'informazione. Quindi anche avendo un sistema crittato a 1e10 bits non si eviterebbero i problemi di attacchi provenienti dall'interno.

    Bisogna essere capaci a relativizzare il problema.
    Un software usato in un ambiente chiuso dove un numero "limitato" di persone ha un accesso quasi totale al sistema, la sicurezza non è più un problema del programma ma dell'organizzazione della ditta (del nostro cliente nel caso specifico).
    Quindi, ci sono problemi in uno dei nostri SCADA? Ok, e allora? Lo sappiamo benissimo e non causa rischi supplementari!
    non+autenticato
  • - Scritto da: Nome e Cognome
    > - Scritto da: Lorello Cuccarino
    > > Praticamente da quel che si capisce in mezzo
    > agli
    > > strafalcioni il discorso sarebbe "realizzare
    > > programmi sicuri ci costerebbe troppo".
    > >A bocca storta
    >
    > Non è quello che dice. Quello che ha detto è
    > "realizzare programmi sicuri costerebbe troppo al
    > cliente"

    Il prezzo fatto al cliente è in funzione del costo di produzione, per questo costerebbe troppo al cliente. Voglio dire, visto che non credo che i programmatori lavorino gratis e che non credo che una ditta possa reggersi in piedi facendo pagare al cliente meno del costo di produzione...
    non+autenticato
  • - Scritto da: Matteo Italia
    > Giuro, ho letto tre volte questo post e non ho
    > capito che cavolo voglia dire, leggo solo delle
    > frasi sconnesse, non c'è filo
    > logico.
    > Qual è il messaggio che vuole comunicare, Geom.
    > Giovanni Monorchio?
    >Perplesso

    Sintetizzo, ha detto: i sistemi SCADA e PLC non sono connessi in rete, ma su macchine che lavorano non connesse da nessuna parte, quindi il pericolo citato è praticamente inesistente.
    Secondo: una verifica accurata per eliminare tutti i bug costa troppo, o per meglio dire chi acquista vuole un prezzo basso che salirebbe parecchio se si facesse una verifica accuratissima.
  • Ok, ma poi non collegate sti cosi ad internet od alla rete dei PC dell'amministrazione...
    non+autenticato
  • - Scritto da: Saddam Hussein
    > Ok, ma poi non collegate sti cosi ad internet od
    > alla rete dei PC
    > dell'amministrazione...

    Il prossimo passaggio tipicamente diventa che vengono collegati "e vabbè ma tanto chi vuoi che attacchi proprio noi". Anonimo
    non+autenticato
  • Quante volte l'abbiamo sentita questa risposta...
    "Ma a noi nessuno ci vuole male, perchè dovrebbero venire a dar fastidio proprio a noi?" oppure "ma che gliene frega al ragazzino cinese di buttarmi giù il server? che ci guadagna?"
    non+autenticato
  • - Scritto da: Alvaro Vitali
    > Quante volte l'abbiamo sentita questa risposta...
    > "Ma a noi nessuno ci vuole male, perchè
    > dovrebbero venire a dar fastidio proprio a noi?"
    > oppure "ma che gliene frega al ragazzino cinese
    > di buttarmi giù il server? che ci
    > guadagna?"

    Ha detto che i sistemi non sono connessi....
    Quindi il ragazzino cinese si "attacca al tram"... Rotola dal ridere
  • > Ha detto che i sistemi non sono connessi....
    > Quindi il ragazzino cinese si "attacca al
    > tram"...
    > Rotola dal ridere

    E io invece ti (e gli) posso dire che piu` di un sistema plc+scada e` bellamente connesso in rete.

    Il discorso del "al ragazzino cinese che gliene frega" in effetti non e` poi cosi` peregrino.
    E` molto piu` facile fare soldi "facili" con phishing od similia, che non buttando giu` un servizio industriale. Come li fai i soldi "facili" in questo secondo caso? Minacci l'industriale di turno? Un po' troppo rischioso, no? E` cosa piu` da mafiosi, o piu` realisticamente da concorrenza sleale, che da ragazzino cinese.
    Quindi in effetti i rischi possono essere ridotti, almeno numericamente.
    Certo che se pesti i piedi al concorrente di turno, non starei troppo tranquillo.
    Ne sanno qualcosa gli iraniani, i cui scada sono stati sforacchiati per bene.
    non+autenticato