Alfonso Maruccia

SCADA e PLC, sicurezza colabrodo

I sistemi computerizzati distribuiti sono vulnerabili a ogni genere di attacchi, dicono i ricercatori. Gli impianti industriali possono essere messi fuori gioco, così come i sistemi di controllo delle prigioni USA

Roma - Dopo una moratoria forzata sulla pubblicazione delle vulnerabilità presenti nei sistemi di controllo numerico programmabili (PLC) e SCADA (supervisory control and data acquisition) realizzati da Siemens, il tanto temuto lavoro di ricerca di Brian Meixell e Dillon Beresford è stato finalmente svelato al pubblico presente alla conferenza Black Hat di Las Vegas.

Beresford, analista presso NSS Labs, ha avuto l'onere e l'onore di partecipare alla conferenza spiegando che sì, i sistemi di automazione che controllano ogni genere di dispositivo elettrico ed elettronico nel mondo civilizzato sono degli autentici colabrodo in fatto di sicurezza.

In particolare la presentazione dell'esperto se l'è presa con i PLC S7-300 ed S7-1200 di Siemens, due dispositivi fallati sin dalla base visto che la username e la password di accesso è identica e banale: "Basisk", "basic" in svedese.
Beresford va però molto oltre e riesce a scrivere dati sui PLC per scavalcare interamente la protezione da password, recupera dati dai PLC, li obbliga a spegnersi, falsifica i rapporti di stato simulando un funzionamento senza problemi (per l'operatore addetto al controllo) quando in realtà la situazione è molto diversa, cambia l'indirizzo MAC, il nome e l'ora del dispositivo, taglia completamente fuori l'operatore.

Mettendo a frutto gli attacchi e gli exploit realizzati da Beresford, si potrebbe mettere fuori gioco un intero impianto industriale prendendo ripetutamente di mira un singolo sistema PLC. E non si tratta solo di questo, visto che il lavoro di ricerca di Beresford fa eco a un altro studio sulla vulnerabilità dei PCL pubblicato nei giorni scorsi: in quel caso si parla di prigioni (USA) in tilt e porte delle celle spalancate a causa della manomissione dei sistemi di automazione.

Alfonso Maruccia
Notizie collegate
  • AttualitàIran: Siemens collaborazionista su StuxnetLe autorità del paese mediorientale chiamano direttamente in causa l'azienda tedesca. E annunciano azioni legali. Le presunte informazioni fornite a USA e Israele avrebbero potuto avere conseguenze gravi
  • SicurezzaSCADA, le promesse di SiemensPresentazione annullata per gli esperti che hanno individuato alcune vulnerabilità di alto livello nei sistemi di controllo industriale prodotti da Siemens. Che dice di voler aggiornare il software ma senza fornire tempistiche certe.
27 Commenti alla Notizia SCADA e PLC, sicurezza colabrodo
Ordina
  • Se nella mia azienda prendo un esperto nella gestione dei contratti il quale parla solo italiano, e poi lo metto a gestire contratti colossali in lingua cinese con la Cina, non posso pretendere che costui non mi porti a casa contratti assurdi che mi mettono in crisi l'azienda.

    Il colabrodo nella sicurezza non è pertanto negli SCADA, ma nel fatto che qualche volpe li ha collegati ad Internet senza porsi i semplici quesiti:
    1) potrebbero ricevere dati dall'esterno?
    2) potrebbero inviare all'esterno dei dati?
  • Molto buona anche la seconda domanda!
    Credo che si sottovaluti molto il fatto che non sia poi così necessario "intrudere" un PC/sistema (cioè fuori -> dentro) quando un qualsiasi troiano può agevolmente "chiamare casa" per ricevere poi, come reply , i comandi da eseguire. Lo stesso dicasi per la consegna dei risultati.
    Teniamo conto che anche un firewall buono come pf o iptables non può nulla contro una sessione "established" (ovvero: i dati che riceve dall'esterno sono delle risposte a sessioni iniziate dall'interno).
    Meccanismi come il port-forwarding dei router funzionano molto bene nel ridirigere il traffico verso porte note, quando quel traffico viene dall'esterno , ma se sono risposte non vengono gestite dal port-forwarding quanto piuttosto dal NAT... il quale dice semplicemente: la domanda veniva dall'IP interno Tale ed allora la risposta la consegno a Tale, anche se le regole di port-forward non hanno traccia di Tale.
    (sì, in questo periodo mi occupo di egress filteringOcchiolino)
    885
  • Il mio lavoro è quello di progettare sistemi PLC/SCADA, centralizzati o distribuiti... e assicuro tutti che il PLC a logica cablata (con la programmazione a contatti per capirsi) è oggi un lontano ricordo. Adesso esistono linguaggi orientati agli oggetti anche sui PLC: non tutto è Siemens per fortuna! Ci sono anche nicchie molto evolute nel mondo industriale, che non abbandonando il PLC come oggetto (per motivi di affidabilità, robustezza, compattezza, ridondabilità nativa, deterministicità, economicità, caratteristiche realtime, etc...), hanno sofisticato di molto le architetture. Qualunque progettista, e come me spero anche altri, non correrebbe mai il rischio di progettare un network di campo aperto senza inserire delle sicurezze: le stesse degli altri sistemi di più comune diffusione. Chi non lo fa, significa che ha pensato a un sistema "scollegato".
    Personalmente punterei il dito verso le aziende/organizzazioni che utilizzano questi strumenti in maniera impropria: in un articolo ho letto che le famose prigioni che possono essere aperte anche da remoto, lo sono in virtù del fatto che le guardie usano internet sui PC destinati ai sistemi di controllo... direi che la prima falla della sicurezza è l'aver concesso alle guardie di utilizzare internet su una postazione che dovrebbe invece essere BLINDATA.
    Tranquillizzatevi: far funzionare un sistema di automazione e controllo alla perfezione che si conosce bene è un lavoro lungo, difficile, pieno di problemi e complicazioni: chi lo vuole sabotare non può avere in nessun caso vita facile!!!
    non+autenticato
  • PAROLE SAGGIE!

    - Scritto da: Michele Brami
    > Il mio lavoro è quello di progettare sistemi
    > PLC/SCADA, centralizzati o distribuiti... e
    > assicuro tutti che il PLC a logica cablata (con
    > la programmazione a contatti per capirsi) è oggi
    > un lontano ricordo. Adesso esistono linguaggi
    > orientati agli oggetti anche sui PLC: non tutto è
    > Siemens per fortuna! Ci sono anche nicchie molto
    > evolute nel mondo industriale, che non
    > abbandonando il PLC come oggetto (per motivi di
    > affidabilità, robustezza, compattezza,
    > ridondabilità nativa, deterministicità,
    > economicità, caratteristiche realtime, etc...),
    > hanno sofisticato di molto le architetture.
    > Qualunque progettista, e come me spero anche
    > altri, non correrebbe mai il rischio di
    > progettare un network di campo aperto senza
    > inserire delle sicurezze: le stesse degli altri
    > sistemi di più comune diffusione. Chi non lo fa,
    > significa che ha pensato a un sistema
    > "scollegato".
    > Personalmente punterei il dito verso le
    > aziende/organizzazioni che utilizzano questi
    > strumenti in maniera impropria: in un articolo ho
    > letto che le famose prigioni che possono essere
    > aperte anche da remoto, lo sono in virtù del
    > fatto che le guardie usano internet sui PC
    > destinati ai sistemi di controllo... direi che la
    > prima falla della sicurezza è l'aver concesso
    > alle guardie di utilizzare internet su una
    > postazione che dovrebbe invece essere
    > BLINDATA.
    > Tranquillizzatevi: far funzionare un sistema di
    > automazione e controllo alla perfezione che si
    > conosce bene è un lavoro lungo, difficile, pieno
    > di problemi e complicazioni: chi lo vuole
    > sabotare non può avere in nessun caso vita
    > facile!!!
    non+autenticato
  • - Scritto da: Michele Brami
    > Il mio lavoro è quello di progettare sistemi
    > PLC/SCADA, centralizzati o distribuiti... e
    > assicuro tutti che il PLC a logica cablata (con
    > la programmazione a contatti per capirsi) è oggi
    > un lontano ricordo.

    Mah, la mia esperienza e' diametralmente opposta. Io do le specifiche per l'automazione e poi controllo cosa e' stato fatto e come. Nel 100% dei casi, se l'hardware e' un PLC, il linguaggio usato e' il ladder, solo quando proprio non se ne puo' fare a meno ho visto usare l'ST, tipo quando si devono costruire dei messaggi da mandare con una scheda seriale.
  • Nella mia Azienda invece il ladder è bandito. Non è portabile, non è riusabile, non è documentabile, non è flessibile... Devo continuare?
    non+autenticato
  • - Scritto da: Michele Brami
    > Nella mia Azienda invece il ladder è bandito. Non
    > è portabile, non è riusabile, non è
    > documentabile, non è flessibile... Devo
    > continuare?

    Infatti. Ma se vuoi il codice scritto in ST, ti sparano preventivi piu' alti, dal 20% al 50% in piu'. Prova tu a convincere il mio ufficio acquisti che sono soldi ben spesi.Occhiolino
  • Magari! Se mi dai un riferimento... Noi non differenziamo in base al linguaggio!
    non+autenticato
  • ma per quanto ho visto normalmente nei piccoli/medi impianti i plc non sono collegati ad internet, al massimo in rete tra di loro... si richiede insomma che ci sia accesso fisico alla macchina, anche solo per mandare il segnale di stop e reset (FISICI, lo stop e reset via remoto si può fare, che io sappia, solo in modalità run_p, ed il relativo switch deve essere in posizione) della macchina dato che il programma in esecuzione è caricato in un'area di memoria poi protetta da scrittura o.O

    qualcuno di più esperto in plc siemens mi corregga se sbaglio... sono sicuro che qua non si parla al vento ma ciò non va pari passo con quello che mi han insegnato
    non+autenticato
  • - Scritto da: Jacopo Monegato
    > ma per quanto ho visto normalmente nei
    > piccoli/medi impianti i plc non sono collegati ad
    > internet, al massimo in rete tra di loro... si
    > richiede insomma che ci sia accesso fisico alla
    > macchina, anche solo per mandare il segnale di
    > stop e reset (FISICI, lo stop e reset via remoto
    > si può fare, che io sappia, solo in modalità
    > run_p, ed il relativo switch deve essere in
    > posizione) della macchina dato che il programma
    > in esecuzione è caricato in un'area di memoria
    > poi protetta da scrittura
    > o.O
    >
    > qualcuno di più esperto in plc siemens mi
    > corregga se sbaglio... sono sicuro che qua non si
    > parla al vento ma ciò non va pari passo con
    > quello che mi han
    > insegnato

    Io di PLC non so nulla, però una azienda che vende i loro impianti in tutto il mondo mi ha chiesto tempo fa di studiare un qualche sistema per farli accedere da remoto ai loro sistemi, via TCP/IP controllavano e potevano riprogrammare i loro impianti con il linguaggio PLC. Loro mi hanno parlato di accesso direttamente all'impianto, non ad un PC con qualche software collegato tramite interfacce dedicate.
    Il loro problema è che non volevano chiedere alle aziende di riconfigurare i loro firewall, aprire porte ecc, volevano capire se c'era un'alternativa.
    non+autenticato
  • una volta era così, ma oggi c'è sempre più la necessità di accedere a quei sistemi da remoto

    ed è a questo punto che avviene il patatrac
    non+autenticato
  • Tutti gli impianti che ho avviato di recente sono collegati in internet, anni fà invece era più comune il modem 56k o isdn.
    Normalmente si accede tramite vpn ai plc, molte volte anche senza vpn, comunque la sicurezza è sempre a carico dell IT dell'azienda.
    Le password sul plc Siemens di base non ci sono, bisogna impostarla e non è obbligatoria, solo i plc failsafe la richiedono obligatoriamente, e normalmente chi la imposta non lo fà per la sicurezza informatica, ma solo per protegersi contro eventuali clienti non paganti. Per gli scada... ne ho visti programmati con i piedi, venduti a costi altissimi.. ma girano comunque su windows o linux quindi direi che più che il scada vulnerabile è sempre un problema dell'aministratore di rete che non ha protetto la macchina esposta su internet.
    non+autenticato
  • - Scritto da: Jacopo Monegato
    > ma per quanto ho visto normalmente nei
    > piccoli/medi impianti i plc non sono collegati ad
    > internet, al massimo in rete tra di loro... si
    > richiede insomma che ci sia accesso fisico alla
    > macchina, anche solo per mandare il segnale di
    > stop e reset (FISICI, lo stop e reset via remoto
    > si può fare, che io sappia, solo in modalità
    > run_p, ed il relativo switch deve essere in
    > posizione) della macchina dato che il programma
    > in esecuzione è caricato in un'area di memoria
    > poi protetta da scrittura
    > o.O

    In aggiunta a quello che è stato già detto, ovvero che sempre più queste macchine sono collegate alla rete (teleservice), non c'è solo l'aspetto di sicurezza contro il sabotaggio, ma anche la possibile fuga di dati aziendali assai importanti tipo cicli di lavoro, dati di produttività, eccetera... finora a nessuno era venuto in mente di fare spionaggio industriale in questa maniera, ma dopo Stuxnet...

    A proposito di Stuxnet: letture per le vacanze, meglio di un romanzoA bocca aperta

    https://www.nytimes.com/2011/01/16/world/middleeas...
    http://www.wired.com/threatlevel/2011/07/how-digit...
    Funz
    13000
  • - Scritto da: Funz
    > A proposito di Stuxnet: letture per le vacanze,
    > meglio di un romanzo
    >A bocca aperta
    >
    > https://www.nytimes.com/2011/01/16/world/middleeas
    > http://www.wired.com/threatlevel/2011/07/how-digit

    Ho letto anche io la storia su Stuxnet (wired), una cosa a dir poco fantastica!!!
    non+autenticato
  • Non credo di essere OT se dico che, in rete come "newbie", non ci sono solo i PLC: anni fa amministravo una centrale telefonica Siemens Hicom-390 il cui modem era perennemente connesso alla rete telefonica e la cui utenza era un default a livello nazionale. :/
    Quando ho visto 'sta cosa son rimasto attonito: chiunque (con un minimo di conoscenza della materia) poteva aprirci la centrale come uno sgombro semplicemente... telefonandoci.Sorpresa
    Al che ho inserito sull'alimentazione del modem in questione uno di quegli aggeggi che si usano per spegnere/riaccendere gli ATM da remoto, comandato da un paio di comandi ad hoc direttamente dal nostro Host: i tecnici Siemens s'incazzavano da morire (ma i miei referenti diretti sapevano che dovevano telefonare prima a ME, perchè abbassassi il ponte levatoioOcchiolino) ma almeno la centrale era salva.A bocca aperta
    (trattasi di sicurezza fisica: modem spento Occhiolino)

    Però se penso che queste centrali, dato che funzionano molto bene, sono piuttosto diffuse (ospedali, comuni, banche, assicurazioni...) e che nel 99% dei casi hanno il modem online (ed entri direttamente in consolle, come "root")... beh... non so a voi ma a me torna in mente il film degli anni '80 WarGames.
    885
  • - Scritto da: Sky
    cito
    "e la cui utenza era un default a livello nazionale. :/"
    mhh ossia era un numero noto all'universo mondo italiano?Sorride dacci qualche indizio in piuSorride... sul wardialing ci ho passato svariati anniCon la lingua fuori)

    Cmq bello violento il tuo hack hardware, ben fattoSorride
    non+autenticato
  • - Scritto da: bubba
    > - Scritto da: Sky
    > cito
    > "e la cui utenza era un default a livello
    > nazionale.
    > :/"
    > mhh ossia era un numero noto all'universo mondo
    > italiano?Sorride dacci qualche indizio in piuSorride...
    > sul wardialing ci ho passato svariati anni
    >Con la lingua fuori)

    Ma guarda, gli indizi sono anche facili:

    1) il numero del modem, ovviamente, faceva parte della selezione (interna) della centrale: non è che si comprava (e pagava) una linea telefonica "per i comodi di Siemens".

    2) una volta che avevi il prompt della centrale, user e password erano "noti (e, presumo, univoci) a livello nazionale".
    Comprensibilmente (a) non posso scendere in ulteriori particolari e (b) ti lascio il divertimento di scoprire gli uni e gli altri.Occhiolino

    Posso solo dire che, secondo me, qualsiasi ex tecnico di centrali telefoniche Siemens (ed anche altri non-Siemens) potrebbe scatenare una "stuxnet"... altro che.

    Per dirla tutta: quando presi in mano io la gestione, il mio collega mi consegnò anche un corposissimo faldone dicendomi "sono le modifiche apportate nell'ultimo mese"... o___O <- mia faccia
    Tradotto: se la centrare va GIU' GIU' (nel senso che entrambi i processori s'impallano e tocca ricaricare)... poi bisogna riapplicare A MANO circa un mese di modifiche... che erano davvero tante (v. la voce "enorme faldone").

    Ci ponzai un attimo e l'attimo dopo decisi che non esisteva: con le mie (limitate) conoscenze del C, un fantastico 386 (correva l'Anno del Signore 1893...) ed un preziosissimo (e legale) TurboC 1.0, in 2 giorni (tra sviluppo e debug) misi in piedi un "log extractor": di fatto il "coso" leggeva i log (formato testo) della centrale, prodotti dal terminale d'interfaccia su PC, ed estraeva i comandi dati dall'ultimo backup in poi (scartava perfino quelli inutili, tipo i displayA bocca aperta)... oh... 5 MB di testo scannerati in meno di un minuto, su un 386 eh (con la produzione di un reapply-log).
    A quel punto avevo sotto mano TUTTI i comandi da riapplicare e mi bastava un comando per farlo in batch... perchè non so se è noto ai più ma, quando in un CED va giù l'host operativo hai tutti i sistemisti, programmatori ed utenti degli uffici centrali ed agenzie alle costole (che non è poco) MA quando va giù la centrale telefonica hai tutti i direttori generali alle costole (visto che non possono telefonare vengono direttamente da TE)... che è decisamente peggio!A bocca aperta
    In quei casi è molto meglio far vedere che "ci stai lavorando", tranquillo e fiducioso con il terminale che macina comandi, piuttosto che vederti lì, tutto sudato marcio che navighi impazzito in mezzo ad un metrocubo di foglietti.A bocca aperta

    > Cmq bello violento il tuo hack hardware, ben
    > fatto
    >Sorride

    Grazie, mi sembrava l'unica.A bocca aperta
    (e creare i comandi ad host, in NCL, alla fine è stata un pò una banalità)
    885
  • Tutti i sistemi "poco" usati hanno gravi falle di sicurezza, principalmente procedurale, in secondo luogo di natura tecnica. L'idea di base è "chi vuoi che faccia un sabotaggio di questo sistema?".

    Ma scusate, ma quanti di voi hanno fornitori che mettono le stesse password a tutti i clienti? e NON vogliono che i cambi...
    tanto per dirne una
    non+autenticato
  • parliamo di sistemi critici, non possono avere falle del genere

    e l'auditing? paghiamo Accenture, Deloitte, Engineering per cosa?

    la situazione dei sistemi scada è semplicemente vergognosa
    non+autenticato
  • > la situazione dei sistemi scada è semplicemente
    > vergognosa

    Non li sto giustificando, ho detto solo che è normale. E' altrettanto normale che una qualsiasi soluzione tecnologica nasca per dare delle risposte a problemi reali, solo successivamente ci si preoccupa della sicurezza.
    Se ci pensi qualsiasi cosa è fatta così, pensa le case di 50 anni fa con quelle di adesso, le automobili senza ABS, airbag ecc ecc di 30 anni fa e quelle di adesso, il TCP/IP come è nato e come si è evoluto (ad esempio IPv6 che supporta nativamente ipsec).

    Insomma, si inizia a nuotare quando l'acqua arriva al c..o. Se si sa nuotare.
    non+autenticato
  • - Scritto da: Lemon
    > > la situazione dei sistemi scada è
    > semplicemente
    > > vergognosa
    >
    > Non li sto giustificando, ho detto solo che è
    > normale. E' altrettanto normale che una qualsiasi

    Anche perché stiamo parlando di sistemi utilizzati in azienducole anche microscopiche; si pensi che la stragrande maggioranza dei programmatori PLC utilizza un linguaggio derivato da quello CABLATO, in cui AND e OR sono espressi come serie e paralleli di interruttori.
    Figurarsi capire TCP/IP!
    Il settore industriale ha una dinamica lentissima, prima che una tecnologia venga sostituita deve passare tanto, ma tanto tempo.

    > Insomma, si inizia a nuotare quando l'acqua
    > arriva al c..o. Se si sa
    > nuotare.

    E purtroppo la maggioranza non sa farlo.
  • E' anche vero che se il problema inizia a sorgere adesso un motivo c'è: fino a qualche anno fa nessun controller industriale era "connesso in rete", tantomeno via WiFi: adesso, con l'avvento della rete (LAN, intranet ed internet) anche nel mondo industriale, si hanno le stesse problematiche che ritroviamo nel resto della rete... con la differenza che, ad esempio, un dev team come quello di Apache è abituato a pensare in termini di falle e compromissioni, mentre un ingegnere che progetta un PLC il 99% lo vede come "stand alone": quando sei a posto con la sicurezza fisica (e da questo lato mi sa che le aziende sono abbastanza a posto, non fosse altro che non vogliono pagare enormità in assicurazioni e/o danni, usando macchine industriali) il resto conta poco... tranne ora.
    -----------------------------------------------------------
    Modificato dall' autore il 05 agosto 2011 18.05
    -----------------------------------------------------------
    885
  • - Scritto da: Sky
    > con la
    > differenza che, ad esempio, un dev team come
    > quello di Apache è abituato a pensare in termini
    > di falle e compromissioni, mentre un ingegnere
    > che progetta un PLC il 99% lo vede come "stand
    > alone":

    Vero, ma ad un certo punto hanno connesso il prodotto PLC in rete, e lì avrebbero dovuto formare il team. Non è stato fatto, e questo è male.
    Poi c'è il problema al contorno, quello cioè delle aziende per cui se compri un oggetto (un motore, una camma o un PLC connesso in rete) quello deve funzionare, una volta "messo giù". Ma con la rete ed il software non è mai così.
    Due sorgenti di problema, insomma!

    > quando sei a posto con la sicurezza
    > fisica (e da questo lato mi
    > sa che le aziende sono abbastanza a posto, non
    > fosse altro che non vogliono pagare enormità in
    > assicurazioni e/o danni, usando macchine
    > industriali) il resto conta poco... tranne
    > ora.

    Beh... insomma, non sono molto d'accordo sulla "sicurezza fisica". Non del tutto, almeno.
    Ma sono sostanzialmente d'accordo con te.
  • Tieni conto che un ambiente in cui ci sono macchine in movimento è, generalmente, un ambiente intrinsecamente insicuro (come indubbiamente sai). Ora... salvo il fatto che tutti tristemente conosciamo come la "sicurezza sul lavoro" viene trattata ed il numero di morti che ci sono, quel che intendevo (e sul quale, penso, concordi) è che non siamo a casa o dal fruttivendolo ma in un "ambiente insicuro by design" (in fabbrica ci ho lavorato)... è lo stesso che dire "in guerra la gente muore perchè volano proiettili ovunque", al di là delle misure di sicurezza che puoi prendere.Occhiolino
    885
  • - Scritto da: Sky
    > Tieni conto che un ambiente in cui ci sono
    > macchine in movimento è, generalmente, un
    > ambiente intrinsecamente insicuro (come
    > indubbiamente sai). Ora... salvo il fatto che
    > tutti tristemente conosciamo come la "sicurezza
    > sul lavoro" viene trattata ed il numero di morti
    > che ci sono, quel che intendevo (e sul quale,
    > penso, concordi) è che non siamo a casa o dal
    > fruttivendolo ma in un "ambiente insicuro by
    > design" (in fabbrica ci ho lavorato)... è lo
    > stesso che dire "in guerra la gente muore perchè
    > volano proiettili ovunque", al di là delle misure
    > di sicurezza che puoi prendere.
    >Occhiolino

    No, siamo d'accordo. Avevo frainteso alcune tue frasi.
  • - Scritto da: Lemon

    > Non li sto giustificando, ho detto solo che è
    > normale. E' altrettanto normale che una qualsiasi

    e su questo ti dò ragione ma come dici tu stesso:

    "soluzione tecnologica nasca per dare delle
    risposte a problemi reali, solo successivamente
    ci si preoccupa della
    sicurezza."

    questi invece sono coscienti del problema da almeno 15 anni e non fanno un tubo

    la cosa per certi versi ridicola è che parliamo di quei sistemi che più di altri dovrebbero essere protetti
    non+autenticato
  • Perchè vogliamo parlare della certificazione dei sw in ambito farmaceutico? Una pagliacciata in stile "facciamo una stampa di 3000 pagine di listati e così certifichiamo che il programma non è stato modificato".... oppure gli screenshot per certificare il comportamento dei sistemi... ma per favore.. e si fanno pagare oro. Puoi fargli certificare quello che ti pare se solo sei un po' sgamato.
    non+autenticato