Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I've been looking at SSPI recently, as it is used for authentication in a variety of Microsoft products. From the looks of it, it's based on GSSAPI and provides an abstraction for wrapping various authentication mechanisms (e.g. NTLM, Kerberos, etc.) for use in application protocols.

What attacks, if any, are possible against SSPI? Can authentication be downgraded to an easily-breakable (or null) mechanism by an active attacker? Is it possible to pull NTLM or other hashes out of the packets and crack them?

share|improve this question
Do you mean attacks on the API? Or attacks on protocols that are provided by that API? Or both? – sta Sep 4 '14 at 15:04
This question is unclear because attacks would usually be against a particular SSP (e.g. NTLM, Kerberos) rather than the SSPI. If you're asking about all SSPs then it's too broad - each SSP should have an individual question. – paj28 Oct 23 '14 at 14:13
@paj28 Sorry, yes, I should've been more clear. I guess I'm mainly referring to Negotiate and Digest SSP (SASL) as they're the two most common. But, as well as that, I'm interested in the security of how SSPI as an interface safely decides which protocol to use when there are mismatches in support between two endpoints. – Polynomial Oct 25 '14 at 13:51
Anton Sapozhnikov has written a whitepaper too on this which is available on Github: – feral_fenrir Sep 29 at 6:44
There is also a DEFCON presentation related to this by Anton Sapozhnikov: – feral_fenrir Sep 29 at 6:44

3 Answers 3

actually these days there is no any attacks or vulnerabilities or explots but in 2010 and 2007 there was some exploits related to sspi

CVE-2010-0161:The nsAuthSSPI::Unwrap function in extensions/auth/nsAuthSSPI.cpp in Mozilla Thunderbird before and SeaMonkey before 1.1.19 on Windows Vista, Windows Server 2008 R2, and Windows 7 allows remote SMTP, IMAP, and POP servers to cause a denial of service (heap memory corruption and application crash) or possibly execute arbitrary code via crafted data in a session that uses SSPI.

CVE-2007-2108:Unspecified vulnerability in the Core RDBMS component in Oracle Database,,, and on Windows allows remote attackers to have an unknown impact, aka DB01. NOTE: as of 20070424, Oracle has not disputed reliable claims that this issue occurs because the NTLM SSPI AcceptSecurityContext function grants privileges based on the username provided even though all users are authenticated as Guest, which allows remote attackers to gain privileges.

share|improve this answer

There seems to be a DEFCON presentation where the presenter attacks SSPI to get password hashes when all the other methods could not be used:

  1. Read It! (PDF)
  2. See it! (Speaker & Slides | Slides Video)
  3. Hear it! (m4b Audio)

Anton Sapozhnikov has written a whitepaper too on this which is available on Github.

The vulnerability exploited as per the paper is as follows:

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.

share|improve this answer
Editing my answer. Thanks for the note mate! – feral_fenrir Sep 28 at 13:57
Thanks for being impatient while I was editing my answer to include the vulnerability and deleting my post. Kindly review my answer now and score accordingly. – feral_fenrir Sep 29 at 7:01

I haven't seen anything exploitable in the wild with regards to SSPI but had I to guess, I would say an impersonation attack to escalate privileges would be a likelihood. There was an instance some time ago where WinSSPI had an issue: See here and here.

I'm going on a whim here and thinking that the way MS is using SpGetContextToken can be abused locally (system): "A handle to the context to impersonate." .. "Do this, using the credentials of N user." From the network side, if someone pulls out an NTLM hash, there is no need to crack it anymore. One can just "pass the hash"

share|improve this answer
I think you misunderstood impersonation. On Windows, the term is used to mean a handle or object created under the context of another user whose credentials (or evidence, to use the official term) you have. For example, an administrative user can create a process that impersonates the limited user Bob, using evidence that he is an administrator. The admin doesn't need to know Bob's password in this case. Bob can't do the opposite (i.e. impersonate admin) because Bob can't provide any evidence that he's allowed to do so, but he may be able to impersonate Alice if he knows her credentials. – Polynomial May 29 '13 at 14:04
I didn't downvote, but I suspect whoever did did so because you didn't provide any evidence for your claims. – Polynomial May 29 '13 at 14:06
Classic misunderstanding/confusion between social engineering and impersonation. – injector Jul 4 '14 at 23:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.