Windows PowerShellIntercettazione del codice dannoso

Don Jones

Ricordi quando Windows Vista era ancora una versione Beta e c'era un grande entusiasmo per la prima versione di un nuovo codice shell della riga di comando definito "Monad"?Si trattava, ovviamente, dell'attuale Windows PowerShell.A quel tempo, fu scritto molto sul "primo virus di Windows Vista".In

realtà, il "virus" era solo uno script malware, un modello di prova denominato "Monad".Per eseguire lo script, sarebbe stato necessario configurare "Monad" in modo specifico, perché con le impostazioni predefinite non avrebbe funzionato.Inoltre, dal momento in cui si sono iniziate a diffondere queste informazioni, Microsoft aveva già annunciato che "Monad" non sarebbe stato fornito con Windows Vista®.In breve, la situazione poteva essere riassunta con il proverbio "tanto rumore per nulla" (o, forse, per poco).

Man mano che Windows PowerShellTM si diffonde (è già stato scaricato oltre un milione di volte), aumenta la probabilità che qualcuno lo utilizzi per creare uno script dannoso.La possibilità di scrivere uno script potenzialmente dannoso in Windows PowerShell è un dato di fatto. È possibile utilizzare qualsiasi strumento di amministrazione a tal fine, compresi Windows PowerShell, cmd.exe e VBSCRIPT.Quindi non si può dare per scontato che un determinato file PS1 sia innocuo.

Fortunatamente, Windows PowerShell è configurato per impostazione predefinita in modo tale da non eseguire tutti gli script, così che qualunque script dannoso richieda sempre l'approvazione dell'utente per essere eseguito.Questo mese, mi piacerebbe immaginare come potrebbe accadere tutto ciò.Con questo non intendo dire che Windows PowerShell non sia un software valido. Penso che Microsoft abbia fatto un buon lavoro progettando una shell di script che evita molti rischi.Tuttavia, vale la pena affrontare questa discussione per far sì che gli utenti siano preparati e pronti a individuare un potenziale attacco.

Protetto per impostazione predefinita

È giusto sottolineare che Windows PowerShell è stato il primo linguaggio progettato da Microsoft dopo la famosa iniziativa Trustworthy Computing.Michael Howard, considerato un guru in materia di tecnologie di protezione (autore del libro Writing Secure Code) era un "amico della protezione" del team di Windows PowerShell.Ha contribuito a rendere più sicura la scrittura del codice e, ancora più importante, a proteggere maggiormente la configurazione della shell.

Per prima cosa, riesaminiamo rapidamente le impostazioni di protezione iniziali di Windows PowerShell.Per impostazione predefinita, la shell non esegue i file con estensione PS1 quando si fa doppio clic su questi ultimi.Tale estensione è associata al Blocco Note.Infatti, per impostazione predefinita, la shell non esegue nessuno script a causa di una funzionalità incorporata, Criteri di esecuzione, che descrive le condizioni in cui viene eseguito uno script.Tale funzionalità è impostata su Con restrizioni per impedire l'esecuzione di tutti gli script e attivare la shell solo per uso interattivo.Le impostazioni di Criteri di esecuzione possono essere modificate utilizzando il cmdlet Set-ExecutionPolicy o tramite un modello amministrativo (file ADM) di Criteri di gruppo fornito da Microsoft.Il file ADM è disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=102940.Nella Figura 1 viene illustrata la funzionalità Criteri di esecuzione che è possibile impostare.

Figura 1 Impostazioni sicure di Criteri di esecuzione

Figura 1** Impostazioni sicure di Criteri di esecuzione **(Fare clic sull'immagine per ingrandirla)

Criteri di esecuzione presenta solo alcune eccezioni.In particolare, anche se è impostata su Con restrizioni, questa funzionalità consente alla shell di importare alcuni file di configurazione XML forniti da Microsoft e installati insieme alla shell.Questi file vengono utilizzati per fornire una funzionalità specifica, come le estensioni ai tipi di Microsoft® .NET Framework e i layout con formattazione predefinita della maggior parte dei tipi di oggetti .NET.Indubbiamente, si tratta dei file che la shell deve caricare all'avvio.

Sebbene questi file possano contenere il codice eseguibile, presentano una firma digitale di Microsoft.La manomissione di tali file rende inutile la firma e, in tal caso, la shell non importa i file all'avvio.Questo progetto rende i file sufficientemente protetti da malware che potrebbero tentare di inserire codice dannoso.

Ovviamente, Criteri di esecuzione, se impostata su Con restrizioni, fa in modo che gli script del profilo di Windows PowerShell non vengano eseguiti all'avvio.Per impostazione predefinita, Windows PowerShell non crea uno script del profilo, ma cerca quattro posizioni specifiche per i nomi di file specifici e, se li trova, tenta di eseguirli a ogni avvio della shell.La documentazione installata con Windows PowerShell fornisce dettagli sui nomi di cartelle e file utilizzati per gli script del profilo.Il profilo è la soluzione agli attacchi di cui parlerò a breve.

Modifica di Criteri di esecuzione

Cmdlet del mese

Set-AuthenticodeSignature è associato a Get-AuthenticodeSignature.Questo cmdlet è stato progettato per esaminare uno script con firma digitale e per fornire dettagli sulla firma.Basta indirizzarlo al file in questione per vedere non solo se il file è stato firmato ma anche se la firma è intatta, quale certificato è stato utilizzato per firmare il file e così via.Oltre a funzionare con gli script di Windows PowerShell, questo cmdlet funziona anche con gli eseguibili firmati, come indicato di seguito:

PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *

Grazie a questo comando, è possibile vedere che l'eseguibile è stato firmato da Microsoft Corp. utilizzando un certificato emesso dall'autorità di certificazione per la firma codice di Microsoft.

Risultati del comando

Risultati del comando  (Fare clic sull'immagine per ingrandirla)

Mi si consenta di sottolineare che in condizioni predefinite è molto difficile, se non impossibile, che Windows PowerShell possa eseguire qualsiasi tipo di codice, tanto meno un codice dannoso.Fino a quando non viene modificata la funzionalità Criteri di esecuzione, è praticamente impossibile che vengano eseguiti script dannosi.È bene chiarire che questo articolo non vuol essere un campanello d'allarme sulle vulnerabilità della protezione di Windows PowerShell; al contrario, contiene alcune procedure consigliate da condividere per mantenere i sistemi protetti.

L'impostazione più permissiva della funzionalità Criteri di esecuzione è Senza restrizioni, che consente l'esecuzione di tutti gli script offrendo fondamentalmente lo stesso scenario inadeguato associato per anni ai file batch e VBScript.Se si imposta la shell su Senza restrizioni, è come se si richiedesse l'esecuzione di uno script dannoso.Se si sceglie l'impostazione Senza restrizioni e viene eseguito uno script che provoca danni, accertarsi di riuscire a giustificare il motivo per cui è stata scelta tale impostazione e prepararsi a confessare la decisione presa quando si dovrà spiegare in che modo un virus è riuscito a demolire l'ambiente in questione.

In realtà, Windows PowerShell cerca comunque di individuare gli script scaricati da Internet e avvisa l'utente prima che vengano eseguiti, anche se è stata scelta l'impostazione Senza restrizioni.Ma il punto è che impostare Criteri di esecuzione su Senza restrizioni non è una buona idea.

Firma degli script

L'impostazione più sicura di Criteri di esecuzione che consente l'esecuzione degli script è AllSigned.Questa impostazione, come suggerisce il nome stesso, esegue solamente gli script che presentano una firma digitale intatta creata mediante un certificato attendibile (solo le firme recenti lo sono).La firma degli script richiede un certificato digitale Class III, in particolare, un certificato di firma codice di Microsoft Authenticode.È possibile ottenere tali certificati dall'infrastruttura a chiave pubblica (PKI) interna dell'azienda, se disponibile, oppure acquistarli da autorità di certificazione (CA) commerciali, come CyberTrust, Thawte e VeriSign.

Se si desidera sapere se sul proprio computer sono installati certificati da utilizzare per firmare gli script, il seguente cmdlet visualizza quanto segue:

Get-ChildItem CERT: -recurse –codeSigningCert

Dopo aver installato il certificato sul computer Windows®, utilizzare il cmdlet Set-AuthenticodeSignature per creare e applicare una firma digitale, che illustra una serie di righe di commenti apparentemente incomprensibili alla fine dello script.Alcuni editor di script possono consentire di applicare una firma a un file di script e di firmare automaticamente gli script man mano che vengono salvati, il che potrebbe risultare utile.

AllSigned è la migliore impostazione di Criteri di esecuzione da utilizzare in un ambiente di produzione.Sebbene non impedisca direttamente la ricezione di script dannosi, garantisce che uno script dannoso venga firmato e che, quindi, venga individuato l'autore (supponendo che i computer Windows siano configurati in modo da convalidare solo le autorità di certificazione attendibili, ma questo argomento non rientra nell'intento di questo articolo).È possibile configurare Windows Script Host (WSH) 5.6 e le versioni successive con un'impostazione simile a TrustPolicy che richiede allo stesso modo le firme digitali, ma ho conosciuto alcuni amministratori che utilizzano questa impostazione.

Di seguito viene fornito un rapido riepilogo di quanto detto finora.Se Criteri di esecuzione è impostata su Con restrizioni, il computer è protetto da script dannosi, ma viene bloccata anche l'esecuzione di script corretti.Se Criteri di protezione è impostata su AllSigned, la shell accetta script firmati, il che garantisce una protezione sufficiente poiché sono pochi gli autori di script dannosi che desiderano far scoprire la propria identità.L'impostazione Senza restrizioni, d'altra parte, è estremamente pericolosa e se la si utilizza è molto facile essere infettati da script dannosi.Si noti che non considero l'impostazione Senza restrizioni una vulnerabilità particolare, ma semplicemente non sicura e, se la si utilizza, quasi sicuramente si sa quello che si sta facendo.

Come intrufolarsi dall'entrata secondaria

Esiste un'altra impostazione di Criteri di esecuzione:RemoteSigned.Penso che questa sia l'impostazione attualmente utilizzata dalla maggior parte degli amministratori, semplicemente perché viene considerata più sicura rispetto a Senza restrizioni e meno problematica di AllSigned.RemoteSigned non richiede una firma per gli script locali.I file PS1 che si trovano nelle unità locali vengono eseguiti senza essere firmati.Gli script remoti, fondamentalmente quelli scaricati da Internet tramite Internet Explorer® o Outlook® (queste applicazioni contrassegnano i file scaricati con un flag speciale), non vengono eseguiti se non sono firmati.

L'impostazione RemoteSigned può fornire, tuttavia, un senso di protezione fasullo.Per cominciare, è facile scaricare script remoti senza applicare flag speciali.I browser non Microsoft, ad esempio, non impostano in genere questo flag, così come la maggior parte dei client di posta elettronica non Microsoft.È importante notare che senza tale flag, Windows PowerShell considera gli script scaricati come se fossero script locali, il che significa che non viene richiesta una firma.Tuttavia, non credo che questo rappresenti una vulnerabilità significativa.Occorre in realtà scaricare lo script, aprire Windows PowerShell ed eseguirlo manualmente.È un abbastanza difficile indurre qualcuno a eseguire tutte queste operazioni, e gli amministratori, che sono in genere gli unici utenti in una rete che dispongono di Windows PowerShell, dovrebbero riconoscere l'inganno.

RemoteSigned offre, tuttavia, una "entrata secondaria" attraverso la quale possono intrufolarsi i malware.Ti ricordi gli script del profilo di Windows PowerShell?Se esistono, a prescindere se siano stati creati dall'utente o da un malware, vengono eseguiti ogni volta che si esegue Windows PowerShell.E con la funzionalità Criteri di esecuzione impostata su RemoteSigned, gli script del profilo, che sono locali, non devono essere firmati.

Di seguito viene riportato questo scenario:

  1. Alcuni malware agiscono sul sistema e creano uno script del profilo della shell o inseriscono il codice dannoso in uno script del profilo esistente.Il malware viene eseguito solitamente nell'account dell'utente collegato, che solitamente dispone dell'autorizzazione per modificare lo script del profilo.
  2. L'utente apre Windows PowerShell, senza rendersi conto che lo script del profilo è stato creato o modificato per contenere codice dannoso.Il codice viene eseguito e il danno è fatto.Il danno è ancora maggiore se si ha l'abitudine di aprire Windows PowerShell con le credenziali di amministratore, una pratica comune quando si utilizza la shell, perché per eseguire qualsiasi attività con la shell sono necessari i privilegi amministrativi.

Mediante il profilo, quindi, è possibile eseguire il codice arbitrario e dannoso senza che l'utente ne sia a conoscenza e l'impostazione di Criteri di esecuzione su RemoteSigned lo consente.

Protezione del profilo

Esiste un solo modo per proteggere il profilo:impostare Criteri di esecuzione su AllSigned.Con l'impostazione AllSigned, è necessario che anche gli script del profilo abbiano una firma digitale, altrimenti, Windows PowerShell non li eseguirà all'avvio.Se gli script del profilo sono stati firmati, una qualsiasi modifica danneggia la relativa firma digitale impedendo l'esecuzione dello script. In tal caso, Windows PowerShell avvisa l'utente del problema all'avvio.AllSigned è di fatto l'unica impostazione sicura di Criteri di esecuzione per gli ambienti di produzione che hanno la necessità di consentire l'esecuzione degli script.

Esiste anche un altro approccio, ma è più complicato e meno affidabile.È possibile creare file di script vuoti per tutti e quattro i file ricercati da Windows PowerShell.Utilizzare un nuovo account utente (che chiamerò "Editor del profilo") per creare questi file e impostare le autorizzazioni NTFS dei file in modo che solo tale account possa modificarli.Gli altri account possono avere accesso in sola lettura.

A questo punto, non accedere mai al computer utilizzando l'account Editor del profilo, se non per modificare il profilo.Con questo approccio, gli account utente normali non possono modificare gli script del profilo.Pertanto, qualunque malware eseguito mentre l'utente è connesso con un account normale non potrà modificare gli script.Cosa accade nell'eventualità che il malware venga eseguito mentre l'utente è collegato come Editor del profilo?Considerando che per modificare gli script del profilo è necessario comunque collegarsi come Editor del profilo, tali modifiche vengono subito rilevate.

È anche possibile estendere la rete di protezione, creando uno script del profilo per tutti gli utenti che viene controllato con autorizzazioni file limitate, come appena descritto.In tale script, scrivere il codice che utilizza il cmdlet Get-AuthenticodeSignature per esaminare le firme digitali sugli altri profili ricercati dalla shell.Fondamentalmente, ciò consente di richiedere le firme sugli script del profilo, senza richiederle per altri script.

Grazie all'impostazione AllSigned di Criteri di esecuzione, tuttavia, è possibile proteggere meglio il profilo.Il mio consiglio è che il computer connesso alla rete abbia la funzionalità Criteri di esecuzione impostata su Con restrizioni, applicata preferibilmente da Criteri di gruppo.In questo modo viene sovrascritta qualsiasi impostazione locale e si garantisce che i nuovi computer del dominio vengano impostati automaticamente per impedire l'esecuzione degli script.I computer sui quali devono essere autorizzati gli script devono disporre di Criteri di gruppo alternativi che impostano Criteri di esecuzione su AllSigned.È necessario applicare una firma digitale a tutti gli script, ma è possibile dormire sereni sapendo che nel proprio ambiente vengono eseguiti solo script attendibili provenienti da autori identificabili.

Don Jones è il guru degli script, lavora presso SAPIEN Technologies ed è coautore di Windows PowerShell:TFM (SAPIEN Press, 2007).È possibile contattarlo all'indirizzo www.ScriptingAnswers.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.