Buio e silenzio di Skype

Non ne ho voluto parlarne subito per poter avere degli elementi in più. Ora forse è anche troppo tardi, ma si sa, il rientro dalle ferie è sempre difficile.
Penso che in pochi non lo sappiano: dal 16 Agosto, per due giorni, c’è stato un black-out dei server di login di Skype che hanno comportato l’impossibilità di connettersi a milioni di utenti. Per la cronistoria c’è il primo avvertimento dato da skype, il suo aggiornamento e addirittura un articolo di Repubblica arrivato con la dovuta calma.

Dal comunicato ufficiale (disponibile anche in italiano) si apprende come:

The disruption was triggered by a massive restart of our users’ computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update.

The high number of restarts affected Skype’s network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact.

Questo è il grafico creato con l’aggregazione dei dati ufficiali rilasciati da Skype: Skype online-user on 16th August

Come si può vedere la discesa del numero di utenti connessi alla rete P2P (che forse non è così tanto P2P) è iniziata intorno alle 9:30AM (GMT) di Giovedì 16 Agosto.
Microsoft ha rilasciato le patch Martedì 14 Agosto, ben due giorni prima del down dei server di Skype. Mi verrebbe da pensare che essendo vicino a Ferragosto molti utenti (casalinghi per la maggior parte) abbiano installato le patch solamente il 16 Agosto scorso, ma dalle statistiche Skype si vede come il 15 Agosto erano circa 700.000 gli utenti in meno in confronto al giorno precedente. Ciò, secondo me, non può giustificare un calo improvviso di “supernodi” imputabile al riavvio dopo l’installazione delle patch. In più come fa notare un post su Security Team solo una patch, tra quelle rilasciate da Microsoft, potrebbe richiedere il riavvio del sistema.

Il 17 Agosto è comparso su un sito di sicurezza Russo (http://en.securitylab.ru/poc/extra/301419.php) un exploit che prometteva un DoS verso i server di Skype passando da riga di comando un numero di telefono arbitrario direttamente al client. Grazie anche all’ottima analisi di ascii si è capito che tale codice non era altro che un fake.
Ciò non significa che l’exploit non esista proprio, magari era stato rilasciato da qualcuno che ne aveva sentito parlare “nell’ambiente” ma che non ha avuto le capacità per riprodurlo.

Guarda caso, sempre il 17 Agosto, è stata rilasciata anche una nuova versione di Skype: 3.5.0.214.

Nel primo comunicato, Skype, ha ammesso che oltre ad essersi presentata una situazione particolare nella propria rete P2P, era emerso un bug finora non conosciuto:

Normally Skype’s peer-to-peer network has an inbuilt ability to self-heal, however, this event revealed a previously unseen software bug within the network resource allocation algorithm which prevented the self-healing function from working quickly.

Nel secondo comunicato è stato chiarito che è stata migliorata la resilienza del software stesso:

The parameters of the P2P network have been tuned to be smarter about how similar situations should be handled. Once we found the algorithmic fix to ensure continued operation in the face of high numbers of client reboots, the efforts focused squarely on stabilising the P2P core.

Ognuno tragga le proprie conclusioni, perchè dalle spiegazioni generiche che ha dato Skype, si capisce solo che non gradiscono la full-disclosure. Vedo che anche zen la pensa come me.

 

Ottimi esempi di persistent XSS

Non a caso ne avevo parlato più di un mese fa: attacchi XSS mediante header HTTP.
Niente di nuovo, sia chiaro. Sono solamente un ottimo esempio per dimostrare come funzionano i persistent XSS e quanto essi siano pericolosi.
Questa tecnica prevede che, al contrario del reflected XSS, i parametri passati, dall’utente, all’applicazione siano salvati da essa sul server per poi essere successivamente visualizzati, in una apposita pagina, senza essere correttamente convertiti in entità HTML o esadecimali nel caso di URL.

Il primo esempio è basato sull’advisory pubblicata a riguardo della “dashboard” di WordPress.com: in questo caso l’applicazione prendeva per buono qualsiasi valore dell’header referer senza codificarlo in alcun modo al momento della visualizzazione. In questo modo potevano essere compromessi tutti gli utenti con un blog sul dominio wordpress.com ed in più tutti quelli, con un blog su dominio di proprietà, che fanno uso del plug-in ufficiale Stats. Diffusione del problema: ALTA.

Il secondo esempio si basa sull’advisory pubblicata a riguardo di StatCounter.com: come nel caso precedente, qualsiasi valore inviato all’applicazione, tramite l’header “Referer”, veniva visualizzato nella pagina “Came From” senza nessuna codifica potendo così iniettare codice HTML o JS a piacimento. In questo caso, grazie ad una vulnerabilità CSRF, era veramente molto facile creare utenti aggiuntivi per l’accesso all’amministrazione delle statistiche. Diffusione del problema: ALTA (molti domini famosi utilizzano questo servizio). Per una dimostrazione del bug potete vedere il video dedicato.

A questo punto, spero che servizi simili prendano coscienza della pericolosità e correggano così i problemi sulle loro applicazioni.
Un grazie a Gianni Amato per il feedback a riguardo di questi XSS.