Evitando que LSASS almacene contraseñas de texto simple en el entorno Kerberos

Navega tus respuestas
9

Es un riesgo de seguridad bien conocido que LSASS almacena contraseñas de texto claro si un usuario ha realizado un inicio de sesión con teclado interactivo en una máquina, ya sea un inicio de sesión local en su estación de trabajo o utilizando RDP en una estación de trabajo remota.

También hay una solución clásica para esto: deshabilitar wdigest y tspkg. Hasta ahora todo bien, pero si se admite Kerberos, entonces aparentemente se necesita una contraseña de texto simple para renovar el Ticket Granting Ticket (TGT) y, por lo tanto, queda entre un lugar difícil y difícil. No apoye a Kerberos y disfrute de todo. Los riesgos asociados con el hash que pasa o admiten Kerberos y aceptan el riesgo de las contraseñas de texto ordenado. La publicación vinculada da los siguientes consejos, que creo que son inaceptables:

  

Por lo tanto, la protección más efectiva es evitar interactivos.   Inicia sesión en cualquier host que no sea de confianza.

Una gran empresa tiene miles de servidores, ¿cómo sabe cuál está comprometido y se debe evitar el inicio de sesión?

Mi pregunta: ¿existen otras medidas prácticas aparte de implementar un 2FA (sobre esas cuestiones más adelante) que permitiría un inicio de sesión seguro mediante teclado interactivo?

P.S. Acerca de 2FA. Los métodos más comunes son el código de acceso + OTP y X.509 PKI en una tarjeta inteligente. Tampoco son impecables:

  1. si has secuestrado el proceso lsass, entonces podrías usar el código de acceso otp + para iniciar sesión en otros servidores mientras el código de acceso es válido. Al utilizar la autenticación, esto podría significar que ha iniciado sesión en decenas de servidores o más durante la ventana de 60 segundos
  2. Según este artículo de TechNet el usuario envía el PIN al servidor y hace que la tarjeta inteligente esté disponible para el servidor RDP. Se puede usar el mismo proceso que en el primer elemento para piratear muchos servidores mientras el administrador hace clic en el servidor comprometido.

°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸

Actualización 2018 : A partir de Windows Server 2012 R2 y Windows 8.1, el LSASS se puede ejecutar como un proceso protegido al habilitar RunAsPPL configurando e inhibiendo el volcado de credenciales. A partir de Windows 10 y Server 2016, la Windows Credential Guard está habilitado de forma predeterminada y logra resultados similares.

°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸

    
pregunta Konrads 10.07.2013 - 11:03
fuente

2 respuestas

1

Para responder a tu pregunta: creo que la forma más segura sería usar psexec para obtener un shell cmd remoto. Este método no debe resultar en una contraseña de texto simple almacenada. ¿O te refieres a interactivo, Y con una GUI?

Desafortunadamente, su mejor solución es evitar el inicio de sesión interactivo siempre que sea posible.

Afortunadamente, existen algunas formas seguras de administrar máquinas de forma remota:

  • winrm (incluyendo Invocar-Comando PowerHell)
  • psexec (solo si NO usa la opción "-u")
  • Asistencia remota

Estos son bastante seguros. Genera un token en la máquina, pero eso es parte de la arquitectura de Windows y no un error / falla.

Debes evitar usar lo siguiente siempre que sea posible, ya que es posible volcar contraseñas de texto simple usando mimikatz:

  • RDP
  • psexec con la opción "-u"

Con Windows 8.1 (y Windows 2012R2?), la contraseña wdigest de texto sin formato está desactivada de forma predeterminada. Sin embargo, como se demuestra en este artículo, simplemente puede volver a habilitar el almacenamiento de contraseñas de texto simple en el registro. Y, siempre hay ataques kerberos .

    
respondido por el nyxgeek 22.01.2016 - 06:31
fuente
1

Aunque no te guste mi respuesta, no veo un problema con eso. Ok, tener la contraseña en la memoria en texto no es ideal, se requiere en estos casos. ¿Cómo sería eso un riesgo de seguridad? Bueno, para explotar esto, necesita derechos administrativos, porque lsass se ejecuta bajo la cuenta protegida del sistema. Y conéctate como el mismo usuario que quieres explotar. Así que no hay una escalada de privilegios resultante de esto; el administrador que inició sesión tiene acceso a su propia contraseña de texto simple. Plantearía un problema si un programa pudiera acceder a esa contraseña de texto simple sin la intervención del usuario. Este no es el caso (UAC, acceso a código de inyección, etc.) Por lo tanto, necesitaría fallas adicionales para obtenerlo.

Para su pregunta específica: ¿Cómo saberlo? Usted no sabe Igual que cuando los usuarios le dicen su contraseña a un amigo. No puedes protegerte contra eso.

Sí, usar 2FA o tarjetas inteligentes es generalmente una buena idea, ya que no ingresas una contraseña directamente.

    
respondido por el http 11.07.2013 - 21:07
fuente

Lea otras preguntas en las etiquetas

¿Qué estructura de datos usaría / ha usado para almacenar las ACL dentro de un sistema híbrido ACL / RBAC? Facebook a veces elimina SSL. ¿Por qué?