La sicurezza inizia dalla nostra volontà di organizzarci

1. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
1 [6]
Anno I - numero 2 - 17 febbraio 2003
Minaccie vere, vulnerabilità evitabili: gestione della sicurezza
di Sandro Fontana - sfontana@secure-edge.com
Il 25 gennaio ultimo scorso, alle 05:30 (UTC) il traffico su tutta Internet riferito alla
porta 1413 è aumentato a dismisura, causando la saturazione ed anche il blocco di
molti dei grandi nodi della rete.
Una idea di cosa questo significhi, può darla il grafico seguente [source:
http://www.sans.org] :
Questo è il modo in cui il worm SQL Slammer, conosciuto anche come Sapphire o
SQL Hell si è presentato alla Comunità.
Il worm sfrutta a suo vantaggio una vulnerabilità da buffer overflow, presente su
Microsoft SQL Server 2000; di per se non è particolarmente sofisticato, ne
malevolo: cerca i sistemi da infettare generando indirizzi IP in modo random, non
contiene back door, o codice per attività di fllooding, come ad esempio Code Red
ed essendo residente solo in memoria, un semplice reboot del sistema permette la
sua eliminazione … fino a quando un computer vicino infetta nuovamente il
sistema appena ripartito!
Nonostante la sua semplicità ed avendo come unico scopo quello di infettare altri
sistemi, il worm ha costretto i computer infettati a generare una quantità enorme di
traffico, dando luogo, quasi involontariamente, ad un vero e proprio denial of
service.

2. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
2 [6]
A seguito di questo evento, in tutto il mondo si sono riportati parecchi danni,
perdite dovute ai tempi di problem determination, reboot dei sistemi, ripresa delle
attività, non rispetto dei livelli di servizio, etc…
In Italia, il caso più eclatante [naturalmente di quelli ufficialmente riportati] lo ha
avuto Poste Italiane, che si è ritrovata, il lunedì mattina, con circa 14.000 sportelli
bloccati; se andiamo a cercare altrove troveremo che negli USA, anche gli ATM
(bancomat) della Bank of America, sono stati vittima di questo worm; alla fine di
sabato, in USA sono stati dennunciati 35.000 host infettati, mentre Incident.Org ha
dichiarato che per le 10:00am (EST) [cioè 15:00 UTC] di domenica, erano 120.000
gli indirizzi IP che risultavano colpiti.
Perché un worm come SQL Slammer, ha potuto essere così efficace ?
Ha sfruttato una nuova e nascosta vulnerabilità del MS- SQL Server 2000 ?
E’ forse un complotto del terrorismo Assiro-Babilonese ad effetto ritardato ?
La realtà è diversa ed ahimè, piuttosto banale.
Andando con ordine:
Il 24 luglio 2002, la Microsoft ha comunicato [1] per la prima volta la presenza di
una vulnerabilità da buffer overflow, sul suo SQL Server 2000; tra l’altro la
Microsoft ha riportato che questa vulnerabilità è presente anche sul MSDE 2000
(Desktop Edition) , piattaforma utilizzata dagli sviluppatori software e presente
all’interno di numerosi packages.
Il worm usa il protocollo UDP sulla porta 1434, quindi un primo consiglio fu quello
di bloccare solo il traffico UDP in/out relativo a questa porta, non tutto il traffico:
questa porta è usata da MS SQL 2000; (questo è quello che hanno fatto gli ISP di
mezzo mondo da sabato mattina allo scopo, in parte riuscito, di limitare la
diffusione del worm)
Il 16 ottobre 2002, la Microsoft emise il Security Bulletin MS02-061 che conteneva
le spiegazioni del caso e la prima patch da installare; ad essa seguiva dopo pochi
giorni [30 ottobre 2002] una non-security hotfix (317748) che risolveva alcuni
problemi procedurali introdotti dalla patch.
Infine, allo scopo di agevolare il più possibile gli utenti, il 28 gennaio 2003
Microsoft ha riemesso la patch originale e l’hotfix come package integrato.

3. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
3 [6]
In pratica per ripulire un sistema infettato dal worm SQL Slammer, la procedura da
seguire è la seguente:
disconnettere il computer dalla rete;
fare lo shutdown e spegnere il sistema;
eseguire un reboot (a freddo);
applicare le patches;
riconnettere il sistema alla rete e monitoralo !!
Ora, credo di non essere annoverato tra i fans di Microsoft, ma obbiettivamente mi
sembra che questa ultima abbia fatto tutto quello che era necessario, desiderabile e
possibile per correggere un bug, non appena questo era stato messo in evidenza.
Mi chiedo quindi di nuovo:
con tutto l’anticipo temporale avuto, le advisory, la patch del fornitore disponibile,
le spiegazioni del caso …
… perché un worm come SQL Slammer, ha potuto essere così efficace ?
Credo che la risposta sia:
mancanza di un processo continuo di Patch Management.
In realtà il problema è più ampio.
Da dove viene il concetto di Patch Management ?
Tanto per cambiare, inizierei dalla ISO/IEC 17799 [3], Code of Practice per il
conseguimento di un Information Security Management System o ISMS.
ISMS è l’acronimo di quattro parole inglesi, che ormai sappiamo pronunciare
correttamente e di cui conosciamo anche il significato ; il problema è che una di
queste parole, guarda caso quella più importante, da quasi tutte le organizzazioni è
pressoché disattesa e sottovalutata; naturalmente la parola è: management.

4. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
4 [6]
Tolta questa parola, quello che rimane è Information Security System, un
qualcosa che ormai quasi tutte le organizzazioni con un minimo di preoccupazione
sul loro futuro, hanno attivato e che risulta, oltre che grammaticalmente corretto,
purtroppo anche apparentemente valido.
Questo approccio difetta quindi della parola management, e di ciò che questo
significa:
valutazione dei rischi a cui è esposta l’organizzazione, necessaria per
l’identificazione delle minacce e delle vulnerabilità esistenti e base per la stima
dell’impatto potenziale sull’Azienda;
valutazione degli obblighi legali e contrattuali e dei regolamenti aziendali;
sviluppo e supporto dei principi, degli obiettivi e dei requisiti aziendali;
implementazione, verifica, evoluzione delle contromisure identificate;
Il Security Management è composto da una serie di aree o compiti, tra le quali
troviamo il Vulnerability Management; quest’area deve essere considerata uno dei
principali obiettivi da gestire da parte di una Azienda, in quanto le vulnerabilità
esistono indipendentemente dalle eventuali patches che possono eliminale o almeno
ridurle.
A sua volta il Vulnerability Management è strutturato in una serie di attività, tra le
quali troviamo il Patch Management, che è poi l’attività generalmente non
effettuata e per questo al 90% responsabile [4] degli accadimenti descritti all’inizio
di questo articolo.
A voler essere pignoli, la ISO/IEC 17799:2000 vede la gestione delle patches
orientata solo al sistema operativo:
[…]
10.5.2 Technical review of operating system changes
Periodically it is necessary to change the operating system, e.g. to install a newly supplied
software release or patches. When changes occur, the application systems should be
reviewed and tested to ensure that there is no adverse impact on operation or security.
[…]
ma è chiaro che noi dobbiamo intenderla estesa a tutto quello che è possibile, cioè
network applications, user applications, operating systems e qualsiasi altro software
che possa richiedere l’analisi delle sue funzionalità a fronte della scoperta di una
nuova vulnerabilità o periodicamente necessitare dell’applicazione di una patch di
sicurezza.

5. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
5 [6]
Cerchiamo quindi di effettuare un temporaneo upgrade allo standard, considerando
queste norme pratiche:
Definire nelle Security Policy le procedure e le responsabilità relative al Patch
Management
Gestire un inventario completo delle apparecchiature ICT
Concordare internamente o in outsourcing un servizio di vulnerability alert
Valutare l’applicabilità degli alert al proprio patrimonio ICT
Definire le modalità ed i gradi di intervento sulle vulnerabilità scoperte
Valutare l’applicabilità delle patches una volta che queste sono rese disponibili
(controllare side effect negativi)
Ridurre la finestra di esposizione con l’istallazione tempestiva delle patches
Controllare che le misure fin qui adottate abbiano ridotto o messo sotto
controllo le vulnerabilità
Riepilogando quindi, mi sento in dovere di assolvere un produttore di software, se
questo è stato pronto a risolvere una debolezza/bug/vulnerabilità nel proprio
prodotto, proponendo una correzione/patches nei tempi adeguati.
Alla fin fine, scagli il primo gigabyte, colui che non ha mai scritto software errato!
Il problema vero risiede nella window of vulnerability [5], cioè nel periodo
temporale compreso tra la disponibilità al pubblico della patch e la data in cui
questa patch viene installata sui sistemi target: tipicamente si parla di mesi !
Il fatto poi che il patch management sia una delle attività di sicurezza che coprono
solo una parte dell’aspetto tattico del Security Management e che non abbia quindi
nulla a che vedere con le attività relative all’aspetto stategico di questo, credo sarà
argomento di un prossimo articolo.

6. laboratorio di idee sulla sicurezza ICT
Newsletter di Secure Edge - your safety .net
SecLab
6 [6]
Note bibliografiche:
[1] Microsoft Security Bulletin (originally posted July 24, 2002):
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-039.asp
[2] Incidents.org preliminary analysis of worm (includes a packet trace):
http://isc.incidents.org/analysis.html?id=180
[3] International Standard ISO/IEC 17799:2000 First edition 2000-12-01;
Information technology — Code of practice for information security management:
http://www.iso.ch
[4] J.G.Perez, “Gardner: Most IT Security Problems Self-Inflicted”,
Computerworld, 9 Oct. 2001:
http://www.computerworld.com/securitytopics/security/story/0,10801,64605,00.html
[5] B. Schneier, “Closing the Window of Exposure”, Counterpane Internet Security
2002: http://www.counterpane.com/window.html
Altre informazioni relative al worm:
Original Vulnerability Analysis by David Litchfield:
http://www.nextgenss.com/advisories/mssql-udp.txt
CERT Advisory:
http://www.cert.org/advisories/CA-2002-22.html
http://www.cert.org/advisories/CA-2003-04.html
Microsoft Advisory:
http://www.microsoft.com/security/slammer.asp