Il taccuino di Armando Leotta Rotating Header Image

Clusit

Aruba va a ruba (e a fuoco): osservazioni sul disservizio

incendio ups arubaI servizi IT sono fallibili, proprio per la natura stessa degli elementi infrastrutturali sottesi all’erogazione del più semplice e banale servizio ICT.

Il 29 aprile è una data che gli addetti ai lavori e, soprattutto, gli utenti Aruba non dimenticheranno facilmente visto che un “principio d’incendio” in un loro datacenter ha causato un downtime totale dei servizi di svariate ore.

Ricordando l’incipit e tenendolo bene a mente per tutta la durata della lettura di questo appunto vado a puntualizzare alcuni aspetti.

Punto primo

C’è chi grida allo scandalo perché disservizi di ore sono ingiustificabili, perché esistono soluzioni di Business Continuity tali da evitare downtime di diverse ore (anche più di 8);

Verissimo, esistono eccome. Tra le varie soluzioni di BC rientra anche la realizzazione o la fruizione di un sito di Disaster Recovery *MA* non si può pretendere certo di fruire di un sito DR se paghi un host condiviso a qualche decina di euro al mese o addirittura all’anno.

 

Punto secondo

Associazione consumatori richiedono la class action contro il fornitore per i danni derivanti dal disservizio.

In linea di massima mi sembra una posizione corretta ma esistono i contratti e anche gli SLA, gli accordi sui livelli di servizio.

E poi c’è Aruba che nel punto 14) e 14.x) del documento Condizioni Generali di Contratto Webfarm Services specifica chiaramente che lo SLA offerto prevede una disponibilità *best effort* e non garantisce *niente*.

A titolo esemplificativo e non esaustivo incollo il punto 14.4:

14.4: In tutti i casi sopra elencati, e in ogni caso in cui si manifesti una sospensione e/o interruzione del Servizio, a qualsiasi causa dovuta, ad eccezione dei casi in cui tali situazioni siano dovute a dolo o colpa grave di Aruba, quest’ultima non sarà in alcun modo responsabile nei confronti del Cliente o di Terzi per la mancata disponibilità del Servizio, impegnandosi ad assicurare la migliore funzionalità del sistema ma non garantendo comunque la continuità del servizio, l’integrità dei dati memorizzati o inviati attraverso il sistema di Aruba e/o attraverso internet. Il Cliente, pertanto, prende atto ed accetta che non potrà avanzare alcuna richiesta di risarcimento danni, siano essi diretti o indiretti, prevedibili o imprevedibili, di rimborso o di indennizzo (a titolo esemplificativo e non esaustivo, per perdite economiche/finanziarie, di affari, di ricavi e di utili e/o di avviamento commerciale) nei confronti di Aruba per il verificarsi di ritardo, cattivo funzionamento, sospensione o interruzione del Servizio e la solleva, ora per allora, da qualsiasi responsabilità in proposito.

In ogni caso, piaccia o no, tenere a mente il punto uno.

(Mi viene da pensare all’integrità dei dati non garantita: vedi servizio PEC)

 

Punto terzo

Nella sezione modulistica e contratti non mi sembra venga fatta distinzione da soluzioni in hosting condiviso da 10 euro all’anno o server dedicati da 300 euro al mese.

Se ho ben inteso (e spero di ricevere tante smentite in proposito) cambia la connettività, la soluzione tecnologica, i servizi erogati e le loro prestazioni ma non la disponibilità degli stessi (vedi punto 2 e punto 1).

Molto mi verrebbe da dire in relazione al servizio PEC ed ai danni derivanti dalla mancata erogazione (l’integrità dei dati di un servizio PEC deve rispettare una normativa specifica e rigorosa).

 

Punto quarto

Le comunicazioni ufficiali.

Ore 11:25 (stralcio):

Si è verificato un principio di incendio nel Powered center della server farm principale che ha coinvolto le batterie degli UPS senza intaccare le sale dati.

Il sistema antincendio si è attivato facendo scattare l’ energy power off togliendo per sicurezza energia all’intera struttura come da procedura.

Stralcio del comunicato stampa:

Inoltre, nonostante sia consuetudine installare le batterie all’interno del data center, per evitare il ripetersi di quanto accaduto, da oggi le batterie del data center di Arezzo e di tutti gli altri data center del Gruppo Aruba saranno installate in appositi locali, esterni e separati dalla struttura principale.

Ora, in primo luogo non è affatto una consuetudine tenere gli ups nei data center. Almeno non mi risulta lo sia per fornitori diversi da Aruba.

Inoltre, cosa ancora più importante del “mal comune mezzo gaudio”, il comunicato stampa che, a mio avviso, smentisce de facto quanto affermato nel primo comunicato.

Dal comunicato stampa si capisce chiaramente che c’è una consuetudine (palesemente falso, ndr) di alloggiare le batterie UPS all’interno dei data center ma che, “per evitare il ripetersi di quanto accaduto“, da *oggi* *saranno* delocalizzate in appositi locali esterni e separati dalla “struttura principale” ossia elaboratori, dispositivi di routing, dati, etc.

Questo significa che, fino a *ieri*, erano localizzate insieme a detti ambienti. Questo cozza completamente con quanto affermato nel primo comunicato dove si specificava che il principio d’incendio non ha interessato le sale dati.

Un po’ di confusione, forse, può starci in momenti di emergenza come quello vissuto dallo staff di Aruba.

Certo è che il lettore resta perplesso, l’utente si perplime decisamente di più.

 

Conclusione

Con servizi come Aruba paghi ciò che ti viene reso e non è pensabile aspettarsi un uptime del 99,9 % su base mensile o settimanale se poi si paga 20 euro l’anno.

Continuo a sperare che servizi diversi dai costi ovviamente diversi abbiano uno SLA garantito sia in termini di disponibilità che di integrità, con penale ma al momento non ne ho trovato traccia sul loro sito.

Soluzioni di Business Continuity, tra cui il Disaster Recovery, costano (vedi punto1).

Golden rule #1: leggere il contratto e le condizioni generali applicate.

Golden rule #2: non si fanno le nozze con i fichi secchi.

Golden rule #3: Aruba? No, grazie.

 

_____
Clusit

[WARNING] Gawker Media hacked. In altre parole account compromessi su Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin e Fleshbot

Ieri mi ero allarmato per un accesso anomalo al mio profilo facebook.

(via lifehacker)

Stanotte ho letto che GaWKER MEDIA ha comunicato di essere stata vittima di un attacco.

Il risultato è la compromissione degli account *registrati* usati per commentare sulle loro piattaforme Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin e Fleshbot.

Due modi per avere la conferma di essere vittime involontarie di questo attacco: usare un widget oppure controllare se il proprio indirizzo di mail è nell’elenco ormai pubblico e pubblicamente disponibile (un torrent da 500 MB) dopo la rivendicazione dell’attacco da parte di un gruppo chiamato Gnosis.

Se volete effettuare manualmente il controllo calcolate lo sha-256 (no salt) del vostro indirizzo di mail usato per registrarvi a gawker (non è salvato in chiaro) e controllate qui in base ai primi caratteri del risultato della funzione hash.

Non ricordavo nemmeno di essere registrato ma ovviamente la mia mail è presente nella lista pubblica e non mi resta che pensare che la password era la stessa usata anche per facebook: ecco probabilmente spiegato il login dal New Jersey di ieri.

Lessons learned? Tenere sempre traccia degli account che si registrano (e che non si usano  abitualmente, ndr) e della mail che si usa per la registrazione. L’ideale sarebbe usare password diverse per servizi diversi ma mi rendo conto della difficoltà oggettiva e della controtendenza dei servizi in the cloud.

In ogni caso, controllate e cambiate immediatamente la password e/o le password ai servizi che utilizzate con le medesime credenziali.

_____
Clusit

Youtube sotto attacco nel weekend: un XSS in cambio di un banner?

Un 4 luglio che non è passato inosservato.
Almeno in casa Google e, a quanto pare, anche a Cupertino.
Tra sabato e domenica Youtube ha subito un attacco che ha avuto come target i video del cantante pop Justin Bieber (e successivamente di Lady Gaga).
L’attacco dimostrativo, che sfrutta una vulnerabilità nel sistema di parsing dei commenti, mostrava un popup dove si leggeva la notizia della morte del cantante.

Youtube hacked (clicca per ingrandire)

4chan

rivendicazioni? (clicca per ingrandire)

Google, dopo un blocco cautelativo dei commenti, ha rilasciato una fix sui suoi sistemi che risolveva la vulnerabilità (XSS) sfruttata dagli hacker.

Post Google fix (clicca per ingrandire)

Sembra infatti che il parsing del contenuto dei commenti fosse effettuato in modo da gestire solo una prima occorrenza del tag script mentre, quanto in esso contenuto, era accettato senza alcun tipo di controllo ulteriore (sufficiente pertanto a consentire commenti con javascript al suo interno, ad esempio).
C’è chi ipotizza un gesto dimostrativo come reazione alla recente scelta di youtube di inserire pubblicità (Skippable ADS) nei filmati a partire da dicembre prossimo (fonte Baljeet Singh, YouTube Senior product manager in una conferenza stampa di giovedì scorso).
Coincidenza? Pretesto? Esibizionismo?
(screenshot via thenextweb)

_____
Clusit

Tab-napping o tabnapping, un nuovo phishing exploit

Tra le tante cose viste, dette ed affrontate in tavole rotonde al Security Summit di ieri a Roma una in particolare mi ha colpito per la semplice genialità.

E quando si parla di tecniche di social engineering e/o di phishing la semplicità è un elemento essenziale affinchè l’attacco vada ahimè a buon fine.

Questo nuovo exploit è stato battezzato “Tab-napping” ed è un cocktail micidiale i cui ingredienti sono javascript, social engineering e browser permissivi.

Cos’è e come funziona

E’ un javascript che viene caricato all’interno di una pagina web apparentemente lecita ed innocua.

In realtà, è innocua finchè non viene cambiato il focus ad esempio aprendo una nuova tab e rendendola attiva.

A questo punto, parte un timer che dopo x secondi “trasforma” la pagina con il codice malevolo con una pagina fake recentemente visitata della quale sono appetibili le credenziali d’accesso.

Si pensi anche solamente a banche ed a servizi di posta.

Esiste un proof-of-concept in rete nel quale è previsto dopo 5 secondi la “trasformazione” della pagina “innocua” nella pagina (FAKE) di logon di gmail, ad esempio. L’utente nella fretta ed in buona fede (visto che lo script carica una pagina IDENTICA all’originale comprensivo di icona distintiva dell’indirizzo –favicon-) reinserisce le credenziali.

A quel punto il gioco è fatto (potrebbe forse spiegare recenti violazioni? Le verifiche sono ancora in corso).

Guardando il codice nulla vieta un redirect verso la vera risorsa e se il cookie è ancora valido per l’utente potrebbe risultare del tutto indifferente (vedi gmail).

Inoltre, ho verificato che non funziona solo sullo switch tra tab: funziona quando perde il focus quindi anche quando ci sono diverse istanze del browser. Questo aspetto non è da sottovalutare visto che più sono le finestre aperte e maggiore è la probabilità che passi inosservato l’inganno.

Se volete, provate, con cautela, direttamente il proof-of-concept.

Suggerimenti

Quando ci autentichiamo a servizi delicati è opportuno chiudere le finestre del browser ed aprirne una nuova dedicandola a tale attività.  Evitare il più possibile sessioni di diversa natura e finalità specialmente se prevedono autenticazione.

Al momento di inserire le credenziali di accesso assicurarsi di essere giunti su quella pagina seguendo un bookmark sicuro o avere digitato manualmente l’indirizzo possibilmente in https. In altre parole, niente link e … attenzione anche ai cambiamenti di pagina!

Usare firefox e NoScript.

*** Aggiornamento 1 ***

Ho inserito di seguito uno screencast per coloro che non vogliono vedere il poc in funzione.

_____
Clusit