Quali possibili attacchi sono possibili contro l'interfaccia SSPI (Security Support Provider Interface)?

33

Ho esaminato di recente SSPI di recente, poiché viene utilizzato per l'autenticazione in una varietà di prodotti Microsoft. Dal suo aspetto, si basa su GSSAPI e fornisce un'astrazione per il wrapping di vari meccanismi di autenticazione (ad esempio NTLM, Kerberos, ecc. .) per l'uso nei protocolli delle applicazioni.

Quali possibili attacchi sono possibili contro SSPI? L'autenticazione può essere sottoposta a downgrade a un meccanismo facilmente interrompibile (o nullo) da parte di un utente malintenzionato attivo? È possibile estrarre NTLM o altri hash dai pacchetti e craccarli?

    
posta Polynomial 29.05.2013 - 14:00
fonte

4 risposte

2

Recentemente, non ci sono nuovi attacchi, vulnerabilità o exploit ma nel 2010 e nel 2007 ci sono stati alcuni exploit relativi a SSPI.

CVE-2010-0161 : la funzione nsAuthSSPI :: Unwrap nelle estensioni / auth / nsAuthSSPI.cpp in Mozilla Thunderbird prima 2.0.0.24 e SeaMonkey precedenti alla 1.1.19 in Windows Vista, Windows Server 2008 R2 e Windows 7 consentono ai server remoti SMTP, IMAP e POP di causare un Denial of Service (danneggiamento della memoria heap e crash dell'applicazione) o di eseguire codice arbitrario tramite dati predisposti in una sessione che utilizza SSPI.

CVE-2007-2108 : la vulnerabilità non specificata nel componente Core RDBMS in Oracle Database 9.0.1.5, 9.2.0.8, 10.1.0.5 e 10.2.0.2 su Windows consente agli autori di attacchi remoti di avere un impatto sconosciuto, noto come DB01. NOTA: a partire dal 20070424, Oracle non ha contestato affermazioni attendibili secondo cui questo problema si verifica perché la funzione AcceptSecurityContext NTLM SSPI concede i privilegi in base al nome utente fornito anche se tutti gli utenti sono autenticati come Guest, consentendo agli aggressori remoti di ottenere privilegi.

    
risposta data 29.04.2015 - 14:22
fonte
-2

Sembra che ci sia una presentazione di DEFCON dove il presentatore attacca la SSPI per ottenere gli hash delle password quando non è possibile utilizzare tutti gli altri metodi:

  1. Leggilo! ( PDF )
  2. Guardalo! ( Altoparlanti e diapositive | Diapositive video )
  3. Ascoltalo! ( m4b Audio )

Anton Sapozhnikov ha scritto anche un white paper su questo che è disponibile su Github .

La vulnerabilità sfruttata come da carta è la seguente:

Microsoft has developed so many different interfaces for user authentication that we have to exploit them somehow.

We created application that uses SSPI to authenticate current user not on the other system but on user’s host.

SSPI allows to directly call it’s routines to obtain request/response messages. It is assumed that the application itself should somehow transmit messages further, e.g., over a network. But our application will not pass them over network. All messages will stay in the application memory.

Depending on which SSP selected transmitted messages will be different, so if we choose NTLM application will transfer the following messages:

  1. NTLM_NEGOTIATE. The client sends a Type 1 message to the server. This primarily contains a list of features supported by the client and requested of the server.
  2. NTLM_CHALLENGE. The server responds with a Type 2 message. This contains a list of features supported and agreed upon by the server. Most importantly, however, it contains a challenge generated by the server.
  3. NTLM_AUTHENTICATE. The client replies to the challenge with a Type 3 message. This contains several pieces of information about the client, including the domain and username of the client user. It also contains one or more responses to the Type 2 challenge.[7]

Since all exchange performed in memory there is no need to transfer any data over network and intercept it later. It means that we do not need any high level privileges. SSPI will prepare for us Type1, 2 and 3 messages which will contain all necessary authentication data. It only remains to get authentication data out.

For ease of implementation we do not modify messages. To improve attack we could generate them and force SSPI to use less secure protocol NTLMv1 instead of NTLMv2.

When challenge/response received we can run brute force attack on them and get user's password.

Due to wide spread of pass-the-hash attacks there is a trend to partially or totally disabling of NTLM protocols family and the transition to Kerberos, but in this case we still have a protocol Digest defined in RFC 2617 and RFC 2069.

As you may notice, Digest is twice as fast as NTLMv2 that means that we can use it instead of NTLMv2 to perform more effective brute force attacks.

Thus, without any privileges in the system, we were able to get a local user's password. Then we can use the recovered password to connect to enterprise services from the Internet, such as Webmail, VPN, Citrix and so on.

    
risposta data 28.09.2015 - 15:22
fonte
-2

L'exploit più recente che ho trovato è stato link ma non sembra essere qualsiasi cosa degli ultimi 3 anni sul sito NIST che puoi cercare qui: link

Dato che un nuovo exploit potrebbe apparire in qualsiasi momento questa domanda è probabilmente un buon candidato da chiudere

    
risposta data 20.01.2016 - 06:06
fonte
-3

Non ho visto nulla di sfruttabile in termini di SSPI, ma dovevo indovinare, direi che un attacco di impersonificazione per aumentare i privilegi sarebbe una probabilità. C'è stata un'istanza qualche tempo fa in cui WinSSPI aveva un problema: vedere qui e qui .

Vado qui per un capriccio e penso che il modo in cui MS sta usando SpGetContextToken può essere abusato localmente (sistema):" Un handle per il contesto da impersonare. " .. "Fai questo, usando le credenziali di N utente." Dal lato della rete, se qualcuno estrae un hash NTLM, non è più necessario craccarlo. Uno può semplicemente " passare l'hash "

    
risposta data 29.05.2013 - 15:01
fonte

Leggi altre domande sui tag