Vuoi verificare la riservatezza del meccanismo SASL di GSS-SPNEGO (LDAP)

Question

Vuoi verificare la riservatezza del meccanismo SASL di GSS-SPNEGO (LDAP)

#1 da (0 voti)

0

Ho svolto alcune ricerche su supportedSASLMechanisms LDAP e sto cercando di far valere se c'è o meno protezione di riservatezza in gioco quando si utilizza GSS-SPNEGO .

La mia valutazione iniziale è che è necessaria una configurazione aggiuntiva per ottenere riservatezza poiché il seguente codice C # (supponiamo che GSS-SPNEGO sia selezionato) mostra solo SASL GSS-API Integrity in Wireshark, ma non 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
    ...
  }
}

Quello che segue è un esempio di catture di pacchetti:

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

Come puoi iniziare a vedere, l'intera transazione (che inizia con la query searchRequest in uscita e tutte le transazioni successive) viene inviata / ricevuta in chiaro. Vedo in SASL Buffer krb5_blob sotto la sezione GSS-API, anche se appena sopra la sezione Payload GSS-API che è anche testo in chiaro.

Credo che le mie domande principali siano:

Un MITM sarebbe ancora in grado di vedere lo stesso traffico che sto vedendo in chiaro e, in tal caso, qual è esattamente il ruolo di Kerberos rispetto alla riservatezza in queste transazioni (se esiste)?
Quale sarebbe la route preferita per garantire il traffico crittografato (ad esempio EXTERNAL o SSL / TLS, in questo caso sto ancora ricercando i dettagli di implementazione, in particolare in C #, come in AuthenticationTypes.SecureSocketsLayer )?

Nota: non ho controllato il "tentativo di decifrare il traffico KRB5" né specificato un file keytab in Wireshark, quindi la mia impressione iniziale è che il ruolo di Kerberos è solo a scopo di firma / verifica e come accennato in precedenza, configurazione aggiuntiva (o codifica) sarebbe necessario per garantire che il traffico sia crittografato.

.net ldap gssapi

posta rdev5 16.05.2016 - 22:46

fonte

1 risposta

Leggi altre domande sui tag .net ldap gssapi

Cosa ottiene questa query iniettata? Aggiungi un nuovo modulo di vulnerabilità su dionaea honeypot

score 0 · Answer 1

Quindi la risposta breve è no, questa non sta negoziando la privacy della GSS-API di SASL e francamente non ho ancora esplorato questa rotta (eccezion fatta per giocare con LdapConnection ).

Il seguente codice psuedo stabilisce una connessione TLS con il server LDAP, tuttavia (numero di porta e credenziali di collegamento obbligatorie):

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();
}

Per completezza, è incluso anche il seguente codice psuedo per la convalida del samAccountName interrogato:

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;
}

Puntate su Wireshark:)