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:
- Leggilo! ( PDF )
- Guardalo! ( Altoparlanti e diapositive | Diapositive video )
- 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:
- 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.
- 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.
- 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.