Quiere verificar la confidencialidad del mecanismo GSS-SPNEGO SASL (LDAP)

Question

Quiere verificar la confidencialidad del mecanismo GSS-SPNEGO SASL (LDAP)

#1 de rdev5 (0 votos)

0

He estado investigando LDAP supportedSASLMechanisms y estoy tratando de afirmar si existe o no una protección de confidencialidad en juego cuando uso GSS-SPNEGO .

Mi evaluación inicial es que se requiere una configuración adicional para lograr la confidencialidad porque el siguiente código de C # (asumiendo que GSS-SPNEGO está seleccionado) solo muestra SASL GSS-API Integrity en Wireshark, pero no SASL GSS-API Privacy .

private static void Main()
{
  using (var ds = new DirectorySearcher())
  {
    ds.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", "jdoe");
    var result = ds.FindOne(); // Begin packet capture
    ...
  }
}

La siguiente es una muestra de las capturas de paquetes:

client -> server: searchRequest(73) "<ROOT>" baseObject 
server <- client: searchResEntry(73) "<ROOT>" 
client -> server: bindRequest(75) "<ROOT>" sasl (SASL mechanism: GSS-SPNEGO)
server <- client: bindResponse(75) success 
client -> server: SASL GSS-API Integrity: searchRequest(9) "DC=com,DC=example" baseObject

Como puede comenzar a ver, la transacción completa (que comienza con la consulta saliente searchRequest y todas las transacciones subsiguientes) se envía / recibe texto sin cifrar. Sí veo en el Buffer SASL krb5_blob en la sección GSS-API, aunque justo arriba de la sección Carga útil GSS-API que también es texto claro.

Supongo que mis preguntas principales son:

¿Un MITM aún podría ver el mismo tráfico que veo en texto claro y, de ser así, cuál es exactamente el rol de Kerberos con respecto a la confidencialidad en estas transacciones (si las hay)?
¿Cuál sería la ruta preferida para garantizar el tráfico encriptado (es decir, EXTERNAL o SSL / TLS; esta parte en realidad todavía estoy investigando los detalles de la implementación, específicamente en C #, como en AuthenticationTypes.SecureSocketsLayer )?

Nota: no he comprobado el "intento de descifrar el tráfico KRB5" ni he especificado un archivo keytab en Wireshark, por lo que mi impresión inicial es que la función de Kerberos es solo para fines de firma / verificación y, como se mencionó anteriormente, configuración adicional (o codificación) sería necesaria para garantizar que el tráfico esté cifrado.

.net gssapi ldap

pregunta rdev5 16.05.2016 - 22:46

fuente

1 respuesta

Lea otras preguntas en las etiquetas .net gssapi ldap

Agregar un nuevo módulo de vulnerabilidad en la zona de honeypot Bloqueo de cliente basado en PKI

score 0 · Answer 1

Entonces, la respuesta corta es no, esto no es negociar la privacidad GSS-API de SASL y, francamente, no he explorado más esta ruta (con la excepción de jugar con LdapConnection ).

Sin embargo, el siguiente código psued establece una conexión TLS con el servidor LDAP (se requieren número de puerto y credenciales de enlace):

var bindPath = "LDAP://dc.example.com:636";

...

if (!ValidUsername(samAccountName))
    throw new Exception("Invalid samAccountName");

using (var context = new DirectoryEntry(bindPath, bindUsername, bindPassword, AuthenticationTypes.SecureSocketsLayer))
using (var ds = new DirectorySearcher())
{
    ds.SearchRoot = context;
    ds.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", samAccountName);

    var sr = ds.FindOne();

    if (sr == null)
        throw new Exception("User [" + samAccountName + "] not found");

    return sr.GetDirectoryEntry();
}

Para completar, también se incluye el siguiente código psuedo para validar el samAccountName que se consulta:

public static bool ValidUsername(string username)
{
    // Must not be empty/null
    if (string.IsNullOrEmpty(username))
        return false;

    // Must not exceed max length expected
    if (username.Length > ValidUsernameMaxLength)
        return false;

    // Must only contain valid characters in whitelist
    if (!ValidUsernamePattern.IsMatch(username))
        return false;

    return true;
}

Apoyos a Wireshark :)