¿Qué ataques, si los hay, son posibles contra la Interfaz del proveedor de soporte de seguridad (SSPI)?

33

He estado viendo SSPI recientemente, ya que se utiliza para la autenticación en una variedad de productos de Microsoft. Por su aspecto, se basa en GSSAPI y proporciona una abstracción para envolver varios mecanismos de autenticación (por ejemplo, NTLM, Kerberos, etc.) .) para uso en protocolos de aplicación.

¿Qué ataques, si los hay, son posibles contra SSPI? ¿Puede un atacante activo degradar la autenticación a un mecanismo fácilmente rompible (o nulo)? ¿Es posible sacar NTLM u otros hashes de los paquetes y descifrarlos?

    
pregunta Polynomial 29.05.2013 - 14:00
fuente

4 respuestas

2

Recientemente, no hay nuevos ataques, vulnerabilidades o vulnerabilidades, pero en 2010 y 2007 hubo algunas vulnerabilidades relacionadas con SSPI.

CVE-2010-0161 : la función nsAuthSSPI :: Unwrap en extensions / auth / nsAuthSSPI.cpp en Mozilla Thunderbird antes de 2.0.0.24 y SeaMonkey antes de 1.1.19 en Windows Vista, Windows Server 2008 R2 y Windows 7 permiten que los servidores SMTP, IMAP y POP remotos causen una denegación de servicio (daños en la memoria del montón y bloqueo de la aplicación) o posiblemente ejecuten código arbitrario a través de datos creados en una sesión que utiliza SSPI.

CVE-2007-2108 : una vulnerabilidad no especificada en el componente Core RDBMS en Oracle Database 9.0.1.5, 9.2.0.8, 10.1.0.5 y 10.2.0.2 en Windows permite que los atacantes remotos tengan un impacto desconocido, también conocido como DB01. NOTA: a partir de 20070424, Oracle no ha cuestionado las afirmaciones confiables de que este problema se produce porque la función NTLM SSPI AcceptSecurityContext otorga privilegios basados en el nombre de usuario proporcionado, aunque todos los usuarios están autenticados como Invitados, lo que permite a los atacantes remotos obtener privilegios.

    
respondido por el Ali 29.04.2015 - 14:22
fuente
-2

Parece que hay una presentación DEFCON donde el presentador ataca SSPI para obtener hashes de contraseña cuando no se pudieron usar todos los otros métodos:

  1. Léelo! ( PDF )
  2. ¡Véalo! ( Altavoz y diapositivas | Diapositivas de video )
  3. ¡Escúchalo! ( Audio m4b )

Anton Sapozhnikov también ha escrito un documento técnico sobre este tema, que está disponible en Github .

La vulnerabilidad explotada según el documento es la siguiente:

  

Microsoft ha desarrollado tantas interfaces diferentes para usuarios   Autentificación que tenemos para explotarlos de alguna manera.

     

Creamos una aplicación que usa SSPI para autenticar al usuario actual, no   en el otro sistema pero en el host del usuario.

     

SSPI permite llamar directamente a sus rutinas para obtener una solicitud / respuesta   mensajes Se supone que la aplicación en sí debería de alguna manera   transmita más mensajes, por ejemplo, a través de una red. Pero nuestra aplicación   No los pasará a través de la red. Todos los mensajes permanecerán en el   memoria de la aplicación.

     

Dependiendo de qué SSP seleccionado se transmitirán los mensajes transmitidos   diferente, así que si elegimos la aplicación NTLM transferiremos el   siguientes mensajes:

     
  1. NTLM_NEGOTIATE. El cliente envía un mensaje de Tipo 1 al servidor.   Esto contiene principalmente una lista de características soportadas por el cliente   y solicitado del servidor.
  2.   
  3. NTLM_CHALLENGE. El servidor responde con un mensaje de tipo 2. Esta   contiene una lista de características admitidas y acordadas por el servidor.   Lo más importante, sin embargo, contiene un desafío generado por el   servidor.
  4.   
  5. NTLM_AUTHENTICATE. El cliente responde al reto con un Tipo 3.   mensaje. Esto contiene varias piezas de información sobre el   cliente, incluido el dominio y el nombre de usuario del usuario cliente. Eso   también contiene una o más respuestas al desafío Tipo 2. [7]
  6.   

Dado que todos los intercambios realizados en la memoria no hay necesidad de transferir   Cualquier dato sobre red e interceptarlo luego. Significa que nosotros no   Necesito privilegios de alto nivel. SSPI nos preparará Tipo 1, 2 y   3 mensajes que contendrán todos los datos de autenticación necesarios. Eso   Sólo queda por sacar datos de autenticación.

     

Para facilitar la implementación no modificamos los mensajes. Mejorar   ataque podríamos generarlos y forzar a SSPI a usar menos seguro   protocolo NTLMv1 en lugar de NTLMv2.

     

Cuando se recibe un desafío / respuesta, podemos ejecutar un ataque de fuerza bruta sobre ellos   y obtener la contraseña del usuario.

     

Debido a la amplia propagación de los ataques pass-the-hash, hay una tendencia a   Deshabilitación parcial o total de la familia de protocolos NTLM y la   transición a Kerberos, pero en este caso todavía tenemos un protocolo   Compendio definido en RFC 2617 y RFC 2069.

     

Como puede observar, Digest es dos veces más rápido que NTLMv2, lo que significa que   Podemos usarlo en lugar de NTLMv2 para realizar una fuerza bruta más efectiva   ataques.

     

Por lo tanto, sin ningún privilegio en el sistema, pudimos obtener un   Contraseña del usuario local. Entonces podemos usar la contraseña recuperada para   conectarse a servicios empresariales desde Internet, como Webmail,   VPN, Citrix y así sucesivamente.

    
respondido por el feral_fenrir 28.09.2015 - 15:22
fuente
-2

El exploit más reciente que pude encontrar fue enlace pero no parece puede ser cualquier cosa de los últimos 3 años en el sitio NIST que puede buscar aquí: enlace

Dado que podría aparecer una nueva vulnerabilidad en cualquier momento, esta pregunta probablemente sea un buen candidato para cerrar

    
respondido por el Bron Davies 20.01.2016 - 06:06
fuente
-3

No he visto nada explotable en la naturaleza con respecto a SSPI, pero si tuviera que adivinar, diría que un ataque de suplantación para aumentar los privilegios sería una posibilidad. Hace un tiempo hubo una instancia donde WinSSPI tuvo un problema: consulte aquí y aquí .

Voy por un capricho aquí y creo que MS está usando SpGetContextToken se puede abusar localmente (sistema):" Un identificador del contexto para suplantar ". .. "Haz esto, usando las credenciales del usuario N". Desde el lado de la red, si alguien saca un hash NTLM, ya no hay necesidad de descifrarlo. Uno simplemente puede " pasar el hash "

    
respondido por el munkeyoto 29.05.2013 - 15:01
fuente

Lea otras preguntas en las etiquetas