Archivio tag: Passwords

Sicurezza informatica: il decalogo sotto le feste

Posted on by

Prevenire truffe online, malware, jackpotting e furti di identità anche quando si effettuano acquisti sul web: ecco il decalogo delle regole da seguire per proteggere email, carte di credito e dati personali.

Il periodo delle festività è un vero banchetto per i cyber criminali e mette seriamente a rischio la sicurezza informatica di utenti privati, imprese e professionisti. Complice la fretta con cui si effettuano acquisti online cercando l’occasione dell’ultimo minuto, spesso ci si ritrova al centro di una truffa o di un furto di dati personali foriero di un danno a proprio nome. Per evitare spiacevoli sorprese sotto le feste o contare i danni all’anno nuovo, è necessario conoscere le minacce più comuni che arrivano dalla rete e seguire alcune semplici regole.

Rischi

L’Italia figura al terzo posto a livello mondiale per quantità di indirizzi IP che inviano spam, circa 856.500.000 (report trimestrale 2014 di Trend Micro).

Gli spammer raramente si accontentano di inondare le vittime di pubblicità o messaggi indesiderati, ma più spesso veicolano malware o puntano a danni da sovraccarico che comportano interruzioni di servizio. Essere vittima di spam non significa solo dover ripulire la casella di posta elettronica, ma anche inconsapevolmente diventare spammer o peggio (qualora il proprio pc infettato diventi parte di una BOTNET).

POS malware

L’Italia si conferma terza anche nella top ten dei paesi con il più alto numero di visite a siti maligni, mentre è seconda al mondo per infezioni malware ai POS che consentono i pagamenti elettronici. È anche uno dei paesi maggiormente colpiti dal crypto-ransomware: un codice maligno con cui spesso i criminali attuano il “cyber-pizzo” criptando i dati personali e chiedendo il pagamento di un “riscatto” per effettuarne lo sblocco (che non sempre avviene anche a fronte del pagamento).

Jackpotting

Fortinet evidenzia invece come sotto le feste incrementino le truffe “jackpotting”, cioè l’hackeraggio dello sportello attraverso la rete con successiva installazione di malware, alla lettura dei dati delle carte e la registrazione del PIN. Ma si verifica anche un picco di finti siti web per vendere prodotti, anch’essi inesistenti. Entrando in queste pagine, si potrebbe finire nella trappola del malware progettato per sottrarre informazioni delle carte di credito.

Truffe online

MCcafee ha anche stilato una lista delle 12 truffe online più frequenti (sebbene il 13% degli utenti Internet non creda ai cyber attacchi, come sottolineano Kaspersky lab eB2B international): si va dalle email di phishing camuffate da notifiche di acquisti effettuati alle pubblicità ingannevoli che sconfinano nella beneficienza fasulla, fino ai siti di e-card di auguri zeppi di malware o delle chiavette usb ricevute in omaggio che potrebbero essere infette, come anche le App fasulle acquisite da siti mirror-malevoli rispetto a quelli veri.  E ancora skimming dei bancomat, finte telefonate da parte di sedicenti responsabili della sicurezza della banca che chiede dati personali e di accesso, o truffe legate ai viaggi di fine anno.

Decalogo

Per contrastare o prevenire la maggior parte delle minacce, frodi e truffe si consiglia di:

  1. Non cliccare sui link contenuti nelle email, verificando mittente, linguaggio utilizzato (spesso mal tradotto e quindi ingannevole), indirizzo del link (che a volte rende evidente il redirect a un sito malevolo) e diffidando di email che annunciano vincite e affari a buon mercato.
  2. Non fornire mai le proprie credenziali di accesso via email o telefono, per qualsiasi servizio sia personale sia aziendale.
  3. Controllare il proprio conto in banca frequentemente in occasione di molteplici acquisti effettuati, per prevenire eventuali doppi addebiti nello stesso punto vendita o altri addebiti a sorpresa che si possono bloccare per tempo dal sito della banca o fisicamente dagli sportelli.
  4. Prelevare soldi da bancomat inseriti all’interno della banca e utilizzare meno possibile quelli esposti su strada (almeno per ridurre il rischio che siano stati manomessi).
  5. Se possibile utilizzare carte di credito ricaricabili oppure carte emesse da un istituto finanziario che offre numeri delle carte di credito ad uso singolo, limitati nel tempo o virtuali.
  6. Installare e tenere aggiornato un antivirus, non solo sul pc di casa, ma su qualsiasi dispositivo (anche smartphone) collegato in rete. Per dispositivi IOS in particolare si possono utilizzare App che rafforzano ulteriormente iphone e ipad, più sicuri  ma non privi di pericoli (ovvero esposti a virus che passano impuniti attraverso Dropbox, malware che utilizzano il jailbreak per infettare il telefono e App ingannevoli che possono danneggiare la privacy).
  7. Effettuare acquisti facendo attenzione che la connessione sia in SSL.
  8. Effettuare acquisti attraverso un browser dedicato che garantisca ricerche anonime, per non lasciare tracce dei propri acquisti e gusti, utilizzabili da eventuali spammers.
  9. Scaricare solo quelle applicazioni per lo shopping che provengono da un App store ufficiale.
  10. Per gli acquisti online e per verificare la veridicità e il livello del servizio si può utilizzare la piattaforma ShoppingVerify, un raccoglitore di giudizi critici e opinioni dei clienti che hanno acquistato da portali di e-commerce di tutto il mondo.

Per approfondimenti: Trend Micro, MCcafee.

fonte: http://www.pmi.it/tecnologia/software-e-web/approfondimenti/91203/sicurezza-informatica-decalogo-feste.html

‎HeartBleed‬ di cosa si tratta esattamente!

Posted on by

INsicurezze/ L’insostenibile leggerezza del software

La scoperta di Heartbleed, uno dei bug più potenzialmente devastanti della storia, suscita riflessioni non solo sulla vulnerabilità dei sistemi. Ma anche sui modelli di sviluppo del software “mission critical”

 heartbleed
Roma – Il folklore dei programmatori annovera da decenni molteplici istanze specifiche della più generale legge di Murphy, le quali descrivono ironicamente ma non tanto i molteplici modi in cui la generale perversità della Natura si manifesta anche nello specifico settore dello sviluppo del software. Dice ad esempio la Seconda legge di Weinberg che “Se gli ingegneri costruissero gli edifici come i programmatori sviluppano i programmi, il primo picchio di passaggio raderebbe al suolo l’intera civiltà”; mentre il primo dei Postulati di Troutman afferma che “L’errore che produce il danno maggiore sarà scoperto solo dopo almeno sei mesi di uso del programma”.Ebbene, il famoso e famigerato bug denominato Heartbleed identificato nella libreria OpenSSL, che da alcuni giorni monopolizza l’attenzione persino dei media generalisti e dei quotidiani mainstream (i quali continuano a scriverne in modo grossolanamente impreciso, ma tant’è…), sembra confermare in pieno quanto presagito dalla saggezza della categoria sin da tempi davvero non sospetti. Esso infatti, se da un lato ha rischiato di mettere in ginocchio una parte significativa del sistema mondiale sul quale si basano la sicurezza e la riservatezza delle comunicazioni in Rete, minando alla base l’infrastruttura preposta alla garanzia sulle identità dei corrispondenti e l’inviolabilità delle comunicazioni, dall’altro è rimasto in circolazione, non ufficialmente scoperto, per oltre due anni dalla sua involontaria (o così almeno pare) introduzione nel codice di produzione. Peggio di così, insomma, non poteva andare.Ma di cosa esattamente si tratta, e perché è così pericoloso? E, soprattutto: com’è potuto succedere? Proviamo a fare il punto della situazione.
Cos’è Heartbleed
Il bug denominato Heartbleed, formalmente identificato mediante il codice CVE-2014-0160 con cui è catalogato nel database Common Vulnerabilities and Exposures, tecnicamente non è altro che un classico e banale caso di “memory out of bound”, ossia di accesso ad un’area di memoria indebita a causa di un indice inizializzato male ed in assenza di controlli specifici atti ad impedirlo. Un errore insidioso ma tra i più comuni, specie tra i programmatori principianti, favorito dal fatto che linguaggi come il C per motivi di efficienza non effettuano automaticamente a run-time il controllo del superamento dei limiti.Nella fattispecie il bug venne introdotto all’interno della libreria OpenSSL nel lontano 2011 quando tale Robin Seggelmann, all’epoca dottorando all’Università di Duisburg-Essen in Germania, implementò la cosiddetta estensione Heartbeat nel protocollo SSL/TLS. Questa, che letteralmente significa “battito cardiaco”, era stata proposta alla IETF (Internet Engineering Task Force) proprio da Seggelmann ed altri, e sarebbe stata da lì a poco emanata come standard formale di Internet col nome di “Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension” (RFC 6520, febbraio 2012). Essa consiste essenzialmente in uno scambio continuo di speciali pacchetti fra client e server autenticati, allo scopo di mantenere attiva e verificata una sessione sicura senza dover rinegoziare ogni volta la connessione.

Il bug nel codice di Seggelmann si trova nella funzione invocata per costruire il pacchetto di Heartbeat da scambiarsi fra client e server, e consiste nel non verificare la validità del valore memorizzato in una variabile, usata come parametro, che dovrebbe contenere la lunghezza del pacchetto stesso. In pratica alla funzione vanno passati come parametri sia il contenuto da assegnare al pacchetto (sotto forma di un array di caratteri) che la lunghezza del pacchetto stesso, ma la mancanza di validazione fa sì che la lunghezza del pacchetto creata dalla funzione possa essere diversa, ed in particolare molto maggiore, di quella dell’array che ne costituirà il contenuto effettivo. Una dimenticanza apparentemente banale ma profondamente pericolosa, come vedremo tra un attimo.

Seggelmann inviò dunque il suo codice per revisione a Stephen N. Henson, uno dei quattro sviluppatori principali di OpenSSL, il quale apparentemente non notò il problema ed incluse il tutto nel repository dei sorgenti della libreria il 31 dicembre 2011. Il codice incriminato entrò quindi a far parte della versione ufficiale 1.0.1 di OpenSSL rilasciata pubblicamente il 14 marzo 2012, e subito adottata da un numero enorme di siti e di distribuzioni di sistemi operativi. Anche le successive release minori, fino alla 1.0.1f, contengono tutte il bug, il quale è stato corretto solo nella versione 1.0.1g rilasciata il 7 aprile 2014 in seguito alla scoperta del problema da parte di alcuni ricercatori indipendenti (Riku, Antti and Matti dell’azienda finlandese Codenomicon e Neel Mehta di Google Security). Per la cronaca, il nome Heartbleed (sanguinamento del cuore) con cui il problema è oggi noto era stato assegnato informalmente al bug dai ricercatori di Codenomicon come gioco di parole su Heartbeat (battito del cuore), ma è subito diventato il nome “ufficiale” con cui esso è universalmente identificato.

Chiarito qual è il bug, vediamo come sia possibile sfruttarlo per carpire informazioni ad un server vulnerabile. Purtroppo è molto facile: basta infatti semplicemente richiedere la restituzione di un pacchetto Heartbeat creato assegnando valori opportunamente malformati ai parametri che ne regolano la costruzione. In pratica occorre passare alla funzione una stringa di inizializzazione corta (ad esempio “pippo”) ed un valore esageratamente ampio come descrizione della sua lunghezza (ad esempio 1.000 o più), ciò che corrisponde a chiedere al server di restituirci un pacchetto costituito dalla stringa “pippo” di mille caratteri! A questa richiesta apparentemente insensata e contraddittoria il server, in mancanza di una specifica validazione, non obietta ma reagisce stolidamente allocando in memoria un buffer di mille caratteri, copiandovi la stringa “pippo” e rimandando indietro tutti e mille i caratteri.

Otterremo così in risposta dal server un pacchetto di mille caratteri nel quale i primi cinque sono la striunga “pippo” e i rimanenti 995 caratteri contengono fedelmente i valori che erano contenuti nella particolare area di memoria del server nella quale è avvenuta l’allocazione del buffer!

In pratica con questo espediente riusciamo ad ottenere dal server la copia di una parte della sua memoria di lavoro, che può in realtà essere di ben 64K per volta; e, trattandosi di memoria dello spazio dati usato dall’istanza attiva del codice OpenSSL, è molto probabile che contenga informazioni significative per il processo stesso, quali ad esempio la chiave privata del server o le credenziali dei client utilizzate nelle sessioni aperte o comunque recenti. Nulla vieta inoltre di inviare centinaia o migliaia di richieste analoghe, per ricostruire così a colpi di 64K alla volta aree assai ampie della memoria del server ed aumentare le probabilità di trovarvi informazioni utili.

In pratica, a furia di richieste ripetute, un client malevolo può riuscire a mapparsi completamente o almeno in buona parte lo spazio di memoria logicamente allocato dal server al processo relativo all’istanza attiva di OpenSSL, di fatto rivelando in chiaro ogni e qualsiasi dato ad esso collegato: comprese quindi le chiavi private e/o le password degli utenti. Un “leakage” di proporzioni colossali, e soprattutto attuabile con facilità e senza lasciare alcuna traccia.

Prove realmente svolte da diversi ricercatori hanno confermato in modo evidente che, effettuando alcune migliaia di richieste, è effettivamente assai probabile riuscire ad ottenere password in chiaro ed altre informazioni critiche dall’analisi dei segmenti di memoria ottenuti. Il problema è infatti aggravato dal fatto che la libreria OpenSSL, per allocare memoria, non utilizza le classiche chiamate standard di sistema quali malloc(), ma implementa delle proprie routine, cosa che comporta due effetti collaterali sfavorevoli: il primo è che così facendo si massimizzano le probabilità che la memoria allocata sia stata precedentemente utilizzata dallo stesso processo, e contenga quindi informazioni sensibili per il suo funzionamento e soprattutto “fresche”; il secondo è che si vanificano gli effetti di eventuali azioni mitigatrici di “sanitarizzazione” della memoria svolte dagli allocatori di sistema, i quali non vengono affatto invocati.

Cosa fare dunque per risolvere il problema? Lato utente, purtroppo, ben poco: l’onere infatti è soprattutto a carico dei gestori dei server vulnerabili. Gli utenti non possono fare altro che attendere che i vari server adottino una versione di OpenSSL priva del problema: solo allora dovranno, per buona norma di prudenza, cambiare la propria password di accesso al servizio erogato da quel server. Sarebbe anche auspicabile che i gestori dei servizi revocassero i certificati usati per autenticare le sessioni SSL/TLS e ne installassero di nuovi, per evitare il rischio che qualcuno possa usare le chiavi private compromesse per costruire attacchi di tipo “man-in-the-middle” a danno degli utenti.Tuttavia il messaggio, come ha anche tenuto a dire l’Agenzia europea per la sicurezza delle reti e dell’informazione (ENISA), è “niente panico”: una sana politica di gestione delle password, che prevede l’utilizzo di password differenti per ciascun servizio e la loro sostituzione frequente, è un’ottimo baluardo di difesa anche contro questo spiacevole problema. Inoltre va ricordato che non tutti i siti che impiegano SSL/TLS lo fanno utilizzando la libreria OpenSSL: quelli che utilizzano altre implementazioni sono ovviamente immuni dal problema, il quale riguarda solo tale libreria e non il protocollo in sé.Alla fine della fiera tuttavia, e senza neppure cedere alle tentazioni complottiste secondo cui l’introduzione del bug è stata pilotata o quantomeno sfruttata per anni dalla solita NSA madre-di-tutte-le-iatture-della-rete, rimane comunque l’amaro in bocca per come sono andate le cose: è infatti possibile che un pezzo di codice di tale criticità, impiegato da circa due terzi dei siti mondiali per rendere sicure le sessioni di lavoro più delicate dei propri utenti, vada in distribuzione definitiva portando con sé un bug così banale ma al tempo stesso così micidiale?In una recente intervista Seggelmann ha riconosciuto di aver scritto codice stupidamente insicuro, omettendo un controllo che avrebbe dovuto essere inserito come semplice pratica di buon senso, ma ha ribaltato la responsabilità del problema sul team addetto alla manutenzione della libreria OpenSSL che non ha effettuato gli opportuni controlli di qualità. OpenSSL dal canto suo ha risposto che la libreria è mantenuta da sole tre persone, le quali sono evidentemente troppo poche per poter assicurare un’adeguata supervisione in tal senso. Altri osservatori hanno recentemente osservato che il codice prodotto da Seggelmann era scritto così male che la sua analisi sarebbe stata comunque lenta e difficoltosa, il che ha probabilmente disincentivato ulteriormente chi avrebbe dovutro assicurarsi della sua correttezza.A prescindere dalle reali colpe, che tutto sommato non ci interessano più di tanto, è il contesto in sé ad essere drammatico: questo incidente infatti mina alle fondamenta la convinzione, diffusa tra tutti gli esperti di sicurezza, che un codice open source sia più sicuro di un codice chiuso in quanto indipendentemente verificato (o verificabile) da decine o centinaia di sviluppatori differenti, cosa che in sé dovrebbe sia minimizzare la probabilità che un bug critico passi inosservato sia consentirne la sua rapida correzione una volta identificato. In questo caso invece il bug non solo non è stato scoperto all’origine, ma è rimasto in un codice di produzione per oltre due anni: un record negativo che solo pochi prodotti commerciali proprietari sembrano aver raggiunto.

Occorre quindi forse ripensare l’intero modello di trust del codice open source ad elevata criticità, introducendo step formali di “quality assurance” come quelli presenti nei prodotti industriali. Il solo fatto che un pezzo di codice “possa essere esaminato” da sviluppatori indipendenti non dà alcuna garanzia che esso sia stato realmente esaminato. Cullarsi in un falso senso di sicurezza è peggio che non avere sicurezza, lo sappiamo. Porre fiducia nell’open source è cosa buona e giusta, ma dobbiamo avere la certezza che tale fiducia sia ben riposta se non vogliamo trovarci di fronte a problemi sempre più gravi.

E la domanda a questo punto sorge spontanea: quanti altri pezzi di codice open source critico, cui affidiamo quotidianamente la nostra sicurezza, potrebbero portare in sé da tempi immemorabili bug potenzialmente devastanti? E soprattutto, chi dovrebbe accorgersene prima che lo facciano quelli sbagliati?

Corrado “NightGaunt” Giustozzi
nightgaunt.org

fonte: http://punto-informatico.it/4033843/PI/Commenti/insicurezze-insostenibile-leggerezza-del-software.aspx

Heartbleed, una delle più grandi falle nella sicurezza della Rete.

Posted on by

Heartbleed è il nome assegnato a una vulnerabilità “zero day” che riguarda OpenSSL, il sistema per criptare le comunicazioni in Internet usato da oltre due terzi dei siti web mondiali, e permette il furto di password e dati sensibili; fino ad oggi considerato uno dei sistemi più sicuri. Ecco tutto quello che c’è da sapere…

Aggiornamento alla mattina del 10 aprile: si consiglia di cambiare password, anche solo a titolo precauzionale, agli account sui siti di Google, Facebook, Yahoo, Tumblr, Dropbox, che hanno già riparato la falla. Su Mashable una lista con spiegazione dettagliata di dove e perché cambiare password, PayPal invece sostiene di non essere stata affetta e che gli utenti non dovrebbero neppure cambiare password (operazione che comunque è sempre consigliabile, ma assicuratevi prima che il servizio in questione abbia chiuso la falla).

Vanno anche aggiornati i software dei wallet e cambiate le password di molti servizi Bitcoin. LocalBitcoins, Blockchain.info, Bitfinex hanno chiuso la falla. Bitstamp aveva sospeso le operazioni, e ora le ha riaperte.

Più che un cuore sanguinante è una carneficina. Heartbleed, una gravissima vulnerabilità che compromette buona parte dei sistemi e dei servizi usati per crittografare il traffico internet, è già stata ribattezzata l’epic falla (dall’espressione epic fail). Da lunedì sera, quando è stata rivelata al mondo, amministratori di sistema e IT manager si sono trovati a gestire una situazione di emergenza, i cui potenziali effetti catastrofici (e del resto, bug catastrofico è stato definito dall’esperto di crittografia Bruce Schneier) sono ancora tutti da capire. Ma vediamo punto per punto di che si tratta e cosa sta succedendo.

La “falla” (oppure “bug”)
Heartbleed è il nome assegnato a una vulnerabilità zero day (CVE-2014-0160) che riguarda OpenSSL, il sistema usato per criptare le comunicazioni internet usato da due terzi dei server e fino ad oggi considerato uno dei sistemi più sicuri. La falla – e questa è una pessima notizia – esiste da due anni, dal dicembre 2011, ed è stata messa a posto in questi giorni nella versione OpenSSL 1.0.1g.  Le versioni vulnerabili di OpenSSL vanno dalla 1.0.1 alla 1.0.1f, mentre non lo sono OpenSSL 1.0.0 e 0.9.8.

Aspetta: cosa sarebbe OpenSSL?
Una implementazione open source di SSL e TSL, i due protocolli che garantiscono la sicurezza delle comunicazioni e transazioni di gran parte di ciò che sta sul web. Avete presente https nel browser, insomma il lucchetto che compare con l’online banking, Gmail e molti altri servizi che devono proteggere (leggi: cifrare) le loro comunicazioni? Ecco è un esempio.

Chi ha scoperto la falla?
La falla è stata individuata da un ingegnere di Google, Neel Mehta, e da alcuni ricercatori di Codenomicon, che hanno poi creato un sito ad hoc, appunto Heartbleed. Non senza qualche polemica riguardo a come la falla è stata comunicata.

Chi ne è colpito?
Molti sistemi operativi sono vulnerabili, tra cui Debian Wheezy, Ubuntu 12.04.4 LTS, CentOS 6.5, Fedora 18, OpenBSD 5.3, FreeBSD 8.4, NetBSD 5.0.2 and OpenSUSE 12.2. Ma al di là di questo, il punto è che OpenSSL gira su due dei web server più usati, Apache e nginx, così come server mail, servizi di chat, VPN e altri servizi. Ora immaginate che il lucchetto per blindare il traffico e le comunicazioni con tutti questi servizi sia potenzialmente apribile da chiunque conosca la falla e vi renderete conto della enormità del problema.

Quali aziende web sono interessate?
Fornitori di servizi, social media, webmail, online banking sono potenzialmente tutti interessati. In particolare: Apple, Microsoft, Twitter, Facebook e Google NON sembra siano state colpite dalla vulnerabilità, al contrario di Yahoo, che è stata esposta dal bug. Gli esperti di sicurezza hanno consigliato agli utenti di non entrare nei proprio account Yahoo in questo momento (il rischio era farsi rubare le credenziali da qualcuno che sfruttando la vulnerabilità sniffasse il traffico).
Tuttavia successivamente da Yahoo hanno fatto sapere che la vulnerabilità è stata messa a posto, quindi allo stato attuale i seguenti servizi sono tornati sicuri: Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr e Tumblr. Il consiglio rimane comunque dicambiare la propria password una volta loggati.
Fortunati gli utenti Google: poiché Gmail usa un avanzato sistema di protezione chiamato Perfect Forward Secrecy, i suoi utenti dovrebbero essere al sicuro anche per quanto riguarda le passate comunicazioni. Con l’occasione la Electronic Frontier Foundation ha consigliato di implementare Perfect Forward Secrecy – che protegge i dati cifrati, anche nel caso siano stati intercettati e salvati da qualche “spione”, e la chiave del sito sia successivamente compromessa – su più servizi possibili.

Qui si trova una lista di possibili siti interessati dalla falla, ma molti potrebbero aver già messo la toppa.

Il problema riguarda anche Tor, il software per l’anonimato, che ieri ha rilasciato una dichiarazione poco rassicurante: “Se avete bisogno di un anonimato e una privacy forte su internet, forse dovreste starre sconnessi per i prossimi giorni finché la situazione non si sistema“.
Tails – il sistema operativo live super sicuro e pro-privacy, basato su Linux (Debian)  – sarebbe invece al riparo.

Che fare? Upgrade, upgrade and revoke
La versione più recente di OpenSSL, 1.0.1g, chiude la falla, quindi ogni sito che usi OpenSSL dovrebbe aggiornare all’ultima releaseimmediatamente. Se un attaccante avesse usato la falla per entrare in un server web, avrebbe potuto accedere ai suoi gioielli:le chiavi di cifratura. Con queste avrebbe potuto decriptare il traffico da e al server; o impersonarlo, cioè far credere a un utente che sta visitando un certo sito mentre in realtà è un altro; o decifrare i database dei server, inclusi username, password, indirizzi email, informazioni sui pagamenti ecc

Quindi oltre ad aggiornare, è anche necessario che siti e servizi rigenerino le chiavi, revochino i loro certificati di cifratura e ne emettano dei nuovi. Qui si può controllare se un sito ha aggiornato i suoi certificati.

E’ possibile calcolare i danni di questa falla? Ed è già stata usata?
Non possiamo sapere se un sito è stato attaccato attraverso la falla (se non a posteriori nel caso escano fuori leaks o altro), non lascia tracce, diciamo. Inoltre non sappiamo se il bug è stato sfruttato, quanto e da quando. La situazione è del tipo: aggiorna, revoca, e incrocia le dita per il passato.

Cosa deve fare un utente?
Cambiare le password dei servizi che usano OpenSSL dopo che sono stati aggiornati. Aggiornare il proprio sistema, le distribuzioni Linux stanno rilasciando update in questo momento. Tenere sotto controllo i propri account.

fonte: http://www.wired.it/attualita/tech/2014/04/09/come-funziona-falla-heartbleed

Le SQL Injections, dopo 15 anni sono ancora oggi il metodo di attacco più potente a disposizione dei black-hat

Posted on by

Che cosa sono le iniezioni SQL

Le iniezioni SQL sono l’attacco più a buon mercato, spesso molto semplice grazie ai tool che automatizzano il processo di ricerca delle vulnerabilità, cosa che rende l’uso della tecnica accessibile anche ai meno esperti. Che cos’è esattamente un’iniezione SQL?

Come suggerisce il termine stesso, l’iniezione SQL è un attacco che si basa sull’iniezione di istruzioni non desiderate all’interno di un’applicazione web. Un’applicazione PHP si interfaccia quasi sempre con un database relazionale. Chi visita un sito dinamico compie delle azioni attraverso il browser. Clicca per visitare le pagine del sito od inserisce dei prodotti in un carrello. Ogni azione del visitatore corrisponde ad una serie di richieste verso il database che vive sotto l’applicazione. Niente di pericoloso fino a quando si tratta di semplici visitatori o di clienti che stanno per acquistare un prodotto. Ma la musica cambia quando dall’altra parte del browser c’è un blackhat o uno script kiddie.

Considera questo esempio:

Una query come questa, passata nel browser, non fa altro che interrogare il database MySql per prelevare dalla tabella catalogo un valore che corrisponde all’idarticolo 88. Ma sicuramente c’è un problema. Sappiamo che l’applicazione può essere vulnerabile ad un’iniezione SQL perchè qualsiasi web app che accetta come input un parametro di query SQL può essere quasi sicuramente sfruttata.

Che cosa succede quindi se l’applicazione web è vulnerabile alle SQL Injections? Un attaccante può passare come parametro di query una qualsiasi istruzione SQL, che verrà interpretata dall’applicazione e passata al DB senza battere ciglio.

Le possibilità sono infinite. Un’applicazione vulnerabile alle iniezioni SQL può rivelare all’attaccante tutti i databases, le tabelle, le colonne, gli utenti e praticamente qualsiasi dato memorizzato all’interno dei DB. Soprattutto se il server non è configurato in modo da limitare i privilegi di ogni utente.

Difendersi dalle iniezioni SQL

La responsabilità più grande è principalmente nelle mani dei developer. Chi scrive il codice può scegliere se scriverlo tenendo a mente la sicurezza e considerando sempre il pericolo che può derivare da un’iniezione SQL andata a buon fine.

Le principali raccomandazioni che gli esperti consigliano per difendersi dalle iniezioni SQL sono:

  • Evitare i dati in chiaro

La principale conseguenza di un’iniezione SQL è l’esfiltrazione di dati. Username, password, indirizzi email, codici fiscali e numeri di carte di credito sono solo alcuni dei dati che possono essere estratti da un’applicazione vulnerabile. Per questo motivo un’applicazione web non dovrebbe mai memorizzare dati in chiaro all’interno del database. Questo vale soprattutto per le password. Inoltre i numeri delle carte di credito non dovrebbero essere affatto memorizzati all’interno di un database potenzialmente esposto all’esterno.

  • Sanitizzazione degli input

Un’applicazione web non dovrebbe accettare ed eseguire ad occhi chiusi qualsiasi istruzione SQL. Gli esperti raccomandano di sanitizzare gli input con tecniche che permettono di ripulire eventuali query anomale e di usare quando possibile i parameterized statement.

  • WAF e hardening del server DB

Lato server sono numerosi gli accorgimenti che possono essere adottati per rendere più sicura un’applicazione web. Primo tra tutti l’uso di un web application firewall come Mod Security. Anche se è importante essere consapevoli che un WAF non può tappare tutti i buchi di un applicativo, l’obiettivo è quello di rendere difficile la vita dell’attaccante. Più ostacoli vengono posti tra un blackhat e l’applicazione e più c’è la possibilità di rallentare, fermare e raccogliere importanti informazioni sull’attacco.
La chiave della difesa è anche nell’hardening del server di database.
I grant degli utenti di un database devono seguire il principio del minor privilegio possibile.
Il logging è fondamentale per registrare anomalie e tentativi di attacco. La crittografia dei dati è essenziale per prevenire esfiltrazioni di dati in chiaro. Inoltre accanto ai WAF esistono software che hanno la funzione di firewall per il database.
Chi difende un’applicazione web deve predisporre qualcosa di simile ad una fortezza, composta da strati concentrici ed irta di ostacoli posati per fermare o rallentare l’attaccante. L’atteggiamento migliore per fronteggiare i rischi di un’iniezione SQL è considerarsi già violati. È fondamentale il penetration testing continuo delle applicazioni e non ultimo è essenziale mettersi nei panni dell’attaccante per comprendere a fondo le tecniche di attacco più elaborate. E non dimentare che i WAF possono essere bypassati con poco sforzo dagli avversari più sofisticati.

fonte: http://www.servermanaged.it/sicurezza/sql-injections-attacco-iniezioni-sql/