Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

0

Share

Download to read offline

Minaccie Vere Vulnerabilita Evitabili

Download to read offline

La sicurezza inizia dalla nostra volontà di organizzarci

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Minaccie Vere Vulnerabilita Evitabili

  1. 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. 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. 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. 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. 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. 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

La sicurezza inizia dalla nostra volontà di organizzarci

Views

Total views

575

On Slideshare

0

From embeds

0

Number of embeds

7

Actions

Downloads

5

Shares

0

Comments

0

Likes

0

×