lunedì 27 marzo 2017

Conoscere il nemico

Come fanno i "cracker" professionisti, quelli che riescono a mettere in crisi server aziendali e a trafugare informazioni che valgono miliardi? Certamente ognuno ha le sue tecniche e le sue preferenze: qui, a semplice titolo di esempio, seguiamo questo post che ci racconta di Alexsey Belan, aka M4g.

Ecco alcune delle mosse, che sono state ricostruite in base agli indizi lasciati sul campo:

  • identificare web server periferici tramite ricerche su Google e LinkedIn: i server gestiti da uffici periferici sono di solito più vulnerabili, meno aggiornati e meno sorvegliati di quelli della Sede Centrale di un'Azienda
  • usare vulnerabilità note di Wordpress e PHP per compromettere i siti: si tenta di forzare prima l'anello debole del sistema
  • modificare i meccanismi di autenticazione per catturare le credenziali di accesso
  • fare uno "scan" della rete interna, per scoprire altri nodi potenzialmente vulnerabili 
  • cercare informazioni di sicurezza sui sistemi di sviluppo software, di gestione errori e di controllo delle versioni software
  • sfruttando la configurazione debole di alcuni sistemi, tentare di usare le stesse credenziali sui sistemi di produzione
  • combinare le varie informazioni raccolte per tentare di forzare l'accesso a VPN aziendali
  • modificare il software sui sistemi di sviluppo installando nel software backdoor che verranno poi usate sui sistemi di produzione
Ogni passo dell'operazione aggiunge informazioni utili all'attacco, che sono normalmente riutilizzate per ampliare la base di sistemi compromessi. Ogni attività è ripetuta più volte, sfruttando le nuove informazioni raccolte.

A questo punto ci si chiede che cosa può essere fatto per prevenire queste catastrofi, o per limitare i danni:

  • separare le diverse componenti, mettendo quelle più a rischio in aree distinte, senza accesso diretto alle informazioni vitali dell'Azienda
  • non lasciare memorizzate sui sistemi di comunicazione interna informazioni di sicurezza di nessun tipo
  • controllare il traffico dei sistemi verso l'esterno, evidenziando destinazioni anomale, non funzionali alla logica del business Aziendale
  • usare sistemi di autenticazione a due fattori (2FA) realmente consistenti, non lasciati alla discrezionalità di chi li usa, che spesso li vede come "inutile perdita di tempo"
  • non utilizzare sui sistemi di produzione credenziali generate per i sistemi di sviluppo o test del software
  • tracciare, controllare e conservare tutti gli accessi ai sistemi, specialmente quelli privilegiati (ma non solo)
  • isolare opportunamente i database e gli altri contenitori di dati importanti e controllarne l'accesso per evitare esfiltrazioni non autorizzate delle informazioni 
Anche una singola password di un account email accessibile via web può costituire un primo "cavallo di Troia" per penetrare fortezze ritenute inespugnabili. Una rappresentazione grafica accurata ed aggiornata di "chi-può-fare-che-cosa" e di "dove-si-può-andare-da-dove" dovrebbe far parte dell'analisi del rischio, tenendo conto che il primo a cedere è sempre l'anello più debole della catena.



sabato 18 marzo 2017

Cloud, IaaS e Security

In questo documento di Symantec (che risale a quasi due anni fa) si parla dei problemi di IT Security legati all'uso, da parte delle Aziende, di infrastrutture IT in "cloud" (IaaS). In altre parole, IaaS permette alle Aziende di evitare i costosi processi di selezione e acquisto delle apparecchiature hardware a supporto dei sistemi di business e relative spese di gestione (energia elettrica, spazi). Peccato che IaaS richieda ancora l'utilizzo di personale specializzato e bene addestrato per la sua gestione logica. Vediamo quali sono i punti di attenzione relativi agli aspetti di sicurezza comuni a tutte le soluzioni IaaS.

Innanzi tutto è bene chiarire la suddivisione dei compiti fra Provider IaaS e Azienda Cliente:

  • a carico del Provider:
    • spazio fisico attrezzato, rack, condizionamento e alimentazione elettrica
    • hardware (CPU, RAM)
    • networking interno e connettività da e verso internet
    • storage (dischi, SSD)
    • virtualizzazione dell'hardware
  • a carico dell'Azienda Cliente:
    • sistema operativo (installazione, configurazione e aggiornamenti)
    • database
    • applicazioni
    • infrastruttura di sicurezza (applicativa e sistemistica)
Normalmente possono essere contrattati alcuni allarmi di base, relativi per esempio allo spegnimento dell'hardware, termini di servizio come MTBF/MTTR, e altri parametri di scalabilità / fatturabilità (limitazioni sulle risorse hardware disponibili).

Per quanto riguarda più in particolare la Sicurezza IT, bisogna sottolineare che l'uso di IaaS non solleva il Cliente da nessuna delle incombenze che avrebbe avuto mantenendo il CED tradizionale gestito in proprio.

In particolare:
  • la sicurezza delle applicazioni non aumenta (né diminuisce) per il semplice fatto che esse sono ospitate in una infrastruttura esterna, salvo il particolare che esse sono esposte ad accessi esterni
  • la sicurezza dei dati (database, backup) deve essere garantita tenendo presente che sono manipolati da applicazioni raggiunte tramite reti "non sicure" (tipicamente internet)
  • il rilevamento di eventuali attacchi (o tentativi di intrusione) non viene normalmente eseguito dai Provider, e va quindi previsto contrattualmente qualche metodo di accesso ai log delle attività, sia applicative che sistemistiche
Il citato studio di Symantec fa rilevare che una moderata attività di discovery, attuata a spese di un servizio IaaS, ha permesso di scoprire 16.000 prefissi di dominio, 51 directory accessibili (che sembrano poche) e 11.000 files contenenti anche dati sensibili o comunque utilizzabili per scopi malevoli.

Significato: la sicurezza nell'accesso ai dati deve essere progettata e predisposta dal Cliente, anche attraverso gli strumenti di IAM (Identity and Access Management) disponibili presso i Provider.

Altri punti deboli riguardano l'uso di chiavi di encryption applicative, che se codificate in maniera statica nelle applicazioni rendono difficoltosa e lenta la reazione ad un eventuale attacco. Anche la gestione di tali chiavi è da tenere attentamente sotto controllo da parte del Cliente.

Inoltre non è da sottovalutare la circostanza che dati e applicazioni, sia pure confinati in ambiti logici separati e distinti, condividono l'hardware con altri ambienti, potenzialmente sconosciuti: sono stati già rilevati casi in cui alcuni malintenzionati hanno acquisito ambienti IaaS al solo scopo di interferire con altri ambienti ospitati sulla stessa piattaforma (un degrado delle prestazioni è l'attacco più banale che possa essere condotto, e su questo pare che i Provider possano intervenire).

Bisogna inoltre prevedere le conseguenze legali dell'affidamento dei dati in locazioni diverse, con legislazioni potenzialmente diverse e talvolta discordanti. Altre precauzioni legali vanno impostate nel caso in cui il Provider stesso perda il controllo della propria infrastruttura, per esempio a seguito di una messa in liquidazione o di una acquisizione da parte di altre società.

Conclusioni.


I servizi IaaS sono sempre più diffusi e possono costituire una valida alternativa alle infrastrutture IT tradizionali, ma non devono essere sottovalutati dal punto di vista dell'IT Security, secondo le specificità del Business di ciascuna Azienda.

venerdì 17 marzo 2017

Automobili



Perché parliamo di automobili? Perché è sempre più vicino il giorno in cui saranno vendute al grande pubblico le automobili che si guidano da sole.

In questo articolo si spiegano quali potranno essere i rischi associati a questi "device".

Innanzi tutto, una nuova specie di furti:

A very simple example with automated vehicles would be stealing one remotely. The appeal to a hacker can simply be profit or to gain leverage over the owner or the manufacturer of the vehicle. This scenario isn’t the most likely risk we should be worried about.'
Non sarà difficile, in assenza di opportune contromisure, rubare una di queste auto direttamente dal luogo dove è parcheggiata, o meglio anche dal deposito della Concessionaria o del Costruttore. Bisognerà prevedere fin d'ora un metodo per disattivare la messa in moto e un'autenticazione forte del proprietario o delle persone abilitate a farne uso.

Poi, azioni di vandalismo, sabotaggio o terrorismo:

'Even just disabling it or making it drive through the wrong neighbourhood is something that could be taken advantage of. Hackers could also use the car to obstruct traffic, or create roads that are completely void of traffic.’
 Se i malintenzionati riusciranno a bloccare il funzionamento dell'auto, o a farla muovere dove non dovrebbe, o peggio a creare problemi ostruendo il traffico, sarà una bella gatta da pelare (inclusa la ricaduta di responsabilità civile e penale sul proprietario "disattento").

Insomma, le eventuali intrusioni e i virus che potrebbero venire installati a bordo di questo tipo di veicoli sono da prendere con la massima attenzione.

In ultimo, restano da citare i "bug", i problemi software immancabili in ogni sistema elettronico che si conosca: in questo campo il Controllo Qualità dovrà essere piuttosto paranoico, rincorrendo condizioni al limite del possibile, per evitare inconvenienti che potrebbero far crollare a zero le vendite di queste auto troppo "intelligenti".

mercoledì 15 marzo 2017

Il "Cioc"? Ma che davéro?



Apprendo da questo articolo che il Gen. Graziano, Capo di Stato Maggiore della Difesa, annuncia che i militari italiani si occuperanno anche di "cyber-war". Con un apposito Comando chiamato "Cioc" (comando interforze operazioni cibernetiche).

Da un lato penso "era ora", poi leggo che, secondo il Generale, "basta un hacker per mettere in crisi un sistema di computer", Mi dispiace contraddirLa, sig. Generale: un cracker (non un hacker) basta per mettere in crisi una infrastruttura informatica ("sistema di computer") non gestita o gestita male. Lo dico con quasi 25 anni di esperienza alle spalle, lo dico anche grazie ai contatti e alle informazioni raccolte "sul campo" come Responsabile della IT Security di Aziende che nulla hanno da invidiare al bilancio della Difesa italiana, Aziende per cui subire un attacco informatico è un rischio estremamente grande, come perdere una battaglia importante (in una guerra mai dichiarata ma sempre attiva). Non sappiamo quali e quante "armi" possano mettere in campo organizzazioni clandestine come il terrorismo internazionale, sappiamo approssimativamente che la "potenza di fuoco" di alcuni Stati (penso a Russia e Cina in particolare, ma anche alla Corea del Nord) è piuttosto elevata.

In ogni caso, è lodevole l'iniziativa. Come sempre i tempi sono spropositati (si parla di 2018, anche se ovviamente il Comando "è già in funzione"). E mi corre l'obbligo (morale) di ricordare che alcune delle eccellenze che avrebbero potuto contribuire alla costruzione di questa nuova entità, nuova per la Difesa, ma non nuova per altri settori della PA, sono state a suo tempo "allontanate" dai loro incarichi (per usare un eufemismo). Penso, fra coloro che "conosco" professionalmente, al Gen. Rapetto (ex Guardia di Finanza), creatore del GAT, e all'ex responsabile della Polizia Postale, dott. Di Legami, piuttosto frettolosamente rimosso dal suo incarico a seguito della vicenda "Occhionero".

Speriamo che il Gen. Graziano, o chi per lui, trovi persone professionalmente valide per comporre i livelli dirigenziali del suo Cioc, perché la "cyber-war" non si combatte solo coi "fucili" degli aspiranti cracker (non hacker) appena laureati, nonostante tutta la loro capacità e buona volontà. Vedremo e forse, trattandosi di cose militari, sapremo. Entro il 2018.

mercoledì 8 marzo 2017

"Weeping Angel" e altri segreti

Questo interessante articolo illustra quanto ci sia di "nascosto" quando si parla di Cyber Security.

Naturalmente, le "azioni" di cui si parla nell'articolo normalmente non riguardano il privato cittadino, anche se qualche governo di pochi scrupoli potrebbe usarle per spiare gli oppositori (e non è detto che non sia già stato fatto).

Un lato interessante è che queste "armi" prendono di mira non soltanto la tecnologia "ultimo grido", che pure offre spunti impensabili fino a pochi anni fa, ma anche livelli tecnologici che siamo abituati a considerare obsoleti. Si trovano più informazioni utili nel "bidone dell'immondizia" tecnologico (v. floppy disk) che altrove.

Il rischio di tali rivelazioni resta sempre che il più grande teatro del cybercrime si trovi improvvisamente per le mani "armi" potentissime, a costo quasi zero. Ricordiamo l'impennata di attacchi tipo "Mirai" da quando il codice di quel software (malware) è stato reso pubblico.

Conclusioni: la tecnologia non è di per sé né "buona" né "cattiva", è l'uso che se ne fa che la qualifica, rispetto agli obiettivi e ai risultati. Se ne è reso conto Nobel, quando ha visto l'utilizzo malvagio che (fin dall'inizio) fu fatto della sua dinamite.

martedì 7 marzo 2017

Consigli per tutti

Sia che si tratti del computer personale, del tablet o del cellulare, che di più importanti (e costose) architetture aziendali, è sempre bene tenere presenti alcune buone pratiche di IT Security:

  1. installare un antivirus, o comunque software di protezione dagli attacchi più comuni
  2. aggiornare regolarmente il sistema operativo, le applicazioni e l'antivirus (o altra soluzione per la sicurezza)
  3. eseguire regolarmente salvataggi (backup) dei dati "che non si possono perdere"
  4. segnalare tentativi di phishing, sia da parte di siti o banner pubblicitari, che tramite mail (qui un articolo sul phishing)
  5. gestire bene le password: impostare password non banali, non comunicarle mai all'esterno, usare password diverse per servizi diversi (attenzione ai SN: non registrarsi mai a nessun servizio importante attraverso le credenziali dei SN), cambiarle periodicamente, rispettando i criteri sopra descritti
  6. se possibile, per i servizi online più importanti (banca, carta di credito e altri che comportano impiego di denaro) impostare l'autenticazione a due fattori (es: sms con codice usa-e-getta in aggiunta alla solita password)
  7. verificare periodicamente lo stato (saldo, movimenti) dei conti bancari, carte di credito e prepagate. Se possibile, attivare le notifiche dei movimenti via sms
  8. fare sempre molta attenzione a ciò che si scrive o si pubblica sui SN*. Impostare una buona privacy policy (che restringa agli amici certi contenuti) e comunque ricordare che ciò che finisce sui SN potrebbe sempre essere visibile "a tutti"
  9. fare in modo di non poter automaticamente sottoscrivere servizi a pagamento (in Italia i provider di telefonia hanno apposite protezioni: attivarle o verificare che siano attive)
  10. guardarsi intorno: uno dei metodi più utilizzati dai malintenzionati è il social engineering, cioè il "furto" di informazioni di sicurezza per via "amichevole" o per semplice contiguità. Attenzione agli hot-spot WiFi pubblici (o semi-pubblici), attenzione all'uso condiviso di computer o connessioni internet
____
(*) SN = Social Network, es: Facebook, Twitter

sabato 4 marzo 2017

Pesca a strascico: il Phishing

Uno dei pericoli nascosti nella navigazione e soprattutto nelle mail è il phishing: il tentativo di carpire la buona fede del navigante per sottrarre informazioni utili, soprattutto credenziali di accesso (username e password).

Comportamenti a rischio


Le operazioni di phishing possono avere origine in diversi modi, per esempio:

  • cliccando su un link presente in una mail (spesso si tratta di mail spam, non autentiche)
  • cliccando su un banner pubblicitario presente su una pagina web (o in una mail)
  • navigando su pagine che contengono materiale di dubbia provenienza (o illegale)

 

Come riconoscere il phishing

 
Quasi sempre il phishing fa leva su notizie di problemi imminenti, come il (presunto) blocco di un account (mail o peggio bancario), la conferma di una password o di altre informazioni importanti e sensibili. Altrettanto spesso, il phishing ama mascherarsi dietro pagine (o mail) che hanno un aspetto molto simile agli originali per cui si spacciano, o sembrano provenire proprio da quelle sorgenti. Esempio: Una mail che sembra provenire dalla Banca sollecita l'aggiornamento della password, oppure una mail che sembra provenire da un antivirus promette di controllare il livello di sicurezza di una password, oppure un (presunto) creditore che chiede di saldare fatture in sospeso, o qualche (falso) Ente fiscale che chiede il pagamento di multe o ammende, infine qualche (falsa) vincita di un premio che chiede le coordinate bancarie per l'accredito. Non citiamo, perché dovrebbero essere ormai note, le mail di qualche (falso) riccone del Terzo Mondo che ha bisogno di passare dal nostro conto corrente per riscuotere ingenti somme di denaro.

In pratica, i tentativi di phishing richiedono una o più delle seguenti informazioni:

  • username e password o altre credenziali di accesso
  • codice fiscale
  • coordinate bancarie (compresi i codici di accesso)
  • PIN (di bancomat o simili)
  • numero di carta di credito
  • informazioni personali: età, indirizzo, nomi dei famigliari, nomi degli animali (questi ultimi utilizzati per il recupero password)
  • data di nascita, sesso, nazionalità

 

Precauzioni e avvertenze

 
Vale la pena di ricordare che nessun Ente legittimo (sia esso il fornitore servizi di mail, la banca, i vigili urbani, la polizia, la riscossione tributi) chiede mai queste informazioni via mail. In caso di dubbio, contattare il presunto mittente, ricavando le informazioni di contatto (numero di telefono, indirizzo) non dalla mail sospetta ma da elenchi pubblici (es: elenco telefonico) o siti ufficiali.

Non rispondere mai direttamente a mail sospette di phishing: l'indirizzo del mittente è di solito ben mascherato, e serve solo a confermare ai malintenzionati di aver raggiunto un fish, una potenziale vittima.

Catalogare queste mail come "spam" (ogni sistema di mail consente di farlo, e "impara" dall'esperienza utente): ciò renderà più difficile in futuro ricevere mail di questo tipo.

In caso di problemi


Se malauguratamente si è già caduti nella rete del phishing, si può:

  • denunciare l'accaduto alla Polizia
  • bloccare o allertare banca (o il fornitore di servizi) se si tratta di denaro (il servizio bancomat offre un numero verde per bloccare subito i prelievi, analogamente le carte di credito o prepagate)
  • recuperare l'account colpito, cambiando le credenziali di accesso (password e altro, se necessario)

Riferimenti



venerdì 3 marzo 2017

Pillole di IT Security




  • Pillola n.1: oggi, come si legge nel comunicato stampa, il Consiglio dei Ministri ha conferito (fra l'altro) al Governo la Delega legislativa per il recepimento della "DIRETTIVA (UE) 2016/1148 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 6 luglio 2016 recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell'Unione". Se avete voglia di digerire un po' di legalese, ecco il testo della Direttiva. In particolare, vorrei sottolineare il seguente comma:
 (29)
Per conseguire e mantenere un livello elevato di sicurezza della rete e dei sistemi informativi è opportuno che ogni Stato membro disponga di una strategia nazionale in materia di sicurezza della rete e dei sistemi informativi che definisca gli obiettivi strategici e gli interventi strategici concreti da attuare.



  • Pillola n.2: corre voce che siano stati cancellati dal Playstore di Android (il sito che contiene le famose "app" scaricabili) una decina di App che andavano a infettare sistemi Windows. Sì, avete capito bene: questo malware utilizzava Android come "cavallo di Troia" per andare a infettare con altro malware ad esso affiliato i sistemi Windows che casualmente entrassero in contatto col telefonino o tablet infetto. Una tattica piuttosto contorta per andare a colpire sistemi già abbondantemente esposti a malware di vario tipo. Purtroppo non ho trovato riscontri* a questa notizia, anche se la fonte pare abbastanza autorevole 
(rif: https://www.facebook.com/unavitadasocial/photos/a.204543133076485.1073741828.202526769944788/606385862892208/).

*Aggiornamento: la notizia parte da questo articolo di Palo Alto Networks, una società che si occupa di Sicurezza in rete. Come spiegato in quel post,

What is more notable is that, one of the infected pages also attempts to download and install a malicious Microsoft Windows executable file at the time of page loading, but as the device is not running Windows, it will not execute.
 Come si legge qui, si tratta di

Non-Android threat: An application that contains non-Android threats. These apps are unable to cause harm to the user or Android device, but contain components that are potentially harmful to other platforms.
Quello che rimane tecnicamente un mistero è come una IFrame aperta su un device Android e contenente malware eseguibile su Windows possa andare ad infettare un device Windows. Ai posteri l'ardua sentenza!

giovedì 2 marzo 2017

Aggiornamento: il fattore umano

Questo post riporta alcuni aggiornamenti (follow-up) rispetto al precedente post, che prendeva spunto dall'episodio di malfunzionamento dei servizi Amazon S3.

In un articolo abbastanza esauriente, Amazon rivela le cause e i meccanismi che hanno portato al malfunzionamento.

In estrema sintesi, un comando attivato per risolvere ben più lievi problemi (fatturazione), usato in modo improprio ha disattivato alcuni elementi critici per il funzionamento di tutto il sistema Amazon S3 della zona Nord America (che in sostanza è un servizio di cloud storage, spazio disco distribuito).

Le lezioni principali che ci sentiamo di trarre da questa vicenda sono le seguenti:

  • mai sottovalutare i single point of failure (SPOF) di un sistema complesso: in questo caso, ben due funzioni critiche (index subsystem e allocation s.) erano state affidate ad altrettanti blocchi monolitici all'interno del sistema stesso
  • mai fidarsi del fatto che la quantità di dati trattati non introduca ulteriori problemi in maniera più che lineare: far ripartire i due citati sottosistemi, che non erano finora mai stati spenti, con tutta la mole di dati accumulati in questo tempo non è stato facile, e soprattutto ha impiegato più tempo del previsto
  • mai sottovalutare le interrelazioni fra le singole parti di un sistema complesso: il fatto che l'allocation subsystem per ripartire avesse bisogno dell'index subsystem funzionante ha peggiorato ulteriormente la situazione
Naturalmente, per ottenere una soluzione strutturale a questo genere di problemi Amazon ha dovuto rivedere la pianificazione di quelle attività di ottimizzazione dell'architettura (e parziale re-ingegnerizzazione) che erano state già previste ma non erano finora considerate urgenti.

Le correzioni immediate agli strumenti in uso erano naturalmente "comprese nel prezzo" pagato per questo incident, come facevamo già rilevare nel precedente articolo.

Un'ultima nota a proposito delle prospettive illusorie di un certo marketing d'assalto: ho sentito teorizzare che questo incident capitato ad Amazon avrebbe aiutato la concorrenza a piazzare meglio la sua soluzione di cloud storage. Secondo me è una boiata pazzesca* tenendo conto che le tecnologie, le architetture, le organizzazioni sottostanti ai sistemi cloud dei diversi fornitori sono sostanzialmente equivalenti: se fosse così facile essere al riparo da quegli imprevisti imprevedibili che sono gli errori umani, sarebbe un bel vantaggio competitivo da far valere prima che la concorrenza cada in un incident.


(*) cit. Fantozzi