¿Qué hace la configuración de registro EnableLinkedConnections a nivel técnico?

Nota: el problema básico para mí es poder acceder a un recurso compartido de red que yo (usuario administrador de Win 7) configuré cuando ejecuto un programa elevado. Normalmente, el programa elevado no tendrá acceso a mis recursos compartidos de red no elevados.

Según Microsoft, la configuración de registro EnableLinkedConnections permitirá que los procesos elevados accedan al recurso compartido de red del proceso de explorador actualmente conectado (no elevado).

Esta explicación tiene sentido:

[...] Cuando es miembro del grupo de Administradores e inicia sesión, UAC transfiere su cuenta a un usuario no privilegiado. Este contexto de ejecución está completamente separado del contexto que obtiene cuando hace clic con el botón derecho en Símbolo del sistema y se inicia como administrador. Como probablemente habrá notado, las unidades de red conectadas en un contexto no son visibles en el otro. [...]

Este hilo del foro pregunta sobre las vulnerabilidades abiertas por esta configuración. La respuesta proporciona enlaces a un artículo sobre cómo deshabilitar las indicaciones de UAC (o eso entiendo).

La pregunta ahora es, ¿qué hace el ajuste del registro EnableLinkedConnections no o permiten en un sistema Windows 7, ya que estamos no se ejecuta en un entorno de dominio .

Editar: Una cosa que me interesa específicamente es si esta configuración solo afecta la (visibilidad de) las unidades de red o si tiene otras implicaciones.

Al no tener acceso a la fuente de Windows, es difícil decir algo que no sea especulación. Dejando de lado ese descargo de responsabilidad, esto es lo que he podido deducir leyendo esto:

UAC crea dos tokens de seguridad en el inicio de sesión: el token elevado que contiene las membresías de grupo completas del usuario y el token restringido que tiene la membresía del grupo "Administradores" despojado. Cada token contiene un ID único localmente distinto (LUID) que identifica la sesión de inicio de sesión. Son dos sesiones de inicio de sesión separadas y distintas.

A partir de Windows 2000 Server SP2, las unidades asignadas (que se representan como enlaces simbólicos en el espacio de nombres del administrador de objetos) se etiquetan con el LUID del token que las creó (puede encontrar algunas referencias de Microsoft a este comportamiento en este artículo de KBase , y puede Obtenga más información sobre la mecánica de la función en esta publicación de blog ). La esencia de la función es que las unidades mapeadas creadas por una sesión de inicio de sesión no son accesibles para otra sesión de inicio de sesión.

Establecer el valor EnableLinkedConnections activa un comportamiento en el servicio LanmanWorkstation y el subsistema de seguridad LSA (LSASS.EXE) para hacer que LSA copie unidades mapeadas por cualquiera de los tokens de los usuarios en el contexto del otro token. Esto permite que las unidades mapeadas con el token elevado sean visibles para el token restringido y el inverso. No hay ninguna peculiaridad en el comportamiento de esta característica con respecto a un entorno de dominio versus no dominio. Si sus usuarios se ejecutan con cuentas de "Administrador" en un entorno que no es de dominio, sus tokens restringidos y tokens elevados, por defecto, tendrán asignaciones de unidades independientes.

En términos de vulnerabilidad, parece que falta documentación oficial de Microsoft. Encontré un comentario y una respuesta de un empleado de Microsoft preguntando sobre las posibles vulnerabilidades en una conversación sobre UAC de 2007. Dado que la respuesta proviene de Jon Schwartz, quien, en ese momento, se titulaba "Arquitecto UAC", tienden a considerar que su respuesta tiene credibilidad. Aquí está la esencia de su respuesta a la siguiente consulta: "... No he encontrado ninguna información para describir lo que realmente está sucediendo técnicamente o si esto abre algún tipo de lagunas UAC. ¿Puede comentar?"

Técnicamente, abre un pequeño vacío ya que el malware no elevado ahora puede "pre-sembrar" una letra de unidad + mapeo en el contexto elevado, lo que debería ser de bajo riesgo a menos que termine con algo específicamente diseñado para su entorno.

Personalmente, no puedo pensar en una forma de "explotar" esta laguna, en la medida en que "sembrar" el token elevado con un mapeo de unidades aún requeriría que el usuario realmente eleve y ejecute algo malicioso a partir de ese mapeo de unidades "sembradas". Sin embargo, no soy un investigador de seguridad, y es posible que no me esté acercando a esto con una buena mentalidad para encontrar posibles hazañas.

He esquivado el uso del valor EnableLinkedConnections en los sitios de mis Clientes al continuar la tendencia que comenzamos cuando los Clientes comenzaron a implementar Windows NT 4.0: hacer que los usuarios inicien sesión con cuentas de usuario limitadas. Eso funcionó bien para nosotros durante años y continúa funcionando bien en Windows 7.

En pocas palabras, vincula sus credenciales de superusuario con sus credenciales normales. Por supuesto, es más complejo, pero básicamente, incluso su cuenta de "administrador" en Windows 7 no es un administrador, sino que necesita hacer el equivalente de SUDO en Linux para realizar una multitud de operaciones. Cuando asigna una unidad de red, debe hacer esto, pero la unidad de red solo se asigna para el superusuario, no para el usuario normal. Esta configuración de registro vincula las credenciales de superusuario con las estándar con el fin de unidades mapeadas. De esta manera, ambos pueden acceder a la unidad asignada en lugar de solo al superusuario.