Windows PowerShellPrevención del código malintencionado

Don Jones

¿Recuerda cuando Windows Vista se encontraba aún en versión beta y existía el rumor de una versión muy temprana de un nuevo shell de línea de comandos cuyo nombre en código era "Monad"?Por supuesto, este pasó a ser conocido como Windows PowerShell.En aquel momento, había una gran cantidad de informes en medios convencionales acerca del "primer virus en Windows Vista".En

realidad, el "virus" era simplemente un script de malware de prueba de concepto dirigido a "Monad".Para ejecutar el script, "Monad" en sí mismo habría tenido que ser especialmente configurado; el script no funcionaría bajo determinadas configuraciones.Además, en el momento en que surgieron estos informes, Microsoft había anunciado que "Monad" no formaría parte de Windows Vista®.En resumen, mucho ruido y pocas nueces (o, al menos, muy poquitas).

No obstante, a medida que Windows PowerShellTM se hace cada vez más popular (ya se han efectuado más de un millón de descargas del mismo), aumentan las probabilidades de que alguien lo use para crear un script malintencionado.La capacidad de escribir un script potencialmente peligroso en Windows PowerShell es un hecho: cualquier herramienta de administración (incluidas Windows PowerShell, cmd.exe y VBScript) puede usarse de manera malintencionada.Así pues, no puede dar por hecho simplemente que un archivo PS1 determinado sea inofensivo.

Afortunadamente, Windows PowerShell está configurado para no ejecutar scripts de forma predeterminada, de manera que cualquier script malintencionado necesite ayuda por su parte para poder ejecutarse.Este mes, mi intención es predecir cómo ocurrirá esto.Mi objetivo no es resaltar un aspecto negativo de Windows PowerShell; creo que Microsoft ha realizado un buen trabajo con el diseño de un shell de scripting que evita muchos de estos riesgos.Sin embargo, este tema merece ser discutido simplemente con el fin de ayudarle a estar listo para prevenir este ataque potencial.

Seguridad predeterminada

Hay que tener en cuenta que Windows PowerShell fue el primer lenguaje diseñado por Microsoft tras la famosa iniciativa Trustworthy Computing.El gurú de seguridad Michael Howard (autor del libro Writing Secure Code) se convirtió en el "coleguilla de seguridad" del equipo de Windows PowerShell.Prestó su ayuda a la hora de garantizar que el código escrito fuera lo más seguro posible y, lo más importante, que el shell incluido fuera configurado de la manera más segura posible.

En primer lugar, revisemos rápidamente la configuración de seguridad inicial de Windows PowerShell.De forma predeterminada, el shell no ejecutará archivos con una extensión de nombre de archivo PS1 cuando haga doble clic en ellos.Esta extensión está asociada al Bloc de notas.De hecho, de forma predeterminada, el shell no ejecutará scripts debido a una característica integrada llamada Directiva de ejecución, que describe las condiciones bajo las cuales se ejecutará un script.Se ha configurado como Restricted, lo cual prohíbe que los scripts se ejecuten y habilita el shell únicamente para uso interactivo.La Directiva de ejecución se puede cambiar mediante el cmdlet Set-ExecutionPolicy o a través de una plantilla administrativa de la Directiva de grupo (archivo AMD) suministrada por Microsoft.Puede obtener el archivo ADM en go.microsoft.com/fwlink/?LinkId=102940.La Figura 1 muestra las Directivas de ejecución que puede configurar.

Figura 1** Elección de una Directiva de ejecución segura **(Hacer clic en la imagen para ampliarla)

La Directiva de ejecución tiene sólo unas pocas excepciones.De manera específica, aún cuando se ha configurado en Restricted, permitirá al shell importar algunos archivos de configuración XML particulares proporcionados por Microsoft e instalados junto con el shell.Estos archivos se usan para proporcionar funcionalidad específica, como extensiones para tipos de Microsoft® .NET Framework y diseños de formato predeterminados para la mayoría de los tipos de objetos .NET.Además, se trata de archivos que deseará que el shell cargue definitivamente durante el inicio.

Aunque estos archivos pueden contener y, de hecho, contienen código ejecutable, llevan la firma digital de Microsoft.El modificar uno de ellos de cualquier modo convertiría la firma en inútil y, si eso ocurriera, el shell no importaría los archivos al inicio.Gracias a este diseño, los archivos están muy protegidos frente al malware que pueda tratar de insertar código malintencionado en ellos.

Por supuesto, si la Directiva de ejecución se deja como Restricted, evitará también que sus propios scripts de perfil de Windows PowerShell se ejecuten durante el inicio.Windows PowerShell no crea un script de perfil de manera predeterminada, pero explora cuatro ubicaciones específicas en busca de nombres de archivo específicos y, si los encuentra, intenta ejecutarlos cada vez que se inicia el shell.La documentación instalada junto con Windows PowerShell proporciona detalles acerca de la carpeta y los nombres de archivo que se usan para scripts de perfil.El perfil es la clave de la vulnerabilidad que voy a explicar.

Modificación de la Directiva de ejecución

Cmdlet del mes

El complemento de Set-AuthenticodeSignature es Get-AuthenticodeSignature.Este cmdlet se ha diseñado para examinar un script con firma digital y para ofrecerle detalles acerca de la firma.Simplemente diríjalo al archivo en cuestión y verá no sólo si se ha realizado la firma de un archivo sino, además, si la firma está intacta, qué certificado se usó para firmar el archivo, etc.Además de funcionar con scripts de Windows PowerShell, este cmdlet funciona también con ejecutables firmados, así:

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

Al ejecutar este comando, puedo ver que el ejecutable fue firmado por Microsoft Corp. mediante un certificado emitido por la CA de firma de código de Microsoft.

Resultados del comando  (Hacer clic en la imagen para ampliarla)

Permítame enfatizar que, bajo las condiciones predeterminadas, es muy difícil, si no imposible, conseguir que Windows PowerShell ejecute cualquier código, menos aún código malintencionado.Los scripts malintencionados resultan imposibles hasta que se modifique la Directiva de ejecución.Para ser claro, esta columna no constituye una advertencia acerca de las vulnerabilidades de seguridad en Windows PowerShell; en su lugar, su objetivo es compartir algunos procedimientos recomendados para reforzar los sistemas.

La Directiva de ejecución más baja es Unrestricted, que permite que todos los scripts se ejecuten sin restricción o consulta, y ofrece, esencialmente, el mismo escenario no deseable que se producía con VBScript y los archivos por lotes durante años.Si configura el shell en Unrestricted, facilitará la entrada de scripts malintencionados y sus consecuentes daños.En caso de que seleccione la configuración Unrestricted y de que sufra, consecuentemente, un ataque, asegúrese de ser capaz de justificar por qué seleccionó la configuración Unrestricted y prepárese para apoyar su decisión cuando tenga que explicar cómo pudo entrar un virus en su entorno.

Para ser justos, Windows PowerShell intentará, de todos modos, detectar los scripts descargados de Internet y le advertirá antes de ejecutarlos, aún cuando la configuración sea Unrestricted.Pero lo importante en este caso es que tener una Directiva de ejecución configurada en Unrestricted no es buena idea.

Firma de scripts

La Directiva de ejecución más segura que permite la ejecución de scripts es AllSigned.Esta configuración, sólo ejecuta scripts que llevan una firma digital intacta creada mediante un certificado confiable (no vale una firma cualquiera).La firma de scripts requiere la adquisición de un certificado digital Class III, más específicamente, un certificado de firma de código de Microsoft Authenticode.Dichos certificados pueden obtenerse de la Infraestructura de claves públicas (PKI) interna de su compañía, si tiene una, o adquirirse de entidades de certificación (CA) comerciales, como CyberTrust, Thawte y VeriSign.

Si desea saber si tiene algún certificado instalado en su equipo que se pueda usar para firmar scripts, el siguiente cmdlet le servirá:

Get-ChildItem CERT: -recurse –codeSigningCert

Tras instalar el certificado en su equipo de Windows®, use el cmdlet Set-AuthenticodeSignature para crear y aplicar una firma digital, que se muestra como una serie de líneas de apariencia incomprensible al final del script.Algunos editores de scripts pueden ofrecer la opción de aplicar una firma a un archivo de script, incluida la oportunidad de firmar scripts de manera automática a medida que los guarda, lo cual puede ser muy útil.

AllSigned es la mejor Directiva de ejecución que puede usar en un entorno de producción.Aunque no evita directamente los scripts malintencionados, garantiza la firma de un script malintencionado y, por lo tanto, podría localizar al autor del script (si damos por hecho que sus equipos de Windows están configurados para confiar únicamente en CA confiables, pero este tema escapa al alcance de esta columna).Es interesante cómo Windows Script Host (WSH) 5.6 y las versiones posteriores pueden configurarse con opciones TrustPolicy que requieren también firmas digitales; no obstante, he conocido a pocos administradores que usan esta configuración.

Hagamos una pequeña recapitulación de lo que tenemos hasta ahora.Con una Directiva de ejecución configurada en Restricted, estará a salvo de scripts malintencionados, pero tampoco podrá ejecutar los beneficiosos.Con una Directiva de ejecución configurada en AllSigned, el shell permite scripts firmados, lo cual es bastante seguro, puesto que pocos autores de scripts malintencionados desean la inclusión de una identidad rastreable en su trabajo.La configuración Unrestricted, por otro lado, es muy poco segura y, si la usa, puede esperar con total seguridad ser atacado de manera eventual por algún script malintencionado.Tenga en cuenta que no considero la configuración Unrestricted como una vulnerabilidad particular, pues no presume de ser confiable. Si usa esta configuración, se supone que sabe a lo que se atiene.

Entrada a hurtadillas por la puerta trasera

Existe otra configuración de Directiva de ejecución:RemoteSigned.Esta es la que creo que usan la mayoría de los administradores hoy en día, simplemente porque se percibe como mucho más segura que la configuración Unrestricted y menos molesta que AllSigned.RemoteSigned no requiere una firma para los scripts locales.Los archivos PS1 almacenados en sus unidades de disco locales se ejecutarán sin ser firmados.Los scripts remotos, principalmente aquellos descargados de Internet mediante Internet Explorer® u Outlook® (estas aplicaciones marcan los archivos descargados con un marcador especial), no se ejecutarán a menos que estén firmados.

La configuración RemoteSigned le puede dar, no obstante, un sentido falso de seguridad.Para empezar, es fácil descargar scripts remotos sin tener aplicado el marcador especial.Por ejemplo, los exploradores que no son de Microsoft, normalmente no configuran este marcador, ni tampoco lo hacen la mayoría de los clientes de correo electrónico ajenos a Microsoft.Es importante tener en cuenta que, sin este marcador, Windows PowerShell trata los scripts descargados como locales, lo cual significa que no será necesaria la firma digital.Aún así, no considero esto como una vulnerabilidad importante,ya que tiene que descargar el script, abrir Windows PowerShell y ejecutar manualmente el script.Es bastante difícil persuadir a alguien para que realice todos estos pasos y los administradores, generalmente los únicos usuarios de una red con Windows PowerShell instalado, deberían estar al tanto.

RemoteSigned ofrece, sin embargo, una "puerta trasera" que el malware puede utilizar.¿Recuerda los scripts de perfil de Windows PowerShell de los que hablamos anteriormente?En el caso de que existan, tanto creados por usted como por el malware, se ejecutarán cada vez que se ejecute Windows PowerShell.Y, bajo la Directiva de ejecución RemoteSigned, sus scripts de perfil, que son locales, no necesitan firma.

Este es el escenario:

1. Determinados fragmentos de malware se adentran en su sistema y bien crean un script de perfil de shell o insertan código malintencionado en un script de perfil existente.El malware se ejecuta normalmente bajo su cuenta de usuario de inicio de sesión, la cual disfruta generalmente de permiso para modificar su script de perfil.
2. Al abrir Windows PowerShell, no se da cuenta de que su script de perfil ha sido creado o modificado para incluir código malintencionado.El código se ejecuta y el daño ya está hecho.El daño es peor si tiene la costumbre de abrir Windows PowerShell con credenciales de Administrador, una práctica común porque, cuando se usa el shell, son necesarios privilegios administrativos para realizar cualquier tarea que requiera el shell.

Entonces, el perfil presenta un método para que se ejecute el código malintencionado y arbitrario sin su conocimiento, y la Directiva de ejecución RemoteSigned permite que esto ocurra.

Protección del perfil

Sólo hay una manera correcta de proteger su perfil:usar la Directiva de ejecución AllSigned.Bajo AllSigned, incluso sus scripts de perfil deben firmarse digitalmente; de lo contrario, Windows PowerShell no los ejecutará durante el inicio.Y, si ha firmado sus scripts de perfil, las modificaciones malintencionadas a los mismos interrumpirán sus firmas digitales, dejándoles sin capacidad para ejecutarse; de hecho, Windows PowerShell le advertirá del problema al inicio.AllSigned es realmente la única configuración segura de la Directiva de ejecución para entornos de producción que necesitan permitir la ejecución de scripts.

Hay otro enfoque, pero es más complicado y menos confiable.Puede crear archivos de script de perfil en blanco para cada uno de los cuatro archivos que busca Windows PowerShell.Use una nueva cuenta de usuario (por ejemplo, "Editor de perfil") para crear estos archivos y configurar los permisos NTFS de los archivos para que sólo la cuenta "Editor de perfil" los pueda modificar.Otras cuentas únicamente tendrán acceso de sólo lectura.

Pero recuerde, jamás inicie la sesión en el equipo mediante la cuenta "Editor de perfil" excepto para editar el perfil.Con este enfoque, sus cuentas de usuario normal no podrán modificar los scripts de perfil.Y cualquier malware que se ejecute mientras usa una cuenta normal tampoco podrá modificar los scripts.¿Qué ocurriría si el malware se ejecutara mientras usa la cuenta Editor de perfil?Bien, como ha iniciado la sesión como Editor de perfil para editar los scripts de perfil, advertirá los cambios.

Puede implementar también su propia red de seguridad mediante un script de perfil de todos los usuarios que se controle con permisos de archivo sólidos, como acabo de describir.Dentro de este script, escriba código que use el cmdlet Get-AuthenticodeSignature para examinar las firmas digitales en los otros perfiles que busca el shell.Esto le permite esencialmente requerir firmas en scripts de perfil, sin requerirlas para otros scripts.

Pero la Directiva de ejecución AllSigned es una manera mucho más completa de proteger su perfil.Mi recomendación es que cualquier equipo conectado a su red debe tener una Directiva de ejecución configurada en Restricted, preferiblemente aplicada por Directiva de grupo.Esto omite cualquier configuración local y garantiza que los equipos de dominios nuevos se configuren automáticamente para rechazar los scripts.Los equipos en los cuales deban permitirse los scripts deben tener una Directiva de grupo alternativa que configure la Directiva de ejecución en AllSigned.Tendrá que firmar digitalmente todos los scripts, pero puede estar seguro de que sólo los scripts confiables de autores identificables se ejecutarán en su entorno.

Don Jones es el principal gurú de scripting de SAPIEN Technologies y coautor de Windows PowerShell:TFM (SAPIEN Press, 2007).Puede ponerse en contacto con él en www.ScriptingAnswers.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.