ShellShock (o Bash Bug) e i CERT

Ieri è stata scoperta la vulnerabilità “Bash Bug” o “ShellShock“.
E’ una vulnerabilità con impatto molto diverso da quanto successo con Heartbleed; quest’ultima è stata una vulnerabilità piatta, è stata come una mano aperta che ha picchiato violentemente sulla superficie del mare, di questo grande mare che è il web.
Ha prodotto un gran rumore, tutti si sono girati a guardarla, tutti ne hanno parlato, fiumi di inchiostro virtuale sono scorsi tra le onde e tra i naviganti. Ma a parte questo nulla è successo. Del resto quelli che potevono essere colpiti erano le grandi imbarcazioni più sensibili alle onde prodotte, cioè i grandi portali web, le banche. Ma anche la soluzione è stata talmente semplice che per loro c’è voluto poco per sistemare. Se qualcosa è successo, è accaduto prima che venisse pubblicata. Chi frequenta (per studio eh) i blackmarket si era reso conto già da giorni che qualcosa era successo, quel boom di disponibilità di credenziali era sospetto.
La “ShellShock” è diversa, non è una mano aperta, è più verticale, appuntita. come un dito. Che se lo infili verticale in acqua (non siamo volgari) non fa rumore, genera poche onde. Le grandi navi quasi nemmeno se ne accorgono. Ma una volta che è sotto può fare grandi danni. E per molto tempo.
Si pensi non ai grandi portali, ma agli impianti industriali, ai device, ai sistemi di videosorveglianza, ai controllo accessi.
E’ una vulnerabilità in grando di colpire dal basso le nostre infrastrutture. Ed esce proprio nel mometo in cui il gruppo terroristico più “connesso” di sempre ci dichiara apertamente guerra cibernetica (e non solo).
Pensare di patchare tutti i sistemi è semplicemente follia, non per nulla perchè molti di questi sono sconosciuti.

Ma non è della vulnerabilità che volevo scrivere.
Come ho detto, questa è una vulnerabilità che può essere assai critica, contestualizzata al momento storico direi quasi da emergenza. Anzi, direi da emergenza senza quasi.

Sono andato a guardare come i vari CERT mondiali e quindi italiani hanno gestito la questione.
Chi mi conosce sa quanto ci tenga al sistema Italia, sostengo sempre che sul fronte “cibernetico” in Italia abbiamo molte eccellenze, a partire dalla Postel che è una delle migliori al mondo.
Ma i CERT… mamma mia che delusione.

In ordine, partiamo dal CERT per eccellenza, quello del governo americano:
https://www.us-cert.gov/ncas/alerts/TA14-268A

 

CERT US

La pagina del CERT americano è impeccabile, informazione corretta, completa e senza “nerdismi” inutili. C’è tutto quello che serve, la descrizione, soluzione, riferimenti e la corretta classificazione dell’impatto:

Impact
This vulnerability is classified by industry standards as “High” impact with CVSS Impact Subscore 10 and “Low” on complexity, which means it takes little skill to perform. This flaw allows attackers to provide specially crafted environment variables containing arbitrary commands that can be executed on vulnerable systems. It is especially dangerous because of the prevalent use of the Bash shell and its ability to be called by an application in numerous ways.

Poi c’è quello UK:
https://www.cert.gov.uk/resources/alerts/update-bash-vulnerability-aka-shellshock/

CERT UKL’home page è un po’ troppo “pop”, con colori sparati e grandi immagini colorate, ma correttamente c’è l’alert con il link alla vulnerabilità.

I contenuti non sono così chiari e professionali come quello US, ma c’è tutto e ben spiegato. Ci sono anche alcune considerazioni interessanti e degne di nota:

The affected versions go back to bash 1.14 which was first released in ~1995. Unlike the Heartbleed vulnerability which affected only openssl (an additional program that only certain users actually implemented), SHELLSHOCK is likely to affect a much wider community.

Giustissimo il riferimento alle CNI (Critical National Infrastructure) (qui meglio di quello USA):

The real-world impact of this vulnerability depends greatly on the systems on which they are deployed. However, due to the common usage of *nix systems as servers in network environments it should be assumed that most server-based architectures are affected. This will inevitably include organisations that are part of the CNI. As such, all organisations that make use of *nix-based environments should pay particular attention to the patching requirements and other mitigation steps.

 

Passiamo a quello italiano.
Quale? Eh si, noi ancora non abbiamo un vero CERT nazionale, noi abbiamo i CERT settoriali. Ne abbiamo tanti.
Partiamo da quello del GARR:
http://www.cert.garr.it/alert/security-alerts/archive/view/listid-1-alert/mailid-1657-alert-gcsa-14033-vulnerabilita-in-gnu-bash

GARR-CERT - Alert GCSA-14033 - Vulnerabilita' in GNU Bash (20140926)

Il testo è in italiano, il che va anche bene, però poi si finisce per usare un mix di inevitabile inglese – italiano e il risultato è un po’ brutto, anche la forma che tende a semplificare il più possibile scade nel far sembrare il sito più un forum di supporto di primo livello per utenti bancari (non me ne vogliano i bancari, era un esempio per dire utilizzatori di pc non obbligati ad esserne anche competenti).
La descrizione è sommaria, e la descrizione dell l’impatto è.. come dire… così:

:: Impatto

Esecuzione di codice arbitrario
Denial of Service
Accesso al sistema

Poi ho guardato quello di Poste:
https://www.picert.it/category/alerts/bollettini/

CERT di Poste Italiane – Bollettini (20140926)

Ho amici che ci lavorano, so che stanno facendo un gran lavoro. Per cui da questo mi aspetto un lavoro sopra la media.

Purtroppo c’è un problema: sono le 00:55 del 26/09/2014 e per il CERT di Poste questa vulnerabilità.. non esiste. Meglio così, occhio non vede, cuore non duole.

Vorrei analizzarne altri,  ma credo che finiamo qui. Segnalo che cercando CERT italia o CERT italiani si finisce su un gran numero di siti abbandonati o cancellati.
Eppure conosco  CERT interni, forse quelli più importanti, che lavorano alla grande. Nettamente meglio della media europea. Ma siamo al solito discorso degli orticelli, io mi faccio il mio e non lo faccio vedere a nessuno, guai! Come diceva Caterina Caselli:
“Nessuno mi può giudicare. Nemmeno tu..”

Infine, una nota di chiusura, siamo in Italia, paese i poeti, santi e navigatori,  non poteva quindi mancare un CERT della chiesa cattolica:
http://cert.chiesacattolica.it

SICEI

Come dite, è una semplice pagina statica senza alcuna utilità?
Ma no! Su dai, il concetto è di preghiera, pregate che non succeda nulla.

ls

PS: inserto pubblicitario gratuito. Ricordatevi che sono CEO, co-founder (e tutto quello che serve fare) di Abissi. Abissi è l’unica azienda in Italia che fa realmente Cyber Surveillance, con un servizio di Cyber Threat Intelligent non basato su una banale correlazione dei vostri log. Vera intelligence, senza paura.
http://www.abissi.eu/wp-content/uploads/2014/07/Abissi-Cyber-Threat-Intelligence.pdf

abissi_divinginthedeepweb

 

 

Mail PEC … sono 2 etti abbondanti, lascio così?

Oggi una persona mi ha chiesto di verificare l’invio di alcune mail certificate su cui nutriva dei dubbi. Per un aggiudicazione per un ente pubblico occorreva inviare entro una certa ora (le 12.00) due mail ovviamente tramite PEC.
La persona si è insospettita perché avendo inviato entrambe le mail intorno alle 10.50, per una ha ricevuto subito la certificazione di consegna, mentre la seconda mail è arrivata alle 13.35, quindi ben fuori dall’orario ammesso.

Posto che non vedo come il destinatario possa interagire (altrimenti sarebbe tutto abbastanza ridicolo), guardando le mail ho avuto un forte mail di testa.
Sarà che oggi non sono informissima, sarà che i neuroni sono quello che sono, ma proprio  non ci riesco a comprendere la logica della firma e della gestione della mail PEC.

Partiamo dalle 2 mail inviate, direttamente dalla webmail PEC di Aruba:

mailpec0

L’orario indicato, 10.49 e 10.56 è quello corretto.

Guardando il primo certificato di consegna, avvenuto praticamente all’istante, mi è venuto la prima emicrania, anche se leggera: Perché indica consegnata alla 10.49(+200)?
E’ forse viaggiata indietro nel tempo arrivando un’ora prima dell’invio (indicato come 10.49(+1.00)?
mailpec1Ovviamente fa riferimento all’orario CEST quindi è corretto, ma se non indichi chiaramente non è che sia proprio banale da capire e soprattutto trattandosi di posta certificata ci dovrebbe essere un certo rigore nel modo di esporre l’informazione principe. o no?

Poi passiamo alla seconda mail, inviata alle 10.56 (GMT +1).
La certificazione di consegna è arrivata alle 13.35, così come anche l’accettazione.
Perché quasi 3 ore dopo?
Aprendo la ricevuta l’imprecisione aumenta ulteriormente. L’ora di consegna è indicata come 13.34 e non 13.35; è solo un minuto? Ok ma .. stiamo parlando di un processo atto a legalizzare una ricezione, la precisione sugli orari dovrebbe essere la cosa principale.
mailpec4Leggendo nel dettaglio si legge che la mail è stata inviata dall’utente xxxx alle ore 13:34:58 (+200), si si, +200! (prima vi era sfuggito eh?) dev’essere proprio una macchina del tempo, ma di quelle serie. Ok dai, l’abbiamo capito, era +2.00 e manca solo un puntino, cosa volete che sia un puntino?

E’ come quando vai dal salumiere e chiedi 2 etti di mortadella e te ne danno 234gr. Non è che bisogna star li a guardare tutto. Dopotutto è solo una mail. Anzi, è solo la certificazione legale degli orari di invio/ricezione della mail.
Sorvoliamo sul discorso che il +2.00 è CEST e non GMT, anche se non riportato l’abbiamo capito per logica (vorrei vedermi a spiegarlo ad un giudice in caso di controversia).

Ma tornando alla ricevuta, e alla frase “sent by l’utentexxxx@xxxxxxxxpec.it, on 2014-05-28 at 13:34:58 (+200)” questa frase farebbe pensare che l’utente ha inviato la mail alle 13.34:58, ma aprendo l’allegata mail si legge un orario differente (che è poi quello corretto):

mailpec3

Scioccamente da una Posta Elettronica Certificata, dove la certificazione a valore legale è soprattutto nell’orario, mi sarei aspettato una certa chiarezza e precisione anche espositiva.
Ma chissà cosa mi passa per la testa, dopotutto è tutto chiaro no? è proprio come quando vai dal salumiere a prendere la mortadelle e lui ti chiede “ne ho messo un po’ di più, lascio?” Verrebbe voglia di rispondergli che in realtà ne ha messo il 15% in più, ma poi pensi che va bene anche così. Facciamocela andar bene.

 

 

McAfee customer information leakage

McAfee è uno dei maggior player in ambito IT Security e in particolare è tra più attivi, se non il più attivo, nel produrre interessantissimi studi che poi condivide con il propri clienti (in particolare con quelli enterprise).

Capita a tutti di sbagliare, anche ai migliori, ma quello che mi ha colpito in negativo in questo caso è stata la poca sensibilità per non dire totale trascuratezza, nel gestire una segnalazione.

Quando ho riscontrato il problema mi sono posto nelle condizioni di un normale utente e ho cercato sul sito, sia quello pubblico generico, sia il portale specifico per i clienti, un punto di contatto specifico per inviare una segnalazione: non l’ho trovato.
A questo punto ho usato il supporto per i clienti cercando di comunicare un “information leakage of customer data” nel sistema dedicato ai clienti enterprise; il primo giro di risposte è stato un simpatico “it’s not our department, contacts another office“.
Another? Quale? “Another.”

Dopo vari tentativi sono passato alle mail, anche in questo caso ho trovato ben pochi riferimenti, per cui mi sono affidato alle mail trovate sul sito, come quella del(la) responsabile della comunicazione.

Mail a McAfee

Sono passati 2 mesi, mai ricevuta una risposta. E il problema è ancora lì. Non bene.

Un azienda che si occupa di sicurezza dovrebbe aver tra i primi valori il saper cogliere ogni segnalazione, anche la più debole.

Questo è il problema segnalato:

Periodicamente McAfee manda ai propri clienti enterprise una mail per notificare una notizia come la disponibilità di uno studio:

McAfee mail

Nella mail compare sempre il link “clicca qui per  scaricare il White Paper” e cliccandoci si apre un form già precompilato con tutti i nostri dati(e suona già male):

mcafee_il_es1

Il link è formulato in questo modo:

https://southern.secureforms.mcafee.com/forms/13Q3ITeDMTroy2013_EUIWPGSCNO1192CUSTOC?elq_mid=16567&elq_cid=4987450&elq=ff0ebc8390774f35bc4cd********6

Da un’analisi abbastanza veloce ricaviamo che la variabile che identifica il cliente è “elq=”.

Con qualche ricerca di google se ne ricavano una buona quantità, ma la cosa più significativa è che alcuni link sono indicizzati (perché?) proprio sul sito “secureforms.mcafee.com” (“secure form” ….).

https://southern.secureforms.mcafee.com/forms/13Q2SEURITeDM2013_EUIWPGSCNO283PARTDWNLOC?elq_mid=15380&elq_cid=4090475&elq=f72d3d6d2a524f009c9fc******2

mcafee_il_es3

https://emea.secureforms.mcafee.com/forms/1202-Q4ThreatsReport-fr?elq_mid=10504&elq_cid=1360924&eid=EUFWCGNONO107&ppcid=PART1-FR&elq=317c75cbd15743a198f7438a9******3

http://midmarket.mcafee.com/forms/LTAM_Q410_Threat_Report_Form_PROSP_BR?elq_mid=5504&elq_cid=2081245&elq=f549327d3f4642639045381******9

e via dicendo.

Non mi sembra il modo migliore di trattare i dati e se da un lato non ci sono dati “sensibili”, ci sono però sufficienti informazioni per tentare un furto di identità.

Inoltre “mi è parso” che lo stesso valore sia usato nel sistema di apertura e gestione ticket e si facilmente possibile impersonare un altro utente.

Da McAfee mi aspetto qualcosa di diverso.

L. (luca.savoldi@abissi.eu)

abissi_divinginthedeepweb