Hace mucho tiempo, cuando el césped era más verde e Internet más seguro, nació la iniciativa Web Based Enterprise Management (WBEM) en TI. Originalmente patrocinado en 1996 por compañías como Cisco Systems, Intel y Microsoft, ha sido ampliamente adoptado e implementado en plataformas que van desde MAC OS hasta Redhat. WBEM está claramente documentado, basado en estándares de Internet, y proporciona un enfoque de gestión de sistemas diferente al de SNMP, por ejemplo.
La adaptación de WBEM para Windows se llama WMI (interfaz de administración de Windows) y se introdujo por primera vez en Windows XP. Sabemos que los sistemas se actualizan más rápido que sus componentes, y muchas vulnerabilidades que antes eran una herramienta de administración conveniente migran de una versión a otra. En este artículo, quiero describir cómo se realizan las tareas de WMI y cómo evitar riesgos potenciales.
Debido a su poder, WMI permite usar utilidades o scripts especiales para realizar varias acciones potencialmente peligrosas en la PC, incluida la detención de servicios críticos e incluso el apagado de la computadora. Por ejemplo, así:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges) .Win32Shutdown (5)
(GWMI -Class Win32_Service -Filter "name = 'WinRM'" -ComputerName Server) .StopService ()
Además, realice las mismas acciones en la máquina remota al igual que en el local, simplemente escriba el nombre de la máquina requerida en la ruta al objeto WMI.
El espacio de nombres de WMI es una sección del repositorio de WMI que está diseñada para agrupar clases y objetos de WMI por propósito, además de definir atributos de seguridad al acceder a clases y objetos en cada contenedor. Todos los espacios de nombres comienzan con una raíz, que se indica con la palabra clave raíz en WMI. El espacio de nombres va seguido de una barra después del nombre raíz. Los espacios de nombres se pueden anidar. La mayoría de las clases y objetos interesantes se encuentran en el espacio de nombres root / CIMv2.
Uno de los espacios de nombres WMI de Windows existentes se puede seleccionar como predeterminado. Esto significa que si intenta conectarse a este host sin especificar un espacio de nombres, automáticamente se conectará al seleccionado de forma predeterminada. En una instalación estándar de Windows, el espacio predeterminado es root \ cimv2.
La tecnología WMI está diseñada para administradores de Windows, y todo el sistema de seguridad en WMI está diseñado para que, utilizando scripts WMI, un usuario en una PC determinada pueda realizar solo aquellas acciones para las que se le han otorgado permisos / privilegios. Estos son los llamados privilegios predeterminados. Así es como se implementa la seguridad WMI en el nivel del sistema operativo: si el usuario en el nivel del sistema operativo no tiene el privilegio de reiniciar la computadora, entonces, usando WMI, tampoco podrá hacerlo.
Las políticas de seguridad adicionales en WMI se implementan en el nivel de espacio de nombres del protocolo COM distribuido (DCOM), un modelo de objeto de componente distribuido. Para ver más de cerca estos tipos de seguridad WMI, recordaré brevemente los conceptos generales básicos relacionados con la seguridad en Windows. Y esta seguridad se basa en los nombres de usuario y sus contraseñas.
Acerca de los permisos de WMI
Cuando se crea un usuario en Windows, a su cuenta del sistema se le asigna un identificador de seguridad único (Identificador de seguridad o SID). En base al SID, se genera un Access Token para el usuario, al que también se le agrega la lista de grupos de los que el usuario es miembro y la lista de privilegios que tiene (por ejemplo, detener servicios o apagar la computadora). Este token de acceso también se asigna a todos los procesos que inicia el usuario. En este momento, cada objeto del sistema operativo, cuyo acceso está determinado por el sistema de seguridad (un archivo, un proceso, un servicio u otra cosa) tiene un Descriptor de seguridad (SD). Este descriptor, a su vez, almacena la Lista de control de acceso (ACL) para este objeto.
Entonces, cuando un usuario o un proceso iniciado por él accede a un objeto, el token de acceso de este usuario se compara con la lista de control de acceso. Dependiendo de los resultados, se otorga o deniega el permiso / privilegio para realizar las acciones solicitadas en el objeto.
A nivel de espacio de nombres, el mecanismo de seguridad de WMI sigue el modelo de seguridad general de Windows. Cada espacio de nombres puede tener su propio descriptor de seguridad que almacena una lista de control de acceso (ACL).
Cada entrada de Entrada de control de acceso (ACE) contiene información sobre los permisos que tiene un usuario en particular cuando realiza varias operaciones en ese espacio de nombres.
Y aquí está la lista de permisos cuando se trabaja con el espacio de nombres:
Ejecutar métodos. Permite llamar a métodos de clases desde un espacio de nombres específico. Si el método tiene éxito o falla depende de si el usuario tiene permiso para realizar la operación en el sistema.
Escritura completa. Permite la creación y modificación de subnombres, clases de sistema e instancias de clases.
Escritura parcial. Abre la capacidad de crear y modificar clases estáticas e instancias de clases que no son del sistema.
Escritura del proveedor.Le permite consultar las clases de proveedor de WMI y las instancias de esas clases en el repositorio de CIM.
Habilitar cuenta. Otorga acceso de lectura al espacio de nombres WMI. Los usuarios con este permiso pueden ejecutar scripts en la computadora local que leen datos WMI.
Habilitar de forma remota (habilitación remota). Permite a los usuarios acceder al espacio de nombres WMI en una computadora remota. De forma predeterminada, solo los administradores tienen este permiso; los usuarios estándar no pueden recuperar datos WMI de máquinas remotas.
Leer seguridad. Otorga el derecho a leer el descriptor de seguridad del espacio de nombres WMI sin modificaciones.
Cambiar las reglas de seguridad (Editar seguridad). Le permite cambiar el descriptor de seguridad para el espacio de nombres WMI.
Todas estas entradas de ACL se almacenan en el repositorio de WMI. Los permisos de WMI para un espacio de nombres en particular se aplican a todos los subespacios y clases que están definidos en ese espacio de nombres (heredados de). No puede definir sus propios permisos de seguridad para una clase de WMI individual.
Acerca de la configuración predeterminada
En Windows, el grupo Administradores tiene todos los permisos de la tabla anterior, y para otros usuarios la cuenta está habilitada ( Habilitar cuenta ), se le permite llamar a métodos ( Ejecutar métodos ) y escribir instancias de clases de proveedor en el CIM ( Escritura de proveedor ).
Un administrador puede cambiar los permisos de usuarios específicos mediante la utilidad de configuración de WMI (complemento wmimgmt.msc de la Consola de administración de MMC).
Captura de pantalla 1.
El protocolo DCOM anterior se utiliza para acceder a la infraestructura WMI en una computadora remota. El usuario ejecuta un script o se conecta a WMI mediante utilidades especiales y actúa como cliente, y el objeto WMI al que se accede es el servidor. Los niveles de suplantación de DCOM estándar se utilizan para determinar qué token de acceso se utilizará cuando se trabaja con WMI en una computadora remota.
Acerca de la suplantación de identidad o los niveles de suplantación de identidad
En ruso suena algo torpe. ¿Qué es la suplantación y por qué es necesaria? Esta es una técnica en la que un proceso o sistema debe utilizar las credenciales de otro principal de seguridad, en lugar de su propio contexto de seguridad, para conectarse a un recurso.
Imagínese: un determinado servicio lanzado en el contexto de seguridad de LocalSystem debe realizar una acción en nombre de otra cuenta (por ejemplo, en nombre del usuario actual que inició sesión en la computadora). En este caso, el servicio necesita crear un token de acceso especial que describa el contexto de seguridad de la cuenta bajo la cual queremos realizar la acción especificada.
Para crear dicho token de acceso, el servicio necesita conocer las credenciales de este usuario y, si este proceso ocurre en la máquina local, obtener una copia del token de acceso del usuario local previamente registrado.
Para hacer esto, el contexto de seguridad del servicio debe tener el privilegio de crear tokens de acceso.
Existe una versión más compleja de suplantación: delegación. Esta opción es necesaria cuando la conexión al recurso de destino no la realiza el principal de seguridad en sí (en el ejemplo anterior, el servicio en nombre del usuario), sino a través de un intermediario (por ejemplo, un servidor intermedio).
Imagínese: un usuario se conecta no directamente a la base de datos, sino a través de una aplicación web en un tercer servidor. Para realizar dicha conexión, la aplicación web debe recibir un token de acceso delegado del principal de seguridad (nuestro servicio); esto permitirá que la aplicación web utilice el token de acceso del principal de seguridad cuando se conecte a la base de datos.
En el caso de WMI, la delegación puede verse así: nosotros, trabajando en la estación del administrador, nos conectamos a través de WMI a un determinado servidor e iniciamos un proceso en él usando el método Execute de la clase Win32_Process. Este proceso no es más que otro script WMI que se conecta a otro host en la red para realizar alguna acción. Si no usamos la delegación, en la máquina de destino, el script se lanzará en el contexto de seguridad de la cuenta del servidor intermedio, lo que está lejos de ser siempre deseable. Por otro lado, una situación similar con la delegación en la vida real ocurre muy raramente.
Acerca de los niveles de suplantación de identidad
Acceso anónimo (Anónimo). El objeto servidor no tiene derecho a obtener información sobre el usuario o proceso que accede a este objeto (en otras palabras, el objeto no puede hacerse pasar por el cliente). Este nivel de suplantación no se usa en WMI.
Identificación. El objeto de servidor puede solicitar un token de acceso asociado con el cliente, pero no puede suplantar.
Este nivel de suplantación rara vez se utiliza en los scripts de WMI, en cuyo caso no puede ejecutar los scripts de WMI en máquinas remotas.
Personificar.El objeto de servidor puede utilizar todos los derechos y privilegios que tiene el cliente. Se recomienda que utilice este nivel de suplantación en los scripts WMI, porque entonces el script WMI en la máquina remota podrá realizar todas las acciones que el usuario que ejecuta el script puede realizar.
DelegarUn objeto en un servidor al que está accediendo un cliente puede hacer referencia a otro objeto en un servidor diferente en nombre del cliente. La delegación permite que un script utilice el token de acceso del usuario que lo ejecuta en la máquina remota. El mismo token se utiliza para acceder a objetos WMI en otras estaciones de trabajo. Existe un riesgo potencial con este nivel de suplantación; la delegación en scripts WMI solo debe usarse cuando sea estrictamente necesario.
El nivel de suplantación predeterminado depende de la versión de WMI en el equipo de destino. En las versiones de WMI inferiores a la 1.5, el nivel predeterminado es Identificar, en las versiones de WMI 1.5 y superiores - Suplantar. Si es necesario, puede cambiar el nivel de suplantación predeterminado escribiendo el nombre del nivel requerido (por ejemplo, suplantar o delegar) en la clave de registro
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Wbem \ Scripting \ Default Impersonation Level .
Captura de pantalla 2.
El protocolo DCOM también brinda la capacidad de solicitar un nivel específico de autenticación (autenticación) y privacidad para una conexión WMI:
Ninguno. Sin autenticacion.
Por defecto (predeterminado). La configuración de seguridad estándar se utiliza para seleccionar el nivel de autenticación. Este es el nivel recomendado porque al cliente se le asignará el nivel de autenticación especificado por el servidor.
Conexiones (conectar). El cliente solo se autentica cuando se conecta al servidor. Una vez establecida la conexión, no se realizan comprobaciones adicionales.
Llamadas. El cliente se autentica al comienzo de cada llamada, mientras que el servidor acepta solicitudes. En este caso, los encabezados de los paquetes están firmados, pero los datos en sí (el contenido de los paquetes) transmitidos entre el cliente y el servidor no están firmados ni cifrados.
Paquete (Pkt).Todos los paquetes de datos que provienen de los clientes al servidor están autenticados. Al igual que con la autenticación a nivel de llamada, los encabezados de los paquetes están firmados pero no cifrados. Los paquetes en sí no están firmados ni encriptados.
Integridad del paquete (Pktlntegrity). Todos los paquetes de datos se verifican para verificar su autenticidad e integridad. Se comprueba que el contenido del paquete no se haya modificado durante la transferencia del cliente al servidor. En este caso, los datos están firmados, pero no cifrados.
Privilegios (PktPrivacy). Todos los paquetes de datos se verifican para verificar su autenticidad e integridad, y los datos están firmados y encriptados para garantizar la confidencialidad de los datos transmitidos.
Los administradores de Windows conocen bien la configuración de seguridad del sistema disponible en la Consola de seguridad del sistema y las Políticas de grupo de dominio y la sección Asignaciones de derechos de usuario. Varias acciones con el sistema operativo pueden realizarse solo si el usuario o grupo al que pertenece tiene uno u otro privilegio. Tales acciones, por ejemplo, incluyen: reiniciar el sistema (apagar su trabajo), restaurar el estado del sistema desde una copia de seguridad o cambiar la hora del sistema.
Debido a que WMI puede realizar todas estas acciones, los desarrolladores de WMI han proporcionado un mecanismo de seguridad adicional: incluso si una cuenta de usuario tiene los privilegios necesarios para operar en el sistema, aún no puede realizar esta acción hasta que active explícitamente el privilegio antes de realizar la acción. En particular, si un administrador ejecuta un script WMI solicitando un reinicio del sistema, esto no sucederá hasta que este privilegio se active explícitamente en el script.
Resumen
Qué se sugiere hacer para garantizar la seguridad de las conexiones WMI:
- Cambie el nivel de suplantación de identidad para servicios críticos (captura de pantalla 2).
- Configure los permisos wmimgmt.msc (captura de pantalla 1).
- Cambie el repositorio predeterminado. Esto puede romper el escenario de ataque de patrón.
4. Cambie los grupos de personas con funciones de activación de WMI y de inicio remoto mediante la utilidad DCOMCNFG.
5. Para iniciar WMI, un usuario debe ser miembro del grupo de administradores o usuarios de DCOM. El servicio de registro remoto también debe estar disponible.
6. Configure el firewall: las conexiones entrantes a DCOM pasan por el puerto TCP 135 y (¿tienen?) Rango dinámico RPC.
En conclusión, quiero decir lo siguiente: WMI brinda velocidad, potencia y facilidad para ejecutar comandos en hosts remotos, y la semántica de comandos basada en SQL hace que sea fácil de aprender.
Hay mucha información en Internet sobre piratería y ataques WMI, porque encajan en la tendencia actual de ataque (el uso de herramientas nativas de piratería del sistema) junto con Telnet NTP y DNS. Nuestra tarea es captar esta tendencia y encontrar métodos de contraataque ya integrados en el sistema.
Autor: Galiulin Timur GTRch