Ediciones ENI Editorial | líder en informática
Proteger PowerShell
Introducción
Los tres capítulos anteriores han presentado muchas formas de utilizar PowerShell para introducirse en un sistema de información, desde el reconocimiento con el escaneo de red hasta la exfiltración de datos de la base de cuentas de Active Directory, pasando por las elevaciones de privilegios. Incluso hemos desarrollado un pequeño ransomware, que nos ha permitido introducir las principales nociones básicas de la criptografía moderna.
La conclusión al acabar esta primera mitad del libro puede parecer preocupante. En resumen, un atacante con un simple acceso a una consola PowerShell en un sistema de información, con una configuración estándar, excluyendo la desactivación del antivirus, puede moverse y elevarse con bastante facilidad hasta los privilegios de administrador del dominio. El antivirus ciertamente aportaría una protección adicional significativa, pero solo contra una parte de las amenazas. La evasión antiviral se ha convertido en un verdadero deporte olímpico en los círculos ofensivos, por lo que confiar en esta única protección es, como mínimo, inconsciente, por no decir suicida.
A pesar de esta realidad, ¡no hay que rendirse! Existen soluciones que se pueden implementar para bloquear a un atacante, o al menos entorpecerlo lo suficiente como para tener tiempo de detectarlo y actuar para evitar que cause...
Suprimir PowerShell
1. ¿Desinstalar, desactivar o bloquear?
Una estrategia clásica para mejorar la protección de un sistema de información es reducir la superficie de ataque. Así, un firewall solo permitirá la entrada de los puertos y protocolos necesarios, por ejemplo. Desde esta perspectiva, la primera pregunta que todo administrador debería hacerse es la siguiente: ¿todos mis ordenadores necesitan realmente tener PowerShell?
No hay que olvidar que PowerShell es un framework, con un lenguaje de programación accesible a través de un Shell de línea de comandos. Esto está muy lejos de las funciones utilizadas por el 80 al 99 % de los usuarios. En realidad, la mayoría puede prescindir de él.
A pesar de todo, PowerShell es ahora una parte integral del sistema operativo Windows, y por lo tanto no es posible simplemente desinstalarlo. Sin embargo, se puede utilizar las Directivas de grupo de Windows para bloquearlo.
2. Bloquer PowerShell por GPO
Las Directivas de grupo, o GPO por sus siglas en inglés, son un mecanismo muy práctico y ampliamente utilizado en las infraestructuras de Microsoft. Estas directivas permiten ajustar finamente muchos parámetros de Windows e incluso algunos programas de terceros. De hecho, la desactivación del antivirus en el primer capítulo, se realizó con esta técnica.
Para bloquear PowerShell usando una GPO...
Execution policy
1. Presentación
La estrategia de ejecución, más a menudo llamada execution policy en la práctica, es una configuración de seguridad que tiene como objetivo controlar la ejecución de scripts de PowerShell en un sistema. Esta funcionalidad solo controla la ejecución de los scripts, es decir, los archivos, pero no los comandos en directo en un Shell.
Es interesante aquí diferenciar la seguridad de la protección. Aunque los dos campos a veces se superponen, se trata de conceptos distintos.
Por un lado, la seguridad es la capacidad de un sistema (organización, personas, edificio, sistema de información, etc.) para resistir amenazas, a menudo supuestamente externas. En particular, la seguridad tiene como objetivo asegurar que estas amenazas no dañen el sistema ni realicen acciones no deseadas. Se trata, por lo tanto, de protegerse para evitar que un riesgo se realice, o minimizar sus consecuencias.
La protección, por otro lado, se refiere más a la capacidad del sistema para funcionar a pesar de que el evento temido se produzca. Se trata de las precauciones tomadas en previsión de la realización de un riesgo para asegurarse de que el sistema seguirá funcionando de manera nominal a pesar del problema. Trata, por ejemplo, de la resiliencia de un sistema frente a errores humanos.
A pesar de que existe mucha confusión sobre esta función, la ayuda de PowerShell (abajo) es muy clara sobre el tema. La estrategia de ejecución no es una función de seguridad y es relativamente fácil de eludir, como se muestra a continuación.
get-help about_Execution_Policies PowerShell’s execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts [...]
The execution policy isn’t a security system that restricts user actions [...]
the execution policy helps users to set basic rules and prevents them from violating them unintentionally.
A pesar de todo, sigue siendo necesario configurar una estrategia de ejecución de scripts en su parque: permite agregar una protección contra algunos errores de administración y evitar que todos los usuarios ejecuten scripts no controlados en sus ordenadores (en la práctica, a menudo scripts descargados de Internet).
2. Configuración
a. Local
La execution policy...
Code signing
1. Presentación
La firma de código es una técnica que utiliza la criptografía asimétrica para detectar modificaciones en el código y verificar la información del emisor de dicho código. Esto se basa en las infraestructuras de gestión de claves mencionadas en el capítulo Los atacantes y PowerShell para proporcionar confianza en el programa que se va a ejecutar. También implica confiar en la robustez de las PKI (Infraestructura de Clave Pública) que emiten los pares de claves y certificados que se usarán para firmar los programas.
El mecanismo de firma digital puede representarse de la siguiente manera. Se basa en los conceptos presentados en el capítulo Los atacantes y PowerShell para el cifrado asimétrico. Sin embargo, en la firma, el uso de las claves se invierte: se «cifra» con la clave privada para permitir que cualquiera descifre el mensaje con la clave pública correspondiente (es decir, verificar que el emisor posee la clave privada).
Si bien tradicionalmente se usa más con programas compilados, la firma de código también existe para scripts de PowerShell, aunque el mecanismo de control se basa en la famosa execution policy… Su utilidad es limitada en términos de seguridad, pero sigue siendo una buena práctica. Además, este mecanismo se encuentra de manera mucho más útil en la mayoría de los ejecutables compilados. Finalmente, la mayoría de los antivirus modernos ahora controlan que lo que se ejecuta en un sistema esté debidamente firmado antes de permitir su inicio.
La captura de pantalla siguiente muestra un ejemplo de la información de firma del binario de Visual Studio Code.
Todas estas razones nos llevan a interesarnos por la firma de código, lo que también brinda la oportunidad de establecer una micro-PKI empresarial y adquirir conocimientos en la gestión de certificados.
2. Implementar una Autoridad de Certificación para el código signing
XCA es una aplicación de gestión de certificados X509. Desarrollada principalmente en C++ por Christian Hohnstaedt bajo una licencia de código abierto específica, permite gestionar y rastrear el ciclo de vida de los certificados: generar solicitudes a partir de plantillas, firmarlas, generar...
AMSI
1. Presentación
AMSI (Antimalware Scan Interface) es una plataforma de intercambio que sirve para que las aplicaciones se comuniquen con un antivirus compatible en la máquina. Esta permite que las aplicaciones dialoguen directamente con el antivirus y, en consecuencia, facilita a los antivirus un mejor control sobre lo que sucede en la máquina.
A diferencia de la execution policy, AMSI fue diseñado como un mecanismo de seguridad. Introducido a partir de Windows 10 (2015), AMSI se utiliza principalmente en forma de API (Access Programming Interface) por desarrolladores de aplicaciones para interactuar con el antivirus en la estación; pero también por los editores de antivirus para admitir de la mejor manera posible las características ofrecidas por este mecanismo.
Volviendo a PowerShell, la dificultad para asegurar un Shell radica en que un usuario puede introducir prácticamente cualquier comando. Por lo tanto, es imposible utilizar un modelo de firma en archivo estático convencional. El análisis de comportamiento (por ejemplo, detectar que el script descarga código y luego lo ejecuta antes de intentar elevar sus privilegios) también es difícil debido a las duraciones de las sesiones de scripting y la posible complejidad de las entradas. AMSI intenta abordar estos problemas. Permite que una aplicación (PowerShell u otro programa) envíe contenido (archivo, texto, bloque de memoria, URL, IP, etc.) al antivirus a través de una API. El siguiente esquema ilustra su implementación en el sistema operativo Windows.
Algunas aplicaciones nativas en Windows integran AMSI en su funcionamiento:
-
El UAC (User Account Control), que gestiona las elevaciones de privilegios de los programas.
-
Windows Script Host (wscript.exe y cscript.exe), que es el intérprete de VBScript, considerado como el precursor de PowerShell... incluso si todavía se encuentran muchos scripts .vbs en los entornos informáticos actuales.
-
jScript y JavaScript, presentes en los motores de Microsoft (Edge, IE). Actualmente, existen extensiones para Firefox y Chrome, pero AMSI no está integrado nativamente en estos navegadores.
-
Office VBA macros, a través de las diversas aplicaciones de Microsoft Office.
-
Carga de Assembly .NET.
-
Llamadas a WMI (Windows Management Instrumentation).
-
Y para terminar PowerShell, para los scripts...
Conclusión
En este capítulo, hemos visto algunos mecanismos de protección existentes y nativos en PowerShell. Es importante tener en cuenta que, si bien el bloqueo puro y simple de PowerShell no es una solución utilizable en todas partes, sigue siendo una opción viable para ciertos alcances de un entorno informático (por ejemplo, entornos muy expuestos o sensibles).
La execution policy que veremos a continuación no es un mecanismo de seguridad en sí, pero sigue siendo interesante de implementar para mejorar la conformidad del entorno, limitar los errores de administración y dificultar el trabajo de los atacantes al obligarlos a sortear este mecanismo adicional. La execution policy también ha permitido abordar el tema de la firma digital de scripts PowerShell, particularmente en el contexto de la gestión de certificados empresariales con las PKI. Este tema a menudo es mal comprendido y a veces implementado de manera aproximada en las empresas. Por esta razón, nos ha parecido interesante desmitificarlo aquí.
La última parte del capítulo se ha centrado en la Interfaz de Escaneo Antimalware (AMSI) de Windows, que protege a PowerShell. A pesar de algunas limitaciones y una adhesión parcial de los antivirus en el mercado, finalmente brinda una protección real a los scripts PowerShell ejecutados únicamente en memoria y al uso interactivo de la consola PowerShell....