Le venti vulnerabilità più critiche per la sicurezza in Internet

Versione 3.2  - Febbraio 2003
Localizzata da Data Security
Copyright 2001-2002, The SANS Institute

 

La maggior parte degli attacchi riusciti ai danni dei sistemi operativi deriva da un numero estremamente limitato di vulnerabilità software. Ciò si deve al fatto che coloro che effettuano gli attacchi agiscono in modo opportunistico, ovvero scelgono la strada più semplice e comoda, sfruttando le vulnerabilità più conosciute e impiegando gli strumenti di aggressione più efficaci e diffusi. Contano sul fatto che le aziende spesso non pongono rimedio ai problemi e quindi spesso conducono attacchi indiscriminati, scegliendo gli obiettivi dai risultati di una serie di scansioni in Internet per rilevare i sistemi vulnerabili.
La compromissione dei sistemi del Pentagono a seguito dell’episodio di hacking Solar Sunrise e la facile e rapida diffusione dei worm Code Red e NIMDA, per fornire solo alcuni esempi, possono essere facilmente collegate allo sfruttamento di alcune vulnerabilità per le quali non sono state tempestivamente applicate le opportune correzioni.

Due anni fa, Il SANS Institute e il National Infrastructure Protection Center (NIPC) pubblicarono un documento che elencava le dieci vulnerabilità più critiche per la sicurezza in Internet. Da allora migliaia di organizzazioni hanno utilizzato quella lista, e la sua evoluzione a venti vulnerabilità diffusa un anno dopo, come guida per risolvere rapidamente i buchi di sicurezza più pericolosi. Le vulnerabilità che hanno favorito i tre esempi riportati sopra - l’episodio Solar Sunrise del Pentagon e i worm Code Red e NIMDA - sono riportate su quella lista.

Questa nuova versione delle “Venti Vulnerabilità più critiche” è in effetti costituita da due liste di dieci: i dieci servizi di Windows le cui vulnerabilità sono più frequentemente sfruttate e i dieci servizi di Unix le cui vulnerabilità sono utilizzate più spesso per condurre un attacco.
Sebbene vi siano migliaia di episodi di violazione della sicurezza che ogni anno colpiscono questi sistemi operativi, la stragrande maggioranza degli attacchi portati a termine sono diretti verso uno o più di questi servizi.

Per quanto anche gli amministratori di sicurezza più esperti troveranno nelle Venti Vulnerabilità più critiche un valido strumento di lavoro, la lista è diretta in particolare a quelle organizzazioni nelle quali scarseggiano le risorse la formare o dove mancano amministratori della sicurezza con una preparazione tecnica particolarmente avanzata. Coloro che hanno la responsabilità della gestione della rete in queste organizzazioni spesso raccontano di non aver corretto molte di queste vulnerabilità semplicemente perché non sapevano quali fossero le vulnerabilità più pericolose, ed erano troppo occupati per poterle eliminare tutte o non sapevano come correggere in modo sicuro. Tradizionalmente gli auditor e i security manager hanno sempre usato strumenti per la rilevazione delle vulnerabilità per cercare cinquecento, mille o anche duemila vulnerabilità molto specifiche, distogliendo gli amministratori dall’obiettivo di proteggere efficacemente tutti i loro sistemi dagli attacchi più comuni. Quando un amministratore di sistema riceve un report che elenca migliaia di vulnerabilità su centinaia di macchine, spesso rimane paralizzato.

Le Venti vulnerabilità più critiche è una lista delle vulnerabilità che richiedono un intervento immediato. L’elenco è ordinato per servizi perché in molti casi un singolo rimedio - disabilitare il servizio, aggiornare alla versione più recente, applicare una patch cumulativa - può risolvere dozzine di vulnerabilità specifiche del software che possono essere evidenziate da una scansione. Questa lista è stata progettata per mitigare questi problemi raggruppando le conoscenze di decine tra i più importanti esperti di sicurezza. Essi provengono dalle agenzie federali statunitensi più sensibili a problemi della sicurezza, dai più importanti produttori di software, dalle più importanti società di consulenza, dai migliori progetti universitari per la sicurezza, dal CERT/CC e dal SANS Institute. L’elenco dei partecipanti è disponibile alla fine del presente documento.

L’elenco SANS/FBI delle venti vulnerabilità più critiche è un documento in continuo aggiornamento. Contiene istruzioni dettagliate e riferimenti a informazioni supplementari utili per correggere i problemi di sicurezza. Nel momento in cui si scoprono minacce più critiche di quelle elencate o metodi di intrusione più diffusi o più comodi, vengono aggiornati l’elenco delle vulnerabilità e le istruzioni per rimediare; in questo processo il vostro contributo è sempre gradito. Questo documento si basa sul consenso di un’intera comunità: la vostra esperienza nel combattere le intrusioni e nell’eliminare le vulnerabilità può aiutare quelli che verranno dopo di voi. Inviate i vostri suggerimenti a info@sans.org, specificando "Top Twenty Comments" nell’oggetto dell’e-mail.

top ^

Note per i lettori:

Codici CVE

Ogni vulnerabilità menzionata è accompagnata dai codici della catalogazione CVE (Common Vulnerabilities and Exposures). Spesso sono riportati anche i numeri CAN, ovvero i codici delle vulnerabilità che sono candidate ad essere incluse nella lista CVE, ma non sono state ancora completamente verificate. Per ulteriori informazioni relative al progetto CVE, oggetto di numerosi riconoscimenti ufficiali, consultate l’indirizzo http://cve.mitre.org/.

I codici CVE e CAN corrispondono alle vulnerabilità più importanti che devono essere verificate per ciascuna voce. Ogni vulnerabilità CVE è collegata all’elemento corrispondente del servizio ICAT di indicizzazione delle vulnerabilità del National Institute of Standards (http://icat.nist.gov/). Per ciascuna vulnerabilità ICAT fornisce una breve descrizione, un elenco delle caratteristiche (ad esempio ambito dell’attacco e danno potenziale), un elenco dei nomi e delle versioni dei software vulnerabili e i collegamenti ai bollettini sulle vulnerabilità e alle informazioni sulle patch.

Porte da bloccare a livello di firewall

Alla fine del documento troverete una sezione aggiuntiva che presenta l’elenco delle porte utilizzate dai servizi che vengono comunemente esplorati e attaccati. Bloccando il traffico che passa attraverso le porte di firewall o di altri dispositivi di protezione del perimetro della rete, potete ottenere un livello di difesa aggiuntivo che aiuta a tutelarvi da eventuali errori di configurazione. Tenete comunque presente che, anche se utilizzate un firewall per bloccare il traffico di rete diretto a una porta, essa non è protetta da possibili azioni causate da soggetti che si trovano già all’interno del perimetro, né dall’azione di hacker penetrati utilizzando altri metodi.

top ^

Le principali vulnerabilità per i sistemi Windows

Le principali vulnerabilità per i sistemi Unix

top ^

Le principali vulnerabilità per i sistemi Windows (W)

W1 Internet Information Services (IIS)

W1.1 Descrizione:

IIS è passibile di vulnerabilità in tre grandi categorie: problemi di gestione di richieste inattese, problemi di "buffer overflow" e vulnerabilità legate alle applicazioni di esempio. Ognuna di queste categorie verrà qui brevemente trattata.

  1. Problemi di gestione di richieste inattese. Molte vulnerabilità di IIS sono dovute a problemi di gestione delle richieste HTTP non corrette o volutamente composte in modo anomalo. Un ben noto esempio è la vulnerabilità Unicode sfruttata dal worm Code Blue. Costruendo una richiesta che sfrutti una di queste vulnerabilità, un aggressore può da remoto:

    • Visualizzare il codice sorgente di programmi non compilati.
    • Visualizzare file che si trovano oltre la radice del Web server.
    • Visualizzare file che il Web server non dovrebbe rendere accessibili.
    • Eseguire comandi arbitrari sul server (che possono avere come conseguenza, per esempio, la cancellazione di file di importanza critica o l’istallazione di una backdoor).

  2. Problemi di buffer overflow. Molte estensioni ISAPI (incluse le estensioni ASP, HTR, IDQ, PRINTER, e SSI) sono vulnerabili ai buffer overflow. Un ben noto esempio è la vulnerabilità dell’estensione ISAPI .idq, che viene sfruttata dai worm Code Red e Code Red II. Una richiesta costruita in modo particolare da un aggressore remoto può portare a:

    • Interruzione del servizio.
    • Esecuzione di codice arbitrario e/o di comandi da parte degli account predefiniti del Web server (es. gli account IUSR_nomeserver or IWAM_nomeserver).

  3. Problemi legati alle applicazioni di esempio. Le applicazioni di esempio sono di solito progettate per esemplificare le funzionalità di un ambiente server e non per resistere ad attacchi, e non sono nate per essere applicazioni da utilizzare se non in fase di test. Se a ciò si aggiunge il fatto che è noto a tutti il loro indirizzo di default e che il loro codice sorgente è disponibile per scopo di analisi, si capisce come esse siano gli obiettivi preferiti degli exploit. Le conseguenze di tali exploit possono essere gravi; ad esempio:

    • Una applicazione di esempio, newdsn.exe, permette a un aggressore remoto di creare o sovrascrivere dei file sul server.
    • Alcune di queste applicazioni permettono di vedere da remoto qualsiasi file, e questo fatto può essere sfruttato per raccogliere informazioni come gli user id e le password dei database.
    • Una applicazione iisadmin, ism.dll, permette l’accesso remoto a informazioni riservate del server, tra le quali la password di amministratore.

W1.2 Sistemi operativi interessati

  • WindowsNT 4 (qualsiasi versione) con IIS 4
  • Windows 2000 Server con IIS 5
  • Windows XP Professional con IIS 5.1

W1.3 Riferimenti CVE

CVE-2001-0241, CVE-2001-0333, CVE-2001-0500, CAN-2002-0079, CVE-2000-0884, CVE-2000-0886, CAN-2002-0071, CAN-2002-0147, CAN-2002-0150, CAN-2002-0364, CAN-2002-0149, CVE-1999-0191, CAN-1999-0509, CVE-1999-0237, CVE-1999-0264, CVE-2001-0151, CAN-1999-0736, CVE-1999-0278, CAN-2002-0073, CVE-2000-0778, CVE-1999-0874, CVE-2000-0226, CAN-1999-1376, CVE-2000-0770, CVE-2001-0507

W1.4 Come determinare se siete vulnerabili

Dato l’alto numero di vulnerabilità, e poiché alcune di queste sono corrette solo da pacchetti cumulativi diffusi da Microsoft, è facile prevedere che chiunque non abbia applicato la patch cumulativa sia vulnerabile. Per determinare se sul vostro server sono è stata applicato un certo pacchetto cumulativo, verificate nel registro la voci che corrisponde alla vostra piattaforma nell’elenco seguente.

Windows NT 4:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q319733

Windows NT 4 Terminal Server Edition:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q317636

Windows 2000:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q319733

Windows XP:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q319733

In alternativa potete utilizzare HFNetChk (consultate la voce "Rimanete aggiornati " al paragrafo W1.5) per verificare la presenza della patch corrispondente:

  • NT 4: Q319733
  • NT 4 Terminal Server Edition: Q317636
  • 2000 o XP: Q319733

Siete probabilmente vulnerabili agli exploit che colpiscono le applicazioni di esempio se qualcuno dei file seguenti è presente nella vostra directory %wwwroot%/scripts (es: C:\inetpub\wwwroot\scripts or D:\web\scripts) o in una sua qualsiasi subdirectory:

  • code.asp
  • codebrws.asp
  • ism.dll
  • newdsn.exe
  • viewcode.asp
  • winmsdp.exe

W1.5 Come proteggersi

  1. Applicate le patch più recenti. Nel caso di IIS 4 su NT 4 con Service Pack 6a, ciò significa applicare una patch cumulativa e una hotfix. Nel caso di IIS 5 su Windows 2000 o di IIS 5.1 su XP, la patch cumulativa e la hotfix sono incluse nei service pack. Gli URL relativi sono riportati qui sotto.

    IIS 4 su NT 4:



    IIS 4 su NT 4 Terminal Server Edition:



    IIS 5 su Windows 2000:



    IIS 5.1 su Windows XP:



  2. Rimanete aggiornati. Questi service pack, patch cumulative e hotfix pongono rimedio solo alle vulnerabilità che sono gia note. Non appena vengono scoperte nuove vulnerabilità di IIS, dovrete correggerle di conseguenza. HFNetChk (Network Security Hotfix Checker) è uno strumento che aiuta gli amministratori di sistema ad analizzare i sistemi locali e remoti per verificare che siano state installate le patch più recenti. Questo strumento funziona su Windows NT 4, Windows 2000 e Windows XP. La versione più recente più essere scaricata da Microsoft all’indirizzo http://www.microsoft.com/technet/security/tools/hfnetchk.asp.

  3. Eliminate le applicazioni di esempio. Le applicazioni di esempio, inclusa iisadmin, dovrebbero essere utilizzate solo per verificare che l’istallazione sia corretta e che il server funzioni nel modo atteso, ma una volta compiute queste verifiche dovrebbero essere immediatamente rimosse. Le applicazioni in questione si trovano nella directory %wwwroot%/scripts. L’ideale sarebbe che l’amministratore scegliesse di non installare mai le applicazioni di esempio e gli strumenti di amministrazione Web-based.

  4. Disabilitate le estensioni ISAPI non necessarie. La maggior parte dei sistemi IIS non hanno bisogno di molte delle estensioni ISAPI che sono mappate per default, in particolare di .htr, .idq, .ism, e .printer. Tutte le estensioni ISAPI che non vengono utilizzate dovrebbero essere disabilitate. Ciò può essere compiuto manualmente tramite l’Internet Services Manager oppure automaticamente utilizzando IIS Lockdown Wizard di Microsoft. La versione più recente di quest’ultimo strumento può essere scaricata da Microsoft all’indirizzo http://www.microsoft.com/technet/security/tools/locktool.asp.

  5. Filtrate le richieste HTTP. Molti exploit di IIS, incluse le famiglie di Code Blue e Code Red, utilizzano richieste HTTP composte in modo particolare per operare attacchi Unicode o buffer overflow. Si può configurare il filtro URLScan per respingere tali richieste prima che il server tenti di processarle. La versione più recente di URLScan è integrata nel IIS Lockdown Wizard, ma può essere anche scaricata separatamente da Microsoft all’indirizzo http://www.microsoft.com/technet/security/tools/urlscan.asp.

indice ^

W2 Microsoft Data Access Components (MDAC) -- Remote Data Services

W2.1 Descrizione

Il componente Remote Data Services (RDS) nelle versioni meno recenti dei Microsoft Data Access Components (MDAC) presenta un baco che permette agli utenti remoti di eseguire comandi locali con privilegi da amministratore. Sfruttando il baco assieme a una vulnerabilità nel Microsoft Jet database engine 3.5 (componente di MS Access), un exploit può anche stabilire un accesso anonimo dall’esterno ai database interni. Queste vulnerabilità sono ben documentate e i rimedi sono disponibili da più di due anni, ma i sistemi non aggiornati o mal configurati ne sono ancora esposti e sono ancora soggetti ad attacchi di questo tipo.

W2.2 Sistemi operativi interessati

La maggior parte dei sistemi Microsoft Windows NT 4.0 con IIS 3.0 o 4.0, Remote Data Services 1.5, o Visual Studio 6.0.

W2.3 Riferimenti CVE

CVE-1999-1011

W2.4 Come determinare se siete vulnerabili

Se utilizzate Microsoft Windows NT 4.0 con IIS 3.0 o 4.0, verificate l’esistenza di "msadcs.dll" (di solito questa dll è istallata in "C:\Program Files\Common Files\System\Msadc\msadcs.dll", ma il percorso può cambiare a seconda dei sistemi).

W2.5 Come proteggersi

Una eccellente guida alle caratteristiche delle vulnerabilità RDS e Jet che illustra come correggerle è disponibile all’indirizzo http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2.

Anche Microsoft ha emesso diversi avvisi di sicurezza che descrivono l’exploit e i metodi per proteggersi attraverso alcune modifiche nella configurazione:

In alternativa si può prevenire il problema aggiornando i MDAC alle versioni 2.1 o successive (per quanto talvolta questo aggiornamento possa comportare alcuni problemi di compatibilità). L’ultima versione dei MDAC è disponibile all’indirizzo http://www.microsoft.com/data/download.htm

indice ^

W3 Microsoft SQL Server

W3.1 Descrizione

Microsoft SQL Server (MSSQL) contiene numerose vulnerabilità gravi che permettono ad aggressori remoti di ottenere informazioni riservate, di alterare il contenuto del database, di compromettere i server SQL e, in alcune configurazioni, anche gli host.
Le vulnerabilità di MSSQL sono molto pubblicizzate e ancora sotto attacco. Un recente worm MSSQL, diffusosi nel Maggio 2002, sfruttava numerose vulnerabilità note di MSSQL. Gli host compromessi da questo worm generano un traffico di rete dannoso quando analizzano la rete alla ricerca di altri host vulnerabili. Ulteriori informazioni possono essere reperite agli indirizzi

La porta 1433 (la porta di default di MSSQL) è risultata regolarmente una delle porte più sondate secondo le analisi dell’Internet Storm Center. Maggiori informazioni sulle vulnerabilità di MSSQL scoperte più di recente possono essere reperite nel CERT Advisory 2002-22

W3.2 Sistemi operativi interessati

Qualsiasi sistema Microsoft Windows con installato Microsoft SQL Server 7.0, Microsoft SQL Server 2000 o Microsoft SQL Server Desktop Engine 2000.

W3.3 Riferimenti CVE

CAN-2002-1138, CAN-2002-1137, CAN-2002-0056, CAN-2002-0649, CAN-2001-0542, CAN-2000-1081, CVE-1999-0999, CAN-2002-0624, CAN-2002-0154, CAN-2000-1209, CAN-2002-1123, CAN-2002-0186, CVE-2000-0202, CVE-2000-0402, CVE-2000-0485, CVE-2000-0603, CVE-2001-0344, CVE-2001-0879, CAN-2000-0199, CAN-2000-1082, CAN-2000-1083, CAN-2000-1084, CAN-2000-1085, CAN-2000-1086, CAN-2000-1087, CAN-2000-1088, CAN-2001-0509, CAN-2002-0187, CAN-2002-0224, CAN-2002-0641, CAN-2002-0642, CAN-2002-0643, CAN-2002-0644, CAN-2002-0645, CAN-2002-0650, CAN-2002-0695, CAN-2002-0721, CAN-2002-0729, CAN-2002-0859, CAN-2002-0982

W3.4 Come determinare se siete vulnerabili

Se la chiave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer è definita, significa che sul sistema è installato SQL Server o SQL Server Desktop Engine. Se il vostro sistema non è mai stato corretto o se non lo avete aggiornato con le patch più recenti, molto probabilmente è vulnerabile.
Microsoft ha sviluppato il Microsoft Baseline Security Analyzer (MBSA), che permette di verificare in SQL Server 7.0 e 2000 la mancanza di hotfix o la presenza di vulnerabilità note. MBSA è disponibile all’indirizzo http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp.

Microsoft fornisce anche una guida per aiutare a verificare la versione di SQL: HOW TO: Identify Your SQL Server Service Pack Version and Edition.

Per accertarvi che le correzioni siano installate correttamente, verificate i singoli file analizzando la data e l’ora dei file riportate nel bollettino corrispondente della Microsoft Knowledge Base, agli indirizzi:

W3.5 Come proteggersi

Sommario:

  1. Applicate il più recente service pack per Microsoft SQL server.
  2. Applicate le patch cumulative più recenti rilasciate dopo l’ultimo service pack.
  3. Applicate ciascuna singola patch rilasciata dopo la più recente patch cumulativa.
  4. Rendete più sicuro il server a livello di sistema e a livello di rete.

In dettaglio:

  1. Applicate il più recente service pack per Microsoft SQL server. Le versioni più recenti dei service pack per Microsoft SQL Server sono: Per accertarvi di essere informati sui prossimi aggiornamenti, controllate regolarmente il documento di Microsoft Technet Make Your SQL Servers Less Vulnerable.

  2. Applicate le patch cumulative più recenti rilasciate dopo l’ultimo service pack. La patch cumulativa più recente per tutte le versioni di SQL Server è disponibile all’indirizzo MS02-061 Elevation of Privilege in SQL Server Web Tasks (Q316333/Q327068).

    Per accertarvi di essere informati sui prossimi aggiornamenti, verificate le patch cumulative più recenti per Microsoft SQL Server agli indirizzi:
  3. Applicate ciascuna singola patch rilasciata dopo la più recente patch cumulativa Attualmente non vi sono patch singole rilasciate dopo la MS02-061 Elevation of Privilege in SQL Server Web Tasks (Q316333/Q327068). Per accertarvi di essere informati sui prossimi aggiornamenti, verificate il rilascio di nuove patch singole agli indirizzi:
  4. Rendete più sicuro il server a livello di sistema e a livello di rete.
    1. Una delle vulnerabilità MSSQL più frequentemente attaccate riguarda il fatto che l’account di amministrazione di default (noto come "sa") viene installato con password vuota. Se il vostro account "sa" non è protetto da password, non potete ritenervi sicuri e potete cadere vittima di worm o di altri exploit. Perciò seguite le raccomandazioni raccolte alla voce "System Administrator (SA) Login" in SQL Server Books Online per assicurarvi che l’account "sa" installato abbia una password sufficientemente robusta, e ciò anche se il vostro SQL server non usa tale account.

      Sulla Microsoft Developer's Network è presente la documentazione su come cambiare il login da amministratore (Changing the SQL Server Administrator Login) e su come verificare e cambiare la password di amministratore usando MSDE (Verify and Change the System Administrator Password by Using MSDE).

    2. Eseguite il servizio MSSQLServer e l’SQL Server Agent sotto un account valido di dominio con privilegi minimi, non come amministratore del dominio o con l’account SYSTEM (su NT) o LocalSystem (su 2000 or XP). Se il servizio compromesso viene eseguito con privilegi locali o di dominio permette all’aggressore di ottenere il controllo completo della vostra macchina e/o della vostra rete.

    3. Abilitate l’Autenticazione Windows NT, abilitate la verifica dei login effettuati e falliti e quindi fermate e riavviate il servizio MSSQLServer. Configurate i client in modo che usino l’Autenticazione NT.

    4. Si raccomanda un’azione di packet filtering effettuata a livello perimetrale in modo da bloccare le connessioni che provengono dall’esterno ai servizi non autorizzati all’interno della rete. Il filtering per l’ingresso dalle porte TCP 1433 e 1434 può prevenire l’azione di aggressori esterni che attraverso queste porte possono effettuare scansioni o infettare eventuali server Microsoft SQL vulnerabili residenti nella rete locale che non sono esplicitamente autorizzati a fornire servizi SQL pubblici.

    5. Se i vostri servizi richiedono che le porte TCP 1433 e 1434 debbano rimanere aperte, abilitate e personalizzate il filtering in ingresso e in uscita in modo da prevenire l’uso non corretto di queste porte.
Ulteriori informazioni su come rendere più sicuro Microsoft SQL Server possono essere reperite agli indirizzi

indice ^

W4 NETBIOS - Condivisioni di rete non protette in Windows

W4.1 Descrizione:

Microsoft Windows fornisce alle macchine host la possibilità di condividere con file o cartelle gli altri host tramite le condivisioni di rete. I meccanismi che permettono questa funzione sono il protocollo Server Message Block (SMB) o il Common Internet File System (CIFS). Questi protocolli permettono agli host di operare su file remoti come se risiedessero in locale.

Per quanto questa funzione di Windows sia utile e valida, la configurazione impropria delle condivisioni di rete può mettere in pericolo i file di sistema o può favorire processi che portino utenti o programmi ostili ad ottenere il pieno controllo dell’host. Uno dei metodi tramite i quali il virus Sircam (vedi il CERT Advisory 2001-22) e il worm Nimda (vedi il CERT Advisory 2001-26) si sono diffusi così rapidamente nell’estate del 2001 era proprio quello di scoprire le condivisioni di rete non protette e di replicarsi in queste. Molti possessori di computer aprono inconsciamente i loro sistemi agli hacker quando vogliono favorire i colleghi o i collaboratori esterni condividendo i loro dischi in lettura e in scrittura per gli utenti della rete. Facendo attenzione quando si configura le condivisione di rete, i rischi possono essere adeguatamente mitigati.

W4.2 Sistemi operativi interessati

Windows 95, Windows 98, Windows NT, Windows Me, Windows 2000 e Windows XP sono tutti vulnerabili.

W4.3 Riferimenti CVE

CAN-1999-0519, CVE-2000-0979, CAN-2000-1079, CVE-2000-0044, CAN-1999-0621,
CAN-1999-0520,CAN-1999-0518

W4.4 Come determinare se siete vulnerabili

Per Windows NT (SP4), Windows 2000 o Windows XP, il Microsoft Baseline Security Advisor aiuta a verificare se l’host è vulnerabile e indica come risolvere il problema. Il test di verifica può essere seguito in locale o su un host remoto.

La maggior parte degli scanner di rete disponibili in commercio rilevano le condivisioni aperte. Un rapido e sicuro test gratuito per rilevare la presenza di condivisioni di file SMB e le relative vulnerabilità, valido per macchine che montano qualsiasi versione di Windows, è disponibile al sito Web della Gibson Research Corporation all’indirizzo http://grc.com/. Cliccate su "ShieldsUP" per ricevere una valutazione in tempo reale sulla vulnerabilità SMB per qualsiasi sistema e istruzioni dettagliate per aiutare gli utenti Microsoft Windows ad affrontare le vulnerabilità SMB. Fate attenzione che se siete connessi a una rete nella quale alcuni dispositivi intermedi bloccano, il risultato prodotto da ShieldsUP sarà che non siete vulnerabili mentre, in realtà, lo potete essere. È il caso, ad esempio, di utenti collegati tramite un provider che blocca SMB all’interno della propria rete: in questo caso ShieldsUP riporterà che non siete vulnerabili, mentre in realtà siete esposti ad eventuali attacchi da parte di tutti gli utenti che utilizzano lo stesso provider.

W4.5 Come proteggersi

Per limitare il rischio determinato dalle vulnerabilità sfruttabili attraverso le Condivisioni di rete di Windows si possono intraprendere diverse azioni:

  • Disabilitare le condivisioni quando non sono necessarie. Se l’host non ha bisogno di condividere file, disabilitate le condivisioni di rete nel pannello di controllo della rete di Windows. Se dovete chiudere una specifica condivisione, potete disabilitarla attraverso il menu delle proprietà di Explorer relative alla directory condivisa, attraverso il Server Manager o attraverso il Group Policy Editor.
  • Non permettete condivisioni operate tramite Internet. Controllate tramite il Pannello di Controllo di rete di Windows che tutti gli host connessi a Internet abbiano le condivisioni di rete disabilitate. Lo scambio di file con gli host connessi ad Internet deve essere permesso solo tramite FTP o HTTP.
  • Non permettete le condivisioni senza autenticazione. Se è necessaria la condivisione, configuratela in modo che sia necessaria una password per accedere alla condivisione.
  • Limitate la condivisione solo alle directory strettamente necessarie. Di norma è necessario condividere solo una cartella e, al limite, le relative sottocartelle.
  • Restringete il più possibile i permessi di accesso alle cartelle condivise. Ponete attenzione in particolare a consentire la scrittura solo quando strettamente necessario.
  • Per una maggiore sicurezza, permettete la condivisione solo ad indirizzi IP specifici, poiché i nomi DNS possono essere aggirati.
  • Bloccate le porte utilizzate dalle condivisioni di Windows al perimetro della vostra rete. Bloccate le porte NetBIOS comunemente utilizzate dalle condivisioni di Windows al perimetro della vostra rete usando il vostro router esterno o il vostro firewall per la protezione perimetrale. Le porte che devono essere bloccate sono le TCP dalla 137 alla 139 TCP, le UDP dalla 137 alla 139, la 445 TCP e la 445 UDP.

indice ^

W5 Accesso anonimo - Null session

W5.1 Descrizione:

Una connessione tramite Null session, nota anche come Accesso anonimo, è un meccanismo che consente ad un utente anonimo di ottenere informazioni attraverso la rete (come ad esempio nomi utente e condivisioni) o di connettersi senza autenticazione. Viene utilizzato da applicazioni come explorer.exe per enumerare le condivisioni sui server remoti. Nei sistemi Windows NT, 2000 e XP, molti servizi locali sono eseguiti con l'account SYSTEM, noto su Windows 2000 e XP come LocalSystem. L'account SYSTEM viene utilizzato per varie operazioni critiche di sistema. Quando una macchina ha bisogno di recuperare dati di sistema da un'altra, l'account SYSTEM apre una sessione nulla su questa seconda macchina.

L' account SYSTEM possiede privilegi virtualmente illimitati e non richiede alcuna password, in modo che non ci si possa connettere normalmente come SYSTEM. A volte l’account SYSTEM ha bisogno di accedere ad informazioni presenti su altre macchine come ad esempio condivisioni disponibili, nomi utente e altre funzionalità tipiche delle Risorse di Rete. Poiché non può connettersi agli altri sistemi con UserID e password, utilizza per accedere una Sessione Nulla. Sfortunatamente anche gli aggressori possono connettersi utilizzando una Sessione Nulla.

W5.2 Sistemi operativi interessati

Tutte le versioni di Windows NT, 2000 e XP.

W5.3 Riferimenti CVE

CAN-2000-1200

W5.4 Come determinare se siete vulnerabili

Provate a connettervi al vostro sistema con una Sessione Nulla utilizzando il seguente comando:

net use \\a.b.c.d\ipc$ "" /user:""
(dove a.b.c.d rappresenta l'indirizzo IP del sistema remoto).

Se ricevete una risposta di "connessione non riuscita", il vostro sistema non è vulnerabile. Se non ricevete alcuna risposta significa che il comando è stato eseguito con successo e il vostro sistema è vulnerabile.

Potete anche utilizzare lo strumento "Hunt for NT". Si tratta di un componente dell’NT Forensic Toolkit reperibile presso http://www.foundstone.com/.

W5.5 Come proteggersi

I controller di dominio richiedono sessioni nulle per comunicare. Perciò, se state lavorando in un dominio di rete, potete limitare la quantità di informazioni che può cadere in mano agli aggressori, ma non potete fermarne del tutto la disponibilità. Per limitare la quantità di informazioni disponibili agli aggressori, modificate la seguente chiave di registro:

HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1

Ricordate che qualsiasi modifica al registro potrebbe provocare un malfunzionamento del vostro sistema. Effettuate quindi le opportune verifiche prima di renderle la modifica definitiva. Per semplificare il ripristino del registro, vi raccomandiamo di effettuarne sempre il backup.

L’impostazione di RestrictAnonymous su 1 permette ugualmente la disponibilità di alcune informazioni per gli utenti anonimi, ma la riduce al minimo. Questa è l’impostazione più restrittiva possibile in Windows NT. In Windows 2000 e XP potete invece impostare il valore a 2. Questa azione bloccherà l’accesso degli utenti anonimi a tutte le informazioni con permessi di accesso non esplicitamente assegnati all’utente anonimo o al gruppo Tutti, il quale include anche gli utenti della sessione nulla.

Se non avete bisogno della condivisione di file e stampa, svincolate il NetBIOS dal TCP/IP.

Fate attenzione al fatto che la configurazione di RestricAnonymous sui controller di dominio e su altri server specifici può compromettere molte operazioni normali di rete. Per questa ragione si raccomanda di configurare questo valore solo per le macchine visibili da Internet. Tutte le altre macchine dovrebbero essere protette da un firewall configurato per bloccare NetBIOS e CIFS.

L'accesso ai controller di dominio o ad altri computer non specificamente configurati per l'accesso esterno non dovrebbe essere mai consentito agli utenti Internet. Per fermare tale accesso, bloccate sul router esterno o sul firewall le porte TCP e UDP dalla 135 alla 139 e le porte 445 TCP e UDP.

indice ^

W6 Autenticazione LAN Manager -- Hashing LM debole

W6.1 Descrizione:

Per quanto la maggior parte degli ambienti Windows attuali non necessitino del supporto LAN Manager (LM), Microsoft memorizza per default in locale gli hash delle password legati al LM (noti anche come hash LANMAN) nei sistemi Windows NT, 2000 e XP. Siccome LAN Manager usa uno schema di codifica molto più debole di quelli, più aggiornati, attualmente utilizzati da Microsoft (NTLM and NTLMv2), le password del LAN Manager possono essere violate in brevissimo tempo. Anche le password che in un altro ambiente sarebbero considerate "forti" possono essere violate con sistemi "brute-force" in meno di una settimana.

La debolezza degli hash del Lan Manager deriva dal fatto che:

  • le password sono troncate a 14 caratteri;
  • le password utilizzano lo spazio come carattere di riempimento per raggiungere i 14 caratteri;
  • i caratteri usati nelle password vengono convertiti tutti in caratteri maiuscoli;
  • le password vengono divise in due blocchi di sette caratteri.

Questo processo di hashing comporta che, per ottenere un accesso autenticato al vostro sistema, un eventuale aggressore ha bisogno solo di determinare due semplici password da sette caratteri, che per di più contengono solo caratteri maiuscoli. Siccome la difficoltà nel violare gli hash aumenta con progressione geometrica in proporzione alla lunghezza dell’hash, ciascuna stringa di sette caratteri è almeno di un ordine di grandezza più semplice da attaccare con sistemi "brute-force" rispetto a una stringa di quattordici caratteri. Dal momento che le stringhe sono tutte esattamente di sette caratteri (spazi inclusi) e tutte in caratteri maiuscoli, anche un attacco da dizionario risulta molto semplificato. IL metodo di hashing del Lan Manager rende quindi inefficace qualsiasi buona policy sull’uso delle password.

In aggiunta al rischio dettato dal fatto di avere gli hash collegati a LM memorizzati nel SAM, il processo di autenticazione del LAN Manager è spesso abilitato per default sui client e accettato dai server. La conseguenza è che macchine Windows, in grado di utilizzare hash più robusti, inviano hash LM deboli attraverso la rete, rendendo l’autenticazione di Windows vulnerabile all’intercettazione attraverso packet sniffing e facilitando il compito degli aggressori di recuperare e violare le password degli utenti.

W6.2 Sistemi operativi interessati

Tutti i sistemi operativi Microsoft Windows.

W6.3 Riferimenti CVE

Non disponibili.

W6.4 Come determinare se siete vulnerabili

Se utilizzate un'installazione predefinita di NT, 2000 o XP, siete vulnerabili, perché l’impostazione predefinita prevede il salvataggio in locale degli hash del LAN Manager.

Se nel vostro ambiente avete sistemi operativi che richiedono l’autenticazione LM per comunicare con in server, allora siete vulnerabili perché tali macchine inviano gli hash del Lan Manager attraverso la rete, e questi corrono il rischio di essere intercettati.

I più sofisticati strumenti per la determinazione delle password in ambiente Windows come LC4 (l0phtcrack versione 4, disponibile all’indirizzo http://www.atstake.com/research/lc/download.html) vi mostreranno tutti gli hash trovati nel database SAM (LM, NTLM o NTLMv2), e metteranno in evidenza la possibilità di violare ciascun hash. ATTENZIONE: Non utilizzate mai un password scanner, neanche sui sistemi per i quali avete un accesso da amministratore, senza autorizzazione esplicita e preferibilmente scritta da parte del vostro datore di lavoro. È già accaduto che amministratori di sistema con le migliori intenzioni siano stati licenziati per aver utilizzato strumenti per la determinazione delle password senza autorizzazione.

W6.5 Come proteggersi

  1. Disabilitare l’autenticazione LM attraverso la rete. Il modo migliore per sostituire l’autenticazione LAN Manager in Windows è quello di utilizzare NT Lan Manager versione 2 (NTLMv2). I metodi di verifica/risposta di NTLMv2 eliminano la maggior parte dei difetti del Lan Manager utilizzando crittografia più avanzata e meccanismi di autenticazione e per la sicurezza delle sessioni decisamente migliori. La chiave del registro che controlla questa proprietà per Windows NT e 2000 è:

        Hive: HKEY_LOCAL_MACHINE
    Key: System\CurrentControlSet\Control\LSA
    Value: LMCompatibilityLevel
    Value Type: REG_DWORD - Number
    Valid Range: 0-5
    Default: 0
    

    Descrizione: questi parametri specificano il tipo di 
    autenticazione che sarà utilizzato.
    0 - Spedisce le risposte LM e le risposte NTLM; non usa mai 
    il meccanismo di sicurezza delle sessioni NTLMv2
    1 - Usa meccanismo di sicurezza delle sessioni NTLMv2 se richiesto
    2 - Invia solo l'autenticazione NTLM
    3 - Invia solo l'autenticazione NTLMv2
    4 - DC rifiuta l'autenticazione LM
    5 - DC rifiuta l'autenticazione LM e NTLM (accetta solo NTLMv2)
    Se tutti i vostri sistemi sono Windows NT SP4 o successivi, potete impostare il valore a 3 su tutti i client e a 5 su tutti i controller di dominio, in modo da evitare qualsiasi trasmissione di hash LM in rete. I sistemi di vecchio tipo (come Windows 95/98) non usano NTLMv2 con il Client di rete Microsoft predefinito. Per implementare le funzionalità NTLMv2, installate il Directory Services Client. Una volta installato, la chiave del registro corrispondente è "LMCompatibility," e i valori consentiti sono 0 o 3.

    Se non potete obbligare i vostri client più vecchi ad usare NTLMv2, potete ottenere comunque un certo miglioramento nel sistema di hashing LM forzando NTLM (NT Lan Manager, versione 1) sul controller di dominio (impostate "LMCompatibilityLevel" a 4). Ma l’opzione più sicura riguardo a questi sistemi è quella di passare a sistemi più recenti, dal momento che i sistemi operativi più vecchi non permettono neanche questo minimo livello di sicurezza.

  2. Evitare la memorizzazione degli Hash LM. Un altro problema che si presenta anche qualora si eviti che gli hash LM vengano inviati attraverso la rete è che gli hash vengono comunque creati e memorizzati nella SAM o Active Directory. Microsoft rende disponibile un meccanismo per evitare la creazione degli hash LM, ma solo in Windows 2000 e XP.
    Sui sistemi Windows 2000, la funzione è controllata da questa chiave del registro:

        Hive: HKEY_LOCAL_MACHINE
    Key: System\CurentControlSet\Control\LSA\NoLMHash

    Se questa chiave viene creata in un Controller di Dominio di Windows 2000, gli hash LanMan non saranno più creati e memorizzati nella Active Directory.
    Su Windows XP, la stessa funzionalità può essere implementata impostando questo valore del registro:

        Hive: HKEY_LOCAL_MACHINE
    Key: System\CurrentControlSet\Control\Lsa
    Value: NoLMHash
    Type: REG_DWORD - Number
    Data: 1
    Dopo aver effettuato queste modifiche al registro, è necessario riavviare il sistema in modo che le nuove impostazioni abbiano effetto. NOTA IMPORTANTE: Questa operazione evita solo che vengano generati nuovi hash LM. Gli hash LM esistenti vengono rimossi singolarmente solo quando l’utente modifica la propria password.

I seguenti articoli di Microsoft forniscono alcune utili indicazioni:

indice ^

W7 Autenticazione generica di Windows
    - Account senza password o con password deboli

W7.1 Descrizione:

In quasi tutte le interazioni tra gli utenti e i sistemi informativi vengono utilizzate password, frasi identificative o codici di sicurezza. La maggior parte delle forme di autenticazione, come la maggior parte delle protezioni per file e dati, si basa su password fornite dall’utente. Dal momento che gli accessi correttamente autenticati spesso non vengono registrati, o anche se vengono registrati non lo sono in modo da fornire alcun segnale di allarme, una password compromessa rappresenta un’opportunità di esplorare un sistema dall’interno potenzialmente senza essere identificati. Un aggressore avrebbe accesso completo a qualsiasi risorsa disponibile per quell’utente e sarebbe molto vicino ad essere in grado di accedere ad altri account, a macchine vicine e forse anche ad ottenere privilegi di amministrazione. Nonostante questi pericoli, gli account con password deboli o addirittura senza password rimangono estremamente diffusi e le società con una buona policy sull’utilizzo delle password ancora troppo rare.

Le più comuni vulnerabilità delle password sono dovute (a) ad account senza password o con password deboli, (b) al fatto che, a prescindere dalla robustezza delle password, spesso gli utenti non le proteggono, (c) al fatto che il sistema operativo o il software applicativo creano account di amministrazione con password deboli o privi di password (d) al fatto che gli algoritmi di hashing delle password sono noti e spesso gli hash vengono memorizzati in modo da essere accessibili a chiunque. La difesa migliore e la più corretta contro queste vulnerabilità è una solida policy che includa le istruzioni per creare delle buone password e che riassuma i comportamenti corretti per conservarne la riservatezza, unita a una verifica proattiva dell’integrità delle password.

W7.2 Sistemi operativi interessati

Qualsiasi sistema operativo e applicazione per accedere alla quale gli utenti si autentichino tramite user ID e password.

W7.3 Riferimenti CVE

CAN-1999-0506, CAN-1999-0504, CVE-2000-0222, CAN-1999-0505

W7.4 Come determinare se siete vulnerabili

Per quanto vi siano alcuni sintomi osservabili di una generale debolezza delle password, come la presenza di account attivi appartenenti a utenti che non operano più all’interno dell’organizzazione o a servizi non più attivi, l’unico modo per accertarsi che ogni singola password sia sufficientemente robusta è quello di verificare tutte le password con gli stessi strumenti per la determinazione delle password utilizzati dagli aggressori. ATTENZIONE: Non utilizzate mai un password scanner, neanche sui sistemi per i quali avete un accesso da amministratore, senza autorizzazione esplicita e preferibilmente scritta da parte del vostro datore di lavoro. È già accaduto che amministratori di sistema con le migliori intenzioni siano stati licenziati per aver utilizzato strumenti per la determinazione delle password senza autorizzazione.

I migliori strumenti per la determinazione delle password sono:

W7.5 Come proteggersi

La difesa migliore e la più corretta contro la debolezza delle password è una solida policy che includa le istruzioni su come generare buone password e descriva i comportamenti corretti per mantenerne la sicurezza, assieme ad una verifica proattiva dell’integrità delle password.

  1. Assicuratevi che le vostre password siano sufficientemente robuste. Disponendo di tempi e risorse hardware adeguate, qualsiasi password può essere violata utilizzando il sistema "brute force". Ma ci sono metodi più semplici e molto più efficaci per venire a conoscenza delle password con uno sforzo minore. I password cracker utilizzano metodi conosciuti come “attacchi da dizionario”. Dal momento che i metodi crittografici sono noti, gli strumenti per l’individuazione delle password non fanno altro che confrontare le password in forma crittata con le forme crittate di parole del dizionario (in diverse lingue), di nomi propri, e con le permutazioni di entrambi. Di conseguenza una password la cui radice assomigli in qualche modo a una parola è estremamente suscettibile di essere violata da un attacco da dizionario. Molte organizzazioni insegnano ai propri utenti a generare password che includano combinazioni di caratteri alfanumerici e caratteri speciali, e gli utenti la maggior parte delle volte prendono una parola (ad esempio "password") e convertono le lettere in numeri o caratteri speciali ("pa$$w0rd"). Queste permutazioni non proteggono, però, dagli attacchi da dizionario: "pa$$w0rd" ha la stessa possibilità di essere violata di "password."

    Una buona password, quindi, non deve avere come radice una parola o un nome proprio. Una solida policy sulle password dovrebbe indirizzare gli utenti verso la creazione di password derivate da qualcosa di più casuale, come una frase o il titolo di un libro o di una canzone. Concatenando una stringa più lunga (prendendo la prima lettera di ogni parola o associando alle parole un carattere speciale o togliendo le vocali, ecc.), gli utenti possono generare stringhe sufficientemente lunghe che combinano caratteri alfanumerici e caratteri speciali in modo tale da creare una grande difficoltà ai tentativi di attacco con metodi da dizionario. E in più se la frase è facile da ricordare, lo sarà anche la password.

    Una volta fornite agli utenti le corrette indicazioni su come generare buone password, possono essere messe in opera le procedure per controllare che queste indicazioni vengano seguite. Il modo migliore per farlo è quello di convalidare le password ogni volta che l’utente le cambia, impiegando Passfilt.

    Gli strumenti per la determinazione delle password devono essere utilizzati in modalità stand-alone come parte di un esame sistematico. FATE ANCORA ATTENZIONE: Non utilizzate mai un password scanner, neanche sui sistemi per i quali avete un accesso da amministratore, senza autorizzazione esplicita e preferibilmente scritta da parte del vostro datore di lavoro. È già accaduto che amministratori di sistema con le migliori intenzioni siano stati licenziati per aver utilizzato strumenti per la determinazione delle password senza autorizzazione Una volta ricevuta l’autorizzazione ad utilizzare strumenti per la determinazione delle password sul vostro sistema, attivateli regolarmente su una macchina protetta. Gli utenti le cui password vengono violate devono essere avvisati in modo confidenziale e devono essere fornite loro le istruzioni su come scegliere una buona password. Gli amministratori di sistema e il management dovrebbero sviluppare assieme questo tipo di procedure, in modo tale che il management possa provvedere quando gli utenti non rispondono alle notifiche.

    Un altro modo per proteggersi da password deboli o assenti è quello di utilizzare forme alternative di autenticazione come token generatori di password o sistemi di autenticazione biometrica. Se avete problemi derivati da password deboli, usate quindi metodi diversi per l’autenticazione degli utenti.

  2. Proteggete le password robuste. Anche se le password sono robuste, gli account possono essere ugualmente compromessi se gli utenti non proteggono adeguatamente la propria password. Una buona policy include sempre istruzioni che specificano come gli utenti non devono mai riferire la propria password a nessun’altro, non devono mai trascrivere la password in supporti che possano essere letti da altri e devono rendere adeguatamente sicuro qualsiasi file nel quale sia conservata una password per l’autenticazione automatica (le password sono più facili da proteggere quando questa pratica è utilizzata solo quando assolutamente necessario).

    La modifica periodica della password deve essere fatta rispettare in modo che quelle password che non rispettano queste regole siano vulnerabili solo in una finestra temporale limitata, e deve essere tassativamente vietato che le vecchie password possano essere riutilizzate. Controllate che agli utenti giungano gli avvisi e sia data loro le possibilità di modificare la propria password prima della scadenza. Quando si trovano di fronte a frasi come: "la vostra password è scaduta e deve essere cambiata," gli utenti tendono a scegliere una cattiva password.

  3. Controllate rigorosamente gli account.

    • Qualsiasi account per l’accesso a un servizio e qualsiasi account di amministrazione che non sia più in uso deve essere disabilitato o eliminato. Qualsiasi account per l’accesso a un servizio e qualsiasi account di amministrazione che siano in uso deve essere forniti di una password solida e recente.
    • Verificate gli account presenti sul vostro sistema e create una master list. Non dimenticate di verificare le password su dispositivi come router e stampanti digitali, fotocopiatrici e controller connessi a Internet.
    • Sviluppate procedure per aggiungere account autorizzati alla lista e per rimuove dalla lista gli account che non sono più in uso.
    • Verificate periodicamente la lista per controllare che non siano stati aggiunti nuovi account e che gli account non più in uso siano stati rimossi.
    • Adottate rigide procedure per la rimozione degli account quando i dipendenti o i collaboratori della società non lavorano più lì o quando gli account non sono più necessari.


  4. Implementate una solida policy per le password in azienda. In aggiunta ai controlli a livello di sistema operativo o a livello di rete, esistono degli strumenti completi che aiutano a gestire una buona policy per le password. L’Enterprise Security Manager (ESM) di Symantec è uno strumento di monitoraggio che risiede sull’host che evidenzia qualsiasi cambiamento nella policy, la creazione di nuovi account e verifica la robustezza delle password. ESM inoltre può eseguire tentativi per verificare la violabilità delle password in accordo con la policy attiva nella vostra rete. ESM utilizza un ambiente client-manager: l’agente è posto sui server o sulle workstation e invia le segnalazioni a un gestore centralizzato. Utilizzando una console remota, è possibile vedere i log e possono essere generati dei report sullo stato attuale della situazione. ESM verificherà i log e segnalerà qualsiasi modifica che sia stata fatta dalla situazione di partenza.

indice ^

W8 Internet Explorer

W8.1 Descrizione:

Microsoft Internet Explorer (IE) è il web browser installato di serie sulle piattaforme Microsoft Windows. Tutte le versioni esistenti di Internet Explorer presentano vulnerabilità critiche. È possibile progettare pagine Web che sfruttino queste vulnerabilità sull’Internet Explorer dell’utente che visualizza tali pagine.

Le vulnerabilità possono essere classificate in diverse categorie che comprendono lo spoofing di pagine Web, le vulnerabilità dei controlli ActiveX, le vulnerabilità da Active scripting, l’interpretazione non corretta di MIME-type e di content-type e i buffer overflow. Le conseguenze possono riguardare la rivelazione del contenuto di cookye, file o dati in locale, l’esecuzione di programmi in locale, il download e l’esecuzione di codice arbitrario, fino al controllo completo del sistema vulnerabile.

W8.2 Sistemi operativi interessati

Queste vulnerabilità sono presenti sui sistemi Microsoft Windows con qualsiasi versione di Microsoft Internet Explorer. È importante notare che IE viene installato da una grande varietà di software Microsoft e che quindi è spesso presente su tutti i sistemi Windows, anche sui server per i quali un sistema di navigazione del Web è raramente necessario.

W8.3 Riferimenti CVE

CAN-2002-0193, CAN-2002-0190, CVE-2002-0027, CVE-2002-0022, CVE-2001-0875, CVE-2001-0727, CVE-2001-0339, CVE-2001-0154, CVE-2001-0002

W8.4 Come determinare se siete vulnerabili

Se utilizzate Internet Explorer sul vostro sistema e non avete installato la più recente patch cumulativa, molto probabilmente siete vulnerabili. Se sulla vostra rete è abilitato l’Aggiornamento di Windows, potete verificare sia se IE è effettivamente installato, sia quali patch di Internet Explorer siano presente sul vostro sistema visitando l’indirizzo http://windowsupdate.microsoft.com/. Se sul vostro sistema non è disponibile l’Aggiornamento di Windows, potete utilizzare per la verifica HFNetChk (Network Security Hotfix Checker) o il Microsoft Baseline Security Analyzer (MBSA).

Potete anche andare all’indirizzo http://browsercheck.qualys.com/ per valutare l'effetto di queste vulnerabilità sul vostro sistema.

W8.5 Come proteggersi

Sono disponibili le patch per queste vulnerabilità per le versioni 5.01, 5.5, 6.0 di Internet Explorer. Anche le versioni precedenti di Internet Explorer sono vulnerabili, ma non sono disponibili per queste versioni le patch di alcune vulnerabilità. Se sul vostro sistema è attiva una versione precedente di IE, dovreste prendere in considerazione un aggiornamento.

Se utilizzate IE 5.01 o successivo, iniziate installando il service pack per Internet Explorer più recente. Potete trovare le versioni più aggiornate agli indirizzi:

Dopo aver installato il service pack 2 per IE 5.5 o IE 5.01, dovete anche aggiungere la più recente cumulative security patch (Q323759), che rimedia ad ulteriori vulnerabilità. (Questa patch è già inclusa nel service pack 1per IE 6.) Per maggiori informazioni riguardo le vulnerabilità a cui rimedia questa patch e le modifiche appropriate da apportare alla vostra configurazione per mitigare i rischi, verificare il relativo Security Bulletin e il corrispondente Knowledge Base article.

Ciascuno di questi articoli discute una variante della vulnerabilità cross-site scripting, della quale qualche aspetto non viene completamente risolto dalla patch. Per ulteriori informazioni, andate all’indirizzo http://sec.greymagic.com/adv/gm010-ie/. Di solito è buona prassi disabilitare gli script quando non sono necessari.

Per mantenere protetto il vostro sistema, seguite costantemente le uscite di nuovi aggiornamenti di IE utilizzando Windows Update, HFNetChk, o il Microsoft Baseline Security Analyzer (MBSA). Potete anche ottenere informazioni generali sugli aggiornamenti di IE dalla Internet Explorer Home.

indice ^

W9 Accesso remoto al Registro

W9.1 Descrizione:

Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000 e Windows XP impiegano un database gerarchico centralizzato, meglio conosciuto come Registro, per gestire il software, la configurazione dei dispositivi e le impostazioni degli utenti.
Permessi o impostazioni di sicurezza non corretti possono permettere un accesso remoto al Registro. È possibile sfruttare questo fatto per compromettere il sistema o porre le basi per adattare l’associazione dei file e i permessi in modo da consentire l’esecuzione di codice dannoso.

W9.2 Sistemi operativi interessati

Tutte le versioni di Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000 e Windows XP.

W9.3 Riferimenti CVE

CAN-1999-0562, CVE-2000-0377, CVE-2000-0663, CVE-2002-0049, CAN-2001-0045, CAN-2002-0642

W9.4 Come determinare se siete vulnerabili

L’NT Resource Kit (NTRK) disponibile presso Microsoft contiene un file eseguibile denominato "regdump.exe" che verifica passivamente i permessi per l’accesso remoto al Registro da un host Windows NT verso altri host Windows NT/Windows 2000 o Windows XP attraverso Internet o la rete interna.

Oltre a ciò, è possibile scaricare una raccolta di shell script a linea di comando che verificano i permessi di accesso al vostro Registro, oltre a una serie di altre caratteristiche che riguardano la sicurezza. È disponibile all’indirizzo http://www.afentis.com/top20.

W9.5 Come proteggersi

Per far fronte a questa minaccia, l’accesso al Registro di sistema deve essere limitato e devono essere rivisti i permessi impostati per le chiavi del Registro più critiche. Prima di ottimizzare il Registro, gli utenti di Microsoft Windows NT 4.0 devono anche assicurarsi che sul loro sistema sia già installato il Service Pack 3 (SP3). ATTENZIONE: Le modifiche al Registro di sistema possono comportare seri effetti sulle performance e sull’operatività del computer e, in casi estremi, possono causare danni irreparabili e richiedere la reinstallazione del sistema operativo.

  • Limitate l’accesso dalla rete. Per limitare l’accesso al Registro dalla rete, seguite i passi elencati qui sotto per creare la seguente chiave di Registro: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg
Descrizione: REG_SZ
Valore: Registry Server

    I permessi di sicurezza impostati in questa chiave definiscono gli Utenti o i Gruppi ai quali è permesso l’accesso remoto al Registro. L’istallazione preimpostata di Windows definisce questa chiave e imposta l’Access Control List per fornire pieni privilegi all’Amministratore del sistema e al Gruppo degli Amministratori (e ai Backup Operators in Windows 2000).

    Le modifiche al Registro di sistema richiedono un riavvio per avere effetto. Per creare la chiave di Registro che limita l’accesso al registro:

    1. Avviate l’Editor di Registro ("regedt32.exe" or "regedit.exe") e andate alla seguente sottochiave: 
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
    2. Dal menu "Modifica", selezionate "Nuova Chiave".

    3. Inserite i seguenti valori: 
      Nome chiave: SecurePipeServers
Tipo: REG_SZ
    4. Andate alla seguente sottochiave: 
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers
    5. Dal menu "Modifica", selezionate "Nuova Chiave".

    6. Inserite i seguenti valori: 
      Nome chiave: winreg
Tipo: REG_SZ
    7. Andate alla seguente sottochiave: 
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg
    8. Dal menu "Modifica", selezionate "Nuova Chiave".

    9. Inserite i seguenti valori: 
      Nome valore: Description
Tipo: REG_SZ
Valore: Registry Server
    10. Andate alla seguente sottochiave: 
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg
    11. Selezionate "winreg." Cliccate "Security" e quindi "Permissions." Aggiungete gli Utenti o i Gruppi ai quali volete fornire l’accesso.

    12. Uscite dall’Editor di Registro e riavviate Microsoft Windows.

    13. Se in un momento successivo volete cambiare la lista degli utenti che possono accedere al registro, ripetete i passi 10-12.


  • Limitate gli accessi remoti autorizzati. Applicare limitazioni troppo ristrette sul registro può avere effetti secondari su servizi dipendenti quali il Directory Replicator e il servizio di spooling per le stampanti di rete.

    È possibile aggiungere un grado di granularità ai permessi, aggiungendo il nome di account per il quale il servizio funziona all’access list della chiave "winreg", oppure configurando Windows in modo che ignori le restrizioni di accesso per certe chiavi elencandole nei valori Machine o User sotto la chiave AllowedPaths: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\
winreg\AllowedPaths

Value: Machine
Value Type: REG_MULTI_SZ - Multi string
Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\
CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\
Services\EventlogSoftware\Microsoft\WindowsNT\CurrentVersionSystem\
CurrentControlSet\Services\Replicator
Valid Range: (Un percorso valido a un indirizzo del registro)
Description: Allow machines access to listed locations in the registry
provided that no explicit access restrictions exist for that location.

Value: Users
Value Type: REG_MULTI_SZ - Multi string
Default Data: (none)
Valid Range: (Un percorso valido a un indirizzo del registro)
Description: Allow users access to listed locations in the registry 
provided that no explicit access restrictions exist for that location.

    Nel Registro di Microsoft Windows 2000 e Windows XP: 

    Value: Machine
Value Type: REG_MULTI_SZ - Multi string
Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\
CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\
control\Server ApplicationSystm\CurrentControlSet\Services\Eventlog\
Software\Microsoft\Windows NT\CurrentVersion

Value: Users (non esiste per default)

Per maggiori informazioni, leggete il Microsoft Knowledge Base Article Q153183, How to Restrict Access to NT Registry from a Remote Computer.

indice ^

W10 Windows Scripting Host

W10.1 Descrizione:

Nella primavera del 2000, uno script di Visual Basic (VBScript), il worm "Love Bug" (conosciuto anche come virus "ILOVEYOU"),ha causato danni per milioni di dollari. Questo worm, come gli altri che sono arrivati dopo, sfruttano il Windows Scripting Host (WSH), che permette a qualsiasi file di testo con estensione ".vbs" di essere eseguito come uno script di Visual Basic. Se WSH è abilitato, un tipico worm si propaga includendo un VBScript come contenuto di un altro file che si esegue quando tale file viene visto, in qualche caso anche solo in anteprima.

Anche se gli amministratori devono sempre controllare che applicativi come browser, client di posta o le suite che li contengono siano sempre aggiornati alle versioni più recenti e siano loro applicate le ultime patch, aggiornare queste applicazioni per eliminare la possibilità che siano colpite da un particolare worm è una soluzione non definitiva (non migliore di una semplice reazione) ai rischi derivati dallo scripting. Windows Scripting Host può essere disabilitato senza problemi, compiendo così una mossa preventiva per impedire la proliferazione dei worm.

W10.2 Sistemi operativi interessati

Windows Scripting Host può essere installato manualmente o con Internet Explorer 5 (o successivi) su Windows 95 o NT. È invece installato per default sulle macchine con Windows 98, ME, 2000 e XP.

W10.3 Riferimenti CVE

CAN-2001-1325, CVE-2001-0149

W10.4 Come determinare se siete vulnerabili

Se utilizzate Windows 95 o NT con IE 5 o successivi, o utilizzate Windows 98, ME, 2000 o XP e non avete disabilitato WSH, allora siete vulnerabili.

W10.5 Come proteggersi

  • Disabilitate o rimuovete del tutto Windows Scripting Host, come sottolineato anche nelle istruzioni fornite da Symantec e Sophos.
  • Aggiornate sempre il vostro software Anti-Virus e le relative definizioni. Alcuni Anti-Virus presentano anche un’opzione che blocca gli script.

indice ^

Le principali vulnerabilità per i sistemi Unix (U)

U1 Remote Procedure Call (RPC)

U1.1 Descrizione

Le Remote Procedure Call (RPC) consentono ai programmi di un computer di eseguire programmi presenti su un altro computer passando loro i dati e recuperando i risultati. Le RPC vengono quindi largamente utilizzate in diversi servizi di rete come l’amministrazione da remoto, la condivisione dei file NFS e NIS. Nelle RPC vi sono però diverse imperfezioni che possono essere sfruttate. In molti casi i servizi RPC vengono eseguiti con privilegi di root, facendo di conseguenza correre gravi rischi ai sistemi che presentano vulnerabilità nei servizi RPC che possono portare un aggressore ad ottenere un accesso root non autorizzato da remoto. Ci sono prove convincenti che la maggior parte degli attacchi del tipo "distributed denial of service" verificatisi durante il 1999 ed i primi mesi del 2000 siano stati eseguiti da sistemi vittime delle vulnerabilità RPC. Anche il massiccio attacco riuscito ai danni dei sistemi delle forze armate americane durante l'incidente Solar Sunrise ha sfruttato vulnerabilità dell' RPC riscontrate su centinaia di sistemi del Dipartimento della Difesa.

U1.2 Sistemi interessati:

Quasi tutte le versioni di Unix e Linux istallano automaticamente, e spesso attivano, servizi RPC.

U1.3 Lista CVE:

CVE-1999-0166, CVE-1999-0167, CVE-1999-0168, CVE-1999-0170, CVE-1999-0211, CVE-1999-0977, CVE-1999-0018, CVE-2000-0666, CVE-1999-0002, CVE-2001-0803, CVE-1999-0493, CAN-2002-0573, CVE-2001-0717, CVE-1999-0003, CVE-1999-0019, CVE-1999-0208, CVE-1999-0696, CVE-1999-0693, CVE-1999-0008, CVE-2001-0779, CAN-2002-0033, CAN-2002-0391, CAN-2002-0677, CAN-2002-0679,

U1.4 Come stabilire se siete vulnerabili:

Utilizzate un vulnerability scanner o il comando 'rpcinfo' per verificare se state utilizzando uno dei servizi RPC più comunemente sfruttati:

Servizio RPC Numero programma RPC
rpc.ttdbserverd 100083
rpc.cmsd 100068
rpc.statd 100024
rpc.mountd 100005
sadmind 100232
cachefsd 100235
snmpXdmid 100249

I servizi RPC vengono generalmente sfruttati per attacchi del tipo "buffer overflow", che hanno successo perché i programmi RPC non eseguono un controllo appropriato degli errori o una adeguata convalida degli input. Le vulnerabilità del tipo "buffer overflow" consentono agli aggressori di inviare dati che il programma non si aspetta (spesso in forma di codice dannoso) nello spazio di memoria del programma. A causa dello scarso controllo errori e dell’insufficiente convalida degli input, i dati sovrascrivono le parti di memoria che sono pronte ad essere eseguite dal processore. In un attacco overflow riuscito, questo codice dannoso viene quindi eseguito dal sistemo operativo. Dal momento che molti servizi RPC vengono eseguiti con privilegi di root, sfruttando un di questi servizi è possibile ottenere da remoto un accesso root al sistema non autorizzato.

U1.5 Come proteggersi:

  1. Disattivate o rimuovete tutti i servizi RPC che non sono strettamente necessari all’operatività della vostra rete.

  2. Installate le patch più recenti per tutti i servizi che non potete rimuovere:

    Patch per Sotware Solaris:
    http://sunsolve.sun.com/

    Patch per Software IBM AIX:
    http://www.ibm.com/support/us
    http://techsupport.services.ibm.com/server/fixes

    Patch per Software SGI:
    http://support.sgi.com/

    Patch per Software Compaq (Digital Unix):
    http://www.compaq.com/support

    Patch per Software Linux:
    http://www.redhat.com/apps/support/errata
    http://www.debian.org./security

  3. Verificate regolarmente se il produttore distribuisce nuove patch e installatele immediatamente.

  4. Bloccate la porta RPC (porta 111) a livello di router o firewall perimetrale.

  5. Bloccate le porte RPC di "loopback" 32770-32789 (TCP e UDP).

  6. Nei sistemi operativi che lo permettono, abilitate uno stack non-eseguibile. Anche se uno stack non-eseguibile non protegge da tutti i buffer overflow, può ostacolare lo sfruttamento di alcuni buffer overflow standard pubblicamente disponibili in Internet.

  7. Per i file system esportati in NFS, si può prevedere i seguenti accorgimenti:

    1. Usate una export list basata su host/IP.
    2. Se possibile, impostate il file system esportato come no-suid o per sola lettura.
    3. Utlizzate 'nfsbug' per rintracciare le vulnerabilità.

Potete trovare un documento di sintesi che riporta indicazioni specifiche sulle tre principali vulnerabilità RPC - Tooltalk, Calendar Manager e Statd - all’indirizzo: http://www.cert.org/incident_notes/IN-99-04.html

Si possono reperire documenti che riguardano le specifiche vulnerabilità RPC agli indirizzi:

indice ^

U2 Web Server Apache

U2.1 Descrizione

Gli amministratori di server Web troppo spesso concludono che poichè l’Internet Information Server (IIS) di Microsoft è particolarmente soggetto ad essere violato (vedi W1. Internet Information Server), il web server open-source Apache è completamente sicuro. Per quanto possa essere condivisibile il confronto con IIS, e nonostante Apache goda di una meritata reputazione di sicurezza, ad una attenta analisi anche questo web server non è invulnerabile.

I metodi per violare Apache o i suoi moduli nel recente passato sono state pochi, ma molto ben documentati e velocemente utilizzati in attacchi concreti. Tra i più recenti vi sono:

In definitiva, nessun web server può essere considerato sicuro finché non viene analizzato nel contesto della sua interazione con le diverse applicazioni web, in particolare con i programmi CGI e con i database. Anche una configurazione particolarmente sicura di Apache può permettere l’accesso non autorizzato ai dati se gli script non sono attentamente verificati o i controlli d’accesso ai database non sono correttamente configurati. Gli script CGI vengono eseguiti con gli stessi permessi del web server, e così uno script CGI fatto ad arte o semplicemente scritto non correttamente può essere altrettanto pericoloso di una vulnerabilità nel software di Apache. Sfortunatamente queste debolezze nel back end del web server rimangono problemi di stretta attualità.

È anche necessario rafforzare la sicurezza del sistema operativo per impedire che i contenuti web vengano sottratti o modificati. Per quanto ciò valga per tutti i servizi attivi, il fatto che i servizi web tendano ad avere una esposizione verso l’esterno si presta alla falsa idea che essi ed i dati che proteggono siano in qualche modo indipendenti dal resto del sistema. Quanto l’omissione di questa attività possa rendere vulnerabile un sistema è spiegato su http://www.wired.com/news/technology/0,1282,43234,00.html.

U2.2 Sistemi interessati:

Quasi tutti i sistemi Linux e molti altri sistemi Unix si presentano con Apache pre-installato e abilitato. Tutti i sistemi Unix sono in grado di far girare Apache. (Gli amministratori di Windows devono fare altrettanta attenzione perché la versione di Apache per Windows è ugualmente soggetta alle stesse vulnerabilità o comunque a vulnerabilità simili.)

U2.3 Lista CVE:

CAN-2002-0392, CAN-2002-0061, CVE-1999-0021, CVE-1999-0172, CVE-1999-0266, CVE-1999-0067, CVE-1999-0260, CVE-1999-0262, CVE-2000-0010, CVE-1999-0174, CVE-1999-0066, CVE-1999-0146, CAN-2002-0513, CAN-2002-0682, CAN-2002-0257, CVE-2000-0208, CVE-2000-0287, CVE-2000-0941, CAN-2000-0832, CVE-1999-0070, CVE-2002-0082, CAN-2002-0656, CAN-2002-0655, CVE-2001-1141, CAN-2002-0657, CAN-1999-0509, CVE-1999-0237, CVE-1999-0264

U2.4 Come stabilire se siete vulnerabili:

Controllate quale sia la versione più recente e il più recente livello di patch sul sito di Apache: http://httpd.apache.org/. Se la vostra versione non è la più recente, il vostro server è probabilmente vulnerabile. Su questo sito troverete anche una lista aggiornata delle vulnerabilità più recenti e la documentazione su come determinare se siete affetti da tali vulnerabilità.

U2.5 Come proteggersi:

Le seguenti istruzioni possono aiutarvi a proteggere un web server Apache:

  1. Recuperate da Apache le patch più recenti all’indirizzo http://www.apache.org/dist/httpd/patches/. Se possibile, aggiornate alla versione più recente.

  2. Modificate l’HTTP Response token di default di Apache. Ciò farà in modo che il vostro server Apache restituisca false informazioni nel suo header di risposta, aiutando a nascondere il software del web server. Anche se questa tecnica non impedisce a un determinato aggressore di scoprire quale sia il vostro software, può fare molto per proteggere il vostro web server Apache da worm che innescano il loro codice di attacco basandosi sulle informazioni ricevute in risposta dagli header. Seguite la discussione di Security Focus su come ciò possa proteggere dall’ Apache/mod_ssl Worm descritto nel CERT Advisory CA-2002-27.

  3. Compilate solo i moduli di Apache necessari per il corretto funzionamento del vostro server. Come per un sistema operativo sul quale girano servizi inutili, lo stesso Apache dovrebbe essere ridotto al minimo per diminuire l’esposizione a futuri problemi di sicurezza.

  4. Considerate la possibilità di eseguire Apache in un ambiente chroot(). Per evitare che vengano eseguite con successo le richieste HTTP dannose, un web server dovrebbe essere configurato per inizializzarsi con la funzione chroot() di Unix. Quando un web server parte in chroot, è posto in un ambiente che si potrebbe definire una "Botte di ferro". Da questa configurazione il web server non può accedere ad alcuna parte della struttura delle directory del sistema operativo al di fuori dell’area chroot() definita. Ciascun web server implementa chroot() in modo diverso, e quindi è necessario consultare la documentazione del software specifico per qualsiasi istruzione. Potete comunque trovare ulteriori informazioni nelle WWW Security FAQ.

  5. Non eseguite Apache come root. Create un nuovo utente con privilegi minimi sulla vostra rete e nel database offerto dai vostri servizi web ed eseguite Apache con tale utente. NON usate l’account nobody, perché questo account è utilizzato per mappare l’account di root account su NFS.

  6. Eliminate i contenuti html di default, inclusi i due script CGI test-cgi e printenv. Le vulnerabilità presenti nei contenuti di default sono molto ben conosciute e frequentemente sfruttate negli attacchi.

  7. Da tenere presente nella gestione degli script CGI:
    • Non configurate il supporto CGI sui Web Server che non ne hanno bisogno.
    • Rimuovete tutti i programmi CGI di esempio dai vostri web server operativi.
    • Analizzate gli script CGI che rimangono ed eliminate dai web server qualsiasi CGI non sicuro.
    • Assicuratevi che tutti i programmatori di CGI aderiscano a una rigida policy che prescriva il controllo della lunghezza del buffer di input nei programmi CGI.
    • Controllate che la vostra directory CGI bin non contenga alcun compilatore o interprete.
    • Eliminate lo script "view-source" dalla directory cgi-bin.
    • Configurate il vostro server Apache perché usi il sistema di avvisi che segnala gli errori degli script CGI. Gli amministratori web hanno bisogno di tenere delle tabelle su tutte queste problematiche di sicurezza collegate ai loro web server. Per aiutare in questo monitoraggio, il web server dovrebbe essere configurato per utilizzare pagine per la risposta agli errori CGI che siano personalizzate, in particolare per i codici di errore 401, 403, 413 e 500. Le pagine di errore sono script CGI in PERL che vengono attivati ogni volta che il server riscontra uno di questi codici di errore. Questi script Questi script sovrintendono a molte importanti funzioni come quella di pubblicare un messaggio di avviso per il client e di spedire immediatamente una notifica via e-mail all’Amministratore. Il messaggio e-mail rende automatico il processo di raccolta dal web server delle informazione di sessione correlate alla sicurezza e degli error log.
    • Non permettete l’indexing delle directory. La visualizzazione del contenuto delle directory può fornire ad un aggressore troppe informazioni riguardo alla struttura delle directory del vostro sito e sulle convenzioni che utilizzate nella denominazione dei file.
    • Non usate Server Side Include (SSI). SSI può potenzialmente portare ad usi non autorizzati e fare in modo che il web server esegua codice del sistema operativo che non era stato previsto dallo sviluppatore.
    • Allo scopo di limitare le directory che possono essere servite ai client, non permettete al server Apache di seguire collegamenti simbolici.
    • Create degli script CGI di avviso per l’identificazione di CGI Scanner. Utilizzate uno script CGI di avviso e rinominatelo chiamandolo come uno dei CGI più vulnerabili come: test-cgi, phf, php.cgi, ecc. Quando un CGI Vulnerability scanner viene eseguito contro il vostro web server, esegue questi script che avvisano via e-mail l’amministratore.

  8. Il suggerimento forse più importante di tutti è quello di controllare che il sistema operativo e i servizi che stanno sotto il vostro web server siano rafforzati, o tutti i provvedimenti suggeriti fin qui risulteranno inutili. Seguite ciò che è descritto negli altri punti di questo documento, nelle SANS Consensus Security Guides, e nei Center for Internet Security's Benchmarks.

Per ulteriori informazioni di sicurezza su Apache, consultate http://www.sans.org/Gold/apache.php e http://www.infosecuritymag.com/articles/april01/features1_web_server_sec.shtml.

indice ^

U3 Secure Shell (SSH)

U3.1 Descrizione

Secure shell (ssh) è un popolare servizio per rendere sicuri i login, l’esecuzione di comandi e il trasferimento di file attraverso una rete. La maggior parte dei sistemi utilizza il pacchetto open-source OpenSSH o la versione commerciale di SSH Communication Security. Per quanto ssh sia largamente più sicuro dei programmi di telnet, ftp, e R-command per sostituire i quali è stato progettato, sono state riscontrate diverse falle in entrambi i pacchetti citati. Si tratta per la maggior parte di bachi di minore importanza, ma alcuni costituiscono dei problemi di sicurezza che devono essere riparati immediatamente. Il più pericoloso di questi buchi di sicurezza attivamente sfruttati permette agli aggressori di ottenere da remoto un accesso root alla macchina.

È stato dimostrato che lo stesso protocollo SSH1 è potenzialmente vulnerabile e in certe configurazioni può permettere la decifratura di una sessione in transito. Per questo invitiamo gli amministratori ad utilizzare, quando possibile, il più solido protocollo SSH2.

Oltre a ciò, gli utenti di OpenSSH devono stare attenti al fatto che le librerie OpenSSL sulle quali di solito OpenSSH è installato presentano a loro volta delle vulnerabilità. Leggete i CERT Advisory 2002-23 per maggiori dettagli. Devono stare anche attenti al fatto che, anche se per un breve periodo di tempo, nell’estate 2002 è stata distribuita una versione di OpenSSH che conteneva un trojano. Leggete http://www.openssh.org/txt/trojan.adv per i dettagli e per controllare che non si tratti della versione che state utilizzando.

U3.2 Sistemi interessati:

Qualsiasi sistema Unix o Linux che esegua OpenSSH 3.3 o precedenti, oppure SSH 3.0.0 o precedenti di SSH Communication Security.

U3.3 Lista CVE:

Per ssh di SSH Communication Security:
CVE-2000-0575, CVE-2000-0992, CVE-2001-0144, CVE-2001-0361, CAN-2001-0471, CVE-2001-0553, CVE-2001-0259

Per OpenSSH:
CVE-2000-1169, CVE-2001-0144,