Sperando di vedere al più presto una patch per questa vulnerabilità ho scritto due WSH script che grazie ad una Startup Script Policy permettono di applicare a tutti i computer del dominio il workaround [1] proposto da Microsoft per la vulnerabilità 0day in Windows Help Center (CVE-2010-1885 [2]).
L'urgenza di creare una procedura automatizzata è nata subito dopo aver appreso [3] il fatto che attualmente questa vulnerabilità viene attivamente sfruttata [4] per diffondere malware attraverso pagine web, senza contare il fatto che Metasploit integra già da qualche giorno un apposito modulo denominato ms10_xxx_helpctr_xss_cmd_exec [5]
[6]Il workaround proposto da Microsoft consiste in primo luogo nel disabilitare completamente il protocollo HCP eliminando la chiave di registro "HKEY_CLASSES_ROOT\HCP" dopo averne esportato una copia di backup.
Per automatizzare questa attività ho creato lo script HCP_Protocol_Backup_And_Delete.vbs [7], il quale nello specifico si occupa proprio di esportare la suddetta chiave in un file denominato "NomeComputer_HCP_Protocol_Backup.reg" e poi di rimuoverla se non si verificano errori.
Se ci fosse bisogno di riabilitare il protocollo HCP, magari a seguito dell'applicazione di una apposita patch di sicurezza, sarà sufficiente re-importare il backup precedentemente creato.
Questo secondo passaggio è svolto invece dallo script HCP_Protocol_Restore.vbs [7], il quale dopo aver importato con successo il file di backup denominato "NomeComputer_HCP_Protocol_Backup.reg" si occuperà anche di rimuoverlo.
Le variabili configurabili in HCP_Protocol_Backup_And_Delete.vbs sono le seguenti
- DebugLog, i valori (booleani) accettati sono True e False (Default: False) - abilita o disabilita la creazione di un file di log contenente una serie di informazioni sulle azioni compiute dallo script.
- HCP_ForceExportIfRegFileExists, i valori (booleani) accettati sono True e False (Default: False) - se impostata a "True" ha lo scopo di forzare nuovamente l'esportazione della chiave di registro nel caso in cui non sia stata cancellata con successo da una precedente esecuzione dello script.
- DebugLogPath, identifica tramite stringa di testo la posizione nella quale verrà creato il file di log (Default: "C:\Documents and Settings\All Users") - può essere anche un percorso UNC di una cartella condivisa con diritti di scrittura al gruppo "Authenticated Users".
- RegFilePath, identifica tramite stringa di testo la posizione nella quale verrà creato il file di backup .reg (Default: "C:\Documents and Settings\All Users") - può essere anche un percorso UNC di una cartella condivisa con diritti di scrittura al gruppo "Authenticated Users".
Le variabili configurabili in HCP_Protocol_Restore.vbs sono le seguenti
- DebugLog, i valori (booleani) accettati sono True e False (Default: False) - abilita o disabilita la creazione di un file di log contenente una serie di informazioni sulle azioni compiute dallo script.
- HCP_OverwriteIfRegFileExists, i valori (booleani) accettati sono True e False (Default: False) - se impostata a "True" ha lo scopo di forzare nuovamente l'importazione della chiave di registro nel caso in cui non sia stato cancellato con successo il file di backup .reg da una precedente esecuzione dello script.
- DebugLogPath, identifica tramite stringa di testo la posizione nella quale verrà creato il file di log (Default: "C:\Documents and Settings\All Users") - può essere anche un percorso UNC di una cartella condivisa con diritti di scrittura al gruppo "Authenticated Users".
- RegFilePath, identifica tramite stringa di testo la posizione nella quale verrà creato il file di backup .reg (Default: "C:\Documents and Settings\All Users") - può essere anche un percorso UNC di una cartella condivisa con diritti di scrittura al gruppo "Authenticated Users".
Esempio di log generati dalle due procedure se terminate con successo
[8]
[9]Entrambi gli script possono essere eseguiti tramite una Script Policy di tipo "Startup Script", in questo caso vi consiglio di abilitare la creazione del file di log settando a "True" la variabile "DebugLog" e di sostituire il valore predefinito di "DebugLogPath" con il percorso UNC di una cartella condivisa con diritti di scrittura al gruppo "Authenticated Users"; in questo modo potrete facilmente tenere traccia dell'esito dell'esecuzione avvenuta sui vari computer del dominio.
Di seguito uno screenshot della Group Policy configurata per lo script "HCP_Protocol_Backup_And_Delete.vbs"
[10]Prima di applicare il workaround
Prima di applicare il workaround tenete in considerazione le seguenti informazioni:
Tratto da Microsoft Security Advisory (2219475) [1]
Impact of Workaround: Unregistering the HCP protocol will break all local, legitimate help links that use hcp://. For example, links in Control Panel may no longer work.
Tratto da Full disclosure: Microsoft Windows Help Centre Handles Malformed Escape Sequences Incorrectly [11]
A few caveats,
- I am aware that some support technicians rely on the Remote Assistance
tool provided by the Help Center application using shortcuts like
"explorer.exe hcp://CN=Microsoft%20Corporation,L=Re...". You can continue
to use this technique by substituting "explorer.exe hcp://..." for
"helpctr.exe /url hcp://...", without relying on the protocol handler.- One or two links in explorer, such as selecting "Help" from the Control
Panel category view, may no longer function. If this concerns you, it is
possible to gracefully degrade by replacing the protocol handler with a
command to open a static intranet support page, e.g.
"chrome.exe http://techsupport.intranet";.- As always, if you do not use this feature, consider permanently disabling
it in order to reduce attack surface. Historically, disabling unused
protocol handlers has always proven to be a wise investment in security.