RELAZIONE DI CONSULENZA TECNICA
Prof. Marcello CHIABERGE
C.T. per conto del
Pubblico Ministero dr. REPOSO Giorgio
Procuratore della Repubblica presso il Tribunale di Biella
pg_0002
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
2
MEMORIA DEL C.T. del P.M.
Il sottoscritto Prof. Marcello Chiaberge, docente di Elettronica e Meccatronica presso il
Politecnico di Torino e vice-direttore del Centro Servizi di Prototipazione / Laboratorio di
Meccatronica del Politecnico di Torino, in qualità di Consulente Tecnico del PM trasmette
la presente memoria all’illustrissimo Giudice Dr.ssa Maria Serena Iozzo
I quesiti posti dal sig. G.I. al C.T. così recitano:
1. Verifichi il CT se tutti gli elementi che compongono il sistema VISTA-RED
installato lungo la Via Martiri della Libertà nel Comune di Salussola siano state
regolarmente omologate e tarate secondo la normativa vigente
2. Esamini il CT il funzionamento del sistema VISTA-RED installato lungo la Via
Martiri della Libertà nel Comune di Salussola
3.
Esamini il CT il funzionamento dell’impianto semaforico in tutti i suoi elem
enti ed
i suoi collegamenti con e senza VISTA-RED funzionante
4. Verifichi il CT
il funzionamento e le varie modalità di regolazione dell’impianto
semaforico installato lungo la Via Martiri della Libertà nel Comune di Salussola
5. Dica il CT se il VISTA-RED installato a Salussola sia dotato di un sistema
hardware o software in grado di verificare se l’attivazione del rilevamento delle
infrazioni avvenga effettivamente dopo 200ms d
all’inizio della fase di rosso e
che prima di essa siano trascorsi effettivamente 4 secondi della fase di giallo
come dichiarato; il tutto anche in relazione a possibili modifiche, anche
involontarie, della durata della fase di giallo impostate sul regolatore semaforico
e a possibili alterazioni della durata dovute a qualsiasi altra causa
6. Verifichi il CT il tempo minimo di sanzionamento (inteso come tempo minimo di
giallo + tempo minimo di scatto differito).
7. Verifichi il CT
se le spire elettromagnetiche affogate nell’asfalto interagiscono e
in quale
modo con l’impianto semaforico.
8. Verifichi il CT con quali modalità avvengono le varie fasi di documentazione
delle infrazioni che sono: rilevamento degli eventi; trasferimento dei filmati;
predisposizione e masterizzazione dei dati; caricamento e visione dei dati
masterizzati.
9. Analizzi la gestione del documento informatico prodotto dal sistema VISTA-RED
e verifichi se rispetti la normativa vigente, con marcatura temporale che certifichi
la data in cui l’evento è stato compiuto e firma digitale volta a dare al documento
informatico certezza della sua autenticità ed inalterabilità nel tempo
pg_0003
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
3
10. Verifichi se il sistema sia nella piena disponibilità della P.M. e non sfugga mai al
Suo diretto controllo in tutte le fasi, automatiche e/o manuali, in relazione alla
gestione dei dati, al rilievo ed accertamento delle infrazioni, alla verbalizzazione
e alla notifica.
11. Verifichi il CT
su quali elementi agisce il controllo remoto dell’apparecchia
tura
VISTA-RED e per quali fini e se -tramite connnessione remota con il WIRELESS
MODEM o con il MODEM ADSL o con il MODEM ISDN è possibile modificare -
con password o con aggressione dall'esterno- la configurazione del sistema.
12. Verifichi il CT se il GSM presente nella cassetta che contiene il VISTA-RED invia
solo degli allarmi o ha funzione di BIDIRECTIONAL TRANSCEIVER, e se
l'armadio che contiene il VISTA-RED ha un allarme remoto: chi lo riceve e chi è
in grado di attivarlo e/o disattivarlo.
13. Dica il CT se esistono elementi e/o dispositivi atti a garantire la non
manomettibilità del sistema VISTA-
RED e dell’impianto
semaforico sia in loco
che da remoto e descriva a chi sono ascritti i compiti e la responsabilità della
loro verifica e gestione.
Le operazioni peritali sono iniziate il giorno 01/09/2009 presso l’ufficio del CT sito al
Politecnico di Torino e proseguite in gran parte (per le analisi tecniche sul sistema in
questione) presso il Comune di Salussola come da elenco verbali allegati alla relazione.
Il posizionamento della sede delle operazioni peritali presso il Comune di Salussola si è
reso necessario per l’analisi dettagliata dell’apparecchiatura installata lungo la Via Martiri
della Libertà e per la verifica della dotazione software in possesso della P.M. del Comune
di Salussola utilizzata per la verifica dei dati e dei filmati prodotti dall’apparecchiatura
stessa e per la successiva procedura di verbalizzazione e notifica delle infrazioni.
Sulla scorta di quanto emerso durante le numerose sedute peritali e dalla documentazione
in mio possesso ho, pertanto, redatto la presente relazione tecnica.
Per semplicità di lettura, saranno riportate schematicamente le considerazioni
effettivamente rilevanti dal punto di vista tecnico o formale suddivise in base ai quesiti
posti al C.T. sopra riportati.
pg_0004
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
4
Quesito n.1
L’impianto VISTA-RED installato presso il Comune di Salussola può essere “scomposto"
nei seguenti elementi fondamentali:
.
Conchiglia stradale (Figura 1 e Figura 5)
.
Pali telecamere e illuminatori infrarossi (Figura 2)
.
Spire elettromagnetiche (Figura 3)
.
Software di visualizzazione e gestione infrazioni (Figura 4)
Figura 1: conchiglia stradale dell'impianto VISTA-RED di Salussola
pg_0005
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
5
Figura 2: telecamere PANASONIC CW-960 e illuminatori infrarossi nei due sensi di marcia
Figura 3: spire elettromagnetiche affogate nell'asfalto
pg_0006
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
6
Figura 4: interfaccia grafica del software "Visualizzazione infrazioni"
Figura 5: elementi fondamentali all'interno della conchiglia stradale del sistema VISTA-RED
pg_0007
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
7
Dal punto di vista formale, il sistema VISTA-RED appare regolarmente omologato in tutte
le sue parti “principali". Dalla documentazione ottenuta, è possibile però affermare che le
richieste di omologazione riguardanti il sistema VISTA-RED sono relative soltanto alle
seguenti parti:
.
Centralina di controllo (installata all’interno della conchiglia stradale)
.
Videoregistratore Panasonic (installato all’interno della conchiglia stradale)
.
Telecamera (installata sui pali in corrispondenza dell’incrocio)
.
Illuminatore (installato sui pali in corrispondenza dell’incrocio sopra alla telecamera)
Le parti sopra elencate risultano in tutta la documentazione relativa alla richiesta di
omologazione ed in particolare:
.
nel documento di deposito del prototipo (composto da videoregistratore Panasonic
HD316, telecamera Panasonic CW-860A e centralina di controllo) presso il
Ministero delle Infrastrutture e Trasporti in data 15/06/2005
.
nel decreto Prot. n.162 del 23/02/2006 del Ministero delle Infrastrutture e dei
Trasporti (approvazione del documentatore fotografico con la telecamera modello
CW-860A)
.
nell’estensione tecnologica Prot. n.60298 del 11/12/2006 del Ministero dei Trasporti
(estensione dell’approvazione del documentatore fotografico con la telecamera
modello CW-960)
.
nel documento aggiuntivo del Ministero dei Trasporti, Prot. n.58761/usc del
4/12/2006 (omologazione VISTA-RED e legittimità delle riprese video effettuate dal
sistema ai fini del rilevamento dell’infrazione)
.
nell’estensione tecnologica Prot. n.57768 del 11/07/2008 del Ministero delle
Infrastrutture e dei Trasporti (estensione dell’approvazione del documentatore
fotografico con illuminatore alogeno agli infrarossi mod. UF300 e mod. UF500). Tali
illuminatori risultano non utilizzati nell’impianto di Salussola grazie alla sufficiente
illuminazione stradale presente nell’incrocio (uno degli illuminatori non è addirittura
montato). In data 15/07/2009 MICROREX comunica la variazione di “marchio" su
questi illuminatori da DERWENT a BOSCH, senza alterazione delle caratteristiche
(documento di presa d’atto del Ministero delle Infrastrutture e dei Trasporti Prot.
n.05/R.C. del 23/09/2009).
Figura 6: etichette sulla centralina di controllo del sistema VISTA-RED
pg_0008
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
8
Figura 7: etichette sul videoregistratore Panasonic
Figura 8: etichette sulle telecamere
Occorre inoltre precisare quanto segue:
.
le spire elettromagnetiche che rilevano il passaggio e la velocità dei veicoli,
appaiono come una periferica della centralina di controllo del sistema VISTA-RED.
Tale periferica è però fondamentale per il corretto funzionamento del sistema
stesso ed è inoltre una periferica installata esternamente alla conchiglia stradale al
pari di telecamere ed illuminatori. Nella documentazione ottenuta riguardante
l’omologazione del sistema VISTA-RED, le spire elettromagnetiche non compaiono
nè è stato possibile risalire chiaramente ad una loro certificazione/omologazione
separata. Il Dott. Rencurosi della ditta SCAE (produttrice dei detector, dichiara che
esiste solamente una certificazione tecnica).
pg_0009
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
9
.
All’interno della conchiglia stradale del sistema VISTA-RED di Salussola è installato
un personal computer industriale modello PB600 (sistema operativo Linux) di
produzione ASEM e denominato VR-FS2 con funzioni di “file server", ovvero di
“ponte" per il trasferimento dei filmati da parte del videoregistratore.
Su questo computer è installato un server FTP (vsftp) a cui il client FTP del
videoregistratore HD316 punta per effettuare il trasferimento automatico di ogni
filmato prodotto. Tale funzione è fondamentale per una gestione automatizzata del
trasferimento dei filmati attraverso la connessione remota presente tra il sistema e
la centrale operativa.
Anche questo componente (personal computer ASEM) non è presente nella
documentazione relativa alla omologazione del sistema VISTA-RED pur svolgendo
(almeno nell’impianto di Salussola) una funzione fondamentale. Per ammissione
della ditta MICROREX (Ing. Selmi), sul computer non sono applicate le etichette
relative all’omologazione ma solo delle etichette identificative. Questo computer
potrebbe anche non essere installato: in questo caso la connessione esterna per la
trasmissione dei filmati accederebbe direttamente al WEB server presente sul
videoregistratore (operazione effettuata durante la seduta peritale del 29/01/2010).
Figura 9: particolare del computer industriale ASEM (sono evidenti le etichette identificative)
.
All’interno della conchiglia stradale è installato anche un piccolo computer con
sistema operativo Windows con funzioni di “gateway" tra la connessione remota ed
pg_0010
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
10
il computer industriale ASEM: anche questo computer non compare nella
documentazione di omologazione del sistema VISTA-RED.
Figura 10: computer con funzioni di "gateway" Windows/Linux tra connessione remota e file server FTP
.
sempre all’interno della conchiglia stradale è installato un modem/router ADSL
wireless utilizzato come canale di trasferimento verso la centrale operativa dei
filmati prodotti dal videoregistratore.
Figura 11: particolare del modem/router ADSL wireless
Utilizzando questo modem (via ADSL o via wireless dall’esterno della conchiglia) e
passando attraverso il personal computer ASEM precedentemente citato, è
possibile accedere (via interfaccia seriale RS232) alla programmazione della
centralina di controllo del sistema VISTA-RED (operazione dichiarata possibile da
MICROREX stessa, Ing. Selmi). Questo elemento è particolarmente importante
perchè permette di accedere al “cuore" del sistema VISTA-RED senza aprire la
conchiglia stradale. Anche questo elemento fondamentale (modem/router) non
compare nella documentazione di omologazione.
.
Ulteriore elemento fondamentale non citato nella documentazione di omologazione
è il software di “visualizzazione e gestione infrazioni". L’unico riferimento nella
documentazione raccolta rispetto alla parte “software" utilizzata in centrale
operativa (da parte della P.M. di Salussola in questo caso) appare nel documento di
presa d’atto del Ministero delle Infrastrutture e dei Trasporti Prot. n.05/R.C. del
23/09/2009. In questo documento viene riportata la seguente dichiarazione: “... si
prende atto .... delle integrazioni del software apportate al VISTA-RED finalizzate
ad acquisire ulteriori dati per finalità esclusivamente statistica senza che questa
implementazione modifichi in alcun modo la funzione di rilevamento delle
infrazioni".
pg_0011
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
11
Questa dichiarazione effettivamente non chiarisce se il software sia quello a bordo
della centralina di controllo nella conchiglia stradale, nel computer ASEM utilizzato
come file server oppure quello installato sui PC della centrale operativa per la
visualizzazione dei filmati. In ogni caso è il primo documento ufficiale del Ministero
che cita anche la parte software del sistema.
Appare quindi chiaro che il sistema installato a Salussola non è approvato/omologato nel
suo complesso, ma lo sono solo alcuni suoi elementi.
Dal punto di vista tecnico questo “approccio" non appare assolutamente giustificabile in
quanto alcuni degli elementi installati e non omologati sono funzionalmente indispensabili
per il sistema stesso e permettono alcune operazioni particolari altrimenti difficili da
realizzare (come nel caso del computer industriale ASEM che MICROREX dichiara non
facente parte del sistema VISTA-RED, ma che permette, oltre alla gestione FTP dei files
video, l’accesso alla centralina di controllo del sistema via connessione seriale RS-232).
Occorre sottolineare che questa mancanza di “certificazione complessiva del sistema" non
appare attualmente imputabile alle aziende produttrici e/o installatrici, bensì ad una
mancanza normativa che non impone un approccio “integrato" per apparecchiature
complesse come il VISTA-RED. E’ da rilevare inoltre che:
.
l’offerta della ditta TRAFFIC TECNOLOGY (ditta installatrice del sistema VISTA-
RED) viene approvata dal Comune di Salussola in data 06/10/2006
.
il contratto tra TRAFFIC TECNOLOGY ed il Comune di Salussola per il “noleggio,
l’installazione, la manutenzione e i servizi collegati delle apparecchiature
elettroniche per la rilevazione delle infrazioni semaforiche e video sorveglianza"
risale al giorno 8/11/2006
.
il verbale di collaudo della P.M. del Comune di Salussola dell’impianto VISTA-RED
installato presso l’incrocio di Via Martiri della Libertà è datato 01/12/2006
.
l’impianto installato a Salussola (dotato di telecamera PANASONIC CW-960) viene
approvato/omologato solo nell’estensione tecnologica del Ministero dei Trasporti
Prot. n.60298 del 11/12/2006
Figura 12: dichiarazione SIT sui documentatori fotografici per infrazioni con semaforo rosso
pg_0012
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
12
Taratura del sistema: essendo questi sistemi dei semplici apparecchi fotografici (e non dei
sistemi di misura), gli stessi non necessitano di tarature periodiche secondo gli standard
internazionali, come dichiarato dallo stesso SIT (Servizio di Taratura in Italia, Figura 12).
Occorre chiaramente verificare, durante le operazioni di manutenzione periodiche, che
l’orologio interno del videoregistratore (che certifica data e ora del filmato registrato) sia
correttamente regolato (si aggiorna automaticamente tramite collegamento a server NTP).
pg_0013
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
13
Quesito n.2
Figura 13: schema a blocchi della conchiglia stradale del sistema VISTA-RED di Salussola
(come da relazione del Prof. Dalla Chiara del 16/06/2009 per il Giudice di Pace di Biella)
L’impianto fin qui descritto e schematizzato in Figura 13, è basato su una tecnologia
sofisticata, ma concettualmente molto semplice.
Il sistema si compone come già detto al QUESITO n.1 di alcuni elementi essenziali:
.
due telecamere digitale Panasonic Day/Night SDII con zoom, brandeggio e auto-
track (mod. CW-960)
.
due spire induttive elettromagnetiche (per senso di marcia)
.
una centralina di comando
.
un videoregistratore digitale HD316
.
un file server
.
una centrale operativa
(alcune descrizioni ritenute pertinenti e corrette sono tratte dal sito de LA SEMAFORICA,
www.lasemaforica.com
).
Il funzionamento del sistema inizia con le spire induttive elettromagnetiche (si veda anche
QUESITO n.7). Le spire utilizzate nel sistema VISTA-RED sono doppie e permettono di
pg_0014
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
14
rilevare un autoveicolo acquisendo anche la direzionalità (per evitare allarmi inutili, dovuti,
ad esempio, ad un automezzo che transita correttamente in direzione opposta).
Questi cavi sono agganciati ad una sorgente elettrica. Inviando corrente elettrica
attraverso un cavo, esso genera un campo magnetico. Questo campo viene fortemente
condizionato da oggetti metallici che passano sopra o in prossimità della spira stessa. Da
questa variazione si ricava un segnale elettrico molto affidabile in grado di segnalare la
presenza o il passaggio di un veicolo sopra la spira.
La centralina di controllo è l’elemento centrale del sistema VISTA-RED. Riceve in ingresso
i segnali delle spire elettromagnetiche e il segnale di rosso (solo quello) proveniente dalla
centralina semaforica adiacente ed in base a questi elementi comanda le telecamere a
loro volta connesse con il videoregistratore digitale. La centralina controlla costantemente
il segnale del semaforo e le spire.
Se un autoveicolo transita sopra le spire nella direzione ammessa quando il semaforo è
rosso, la centralina attiva la telecamera digitale che inizia la registrazione del filmato. La
telecamera, oltre a iniziare a registrare, segue l’autoveicolo ed effettua uno zoom nella
zona dove si suppone essere la targa: il filmato ottenuto viene memorizzato in locale sul
videoregistratore digitale che archivia l’intero evento (il filmato dell’intera infrazione).
Quando la luce del semaforo è verde, la centralina ignora le spire e non attiva le
telecamere. Il sistema rimane “inattivo" fino a quando non riceve il segnale di rosso dalla
centralina semaforica. Se il veicolo è già nel mezzo dell’intersezione quando la luce
diventa rossa, il sistema non rileverà l’infrazione.
Il sistema VISTA-RED di Salussola è programmato per attendere 200ms (tempo
REDDELAY) dopo l’accensione della luce rossa, per fornire al veicolo un “periodo di
comporto" (
http://www.lasemaforica.com/it/prodotti/infrazioni-semaforiche/vista-red.html
).
La funzione del tempo REDDELAY verrà successivamente adeguatamente analizzata.
Trascorso questo tempo dopo l’accensione del rosso, quando entrambe le spire sono
attivate in una rapida successione, la centralina riconosce che un veicolo sta
attraversando l’intersezione in velocità.
Se il veicolo attiva solo la prima spira, la centralina riconosce che esso si è fermato
all’inizio dell’intersezione senza attraversarla.
Quando un veicolo attiva in sequenza entrambe le spire dopo l’accensione del rosso (e
trascorso il tempo REDDELAY), la centralina automaticamente avvia la telecamera ed il
videoregistratore digitale il quale memorizza un “mini-filmato" dell’evento (partendo da due
secondi prima e fino a quattro secondi dopo la ricezione del segnale di attivazione da
parte della centralina di controllo).
I segnali provenienti dalle due spire vengono anche utilizzati per calcolare una stima
approssimativa della velocita del veicolo in modo da regolare opportunamente lo zoom ed
il tilt della telecamera ed inseguire così in maniera ottimale la vettura dopo l’incrocio. Il
sistema discrimina tra due velocità in base ad alcuni parametri interni della centralina di
controllo (<40km/h e >40km/h, modificabile in base alla geometria dell’incrocio e alla
distanze delle spire elettromagnetiche).
pg_0015
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
15
Tale filmato viene memorizzato in formato H3R (formato proprietario di PANASONIC) sul
videoregistratore, corredato di tutte le informazioni fondamentali dell’evento (data, ora,
ubicazione impianto).
Il nome del file H3R memorizzato sul videoregistratore permette di risalire a queste
informazioni, nonchè al numero della telecamera che lo ha prodotto. Il file video è
riproducibile esclusivamente dal videoregistratore stesso o dal programma VIEWER reso
disponibile dalla stessa PANASONIC (Figura 14). Il videoregistratore memorizza i files
video sul proprio hard-disk interno con una codifica cifrata. Il contenuto dell’hard-disk
diventa così difficilmente utilizzabile al di fuori del videoregistratore o in assenza di
informazioni dettagliate da parte di PANASONIC sulla tecnologia impiegata.
Quanto sopra riportato è emerso durante l’analisi degli hard-disk del sistema.
Figura 14: due fotogrammi significativi di un video di esempio riprodotto con il VIEWER PANASONIC
I file video posso essere prelevati dalla conchiglia stradale attraverso un file server FTP
residente su un computer industriale installato all’interno della stessa conchiglia che
preleva i file video dal videoregistratore digitale e li invia tramite connessione remota alla
centrale operativa.
NOTA: la P.M. del Comune di Salussola non ha accesso diretto alla conchiglia
dell’impianto ma solo al server della centrale operativa da dove puo’ prelevare/verificare i
video che vengono comunque forniti su DVD dalla TRAFFIC TECNOLOGY.
In teoria, per l’analisi dei filmati e la successiva emissione delle eventuali contravvenzioni
basterebbe il semplice utilizzo del VIEWER PANASONIC direttamente da parte della
centrale operativa: chiaramente questa procedura essendo totalmente “manuale"
comporterebbe tempi lunghi per l’analisi di tutti i filmati.
La procedura utilizzata a Salussola prevede che i filmati vengano periodicamente acquisiti
dalla stessa TRAFFIC TECNOLOGY che si occupa di creare attraverso opportuni moduli
software automatizzati il data-base filmati/infrazioni per conto della P.M. del Comune di
Salussola.
pg_0016
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
16
Tale database completo di filmati e di fotogrammi “interessanti" viene poi fornito alla P.M.
tramite DVD creati dalla stessa TRAFFIC TECNOLOGY. Il database è
“precompilato/preelaborato" dall’azienda fornitrice del servizio e contiene già le infrazioni, i
numeri di targa ed i casi considerati “errori di scatto".
Figura 15: software installato a Salussola sui personal computer della P.M. per l'analisi
del database e la validazione delle infrazioni
Compito della P.M. è quello di analizzare la casistica proposta e preelaborata e validare le
situazioni riportate (verde: infrazione proposta, rosso: errore di scatto). La P.M. ha
chiaramente la facoltà di modificare totalmente la soluzione proposta. I tre fotogrammi
visibili nella figura (Figura 15), sono tre fotogrammi proposti automaticamente dal sistema
di preelaborazione software congiuntamente al numero di targa elaborato da un sistema di
riconoscimento automatico e conversione in dato. Tali fotogrammi (come anche il numero
di targa) possono essere modificati se non ritenuti soddisfacenti, esaustivi e/o errati da
parte dell’operatore della P.M.
Figura 16: pubblicità VISTA-RED (sx) e impianto Salussola (dx)
pg_0017
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
17
Figura 17: interfaccia software per il controllo dati proposta nella pubblicità sul sito de La Semaforica
Le figure sopra riportate (Figura 16 e Figura 17) propongono il confronto di alcune
immagini del sistema VISTA-RED tratte dal sito de La Semaforica e quelle dell’impianto di
Salussola e del software di “controllo dati": sia la conchiglia stradale che il software
appaiono diversi da quelli dell’impianto di Salussola analizzato.
Il sistema VISTA-RED analizzato è purtroppo rimasto spento troppo tempo dall’inizio delle
indagini per cui al momento della sua riaccensione effettuata in data 17/12/2009, le
batterie tampone utilizzate per il salvataggio dei dati risultavano completamente scariche
ed il sistema si è resettato ai parametri di fabbrica. Non è stato perciò possibile effettuare
una analisi dei dati memorizzati sulla centralina o degli ultimi valori impostati nei parametri
principali della stessa.
pg_0018
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
18
Quesito n.3
L’impianto semaforico (Figura 18) non è posto sotto sequestro e funziona regolarmente.
Figura 18: visione dell'incrocio con evidenti le lanterne semaforiche e la segnalazione di presenza apparecchiature per il rilievo
automatico delle infrazioni del 146/3 c.d.s.
Dai rilievi eseguiti, l’impianto semaforico ha un collegamento estremamente semplice con
il sistema VISTA-RED posto sotto sequestro.
La centralina di controllo VISTA-RED preleva il segnale di rosso direttamente dalla
tensione di alimentazione della luce rossa della lanterna semaforica (230 Volt) attraverso
un relay come si puo’ chiaramente vedere dalle fotografie allegate (Figura 20 e Figura 21).
Il tipo di interfacciamento è puramente passivo, ovvero il sistema VISTA-RED è “schiavo"
del sistema di regolazione delle lanterne semaforiche e non può alterare in nessun modo
ed in nessun istante il funzionamento della lanterna semaforica (Figura 19).
pg_0019
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
19
Figura 19: dichiarazione MICROREX relativa all'interfacciamento tra sistema VISTA-RED e impianto semaforico.
Nessun interfacciamento è presente verso il segnale di giallo che quindi non viene
nemmeno “monitorato" dal sistema VISTA-RED.
Nessun altro tipo di interfacciamento è previsto verso il sistema di gestione e
temporizzazione della lanterna semaforica.
La presenza o meno del sistema VISTA-RED non influenza il funzionamento dell’impianto
semaforico in nessuna delle sue funzioni.
pg_0020
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
20
Figura 20: conchiglia stradale impianto semaforico
Figura 21: particolare dei cablaggi all'interno della conchiglia stradale dell'impianto semaforico
pg_0021
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
21
Come si può vedere dalla Figura 21, i due grossi cavi grigi servono per alimentare il
sistema VISTA-RED (cavo di sinistra) e per prelevare il segnale del rosso direttamente
dalla morsettiera (cavo di destra con nastro rosso in punta). Nessuna altra connessione è
presente tra i due sistemi.
pg_0022
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
22
Quesito n.4
Come precedentemente descritto l’impianto semaforico non viene assolutamente
influenzato dalla presenza o assenza o malfunzionamento del sistema VISTA-RED.
L’impianto viene interamente controllato dalla centralina visibile in Figura 22, configurabile
tramite comandi manuali sulla stessa e sotto il totale controllo della P.M. del Comune di
Salussola.
Le chiavi della conchiglia stradale sono in esclusivo possesso della P.M. del Comune di
Salussola.
Eventuali manomissioni temporanee del sistema non sono documentabili e/o rintracciabili
in quanto qualunque intervento sul sistema viene effettuato manualmente aprendo la
conchiglia stradale stessa.
L’impianto funziona regolarmente e senza problemi documentati.
Esclusivamente per il funzionamento dell’impianto semaforico, si acquisisce interamente la
relazione del CTU Prof. Bruno Dalla Chiara per il Giudice di Pace di Biella depositata a
Biella il 16/5/2009 (pagg. 8 e 9 della relazione).
Figura 22: rack di controllo dell'impianto semaforico
pg_0023
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
23
Quesito n.5
Il sistema VISTA-RED non possiede alcun sistema in grado di rilevare la durata della fase
di giallo in quanto preleva dalla conchiglia dell’impianto semaforico unicamente il segnale
di rosso.
Il sistema VISTA-RED è tarato per entrare in funzione 200ms (tempo REDDELAY) dopo il
segnale di rosso ma non esiste un sistema di rilettura di tale tempo a scopo di verifica e/o
certificazione dello stesso.
Come in tutti i sistemi elettronici non critici, però, tale sistema non appare indispensabile in
quanto il tempo di 200ms viene calcolato elettronicamente a partire da un segnale (clock)
a frequenza molto più alta (16MHz) generato da un oscillatore locale presente nella
centralina del sistema.
Tale segnale di clock inoltre non richiede tarature particolari (non potrebbe nemmeno
essere soggetto a tali tarature), in quanto generato da un componente elettronico con
tolleranze tali (0.8% nel range di temperatura di funzionamento compreso tra –20° a + 80°)
da rendere assolutamente trascurabili gli effetti sul tempo generato dei 200ms.
Rimane comunque evidente che un eventuale malfunzionamento hardware/software del
sistema (per esempio, accidentale azzeramento, riduzione o aumento del tempo
REDDELAY) non sarebbe rilevato dal sistema, nè segnalato in un file di diagnostica
memorizzato nel sistema, nè segnalato all’operatore della P.M., nè all’operatore della
manutenzione.
Si rileva inoltre che il numero dei fotogrammi memorizzati dal sistema VISTA-RED sono
tali da non permettere di ricavare in maniera analitica affidabile la durata del tempo
REDDELAY durante la fase di analisi dei filmati.
Eventuali alterazioni e/o modifiche della fase di giallo non sono in alcun modo rilevabili dal
sistema.
pg_0024
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
24
Quesito n.6
Il sistema VISTA-RED di Salussola è tarato per entrare in funzione 200ms (tempo
REDDELAY) dopo lo scatto del segnale di rosso (Figura 23).
Figura 23: dichiarazione della ditta Traffic Tecnology riguardo la regolazione del tempo REDDELAY sull'impianto di Salussola
Tale tempo è stato verificato anche tramite collegamento diretto con la centralina del
sistema VISTA-RED effettuata durante la seduta peritale del 17/12/2009.
Il tempo del giallo non dipende in nessun modo dal sistema VISTA-RED. Il tempo di giallo
misurato sul sistema con un cronometro manuale è pari a 3.95 secondi. Tenendo conto
degli errori della misura manuale e delle tolleranze dello strumento di misura, tale tempo è
perfettamente compatibile con il tempo impostato sulla centralina di controllo semaforico
pari a 4 secondi.
Le eventuali variazioni del tempo di giallo legate alle tolleranze del sistema di controllo
dell’impianto semaforico (installato nel 1996 dalla ditta INCES) sono nell’ordine di ±30ms
(variazione legata essenzialmente alla variazione della frequenza di rete
dell’alimentazione a 230V).
pg_0025
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
25
Tale variazione è sicuramente trascurabile rispetto al tempo di giallo impostato ma non
totalmente trascurabile rispetto al tempo REDDELAY impostato sulla centralina del
sistema VISTA-RED.
Il Ministero delle Infrastrutture e dei Trasporti, nel parere espresso il 5/10/2005 (Prot. N.
2015) per l’omologazione del “documentatore fotografico delle infrazioni commesse alle
intersezioni regolate da semaforo denominato “VISTA-RED, prodotto dalla ditta Microrex
S.p.A.", afferma (a pagina 3 del documento) quanto segue:
Figura 24: pagina n.3 del parere n.2015 del 5/10/2005 del Ministero delle Infrastrutture e dei Trasporti
Anche il Consiglio Superiore dei Lavori Pubblici nel “parere per l’omologazione del
documentatore fotografico VISTA-RED" del 17/11/2005 (n. del protocollo 240/05) riporta la
stessa argomentazione a pagina 5:
Figura 25: pagina n.5 del parere n.240/15 del 17/11/2005 del Consiglio Superiore dei Lavori Pubblici
pg_0026
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
26
Appare quindi chiaro che
.
nella valutazione del tempo REDDELAY deve essere anche tenuta in conto la
tolleranza del tempo di giallo in quanto quest’ultima può totalmente annullare o
comunque pesantemente condizionare il tempo minimo di sanzionamento (inteso
come tempo minimo di giallo + tempo RED DELAY)
.
il tempo REDDELAY dell’impianto di Salussola è regolato su un valore di 200ms,
meno della metà del tempo dichiarato sui documenti del Ministero delle
Infrastrutture e dei Trasporti e su quelli del Consiglio Superiore dei Lavori Pubblici
relativi alle pratiche di omologazione dell’apparato VISTA-RED stesso e dichiarato
espressamente come “non modificabile".
Il valore del tempo REDDELAY (ed i fattori che lo modificano) può influire in maniera
significativa in tutte le situazioni ove la vettura attraversa la linea di arresto (e quindi le
spire) in prossimità della commutazione giallo/rosso della lanterna semaforica (Figura 26).
Figura 26: tre fotogrammi consecutivi di caso "limite" (attraversamento spire durante la commutazione giallo/rosso)
pg_0027
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
27
Occorre aggiungere che in alcune comunicazioni del Ministero delle Infrastrutture e dei
Trasporti indirizzate al Comando di P.M. della città di Fossombrone (prot. 19/EM del
9/9/2009 e prot. 0088631 del 14/10/2009, documentazione fornita dalla ditta MICROREX
ed allegata alla presente relazione), l’Ing. Mazziotta (dirigente tecnico del ministero),
relativamente al parametro REDDELAY, dichiara:
.
... la formula adottata
(per la durata del tempo di ritardo, ndr)
non impone un tempo
unico valido per qualsiasi installazione, ma
solo che lo stesso sia “prefissato",
ovviamente con riferimento alla singola intersezione controllata, in funzione delle
sue caratteristiche ...
.
... pertanto il parametro REDDELAY può essere diverso in funzione della geometria
dell’intersezione e del pos
izionamento delle spire, ma la sua impostazione deve
essere fatta dal produttore o tecnico autorizzato e non può essere modificato
dall’utilizzatore del sistema
...
.
... ciò non vuol dire che tale parametro
(REDDELAY, ndr)
sia fisso per ogni
applicazione, ma soltanto che non può essere autonomamente modificato
dall’utilizzatore, perchè occorre un intervento da parte del produttore o da parte di
un tecnico autorizzato dal produttore ...
Nel caso in analisi (Salussola), non risultano però evidenti e neanche documentati:
.
i criteri con cui può essere stimato il parametro REDDELAY in funzione della
geometria dell’impianto
.
i criteri di autorizzazione per la modifica del parametro REDDELAY (l’utilizzatore
sembra essere il Comune di Salussola ma contemporaneamente TRAFFIC
TECNOLOGY dispone degli accessi completi al sistema ed è allo stesso tempo il
gestore del flusso di informazioni provenienti dal sistema stesso nonchè apparente
beneficiario, in base all’art. 10 del contratto di fornitura, di parte dei proventi delle
sanzioni comminate)
Per una effettiva valutazione dell’impatto di questo parametro sul numero totale di
infrazioni, un possibile metodo potrebbe avvalersi di una analisi statistica dettagliata
dell’incrocio eventualmente modificando il comportamento dell’attuale strumentazione
installata ai fini della semplice rilevazione numerica delle infrazioni “palesi"
(attraversamento con rosso pieno) rispetto a quelle “limite" (attraversamento entro il tempo
REDDELAY).
pg_0028
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
28
Quesito n.7
Figura 27: spire elettromagnetiche affogate nell’asfalto prima (sx) e dopo (dx) la linea di arresto
Le spire del sistema VISTA-RED (Figura 27 e Figura 28) hanno una duplice
importantissima funzione ai fini dell’operatività dell’apparato:
.
determinare con certezza l’attraversamento completo della linea di arresto in
presenza del segnale di rosso (una volta trascorso il tempo REDDELAY)
.
stimare la velocità di attraversamento del veicolo in modo da fornire alla centralina
di controllo gli elementi per comandare in maniera appropriata la fase di brandeggio
e zoom della telecamera
Figura 28: schema della zona di arresto con indicazione delle spire elettromagnetiche
pg_0029
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
29
La sequenza di eventi che portano alla attivazione del segnale di trigger (veicolo in
contravvenzione) sulla centralina di controllo del sistema VISTA-RED è la seguente:
.
attesa che la lanterna semaforica diventi rossa
.
attesa del tempo REDDELAY
.
attesa che la spira 1 sia libera
.
la spira 1 deve essere impegnata
.
la spira 2 deve essere impegnata senza che sia rilasciata la spira 1 (ovvero un
unico veicolo deve coprire contemporaneamente le due spire)
.
la spira 2 deve essere rilasciata
.
il segnale di trigger viene attivato al rilascio della spira 2 (la spira 1 potrebbe essere
nuovamente impegnata dal veicolo seguente)
Un eventuale veicolo che stia impegnando la spira 1 al momento del termine del tempo
REDDELAY, viene automaticamente scartato. Un ipotetico secondo veicolo che seguisse
alla velocità di 50 Km/h impiegherebbe ulteriori 72 millisec. per percorrere il metro
necessario per impegnare completamente la spira 1 (larghezza della spira) e quindi tale
secondo veicolo può essere rilevato con sicurezza. Tale tempo è anche ampiamente
inferiore al tempo TRIGTIME impostato sulla centralina come tempo massimo per il
passaggio dalla prima alla seconda spira e pari a 500ms.
Il tempo REDDELAY (200ms nel caso di Salussola) viene conteggiato da un apposito
programma software presente sulla centralina dell’impianto.
Il segnale di trigger della centralina del sistema VISTA-RED non è unico ma è costituito da
due distinti segnali di trigger inviati al videoregistratore presente nel sistema a seconda
che il veicolo transiti sopra le spire ad una velocità approssimativa superiore o inferiore a
40 Km/h.
Questo duplice segnale di trigger viene utilizzato per attivare due distinte impostazioni
sulla telecamera del sistema per l’inseguimento ottimale (brandeggio e zoom)
dell’autoveicolo. La misurazione di questa velocità è empirica e viene usata solo per
decidere quale impostazione della telecamera utilizzare per il migliore inseguimento dello
specifico veicolo che ha generato l’evento di trigger.
Nessun riferimento a questo valore di velocità viene reso disponibile ai fini del
sanzionamento.
Le spire sono collegate esclusivamente alla centralina del sistema VISTA-RED attraverso
dei “detector" a bassa tensione (12V) serie A1100 prodotti dalla ditta S.C.A.E. S.p.A.
(
www.scae.net
) e non interagiscono in nessun modo con il funzionamento dell’impianto
semaforico.
pg_0030
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
30
Quesito n.8
La sequenza delle fasi di documentazione delle infrazioni è estremamente semplice e
schematicamente può essere cosi’ riassunta:
.
rilevamento dell’infrazione da parte del sistema VISTA-RED e registrazione del
filmato da parte del videoregistratore all’interno della conchiglia stradale
.
trasferimento automatico (attraverso procedure informatiche presenti sul computer
industriale ASEM PB600, installato all’interno della conchiglia stradale) del filmato
presente sull’hard-disk del videoregistratore sul server remoto della centrale
operativa gestita dalla TRAFFIC TECNOLOGY (
www.vcr.146-3.it
)
.
possibile visione e download del filmato da parte della P.M. del comune di
Salussola tramite collegamento diretto al server remoto dela centrale operativa
.
TRAFFIC TECNOLOGY prepara ogni 15gg i CD/DVD dei filmati memorizzati sul
server. I CD/DVD contengono sia i filmati che il database precompilato con le
informazioni essenziali relative alle infrazioni ovvero i fotogrammi fondamentali, la
targa, etc... (si veda anche la risposta al Quesito n.2).
Il CD/DVD contiene anche i cosiddetti errori di scatto ovvero quelle situazioni che
hanno generato un evento sul sistema VISTA-RED ma che non sono catalogabili
come infrazione.
.
La P.M. del comune di Salussola riceve i CD/DVD e carica il database precompilato
nel software “Gestione Infrazioni". L’operatore deve verificare una per una tutte le
voci del database ognuna delle quali corrisponde ad una infrazione.
Verificata l’infrazione, il filmato, i tre fotogrammi fondamentali e la targa del veicolo,
l’evento viene catalogato come una effettiva infrazione e viene quindi generato il
relativo verbale nonchè emessa la sanzione (si veda anche la risposta al Quesito
n.10).
pg_0031
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
31
Quesito n.9
Come si evidenzia nella descrizione del funzionamento del sistema VISTA-RED, non
sembra essere presente alcun utilizzo di tecniche conformi alla gestione e formazione del
documento informatico, ai sensi della normativa vigente (dpcm 13/1/2004 e successive
modificazioni ed integrazioni).
Durante la registrazione, trasmissione e conservazione dei flussi video non risulta difatti
alcun utilizzo di tecniche di validazione (tipicamente detta firma elettronica) o tecniche di
validazione temporale (tipicamente indicata come marca temporale).
La memorizzazione con un formato "chiuso" (come quello H3R di PANASONIC) e della
crittografia (di cui peraltro non si conoscono le tecniche e gli algoritmi adottati), secondo la
letteratura scientifica sull'argomento, non sono ritenuti strumenti sufficienti a garantire
l'inalterabilità di un documento informatico e non è altresì adatto a garantirne l'inalterabilità
nel tempo.
Gli stessi DVD inviati alla P.M. di Salussola non risultano contenere dati che ne
identifichino l'originalità nei termini informatici secondo gli standard di conservazione dei
flussi documentali (confrontare per riferimenti ulteriori il sito
http://www.cnipa.gov.it/site/it-
it/Normativa/Raccolta_normativa_ICT/Gestione_dei_flussi_documentali/Conservazione_d
ei_documenti_informatici/
).
Come prova di quanto detto sopra è stata sperimentata una alterazione casuale dei dati
contenuti in un video H3R per verificare se il sistema di visualizzazione fosse in grado di
identificare la manomissione; il software di visualizzazione non è in grado di rilevare le
alterazioni del filmato ed in alcuni casi, alterando pesantemente il video, è stato possibile
far saltare alcuni fotogrammi, ritenuti dal sistema video corrotti, e quindi non visualizzabili.
In nessun caso il software ha evidenziato una alterazione dei contenuti, ma solo generiche
impossibilità di apertura del file, a fronte di pesanti alterazioni del flusso video.
È pertanto lecito supporre che chiunque sia a conoscenza della struttura del formato H3R
e delle tecniche crittografiche utilizzate all'interno del sistema PANASONIC, sia in grado di
apporre qualsiasi alterazione dei flussi video, senza che esista alcuna evidenza di tale
alterazione.
pg_0032
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
32
Quesito n.10
Come ribadito successivamente al QUESITO n.11, la conchiglia stradale del sistema
VISTA-RED di Salussola non risulta essere nella piena (ed esclusiva) disponibilità della
P.M. e non risulta possibile monitorare e/o registrare le attività svolte su di esso da terzi
oltre alla P.M. stessa. L’analisi degli hard-disk del computer industriale ASEM (file server
FTP) e del “gateway" Windows hanno permesso di verificare attività considerevoli di
tentativi di accesso al sistema come documentato negli allegati 1 e 2. Risulta difficile
catalogare il numero di accessi effettivamente riusciti data la mancanza sistematica delle
informazioni relative alle sessioni di lavoro (completamente assenti nel sistema Windows,
mentre il sistema Linux preservava solo gli ultimi due mesi di dati).
Le operazioni di gestione dei dati dalla conchiglia stradale del sistema VISTA-RED alla
centrale operativa, sono effettuate (come detto al QUESITO n.1) dalla società incaricata
(TRAFFIC TECNOLOGY) che scarica i filmati, preelabora gli stessi ai fini dell’estrazione
dei dati significativi (fotogrammi e targa) e precompila il database da fornire alla P.M. di
Salussola tramite DVD masterizzati.
La P.M. non ha le credenziali per l’accesso diretto alla conchiglia (dichiarazione di
TRAFFIC TECNOLOGY, Dott. Pesavento) ma puo’ accedere al server della centrale
operativa per visionare/verificare i filmati prima dell’arrivo dei DVD o per fare un controllo
incrociato dei dati presenti sul DVD. Allegato il mail del 19/5/2010 in cui viene descritto
questo procedimento:
Egregio ing. Chiaberge,
come da sua richiesta abbiamo provveduto a ripristinare una copia di backup del database storico di
Salussola, che ora è nuovamente consultabile tramite l'accesso all'indirizzo: www.vcr.146-3.it
Colgo l'occasione, relativamente alle domande poste nella sua precedente mail, per precisare meglio alcuni
aspetti legati al trattamento delle informazioni.
La procedura di archiviazione dei dati nel database storico è completamente automatica e sposta man mano
i dati più vecchi di un anno dal database on-line a quello storico. L'obiettivo di questa procedura è di non
appesantire il database on-line in modo da garantire buone performance di accesso e consultazione del sito.
Tale sito è messo a disposizione di tutti i nostri clienti, i quali vi accedono con credenziali differenziate, al fine
di visionare in tempo reale gli eventi rilevati dal sistema, con largo anticipo rispetto all'invio quincidinale del
cd masterizzato.
Quindi i filmati sono immediatamente visionabili da parte del Comando di Polizia Municipale nello stesso
istante in cui gli eventi registrati giungono nella Centrale di Raccolta (server dedicato al singolo Comune in
Traffic).
La trasmissione dalla conchiglia stradale alla Centrale di Raccolta è realizzata anch'essa con procedure
completamente automatiche e senza alcun intervento umano: in questo modo il Comando può monitorare in
tempo reale il funzionamento del sistema e visionare gli eventi prima che gli stessi vengano trattati da
personale Traffic.
Solo successivamente, generalmente con un ritardo di qualche giorno, gli eventi vengono presi in carico
dagli operatori Traffic, catalogati, masterizzati e inviati al comando.
Rimango a disposizione per eventuali altri chiarimenti.
Cordialmente, Domenico Pesavento
Bisogna inoltre sottolineare che, come evidenziato dall’analisi del computer industriale
ASEM PB600 (allegato 1), è lecito supporre che il sistema fosse pienamente disponibile
sulla rete Internet e quindi potenzialmente esposto a tentativi di accesso non autorizzato o
pg_0033
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
33
a forzature esterne da parte di utenti non autorizzati (i files di LOG, questa volta presenti,
ne contano ben piu’ di 500.000).
Il rilievo ed accertamento delle infrazioni, la verbalizzazione e la notifica sono operazioni
interamente a carico della P.M. di Salussola effettuate caricando il database di cui sopra
ed analizzando i singoli casi al fine di verificare la correttezza delle informazioni
precaricate da TRAFFIC TECNOLOGY (si vedano filmati allegati alla perizia).
Occorre evidenziare che il software di analisi e verbalizzazione non è dotato di un sistema
di memorizzazione delle operazioni compiute dall’operatore (file di LOG) per cui in teoria è
possibile validare contemporaneamente tutte le infrazioni proposte senza analizzarle una
ad una come da stessa ammissione dell’operatore della P.M. del Comune di Salussola.
In questo modo le operazioni di rilievo, accertamento e verbalizzazione verrebbero
effettuate sui dati preelaborati da TRAFFIC TECNOLOGY e non in base all’analisi
puntuale dei singoli filmati. Nel software non esiste un file di LOG delle operazioni
effettuate dall’operatore e una cronologia delle stesse.
Non sono stati analizzati a fondo i personal computer in possesso della P.M. del Comune
di Salussola in quanto è stato ritenuto fosse passato troppo tempo dall’inizio delle
operazioni sul sistema VISTA-RED per trovare qualcosa di significativo ascrivibile a fatti
relativi l’indagine tecnica.
pg_0034
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
34
Quesito n.11
Il sistema VISTA-RED installato a Salussola è potenzialmente violabile sia in loco che da
remoto.
Nei punti precedenti è stato evidenziato come l’apertura della conchiglia stradale non
scatena nessun allarme nè presso la centrale operativa nè presso la P.M. del Comune di
Salussola.
In particolare, in loco, ci si puo’ collegare direttamente:
.
al videoregistratore (note le credenziali di accesso utente e password) tramite
semplice cavo di rete e modificare settaggi o alterare il contenuto dello stesso
(operazione effettuata durante la seduta peritale del 29/10/2010).
.
alla centralina di controllo(senza credenziali di accesso) tramite semplice cavo
seriale e programma Windows HyperTerminal scaricando ed eventualmente
modificando i valori impostati dei parametri della stessa (come per esempio il tempo
REDDELAY)
Le stesse operazioni possono essere effettuate da remoto tramite collegamento ADSL o
wireless (modem wireless) attraverso il computer industriale ASEM che svolge la funzione
di file server FTP.
MICROREX stessa dichiara esplicitamente quanto segue:
Mediante collegamento remoto sono possibili le seguenti interazioni con il sistema VISTA-RED
una volta conosciuti nome utente e password per l’accesso:
.
Videoregistratore VR-HD316
Mediante password è possibile accedere al web server del videoregistratore ed effettuare
tutte le operazioni previste dal manuale...
Attraverso il videoregistratore è possibile accedere alla telecamera ed effettuare tutte le
operazioni previste dal manuale...
.
File server VR-FS2 (se presente in quanto non facente parte del sistema VISTA-RED)
Mediante password è possibile accedere al server FTP (vsftpd) per prelevare i filmati
prodotti dal videoregistratore e ad esso precedentemente inviati.
Mediante password è possibile accedere ad un sistema di amministrazione (webmin) per il
controllo e gestione della macchina.
Da VR-FS2 è inoltre possibile accedere
–
via interfaccia RS232
–
alla programmazione
della centralina di controllo VR-CU2
Le attività rilevate sugli hard-disk del computer industriale ASEM e del “gateway"
Windows-Linux non sono catalogabili tra accessi consentiti ed eventuali accessi non
consentiti. Appare comunque chiaro che il sistema è potenzialmente accessibile da remoto
per sua stessa architettura e realizzazione.
pg_0035
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
35
Quesito n.12
Figura 29: sistema di allarme GSM "SIMPLY GSM" presente all'interno della conchiglia stradale del sistema VISTA-RED
Il piccolo sistema GSM (SIMPLY GSM, Figura 29) presente all’interno della conchiglia
stradale del sistema VISTA-RED serve esclusivamente ad inviare un messaggio di allarme
via SMS in caso di malfunzionamento del sistema di riscaldamento o in caso di mancanza
di alimentazione (230V) all’interno della conchiglia.
L’apparato è un normalissimo telecontrollo GSM utilizzato normalmente per il telecontrollo
dell’impianto di riscaldamento delle seconde case. Presenta quindi dei segnali di uscita
utilizzabili per attivare per esempio una caldaia e dei segnali di ingresso utilizzabili per
rilevare eventuali anomalie. Queste informazioni sono facilmente reperibili in rete (per
esempio sul sito
http://www.shitek.eu/public/UploadFolder/Download/ST_000001_ita_%28SIMPLY%20GSM%29_ed1.PDF
)
e l’oggetto è normalmente commercializzato per un uso non industriale. Funziona con
delle normalissime schede SIM anche ricaricabili.
Non è possibile utilizzare questo sistema GSM come BIDIRECTIONAL TRANSCEIVER
per la trasmissioni di dati “complessi" (stringhe di dati) o comunque tali da alterare la
configurazione del sistema VISTA-RED in uno dei suoi parametri funzionali fondamentali.
Questo allarme viene ricevuto dalla società che gestisce il sistema VISTA-RED la quale
provvede al ripristino del sistema con l’ausilio della P.M. del Comune di Salussola. Non
esiste nessun altro allarme remoto all’interno della conchiglia stradale del sistema VISTA-
RED: questo vuol anche dire che la conchiglia può essere aperta senza far scattare
nessun allarme o procurare anomalie al sistema stesso.
pg_0036
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
36
Quesito n.13
Il sistema VISTA-RED e l’adiacente impianto semaforico, sono contenuti in due conchiglie
stradali (Figura 30 e Figura 31) in vetroresina chiuse (entrambe) da apposita serratura di
sicurezza. Le chiavi delle due conchiglie sono (a quanto è dato sapere) in esclusivo
possesso della P.M. del Comune di Salussola.
Tutte le operazioni di manutenzione e verifica (sia dell’impianto semaforico che
dell’impianto VISTA-RED) sono sempre state fatte dalle aziende fornitrici preposte in
presenza di un agente della P.M. del Comune di Salussola (sempre in base alle
dichiarazioni della P.M. stessa). In particolare:
.
conchiglia dell’impianto semaforico: una volta aperta, si accede direttamente al
sistema di regolazione dei tempi delle lanterne semaforiche, alle morsettiere di
collegamento ed al sistema di alimentazione.
Qualunque modifica può essere fatta in maniera estremamente semplice anche da
personale non qualificato. Non esiste nessun sistema che permetta la “non
manomettibilità" dell’impianto o un sistema di allarme (remoto o locale) che avvisi
terzi (P.M. o altri) che la conchiglia è stata aperta.
Figura 30: conchiglia stradale impianto semaforico aperta
.
conchiglia dell’impianto VISTA-RED: una volta aperta, si accede direttamente agli
elementi costitutivi del sistema (computer, videoregistratore, gruppo di continuità,
cablaggi, interruttori differenziali, etc...).
Anche in questo caso non esiste alcun sistema che permetta la “non
manomettibilità" dell’impianto o un sistema di allarme (remoto o locale) che avvisi
terzi (P.M. o altri) che la conchiglia è stata aperta.
pg_0037
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
37
Figura 31: conchiglia stradale del sistema VISTA-RED aperta
Parlando di possibili manomissioni, si deve però evidenziare quanto segue:
.
sull’impianto semaforico, eventuali manomissioni sono molto facili da fare ed
relativamente difficili da rilevare (si pensi ad esempio alla modifica del tempo di
giallo di 1 solo secondo) se non dopo una segnalazione da parte di automobilisti
molto attenti (si ricorda che il tempo di giallo non viene misurato dal sistema VISTA-
RED e quindi non è monitorato).
.
sull’impianto VISTA-RED alcune manomissioni possono risultare estremamente
semplici da effettuare ma anche molto evidenti (sconnessione di alcuni cavi,
modifica manuale del settaggio del videoregistratore, etc...) e rilevabili in tempi brevi
dall’azienda che gestisce l’impianto o dalla P.M. del Comune di Salussola stessa
nel momento in cui si scaricano i filmati e si visualizzano per la verifica delle
infrazioni.
Altre manomissioni possibili su questo impianto richiedono competenze specifiche
sull’impianto o in generale sui sistemi elettronici e informazioni sulle credenziali di
accesso ai sistemi dell’impianto (si veda in particolare la risposta al Quesito n.11).
pg_0038
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
38
Conclusioni
Dall’analisi della documentazione e dalle prove tecniche svolte durante le sedute peritali
appaiono quindi molto chiari i seguenti sintetici punti:
.
analisi difficoltosa a causa del lungo tempo di spegnimento del sistema VISTA-RED
.
sistema omologato solo in alcuni componenti
.
altri componenti presenti nell’impianto di Salussola non risultano facenti parte del
sistema VISTA-RED (a detta di MICROREX) e quindi non sono omologati
.
dissincronia temporale tra installazione del sistema e date omologazione
.
tempo di REDDELAY non conforme a quanto dichiarato nei documenti di
omologazione
.
mancanza di criteri oggettivi per la determinazione dell’eventuale modifica del
tempo REDDELAY
.
conchiglie VISTA-RED e impianto semaforico violabili senza allarme e/o
segnalazione remota
.
sistema VISTA-RED violabile da remoto via ADSL o wireless se note le credenziali
di accesso o tramite attacco informatico (protocollo HTTP violabile)
.
sistema VISTA-RED (ed in particolare la centralina MICROREX) violabile in locale
senza credenziali
.
sistema semaforico violabile in locale con semplici operazioni manuali
.
le operazioni effettuate dalla P.M. di Salussola sul database infrazioni preelaborato
da TRAFFIC TECNOLOGY non sono monitorate nè documentate
Con queste considerazioni, il sottoscritto C.T. per conto del PM della Procura della
Repubblica di Biella Prof. Marcello Chiaberge, coadiuvato dagli ausiliari tecnici Prof. Nello
Balossino e Ing. Sergio Rabellino, deposita la presente relazione presso il Tribunale della
Procura di Biella in data 2 luglio 2010.
il C.T. Prof. M. Chiaberge ____________________________
gli ausiliari tecnici Prof. N. Balossino ____________________________
Ing. S. Rabellino ____________________________
pg_0039
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
39
Allegato 1 – Analisi computer industriale ASEM PB600 (file server)
La macchina presa in considerazione è quella che nel sistema sembra sovraintendere al
funzionamento del registratore digitale ed è identificata come "Computer" all'interno dello
schema descrittivo della conchiglia.
L'hard disk corrispondente ha le seguenti caratteristiche:
Capacità 40GB (40007761920 bytes)
HASH SHA-1 AC158D1B23B192EFB97AB629161F7C8CBE2D1EED
Il disco è partizionato come segue:
Disk /dev/loop0: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/loop0p1 * 1 13 104391 83 Linux
/dev/loop0p2 14 4864 38965657+ 8e Linux LVM
La prima partizione è ad uso esclusivo per l'avvio del sistema, mentre nella seconda
partizione sono contenuti i volumi logici del sistema operativo contenuto nel disco che
risulta essere
Fedora Core release 6 (Zod) - kernel 2.6.18-1.2798.fc6
I volumi logici contenuti nel disco sono i seguenti:
--- Logical volume ---
LV Name /dev/VolGroup01/LogVol00
VG Name VolGroup01
LV Write Access read/write
LV Status available
# open 1
LV Size 36.66 GB
Current LE 1173
Segments 1
Allocation inherit
Block device 253:4
--- Logical volume ---
LV Name /dev/VolGroup01/LogVol01
VG Name VolGroup01
LV Write Access read/write
LV Status available
# open 0
LV Size 480.00 MB
Current LE 15
Segments 1
Allocation inherit
Block device 253:5
In cui il primo volume logico (36.66GB) è destinato al sistema e il secondo volume logico
(480MB) è destinato come area di swap per il sistema operativo.
pg_0040
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
40
La ricerca dei dati si svolgerà quindi principalmente sul primo volume logico, in quanto per
i fini della analisi, l'area di swap non risulta di particolare interesse.
Il filesystem contenuto nel volume logico LogVol00 è di tipo ext3
/dev/mapper/VolGroup01-LogVol00 on /mnt/hdd40 type ext3 (ro)
e rappresenta la scelta standard del sistemo operativo Fedora, così come risulta standard
anche il partizionamento del disco come qui descritto. Non si evidenziano pertanto aree di
disco al di fuori di quelle strettamente necessarie al funzionamento del sistema o aree
occulte.
Nel sistema sembrano utilizzabili come accesso solo 2 utenti, come si evince dal file delle
autorizzazioni /etc/passwd
root:x:0:0:root:/root:/bin/bash
hd300:x:500:500::/home/hd300:/bin/bash
laddove l'utente root è l'utente standard di amministrazione del sistema.
Di seguito sono riportati i processi con esecuzione automatica a tempo determinato
(cronjobs) che sono stati impostati per l'utente amministrativo (root):
0 3 * * * /sbin/shutdown -r -F now #RIAVVIAMENTO CON CONTROLLO FILE SYSTEM
# @hourly /usr/local/sbin/kermit/MICROftp.mx >/dev/null #Avviamento CLIENT FTP
per invio files
# 0 6,12 * * * /usr/local/sbin/kermit/hdlog.mx 4
>/usr/local/sbin/kermit/hdlog.log #RACCOLTA FILE LOG DA TUTTI GLI HD316
COLLEGATI
# 0,30 * * * * /usr/local/sbin/kermit/ftpcollect.mx
>/usr/local/sbin/kermit/ftpcollect.log #raccolta dati remoti FTPCOLLECT
con file log
# 0,30 * * * * /usr/local/sbin/kermit/ftpcollect.mx #raccolta dati remoti
FTPCOLLECT con visualizzazione in CRON
0,30 * * * * /home/hd300/ALLARMI/Ping_HD316.sh
Da cui si evince che solo due di questi sembrano attivi al momento dello stop della
macchina, ovvero il primo che pare destinato ad essere eseguito alle 3:00 di ogni giorno e
che riavvia il sistema, e l'ultimo in lista che dovrebbe essere eseguito ogni 30 minuti: lo
script Ping_HD316.sh, la cui attività sarà oggetto di successiva analisi.
Non sembrano invece presenti cronjobs relativi all'utente hd300.
Di interesse sono invece i cronjobs standard del sistema, posti nelle directory
drwxr-xr-x 2 root 4096 Jan 30 2007 cron.daily
drwxr-xr-x 2 root 4096 Jul 15 2006 cron.hourly
drwxr-xr-x 2 root 4096 Jan 25 2007 cron.monthly
drwxr-xr-x 2 root 4096 Jan 25 2007 cron.weekly
ed in particolare dentro a cron.daily
-rwxr-xr-x 1 root root 180 Oct 1 2006 logrotate
pg_0041
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
41
procedura che fa riferimento al file /etc/logrotate.conf al cui interno si può reperire
# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
Il comando logrotate (che dovrebbe essere eseguito almeno 1 volta al giorno) sovrintende
alla periodica cancellazione dei log di sistema, per evitare proattivamente la saturazione
dello spazio disco; la configurazione standard di Fedora configura il sistema in modo che il
log degli accessi (/var/log/wtmp) venga archiviato ogni mese e che venga tenuta una sola
copia di archivio, pertanto sul disco risultano presenti esclusivamente i dati degli accessi al
sistema degli ultimi 2 mesi. La particolare natura del filesystem ext3 e del formato
utilizzato dai sistemi unix per la archiviazione degli accessi non ha permesso una efficace
ricerca tra i file cancellati dei wtmp più vecchi di 2 mesi, per cui non risulta possibile
determinare la storicità completa degli accessi al sistema in analisi.
Di seguito una stampa comprensibile del contenuto dei due file /var/log/wtmp e
var/log/wtmp1
last -f /var/log/wtmp
reboot system boot 2.6.18-1.2798.fc Wed Feb 18 11:41 (449+11:52)
reboot system boot 2.6.18-1.2798.fc Mon Feb 16 07:51 (451+15:42)
reboot system boot 2.6.18-1.2798.fc Mon Feb 16 03:02 (451+20:31)
reboot system boot 2.6.18-1.2798.fc Sun Feb 15 08:28 (18:31)
reboot system boot 2.6.18-1.2798.fc Sun Feb 15 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sat Feb 14 09:05 (17:54)
reboot system boot 2.6.18-1.2798.fc Sat Feb 14 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Feb 13 09:42 (17:17)
reboot system boot 2.6.18-1.2798.fc Fri Feb 13 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Feb 12 10:19 (16:40)
reboot system boot 2.6.18-1.2798.fc Thu Feb 12 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Feb 11 10:56 (16:03)
reboot system boot 2.6.18-1.2798.fc Wed Feb 11 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Tue Feb 10 11:33 (15:26)
reboot system boot 2.6.18-1.2798.fc Tue Feb 10 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Mon Feb 9 12:10 (14:49)
reboot system boot 2.6.18-1.2798.fc Mon Feb 9 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Feb 8 12:47 (14:12)
reboot system boot 2.6.18-1.2798.fc Sun Feb 8 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sat Feb 7 13:25 (13:34)
reboot system boot 2.6.18-1.2798.fc Sat Feb 7 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Feb 6 14:02 (12:57)
reboot system boot 2.6.18-1.2798.fc Fri Feb 6 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Feb 5 14:39 (12:20)
reboot system boot 2.6.18-1.2798.fc Thu Feb 5 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Feb 4 15:16 (11:43)
reboot system boot 2.6.18-1.2798.fc Wed Feb 4 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Tue Feb 3 15:53 (11:06)
reboot system boot 2.6.18-1.2798.fc Tue Feb 3 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Mon Feb 2 16:30 (10:29)
reboot system boot 2.6.18-1.2798.fc Mon Feb 2 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Feb 1 17:07 (09:52)
wtmp begins Sun Feb 1 17:07:23 2009
pg_0042
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
42
last -f /var/log/wtmp.1
reboot system boot 2.6.18-1.2798.fc Sun Feb 1 03:02 (466+20:31)
reboot system boot 2.6.18-1.2798.fc Sat Jan 31 17:44 (09:15)
reboot system boot 2.6.18-1.2798.fc Sat Jan 31 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Jan 30 18:21 (08:38)
reboot system boot 2.6.18-1.2798.fc Fri Jan 30 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Jan 29 18:58 (08:01)
reboot system boot 2.6.18-1.2798.fc Thu Jan 29 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Jan 28 19:35 (07:24)
reboot system boot 2.6.18-1.2798.fc Wed Jan 28 03:03 (23:56)
reboot system boot 2.6.18-1.2798.fc Wed Jan 28 00:55 (02:04)
reboot system boot 2.6.18-1.2798.fc Tue Jan 27 03:03 (23:56)
reboot system boot 2.6.18-1.2798.fc Tue Jan 27 01:32 (01:27)
reboot system boot 2.6.18-1.2798.fc Mon Jan 26 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Mon Jan 26 02:09 (00:50)
reboot system boot 2.6.18-1.2798.fc Sun Jan 25 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Jan 25 02:46 (00:13)
reboot system boot 2.6.18-1.2798.fc Sat Jan 24 03:23 (23:36)
reboot system boot 2.6.18-1.2798.fc Sat Jan 24 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Jan 23 04:00 (22:59)
reboot system boot 2.6.18-1.2798.fc Fri Jan 23 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Jan 22 04:37 (22:22)
reboot system boot 2.6.18-1.2798.fc Thu Jan 22 03:03 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Jan 21 05:15 (21:44)
reboot system boot 2.6.18-1.2798.fc Wed Jan 21 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Tue Jan 20 05:52 (21:07)
reboot system boot 2.6.18-1.2798.fc Tue Jan 20 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Mon Jan 19 06:29 (20:30)
reboot system boot 2.6.18-1.2798.fc Mon Jan 19 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Jan 18 07:06 (19:53)
reboot system boot 2.6.18-1.2798.fc Sun Jan 18 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sat Jan 17 07:43 (19:16)
reboot system boot 2.6.18-1.2798.fc Sat Jan 17 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Jan 16 08:20 (18:39)
reboot system boot 2.6.18-1.2798.fc Fri Jan 16 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Jan 15 08:57 (18:02)
reboot system boot 2.6.18-1.2798.fc Thu Jan 15 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Jan 14 09:34 (17:25)
reboot system boot 2.6.18-1.2798.fc Wed Jan 14 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Tue Jan 13 10:11 (16:48)
reboot system boot 2.6.18-1.2798.fc Tue Jan 13 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Mon Jan 12 10:49 (16:10)
reboot system boot 2.6.18-1.2798.fc Mon Jan 12 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Jan 11 11:26 (15:33)
reboot system boot 2.6.18-1.2798.fc Sun Jan 11 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sat Jan 10 12:03 (14:56)
reboot system boot 2.6.18-1.2798.fc Sat Jan 10 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Jan 9 12:40 (14:19)
reboot system boot 2.6.18-1.2798.fc Fri Jan 9 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Jan 8 13:17 (13:42)
reboot system boot 2.6.18-1.2798.fc Thu Jan 8 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Wed Jan 7 13:54 (13:05)
reboot system boot 2.6.18-1.2798.fc Wed Jan 7 10:41 (16:18)
reboot system boot 2.6.18-1.2798.fc Wed Jan 7 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Tue Jan 6 14:31 (12:28)
reboot system boot 2.6.18-1.2798.fc Tue Jan 6 03:02 (23:57)
pg_0043
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
43
reboot system boot 2.6.18-1.2798.fc Mon Jan 5 15:08 (11:51)
reboot system boot 2.6.18-1.2798.fc Mon Jan 5 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sun Jan 4 15:45 (11:14)
reboot system boot 2.6.18-1.2798.fc Sun Jan 4 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Sat Jan 3 16:22 (10:37)
reboot system boot 2.6.18-1.2798.fc Sat Jan 3 03:03 (23:57)
reboot system boot 2.6.18-1.2798.fc Fri Jan 2 16:59 (10:00)
reboot system boot 2.6.18-1.2798.fc Fri Jan 2 03:02 (23:57)
reboot system boot 2.6.18-1.2798.fc Thu Jan 1 17:36 (09:23)
wtmp.1 begins Thu Jan 1 17:36:45 2009
Da cui si ipotizza che non siano rintracciabili sessioni di lavoro ( l'utente reboot è uno
pseudo utente utilizzato per registrare il riavvio del sistema); le registrazioni qui elencate
sembrano pertanto frutto esclusivo del riavvio periodico del sistema. Non sono però
facilmente comprensibili, allo stato delle analisi effettuate, gli orari in cui alcuni di questi
reboot sono avvenuti, poichè se in molti casi il riavvio è legato al cronjobs delle 3:00, in
altri casi (orari distanti dalle ore 03:00) non sono legati ad alcuna attività preordinata e
pertanto non direttamente riconducibili ad attività automatiche. Potrebbero essere legati al
gruppo di continuità, ma ciò non sembra in alcun modo confutabile poichè i log relativi ad
eventi del software di controllo del gruppo di continuità "Powerware" risultano senza
informazioni di rilievo come ad esempio:
"02/16/2009 13:00:36","1234785636","NoData","NoData","NoData","NoData","NoData",
"NoData","NoData","NoData","NoData","NoData","NoData"
Si ipotizza quindi che le uniche chiamate di shutdown registrate sono quelle del cronjob
delle 3:00, come si vede dai log di /var/log/messages.*
messages:Feb 16 03:00:01 hd300-server shutdown[13508]: shutting down for system
reboot
messages.1:Feb 9 03:00:01 hd300-server shutdown[5355]: shutting down for system
reboot
messages.1:Feb 10 03:00:01 hd300-server shutdown[6285]: shutting down for system
reboot
messages.1:Feb 11 03:00:01 hd300-server shutdown[14158]: shutting down for
system reboot
messages.1:Feb 12 03:00:01 hd300-server shutdown[9495]: shutting down for system
reboot
messages.1:Feb 13 03:00:02 hd300-server shutdown[11538]: shutting down for
system reboot
messages.1:Feb 14 03:00:01 hd300-server shutdown[8144]: shutting down for system
reboot
messages.1:Feb 15 03:00:01 hd300-server shutdown[6313]: shutting down for system
reboot
messages.2:Feb 2 03:00:01 hd300-server shutdown[8047]: shutting down for system
reboot
messages.2:Feb 3 03:00:01 hd300-server shutdown[10295]: shutting down for
system reboot
messages.2:Feb 4 03:00:01 hd300-server shutdown[8507]: shutting down for system
reboot
messages.2:Feb 5 03:00:01 hd300-server shutdown[6846]: shutting down for system
reboot
messages.2:Feb 6 03:00:01 hd300-server shutdown[7411]: shutting down for system
reboot
messages.2:Feb 7 03:00:01 hd300-server shutdown[10904]: shutting down for
system reboot
messages.2:Feb 8 03:00:01 hd300-server shutdown[6006]: shutting down for system
pg_0044
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
44
reboot
messages.3:Jan 26 03:00:01 hd300-server shutdown[2483]: shutting down for system
reboot
messages.3:Jan 27 03:00:02 hd300-server shutdown[4597]: shutting down for system
reboot
messages.3:Jan 28 03:00:02 hd300-server shutdown[2657]: shutting down for system
reboot
messages.3:Jan 29 03:00:02 hd300-server shutdown[7167]: shutting down for system
reboot
messages.3:Jan 30 03:00:01 hd300-server shutdown[6433]: shutting down for system
reboot
messages.3:Jan 31 03:00:02 hd300-server shutdown[3700]: shutting down for system
reboot
messages.3:Feb 1 03:00:01 hd300-server shutdown[7289]: shutting down for system
reboot
messages.4:Jan 19 03:00:01 hd300-server shutdown[6417]: shutting down for system
reboot
messages.4:Jan 20 03:00:01 hd300-server shutdown[5340]: shutting down for system
reboot
messages.4:Jan 21 03:00:01 hd300-server shutdown[7294]: shutting down for system
reboot
messages.4:Jan 22 03:00:01 hd300-server shutdown[6893]: shutting down for system
reboot
messages.4:Jan 23 03:00:01 hd300-server shutdown[5974]: shutting down for system
reboot
messages.4:Jan 24 03:00:01 hd300-server shutdown[14865]: shutting down for
system reboot
messages.4:Jan 25 03:00:01 hd300-server shutdown[2407]: shutting down for system
reboot
Quindi rimangono senza una chiara spiegazione molti dei reboot della macchina.
Per meglio comprendere le possibilità di accesso al sistema dall'esterno, è necessario
analizzare la configurazione del sistema di networking; il sistema sembrerebbe risultare
configurato con due schede di rete i cui parametri estratti dal disco sono i seguenti:
cat /etc/sysconfig/networking/profiles/default/ifcfg*
::::::::::::::
ifcfg-eth0
::::::::::::::
# Intel Corporation 8255xER/82551IT Fast Ethernet Controller
DEVICE=eth0
BOOTPROTO=none
BROADCAST=90.0.0.255
HWADDR=00:12:cd:00:4a:6d
IPADDR=90.0.0.10
NETMASK=255.255.255.0
NETWORK=90.0.0.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
::::::::::::::
ifcfg-eth1
::::::::::::::
# Intel Corporation 82562EM/EX/GX - PRO/100 VM (LOM) Ethernet Controller Mobile
DEVICE=eth1
BOOTPROTO=none
pg_0045
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
45
BROADCAST=192.168.0.255
HWADDR=00:12:cd:00:4a:6c
IPADDR=192.168.0.81
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes
GATEWAY=192.168.0.1
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
In cui si nota l'uso di un indirizzo "pubblico" 90.0.0.10 che è assegnato in internet come
segue:
Nome: amontpellier-257-1-113-10.w90-0.abo.wanadoo.fr
Address: 90.0.0.10
indirizzo che risulta di proprietà dell' ISP "Orange" ma usato probabilmente come indirizzo
di rete tra la macchina ed il videoregistratore, per quanto questa pratica sia
informaticamente poco corretta. A ragione di ciò questo indirizzo non dovrebbe poter
essere utilizzato direttamente su internet.
L'altra scheda di rete ha invece un indirizzo "privato" a norma RFC1918, indirizzo che non
può essere veicolato su internet per la sua stessa natura.
D'altro canto nei log di sistema risultano una notevole quantità di tentativi di accesso falliti,
segno che almeno la porta del servizio SSH era visibile su internet, probabilmente con
meccanismi di port-forwarding da parte del modem/router ADSL, come si vede in un
estratto di /var/log/btmp:
last -f /var/log/btmp
test ssh:notty 98.126.9.226 Mon Feb 16 11:52 gone - no logout
test ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
oracle ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
oracle ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:52 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:52 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 98.126.9.226 Mon Feb 16 11:51 - 11:51 (00:00)
root ssh:notty 89.106.12.190 Mon Feb 16 01:24 - 11:51 (10:27)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 01:24 (06:37)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 18:46 (00:00)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 18:46 (00:00)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 18:46 (00:00)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 18:46 (00:00)
webmaste ssh:notty 96.246.160.18 Sun Feb 15 18:46 - 18:46 (00:00)
pg_0046
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
46
in cui sono registrati i tentativi falliti di accesso al sistema. È lecito quindi supporre che il
sistema fosse accessibile direttamente da qualsiasi postazione internet per quanto allo
stato della analisi non siano direttamente reperibili tracce di avvenute connessioni sui
normali canali di accesso al sistema principalmente per i motivi scritti in precedenza. Gli
accessi falliti elencati nell'estratto sono indirizzi la cui provenienza è qui sotto descritta a
titolo di esempio:
[root@localhost log]# nslookup 98.126.9.226
Server: 192.168.50.2
Address: 192.168.50.2#53
Non-authoritative answer:
226.9.126.98.in-addr.arpa name = 98.126.9.226.customer.krypt.com.
Authoritative answers can be found from:
[root@localhost log]# nslookup 96.246.160.18
Server: 192.168.50.2
Address: 192.168.50.2#53
Non-authoritative answer:
18.160.246.96.in-addr.arpa name = static-96-246-160-18.nycmny.fios.verizon.net.
[root@localhost log]# nslookup 89.106.12.190
Server: 192.168.50.2
Address: 192.168.50.2#53
Non-authoritative answer:
190.12.106.89.in-addr.arpa name = reverse-89-106-12-190.turkticaret.net.
È possibile comprendere come anche solo questi pochi esempi siano significativi della
distribuzione geografica dei probabili tentativi di accesso alla macchina in oggetto. Dalla
messa in opera della macchina alla data di sequestro i tentativi falliti di accesso registrati
risultano essere ben 537630, dato ricavabile poichè il file di log /var/log/btmp non era
soggetto ad archiviazione come succedeva per gli altri file di log.
È lecito supporre inoltre che il sistema si candidi come ponte per l'accesso al
videoregistratore, come si può dedurre dalla configurazione del networking che segue:
[root@localhost etc]# more sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
pg_0047
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
47
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
In cui è importante notare che sembra risultare abilitato il Packet Forwarding (ovvero il
sistema agisce come un router internet) e dalle regole di filtro di rete che seguono:
cat /etc/iptables
# Generated by iptables-save v1.3.5 on Mon Jan 29 18:09:40 2007
*filter
:INPUT ACCEPT [590:162114]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [457:151022]
-A FORWARD -o eth0 -j ACCEPT
-A FORWARD -o eth1 -j ACCEPT
COMMIT
# Completed on Mon Jan 29 18:09:40 2007
# Generated by iptables-save v1.3.5 on Mon Jan 29 18:09:40 2007
*mangle
:PREROUTING ACCEPT [3300:796811]
:INPUT ACCEPT [3200:771712]
:FORWARD ACCEPT [100:25099]
:OUTPUT ACCEPT [2683:720845]
:POSTROUTING ACCEPT [2819:752166]
COMMIT
# Completed on Mon Jan 29 18:09:40 2007
# Generated by iptables-save v1.3.5 on Mon Jan 29 18:09:40 2007
*nat
:PREROUTING ACCEPT [161:22901]
:POSTROUTING ACCEPT [30:2434]
:OUTPUT ACCEPT [48:4926]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination
90.0.0.20
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination
90.0.0.20
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination
90.0.0.20
-A PREROUTING -i eth1 -p tcp -m tcp --dport 10002 -j DNAT --to-destination
90.0.0.30:80
-A PREROUTING -i eth1 -p tcp -m tcp --dport 10003 -j DNAT --to-destination
90.0.0.40:80
-A PREROUTING -i eth1 -p tcp -m tcp --dport 10004 -j DNAT --to-destination
90.0.0.50:80
-A POSTROUTING -o eth1 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Mon Jan 29 18:09:40 2007
In cui si può supporre che il sistema offra la porta 80 di ciascuna delle sue interfacce di
rete come forwarders verso la porta 80 del sistema avente IP address 90.0.0.20, indirizzo
che è assegnato presumibilmente all'apparecchiatura di videoregistrazione. Questo ultimo
fatto si può dedurre andando ad analizzare il cronjob eseguito ogni 30 minuti
/home/hd300/ALLARMI/Ping_HD316.sh:
pg_0048
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
48
[root@localhost ALLARMI]# more Ping_HD316.sh
#!/bin/bash
if ping -c 4 -w 5 90.0.0.20 &>/dev/null ; then echo -ne `date +"%d/%m/%Y
%H:%M:%S"` 'Ping HD316 OK \r\n';else echo -ne `date +"%d/%m/
%Y %H:%M:%S"` 'Ping HD316 non riuscito \r\n'; fi>> /home/hd300/ping_HD316.log
tail --lines=50 /home/hd300/ping_HD316.log >
/home/hd300/ALLARMI/HD001/ping_HD316.lnx
il cui risultato è archiviato regolarmente nel file /home/hd300/ping_HD316.log e le ultime
50 linee sono copiate nel file /home/hd300/ALLARMI/HD001/ping_HD316.lnx, di cui diamo
un estratto
head ping_HD316.lnx
15/02/2009 13:30:04 Ping HD316 OK
15/02/2009 14:00:04 Ping HD316 OK
15/02/2009 14:30:04 Ping HD316 OK
15/02/2009 15:00:04 Ping HD316 OK
15/02/2009 15:30:04 Ping HD316 OK
15/02/2009 16:00:04 Ping HD316 OK
15/02/2009 16:30:05 Ping HD316 OK
15/02/2009 17:00:04 Ping HD316 OK
15/02/2009 17:30:04 Ping HD316 OK
tail ping_HD316.lnx
16/02/2009 09:30:04 Ping HD316 OK
16/02/2009 10:00:04 Ping HD316 OK
16/02/2009 10:30:04 Ping HD316 OK
16/02/2009 11:00:04 Ping HD316 OK
16/02/2009 11:30:04 Ping HD316 OK
16/02/2009 12:00:04 Ping HD316 OK
16/02/2009 12:30:04 Ping HD316 OK
16/02/2009 13:00:04 Ping HD316 OK
16/02/2009 13:30:04 Ping HD316 OK
18/02/2009 12:00:05 Ping HD316 OK
Si può notare la correttezza delle date iscritte nel logfile che sono cadenzate ogni 30
minuti.
Sulla base di queste evidenze, si deve quindi presupporre che il servizio presente sulla
porta 80 del videoregistratore, che per gli standard internet
(
http://www.iana.org/assignments/port-numbers
) corrisponde al protocollo HTTP ovvero
un web-server, fosse liberamente consultabile tramite internet, servizio che era pertanto
disponibile in continuo da qualsiasi postazione internet. Essendo il protocollo HTTP
intrinsecamente insicuro (difatti per le transazioni sicure è stato realizzato il protocollo
HTTPS) e supposto che il servizio fosse liberamente disponibile su internet, diventa un
naturale obiettivo di possibili attacchi e tentativi di intrusione nonchè di accessi autorizzati.
Nel sistema sembra risultare presente anche un processo che viene eseguito ogni volta
che la macchina si avvia, tramite il file /etc/rc.local, qui sotto riportato:
[root@localhost rc.d]# more rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
pg_0049
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
4
9
touch /var/lock/subsys/local
/usr/local/sbin/kermit/MICROstart.mx &
in cui è significativo lo start dello script MICROstart.mx, qui sotto riportato:
[root@localhost kermit]# more MICROstart.mx
sleep 10
echo - >/dev/tty1
echo ----------------------------- >/dev/tty1
echo . AVVIAMENTO serialget >/dev/tty1
echo ----------------------------- >/dev/tty1
sleep 10
echo attendere 75 secondi >/dev/tty1
sleep 20
echo attendere 55 secondi >/dev/tty1
sleep 20
echo attendere 35 secondi >/dev/tty1
sleep 20
echo attendere 15 secondi >/dev/tty1
sleep 10
echo attendere 5 secondi >/dev/tty1
sleep 5
/usr/local/sbin/kermit/serialget.mx 4 >/dev/tty1 &
#sleep 10
#/usr/local/sbin/kermit/camset.mx >/dev/tty1 &
#/usr/local/sbin/kermit/camset.mx >/dev/null &
Dove è richiamato in particolare lo script serialget.mx, qui sotto riportato:
[root@localhost kermit]# more serialget.mx
#!/usr/bin/kermit +
;=======================================================
; Serialget realizzato da Ing. Selmi il 29-05-2006
; ver. 1.0 versione iniziale del 29-05-2006
; ver. 1.1 del 12-01-2007 (ldelete directory RICEZIONE)
; ver. 2.0 del 23-02-2007 per MICROftp
;=======================================================
set quiet on ; nessun messaggio
;set ftp degug on ; visualizza messaggi client FTP
;-------------------- variabili generali ---------------
.SerialSetv := ver 2.0 get ; versione
corrente
.FileSerial := /usr/local/sbin/kermit/Serial.mx ; elwnco file su
FTP remoto
.LocalDirec := /usr/local/sbin/kermit/RICEZIONE ; directory
lavoro
.ShareDirec := /home/hd300/ALLARMI/HD001/ ; directory locale per file
ricevuti
;-------------------
; inizio macro
;-------------------
define HDGET {
; HD316 da controllare
echo ------ INDIRIZZO IP \m(IpAddress)
echo ------ DIRECTORY FS \m(ShareDirec)
; cancella 'serial.mx' presente nella directory /home/hd300/ALLARMI/...
delete \m(ShareDirec)Serial.mx
; if fail echo -------------------------FILE 'Serial.mx' NON TROVATO
pg_0050
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
50
; apre la connessione ftp
ftp open \m(IpAddress) /user:ADMIN /password:12345
; if fail exit 1 --------------------------CONNESSIONE a \m(IpAddress) NON
RIUSCITA
if fail end
; if not \v(ftp_loggedin) exit 1 ----------------------LOGIN a
\m(IpAddress) FALLITO
if not \v(ftp_loggedin) echo ----------------------LOGIN a \m(IpAddress)
FALLITO
echo ..... CONNESSIONE a \m(IpAddress) RIUSCITA
; si posiziona sulla directory 'USER_DATA' su HD316
ftp cd USER_DATA
; if fail exit 1 -------------------------DIRECTORY HD316 'USER_DATA' NON
TROVATA
if fail echo -------------------------DIRECTORY HD316 'USER_DATA' NON
TROVATA
; echo ..... DIRECTORY REMOTA 'USER_DATA' TROVATA
; si posiziona sulla directory locale 'LocalDirec'
lcd \m(LocalDirec)
if fail exit 1 -------------------------DIRECTORY LOCALE
'\m(LocalDirec)' NON TROVATA
; echo ..... DIRECTORY LOCALE '\m(LocalDirec)' TROVATA
; trasferisce il 'serial.mx'
ftp get Serial.mx
ftp get /rename-to:\m(ShareDirec)Serial.mx Serial.mx
; if fail exit 1 -------------------------ERRORE \%n - RX FILE 'Serial.mx'
if fail echo -------------------------ERRORE \%n - RX FILE 'Serial.mx'
ldelete Serial.*
; aggiunge data e ora al file Serial.mx
fopen /append \%c \m(ShareDirec)Serial.mx
if fail end
fwrite \%c \v(ndate)-\v(time) - \v(date) - \m(SerialSetv)
fclose \%c
; visualizza il file ricevuto da HD316
echo ----------- FILE Serial.mx --:
set flag off
fopen /read \%c \m(ShareDirec)Serial.mx
; if fail exit 1 ------------------------- FILE 'Serial.mx' NON TROVATO
if fail end
while not flag {
fread \%c FileName
if fail break
echo \m(FileName)
}
fclose \%c
ftp bye
}
;=========================================================
; INIZIO PROGRAMMA
;=========================================================
screen clear
if not defined \%1 ask \%1 {Inserire numero HD-316 collegati [1-4] -> }
if equal \%1 "1" {
.IpAddress := 90.0.0.20
.ShareDirec := /home/hd300/ALLARMI/HD001/ ;
HDGET
}
if equal \%1 "2" {
.IpAddress := 90.0.0.20
.ShareDirec := /home/hd300/ALLARMI/HD001/ ;
HDGET
pg_0051
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
51
.IpAddress := 90.0.0.30
.ShareDirec := /home/hd300/ALLARMI/HD002/ ;
HDGET
}
if equal \%1 "3" {
.IpAddress := 90.0.0.20
.ShareDirec := /home/hd300/ALLARMI/HD001/ ;
HDGET
.IpAddress := 90.0.0.30
.ShareDirec := /home/hd300/ALLARMI/HD002/ ;
HDGET
.IpAddress := 90.0.0.40
.ShareDirec := /home/hd300/ALLARMI/HD003/ ;
HDGET
}
if equal \%1 "4" {
.IpAddress := 90.0.0.20
.ShareDirec := /home/hd300/ALLARMI/HD001/ ;
HDGET
.IpAddress := 90.0.0.30
.ShareDirec := /home/hd300/ALLARMI/HD002/ ;
HDGET
.IpAddress := 90.0.0.40
.ShareDirec := /home/hd300/ALLARMI/HD003/ ;
HDGET
.IpAddress := 90.0.0.50
.ShareDirec := /home/hd300/ALLARMI/HD004/ ;
HDGET
}
;=========================================================
; FINE PROGRAMMA
;=========================================================
echo ++++++++> LETTURA 'serial.mx' RIUSCITA \v(date) - \v(time) --
\v(ndate)-\v(ntime)
exit
Gli script fanno sicuramente parte del sistema sviluppato e sembrano consentire
l'acquisizione dello stato del videoregistratore.
Nella cartella /usr/local/sbin/kermit sono presenti un insieme di script atti alla gestione del
videoregistratore, ma non sembrano essere inseriti in alcun sistema di esecuzione
automatica.
[root@localhost kermit]# ls -la
total 224
drwxr-xr-x 4 root root 4096 Mar 16 2007 .
drwxr-xr-x 4 root root 4096 Jan 31 2007 ..
-rwxr-xr-x 1 root root 5912 Jan 23 2007 ar-2
-rw-rwSrwT 1 root root 487 Jan 30 2007 camconf.mx
-rwxr-xr-x 1 root root 10902 Feb 23 2007 camsetGN.mx
-rwxr-xr-x 1 root root 31171 Jan 30 2007 camset.mx
-rwxr-xr-x 1 root root 5175 Jul 7 2006 ftpcollect.mx
-rw-rwSrwT 1 root root 151 Mar 7 2007 FTPconf.mx
drwxr-xr-x 2 root root 4096 Mar 16 2007 HD316
-rwxr-xr-x 1 root root 4315 Jul 7 2006 hdlog.mx
-rwxr-xr-x 1 root root 9664 Mar 7 2007 MICROftp.mx
pg_0052
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
52
-rwxr-xr-x 1 root root 557 Mar 16 2007 MICROstart.mx
-rwxr-xr-x 1 root root 14677 Mar 3 2003 parashell
-rwxr-xr-x 1 root root 14415 Mar 3 2003 pin
drwxr-xr-x 2 root root 4096 Feb 16 2009 RICEZIONE
-rwxr-xr-x 1 root root 4120 Feb 26 2007 serialget.mx
-rwxr-xr-x 1 root root 4245 Mar 7 2007 serialset.mx
Tutta l'attività del server FTP viene normalmente memorizzata nel file /var/log/xferlog,
anche questo in versione completa in quanto non oggetto di archiviazione, di cui si riporta
un estratto a titolo di esempio:
Sun Dec 23 08:23:08 2007 13 90.0.0.20 4237312
/home/hd300/ALLARMI/HD001/02_071223092753_0012_04_00.h3r b _ i r hd300 ftp 0 * c
Sun Dec 23 08:47:31 2007 12 90.0.0.20 3901440
/home/hd300/ALLARMI/HD001/01_071223095219_0012_04_00.h3r b _ i r hd300 ftp 0 * c
Sun Dec 23 09:39:57 2007 14 90.0.0.20 4384768
/home/hd300/ALLARMI/HD001/02_071223104446_0012_04_00.h3r b _ i r hd300 ftp 0 * c
Sun Dec 23 09:57:55 2007 13 90.0.0.20 4075520
/home/hd300/ALLARMI/HD001/02_071223110244_0012_04_00.h3r b _ i r hd300 ftp 0 * c
Sun Dec 23 10:06:40 2007 13 90.0.0.20 4364288
/home/hd300/ALLARMI/HD001/01_071223111134_0012_04_00.h3r b _ i r hd300 ftp 0 * c
Le uniche attività che non sono direttamente riconducibili al videoregistratore sembrano le
seguenti:
Mon Jan 29 15:11:58 2007 1 192.168.0.68 29696
/home/hd300/ALLARMI/HD001/ITALIEN.XLS b _ i r hd300 ftp 0 * c
Mon Jan 29 15:12:05 2007 1 192.168.0.68 891
/home/hd300/ALLARMI/HD001/rubrica.csv b _ i r hd300 ftp 0 * c
Mon Jan 29 15:12:13 2007 1 192.168.0.68 21602
/home/hd300/ALLARMI/HD001/DISINSTALLAZIONE.zip b _ i r hd300 ftp 0 * c
Wed Jan 31 15:53:11 2007 1 192.168.0.81 0 /home/hd300/ALLARMI/HD001/Serial.mx b
_ o r hd300 ftp 0 * i
Wed Jan 31 15:57:30 2007 1 192.168.0.81 0 /home/hd300/ALLARMI/HD001/Serial.mx b
_ o r hd300 ftp 0 * i
Fri Feb 23 11:26:42 2007 1 192.168.0.81 0 /home/hd300/ALLARMI/HD001/Serial.mx b
_ o r hd300 ftp 0 * i
Fri Sep 19 09:39:01 2008 1 217.194.179.241 0 /home/hd300/ b _ o r hd300 ftp 0 *
i
Sulla cui natura e obiettivo è difficile dare una valutazione precisa oltre a quella intuitiva
basata sul nome del file che viene trasferito.
Sul sistema si rileva poi che sembra attivo il sistema di amministrazione remota "webmin"
ma il log, che sembra integro e completo nel tempo, riporta molte attività ad inizio
installazione, nel Gennaio del 2007, e successivamente nel 2008 una sequenza di errori
come segue:
[31/Dec/2008:03:03:24 +0100] miniserv.pl started
[31/Dec/2008:03:03:24 +0100] Perl module Authen::PAM needed for PAM is not
installed : Can't locate Authen/PAM.pm in @INC (@INC contains:
/usr/libexec/webmin /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5
pg_0053
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
53
/usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8 .) at (eval 7) line 1.
e nel 2009 le stesse sequenze di errori più quanto segue:
[15/Feb/2009:02:04:39 +0100] [88.191.95.79] Bad Request : This web server is
running in SSL mode. Try the URL <a
href='https://192.168.0.81:10000/'>https://192.168.0.81:10000/</a> instead.<br>
[15/Feb/2009:02:04:40 +0100] [88.191.95.79]
/unauthenticated//..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..
#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..
#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..
#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..#/..
#/..#/..#/..#/..#/etc/shells : File not found
In cui nell'ultima riga risulta riconoscibile un tentativo di attacco informatico, probabilmente
fallito, ma segno ulteriore di quanto i sistemi sembrino esposti agli accessi da internet.
Sul sistema sembra attivo anche il server SMB (SambaServer) per la condivisione dei file
con sistemi operativi di tipo windows, anche qui non ci sono evidenze di accessi, ma una
larga quantità di accessi falliti ed errori quantificabili in
[root@localhost samba]# ls /var/samba/spool|wc -l
75149
differenti sistemi che hanno tentato di collegarsi al servizio, producendo ognuno un
differente file di log.
pg_0054
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
54
Allegato 2 – Analisi computer con funzioni di "gateway" Windows/Linux
tra connessione remota e file server FTP
La macchina presa in considerazione è quella che nel sistema complesso sembra
sovraintendere al funzionamento ed è identificata come "XP" all'interno dello schema
descrittivo della conchiglia.
L'hard disk corrispondente ha le seguenti caratteristiche:
Capacità 80GB (80026361856 bytes)
HASH SHA-1 FAE109AB5F71ADEB7FFA7E7A38A1BAE317493A6D
Il disco è partizionato come segue:
Disk /dev/loop1: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/loop1p1 * 1 9728 78140128+ 7 HPFS/NTFS
L'unica partizione presente ricopre quasi interamente la capacità del disco e quanto
rimane nella parte terminale (21230 settori corrispondenti a circa 10MB) viene usualmente
riservata quando il disco è partizionato con il sistema operativo Windows XP, qui installato
nella versione "Professional". Il filesystem contenuto nella partizione è di tipo NTFS, scelta
che rappresenta lo standard per il sistema installato.
Il registro degli eventi di sicurezza sembra risultare vuoto, poichè non viene normalmente
abilitato sui sistemi Windows XP non legati ad un dominio, per cui risulta difficile risalire ad
eventuali sessioni utente che si siano succedute sul sistema; si possono analizzare i
software che automaticamente operano nel sistema per il funzionamento della conchiglia
di Salussola.
Per la gestione dei processi automatizzati risulta stato installato il software "24x7
Automation Suite 3" e sono configurate al suo interno 5 attività:
1.
Connetti
2.
Giorno_Notte
3.
reb_Conch
4.
reboot ore 03.00 AM
5.
trasferisci_files_fs1
Possiamo analizzare ciascuno di essi per verificarne l'attività operata:
1. Connetti
esecuzione di un batch ogni 7 minuti di tutti i giorni, C:\bat\connetti.bat il cui contenuto
risulta il seguente:
rasdial VPN serv_isa\conc_salussola caccia
pg_0055
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
55
il cui scopo sembra essere quello di attivare una connessione con il server
217.194.178.13, indirizzo che risulta appartenere alla seguente società:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See
http://www.ripe.net/db/support/db
-
terms
-
conditions.pdf
% Note: This output has been filtered.
% To receive output for a database update, use the "
-
B" flag.
% Information related to '217.194.178.0
-
217.194.178.15'
inetnum
: 2
17.194.178.0
-
217.194.178.15
netname: MNT
-
skytek
-
217
-
194
-
178
-
0
descr: Infoplus s.r.l. public IP network MNT
-
skytek
-
217
-
194
-
178
-
0
country: IT
admin
-
c:
MS14551
-
RIPE
tech
-
c:
MS14551
-
RIPE
tech
-
c:
SN1925
-
RIPE
status: ASSIGNED PA
remarks: Customer of Skytek services (www.skytek.it).
remarks: Customer name is Infoplus s.r.l.
remarks: For any abuse generated
from this network
remarks: please contact support@skytek.org.
mnt
-
by:
MNT
-
skytek
source: RIPE # Filtered
person
:
Matteo Santini
address: via G. Cecchin, 1
address: Marostica, VI
address: IT
remarks: Infoplus s.r.l.
phone: +390424470772
e
-
mail: tecnici.infoplus@appalti.org
nic
-
hdl: MS14551
-
RIPE
mnt
-
by:
MNT
-
skytek
source: RIPE # Filtered
2. Giorno_Notte
esecuzione di un eseguibile ogni 10 minuti C:\bat\Giorno_Notte.exe, la cui attività non è
determinabile direttamente, ma che dai log presenti nel disco in C:\Giorno_Notte.log si può
presumere che operi nella gestione delle videocamere e sulla sensibilità della ripresa
video, come si può ipotizzare leggendo un estratto del file di log:
12/02/09 17.06.22 Passa a Notte Dome
1:Falso(0021041);SHUTTER_1/120(0021109);AGC_LOW(0021208);
12/02/09 17.06.53 Passa a Notte Dome
2:Falso(0021041);SHUTTER_1/120(0021109);AGC_LOW(0021208);
13/02/09 8.16.21 Passa a Giorno Dome
1:Falso(0021041);SHUTTER_1/1000(002110E);AGC_OFF(0021201);
13/02/09 8.16.53 Passa a Giorno Dome
2:Falso(0021041);SHUTTER_1/1000(002110E);AGC_OFF(0021201);
16/02/09 9.56.27 Passa a Giorno Dome
1:Falso(0021041);SHUTTER_1/1000(002110E);AGC_OFF(0021201);
16/02/09 9.56.58 Passa a Giorno Dome
2:Falso(0021041);SHUTTER_1/1000(002110E);AGC_OFF(0021201);
pg_0056
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
56
3. reb_Conch
esecuzione di un eseguibile ogni 30 minuti C:\bat\Reb_Conch.exe la cui attività non è
determinabile direttamente, ma anche in questo caso esiste un log in C:\Reb_Conch.log
che riporta quanto segue in estratto:
16/02/09 11.43.45 Ping a 172.17.4.22 eseguito con successo. FS1 ping OK. HD316
OK
16/02/09 12.13.48 Ping a 172.17.4.22 eseguito con successo. FS1 ping OK. HD316
OK
16/02/09 12.43.45 Ping a 172.17.4.22 eseguito con successo. FS1 ping OK. HD316
OK
16/02/09 13.13.45 Ping a 172.17.4.22 eseguito con successo. FS1 ping OK. HD316
OK
18/02/09 12.14.37 Ping a 172.17.4.22 Ping fallito. RIAVVIO PC
Anche in questo caso si può ipotizzare che sia un sistema di verifica di efficienza del
sistema e controllo delle funzionalità.
4. reboot ore 03.00 AM
esecuzione di un eseguibile ogni giorno alle ore 03:00 C:\bat\riavvia.bat i cui contenuto è
di seguito:
rasdial VPN /disconnect
C:\bat\Reboot_portatili.exe
Opera una disconnessione dalla VPN ed esegue il programma Reboot_portatili la cui
attività non è facilmente determinabile.
5. trasferisci_files_fs1
esecuzione di un batch ogni 2 minuti C:\bat\mappa_z.bat il cui contenuto segue:
if exist z:\hd001\salussola_1.txt goto :step1
net use z: \\192.168.0.81\hd300 /user:hd300 microrex,11 /yes
:step1
xcopy z:\hd001\serial.mx c:\hd300\hd001\ /y
move z:\hd001\*.h3r c:\hd300\hd001\
La cui attività sembra consistere nell'aggancio tramite protocollo SMB (Samba) del disco
virtuale Z: operante in remoto sul sistema unix/Fedora e alla successiva copia dei filmati
acquisiti dal videoregistratore.
Sulla macchina inoltre sembra installato un server del protocollo FTP (FileZilla Server) in
cui viene definito un utente server_ttecno con visibilità sulla cartella C:\hd300
regolarmente riempita dalla attività automatica trasferisci_files_fs1. Il log delle attività di
questo servizio sembra però disabilitato e pertanto è impossibile risalire alla attività
eseguita.
Per accedere da remoto al sistema sul sistema risultano installati il server del protocollo
VNC (UltraVNC) utile per collegarsi al sistema con l'interfaccia grafica completa. Anche i
log di questo servizio non sembrano attivati.
pg_0057
Fascicolo n. 278/09
Tribunale di BIELLA
Marcello Prof. CHIABERGE
57
L'ultima esecuzione di hyperterminal, tipico software per connessione seriale ritrovato sul
sistema dalle evidenze sembra risalire al 4 dicembre 2008, informazione riscontrabile dalla
cartella Prefetch del sistema operativo che registra l'ultima esecuzione di un certo
programma.
-rwxrwxrwx 2 root root 15370 Dec 4 2008 HYPERTRM.EXE-0D3D04C6.pf
Sul desktop è reperibile il programma putty, utile anch'esso per connessioni seriali o
TCP/IP, e analizzando la cartella di Prefetch, sembra risultare che sia stato utilizzato
l'ultima volta il 4 dicembre 2008
-rwxrwxrwx 2 root root 12812 Dec 4 2008 PUTTY.EXE-35FB9264.pf
Sempre nella cartella Prefetch non sembrano essere sono presenti programmi che siano
stati cancellati dopo l'uso.