Posted on by Andrea Monti

Reagire ai pen-test non autorizzati

di Andrea Monti monti@ictlex.com – ICTLEX BRIEFS 1/06

Il concetto, in sintesi

  • Il pen-test non autorizzato è uno strumento con il quale “ricercatori indipendenti” cercano vulnerabilità dei sistemi informativi delle aziende.
  • I risultati dei pen-test sono comunicati agli interessati, insieme all’avviso che – nel migliore dei casi – in assenza di dichiarazioni pubbliche di ringraziamento allo “scopritore”, l’informazione sulla vulnerabilità sarà comunque resa nota.
  • Queste azioni possono configurare quantomeno il reato di estorsione a carico dello “scopritore”.
  • Le reazioni possibili, da parte di un’azienda, sono tre: azione legale, deniability, muro di gomma.
  • Ogni soluzione ha delle controindicazioni. L’azione legale può creare problemi di immagine e deve necessariamente essere portata a compimento; la negazione del problema espone al rischio che l’insabbiamento della notizia sia soltanto parziale; il muro di gomma richiede di adottare alcuni provvedimenti immediati (nei casi più seri anche dei licenziamenti), nella consapevolezza che dopo qualche tempo la vicenda sarà totalmente dimenticata.

Il concetto in teoria

Premessa
Capita sempre più di frequente anche in Italia, che internet provider, compagnie telefoniche e – in generale – aziende di una certa dimensione vengano avvicinate più o meno direttamente da soggetti che dicono di avere scoperto una vulnerabilità dei loro sistemi informativi (spesso si tratta dei web istituzionali). Questi soggetti – quantomeno nei casi analizzati direttamente – “colgono l’occasione” per formulare vari tipi di richieste che vanno dal preannunciare tout court la diffusione in pubblico della vulnerabilità, al chiedere che venga emesso un comunicato stampa con ringraziamenti pubblici al “ricercatore indipendente” di sicurezza, al proporsi addirittura come consulenti.

1. I reati possibili
Benché non automaticamente illecita, eseguire pen-test non autorizzati e diffondere senza alcun controllo i risultati può degenerare facilmente nell’estorsione, un reato punito dall’art. 629 del codice penale (c.p.) con la reclusione da cinque a dieci anni e una multa da 516,00 a 2065,00 Euro.
Questi comportamenti possono inoltre essere sanzionati con l’art. 615 ter c.p. che punisce l’accesso abusivo (anche tentato) a un sistema, e l’art. 615 quater c.p. (detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici). La “scoperta” delle vulnerabilità, infatti, non è una scoperta ma – al contrario – una vera e propria “ricerca”. Presuppone cioè un comportamento attivo del soggetto, che deliberatamente comincia ad eseguire attacchi non autorizzati su una piattaforma di produzione specificamente individuata.
La differenza fra “scoperta” e “ricerca” è sottile ma non banale perché a seconda che ricorra l’una o l’altra condizione, cambia radicalmente lo scenario delle responsabilità giuridiche anche penali. Una vulnerabilità scoperta accidentalmente e comunicata alla “vittima” senza chiedere nulla in cambio è un atto equivalente a chiamare il 115 quando ci si imbatte in un incendio. Una vulnerabilità ricercata attivamente svolgendo attività sistematica nei confronti di un sistema è un attacco bello e buono.

2. Non è full disclosure
Per chiarire meglio questo ultimo concetto è utile spiegare perché la pubblicazione di una vulnerabilità che affligge una certa piattaforma in quanto tale non è illecita, mentre lo diventa quando il bug si riferisce a una specifica implementazione, in un particolare settore, in una macchina in produzione.
Se, nel settore dei beni di consumo dimostro che un certo prodotto contiene delle sostanze tossiche nessuno potrà accusarmi di avere violato la legge. Allo stesso modo, se analizzo il comportamento di un sistema operativo e ne individuo un difetto che indebolisce il sistema, non posso essere considerato responsabile per il solo fatto di parlarne. Altro discorso è se, invece di descrivere un problema di tipo generale, diffondo la notizia che il server della società XYZ è esposto ad attacchi cross-site scripting, fornendo anche istruzioni dettagliate per realizzare il “colpo”.
E’ vero che anche la full disclosure (cioè, appunto, la diffusione di informazioni sulle vulnerabilità di sistemi operativi e applicazioni) va gestita in modo responsabile per evitare conseguenze spiacevoli. Dunque, se si scopre una vulnerabilità seria è impensabile evitare di avvisare immediatamente il produttore del software difettoso. E se si usa strumentalizza la scoperta si potrebbero anche passare dei guai giudiziari.
Ma è anche vero che, legalmente, esiste una differenza sostanziale fra l’analisi teorica di un problema e l’attacco a un server pubblico. Anche perché non è affatto detto, in questo secondo caso, che la scoperta “casuale” della vulnerabilità sia necessariamente merito originale del “ricercatore indipendente”. In altri termini, se il bug viene scoperto con il semplice uso di strumenti di intrusione o con programmi che automatizzano gli attacchi, viene meno anche la “giustificazione” del voler fare ricerca. Non c’è contenuto scientifico nel lanciare un programma contro un’applicazione e aspettare per vedere cosa succede.

3. Scoppia il caso
Veniamo ora al momento critico: di punto in bianco, qualcuno della divisione sicurezza (o – nei casi di aziende più piccole – il webmaster del sito) trova in mailbox un messaggio che lo avvisa del problema. I toni sono, di solito, abbastanza amichevoli e collaborativi ma, nella sostanza, estremamente chiari: a seguito di una scoperta casuale il mittente della mail si è “imbattuto” in una vulnerabilità che potrebbe creare pericoli alla privacy dei clienti. Per fortuna che se ne è accorto lui che è bravo, perché se invece l’informazione fosse finita in altre mani chissà cosa sarebbe successo, e dunque sarebbe gentile che questa gentilezza fosse ricompensata in vario modo.

4. Reagire in sede giudiziaria
Di fronte a queste “scoperte” più o meno casuali, la reazione a caldo più frequente delle aziende interessate è quella di denunciare il fatto e cercare di ottenere l’eliminazione delle informazioni diffuse in rete. Sebbene questa sia una strada tecnicamente – in senso legale – percorribile, presenta delle criticità in termini di gestione dell’immagine aziendale. Il rischio, in altre parole, è sempre quello di creare un “martire/eroe” e di alimentare il concetto di “multinazionale cattiva”. Il “ricercatore indipendente”, infatti, si troverebbe in una posizione semplice da comunicare: “ho trovato un bug, ho dimostrato che l’ISP XYZ è vulnerabile e ora questo si vuole vendicare”.
Viceversa, l’azienda oggetto dell’estorsione, avrebbe qualche difficoltà in più a spiegare ai propri clienti in modo semplice il concetto che un conto è fare il “test dell’alce” su un’automobile dimostrando che si ribalta, e un’altra è “aggredire” abusivamente un servizio internet in produzione. In questo caso, una strada per attenuare l’impatto della notizia può essere quella di evidenziare il tentativo di strumentalizzazione da parte del “ricercatore”, per esempio nel caso in cui prima che la vulnerabilità sia stata eliminata, questa venga resa pubblica. Circostanza che consentirebbe di dimostrare la volontà di provocare danni e non quella di cooperare per risolvere un problema.
Quello che è certo, è che se l’azienda sceglie di perseguire legalmente il “ricercatore indipendente”, non può permettersi di tornare indietro o di avere la mano leggera, ma deve assolutamente ottenere una condanna. L’effetto di una assoluzione o di una “marcia indietro” sarebbe peggiore del danno che si intendeva contrastare. Scegliere la via giudiziaria, comunque, richiede alcune cautele di tipo legale per evitare che il processo si trasformi un nulla di fatto. Se la vulnerabilità segnalata dal “ricercatore indipendente” è di quelle che consente l’accesso ai sistemi bersaglio, costui ha commesso un accesso abusivo che è sanzionato dall’art. 615 ter del codice penale. Questo reato – salve alcune eccezioni – è “perseguibile a querela”. Ciò significa due cose: la prima è che bisogna rivolgersi alla magistratura entro novanta giorni dal momento in cui si scopre il fatto; la seconda è che – se la vittima è un’azienda – solo il legale rappresentante (o chi ha una procura speciale) può firmare la querela. Se anche uno solo di questi due elementi viene trascurato è fortissimo il rischio che il responsabile del reato riesca a farla franca.

5. Negare il problema
Una cosa da evitare a meno di non essere assolutamente certi di avere tutto sotto controllo è la deniability; vale a dire la negazione del problema. Una volta messa a posto la vulnerabilità, infatti, si potrebbe semplicemente “fare finta di nulla”. Ma – come sanno i servizi segreti di tutti i paesi – la deniability funziona se e solo se sono cancellate irrimediabilmente tutte le tracce del fatto che si vuole nascondere; perché altrimenti si rischierebbe di essere sbugiardati due volte (la prima per non essersi accorti della vulnerabilità, la seconda per avere cercato di negarla). Sono stati registrati casi, in Italia, di soggetti che – per vanificare l’insabbiamento della “scoperta” addirittura si erano precostituiti la prova dell’esistenza della vulnerabilità con una una vera e propria perizia depositata in uno studio legale.

6. Il muro di gomma
Un’ultima opzione è quella di ignorare semplicemente il problema. Smorzatasi l’ondata di rumore eventualmente generata dalla notizia – e adottati quei provvedimenti disciplinari minimi che consentono di raffreddare gli animi – tutto ritorna come prima. Chi ricorda il rumore provocato dal bug dei modem Alcatel Speed Touch scoperto da Shimomura Tsutomu, quello dei router Telindus o il DRM-rootkit nascosto da SonyBMG in decine di titoli musicali?

Il concetto, in pratica

  • Chi entra in contatto con il “ricercatore indipendente” deve mantenere la calma, non fare commenti, e ottenere le generalità del “segnalante”.
  • La notizia deve essere immediatamente comunicata alla direzione affari legali, alle relazioni esterne, alla direzione sicurezza, ai responsabili del servizio attaccato.
  • Prima di decidere l’approccio da utilizzare è necessario verificare se la vulnerabilità dipende dagli apparati in sé (es.: router difettoso, sistema operativo o applicazione con difetti non documentati), da errori di implementazione (es: mancato cambio delle password di default) o ancora da errori di amministrazione (es: mancata installazione di patch).
  • Bisogna inoltre ottenere velocemente dati attendibili sul numero dei clienti potenzialmente affetti dal problema e sull’effettivo impiego della vulnerabilità, congelando – con una perizia indipendente – lo stato di fatto (a prescindere dal non uso che se ne dovesse fare).
  • Può essere utile – in casi gravi – rivolgersi a società di relazioni pubbliche specializzate in crisis management per gestire in modo più efficiente il controllo delle informazioni e le strategie da adottare.
  • Le relazioni esterne (quando esistono come struttura autonoma) e l’ufficio stampa devono essere immediatamente pronti a rilasciare dichiarazioni serie, concrete e non ambigue in modo da ridurre l’impatto della eventuale strumentalizzazione della notizia.

Possibly Related Posts: