Cronistoria di un'infezione aspettando l'hyperworming Slammer, Sql Hell, Sapphire. Tanti nomi per un solo problema che è diventato, in poche ore, il nuovo incubo degli amministratori di sistema e di rete. Il malicious code, di categoria worm, è fondamentalmente senza effetti collaterali di rilievo se non quello di autodiffondersi in maniera esponenziale, su quasi tutte le piattaforme che gestiscano, direttamente o indirettamente, un motore Microsoft Sql 2000. Allo stato attuale vengono indicate, per gli utenti finali, piattaforme come Access2000 e Office XP, mentre per quanto riguarda gli sviluppatori il discorso è leggermente più ampio. L'incremento di questo worm ha causato un vero e proprio rallentamento anche a livello di Internet service provider e di alcune banche e colossi di carte di credito statunitensi. Le macchine infette sono state oltre cinquantamila. Ma l'infezione in sè non è l'unico problema, in quanto la continua ricerca di macchine vulnerabili da parte del worm ha generato dei grossi rallentamenti della rete in generale, creando fino a 800 scansioni al minuto su una rete di 8.000 indirizzi Ip con un incremento medio del 9% ogni ora. Una "prova" annunciata. Con questo termine si descrive l'applicazione pratica di una teoria frutto di una ricerca personale e/o altrui. Quella cui Slammer verosimilmente si riconduce si chiama Better Worm, secondo la quale, dato un particolare tipo di worm, deve essere sempre possibile migliorarne le performances. Nell'ottobre 2001 si parlò di alcune nuove teorie di derivazione accademica relative alla possibilità di diffondere su scala mondiale un worm in soli 15 minuti o, addirittura, in 30 secondi. Per raggiungere obiettivi di questo genere il writer doveva essere in grado di aver fatto una ricognizione a priori dello spazio Internet e avere accumulato in base a determinate tecniche (dette di "information gathering") informazioni quali il numero di macchine aventi una determinata piattaforma applicativa o un determinato servizio vulnerabile. Dette "mappe" risultano essere poi utili per velocizzare una successiva fase di infezione. Slammer ha dimostrato praticamente questa tecnica (denominata Hyperworming), anche perché le applicazioni colpite da Slammer non sono state solo quelle Microsoft "pure" ma tutte quelle che contenevano il modulo software incriminato, tra le quali anche alcuni prodotti di sicurezza, antivirus e Intrusion detection inclusi. I fatti. Slammer ha dimostrato, pur non avendo un effetto (payload) distruttivo in senso stretto, di essere in grado di creare un effetto di tipo Denial of Service (DoS) di fatto molto forte, utilizzando un insieme di macchine infette come componenti di una DoS net (rete di macchine utilizzate con questa finalità), limitando paradossalmente il problema dell'autodiffusione a "sole" cinquantamila macchine ma coinvolgendo di fatto tutto il perimetro delle reti a causa del continuo traffico generato. Ecco, in pratica, quello che è successo. Verso le 23 di venerdì 25 gennaio (ora italiana) alcune università americane hanno iniziato a segnalare un incremento sul traffico relativo alla porta 1434 Udp, utilizzata dal servizio SQL 2000 Based di Microsoft per alcune operazioni e sfruttata dal worm per autodiffondersi. Nel giro di poche ore, i maggiori Isp mondiali hanno notato un incremento esponenziale di questo tipo di traffico, a tal punto da dover decidere di effettuare dei filtraggi di emergenza, al fine di limitare l'escalation di questa ormai accertata diffusione di malicious code. Successivamente si sono avviate le procedure di monitoraggio sia da parte dell'Internet Storm center americano, sia da parte dei vari produttori di antivirus. L'Isc si occupa in prima persona del monitoraggio del l'impatto di particolari incidenti attribuendo dei codici di allarme su una scala cromatica. Durante il picco dell'infezione è stato raggiunto l'allarme giallo. Va comunque ricordato, a tal proposito, che il calcolo dell'impatto viene si valutato su scala mondiale ma su proporzioni numeriche differenti rispetto alle misurazioni di un produttore antivirus, che basa le misurazioni generalmente su campioni di suoi clienti. Come difendersi? Una delle caratteristiche principali di questo worm consiste nel fatto che non scrive sul disco ma rimane in memoria. Pertanto un "semplice" riavvio della macchina colpita dovrebbe essere in grado di "ripulirla". Microsoft, inoltre, aveva rilasciato da tempo degli aggiornamenti di sistema per risolvere il bug incriminato. Queste "patch" sono abbastanza "pesanti" in termini di megabytes. Questo ha evidentemente rallentato la loro distribuzione sui siti remoti e aumentato le possibilità di diffusione del worm. L'applicazione delle patch, inoltre, non è una cosa semplicissima, specie con macchine che devono rimanere in produzione 24 ore su 24 e chi ha scritto il worm lo sapeva bene. Ecco perché anche la stessa Microsoft è stata colpita. Le polemiche post incidente. Partiamo proprio da chi può essere il possibile autore di una cosa di questo tipo. Ogni volta che avviene un incidente di questa entità si assiste ad una vera e propria ressa: c'è sempre il produttore di sistemi di sicurezza che dichiara di avere la soluzione, il consulente tuttologo che sa perché il mondo intero è rimasto infetto eccetto lui, e gli amministratori di rete e sistemi che giocano a scaricabarile. C'è sempre il solito cercatore di scoop che attribuisce al cinese di turno la paternità del malicious code, così come è successo per Nimda e altri esempi simili. La realtà è una: non si è certi della paternità di un attacco fino a quando non si è rintracciato fisicamente il responsabile. Comunque sia, l'attenzione della comunità scientifica si è spostata sul senior staff del presidente Bush, avvisato per tempo dell'accaduto e, soprattutto, su un certo David Litchfield, ricercatore molto conosciuto in certi ambienti. Litchfield è noto per aver scritto alcuni tra gli exploit (codice che se eseguito sfrutta le vulnerabilità) più efficaci della storia. Subito dopo l'inizio del problema, negli ambienti di analisi si sono susseguite oltre dieci autorevoli "interpretazioni" del codice. Molte di queste hanno denotato il fatto che Slammer sia molto probabilmente derivato da un template scritto da questo programmatore un po' di tempo fa, proprio per sfruttare la vulnerabilità sul Motore Sql 2000. Anche se la comunità è concorde nel dire che questo template ha risparmiato a chi ha scritto il worm solo una ventina di minuti, David ha deciso di rivedere la sua politica di Full disclosure, cioè di diffusione dei dettagli su un determinato problema di sicurezza. Staremo a vedere. Nel frattempo, però, Litchfield ha appena rilasciato un avviso affermando di aver trovato un'altra falla di sicurezza sulla piattaforma Windows (consigliamo ai tecnici di verificare il proprio ambiente Rpc), che può essere sfruttata allo stesso modo e con gli stessi effetti. Dal punto di vista della tecnica utilizzata per diffondere l'infezione, questa si basa, tra l'altro, sull'utilizzo del protocollo Udp che, per le sue caratteristiche, rende molto complessa l'effettuazione dei percorsi a ritroso da parte di chi è preposto a farlo. L'episodio Slammer, insomma, non ha né vincitori né vinti. Gli operatori sanno che il tempo della tecnologia come unica soluzione di tutti i mali è ormai passato. E anche i produttori di antivirus, più "silenziosi" del solito, lo sanno. Sanno che il rilascio di un "antidoto" non è più sufficiente. In quanto il vero hyperworming è in agguato e deve ancora arrivare. (Ndr: ripreso da @lfa Il Sole-24 Ore di Venerdí 14 Febbraio 2003) |