Ese diagrama es muy preciso para XP y anterior. La razón por la que es tan complicado es por los diversos niveles de abstracción involucrados.
Hay dos formas principales (como en "la más utilizada") de iniciar sesión en Windows: como usuario de una estación de trabajo independiente y como miembro de un dominio. En ambos casos, en XP esas credenciales pasan a través del cliente LSA y su servidor.
En el backend, entonces, LSA debe determinar "a quién preguntar" para determinar si las credenciales son realmente válidas. Ahí es donde entra el bloque de "negociación", que hará una de dos cosas:
- Si el sistema está configurado como una estación de trabajo, use el esquema NTLM como está configurado en la caja y hable con la base de datos SAM.
- Si el sistema está configurado como parte de un dominio, hable con el servidor para ver qué es lo que admite, y dele lo que necesita.
En esencia, este proceso no es tan diferente de negociar qué tipo de hash usar para decir un método de autenticación HTTP: el servidor dice lo que quiere (PLAIN, DIGEST, MD5) y le envío la contraseña según sea necesario.
Hay una alusión a otros tipos de credenciales que se ajustan aquí en la forma de "msgina.dll". Este es el componente responsable de hablar con el usuario después de Ctrl + Alt + Delete y se puede reemplazar para proporcionar una nueva interfaz de usuario, como la huella digital y el inicio de sesión con tarjeta inteligente. En cada uno de estos casos, LSA todavía debe hablar con la base de datos backend (donde sea que se encuentre) para obtener un token de autenticación de alguna forma.
También puede agregar protocolos de autenticación adicionales a LSA a través de proveedores de LSA. Este es el componente correspondiente "hablar con la base de datos de autenticación para determinar si se trata de un usuario válido" y puede leer sobre estos componentes aquí e instrucciones sobre cómo escribir uno aquí .
Ahora, una vez completado este proceso, el usuario recibe un token de autenticación llamado token de acceso . Aparte de UAC, presentar este token es la forma en que los procesos indican al sistema que ya están autorizados para actuar en nombre del usuario.
Esto es lo que está sucediendo y cómo LSA y los diversos componentes encajan entre sí.
Ahora, la segunda parte de mi respuesta. Flame apuntó a LSA por dos razones:
- Es estensible. Puede registrar nuevos protocolos de autenticación, nuevos proveedores de GINA / credenciales (XP / Vista + respectivamente).
- Se ejecuta en el arranque del sistema, con
NT AUTHORITY\SYSTEM privilegios.
Esto lo convierte en un lugar maravilloso desde donde lanzar su malware y permanecer persistente en el sistema. Consulte este análisis
Como puede imaginar, hay controles y balances que impiden que cualquier programa antiguo se instale allí e incluso se ejecute allí, mediante Autentodo . Sin embargo, Flame utilizó un certificado robado para evitar esto, que es donde las cosas se pusieron interesantes La información, específicamente el nombre común, contenida en el certificado de autenticodo se muestra como parte del cuadro de diálogo de advertencia de autenticodo. Por lo tanto, en este caso, el malware parece ser creado por "Microsoft Corporation". Una vez que hacen clic en Aceptar y ejecutan Flame con privilegios elevados, tiene todo el acceso que desea. Luego puede registrarse como proveedor de LSA y luego se ejecutará automáticamente cada vez que se inicie el sistema.
