33

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?

Improve this question
7
  • Do you mean attacks on the API? Or attacks on protocols that are provided by that API? Or both?
    – sta
    Commented Sep 4, 2014 at 15:04
  • 3
    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
    Commented Oct 23, 2014 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
    Commented Oct 25, 2014 at 13:51
  • Polynomial, you've looked at it, so how have you audited it? which functions in which DLL(s) does SSPI use (other than the standard NTDLL)? On which platform/OS/etc. (e.g. Win7x64? Win7x86? Vista? Win10?)
    – grepNstepN
    Commented Jun 25, 2016 at 20:34
  • @grepNstepN Sorry, not a clue. Haven't touched SSPI since 2014.
    – Polynomial
    Commented Jun 27, 2016 at 9:09

4 Answers 4

Reset to default
2

Recently, there are no new attacks, vulnerabilities or exploits but in 2010 and 2007 there were some exploits related to SSPI.

CVE-2010-0161: The nsAuthSSPI::Unwrap function in extensions/auth/nsAuthSSPI.cpp in Mozilla Thunderbird before 2.0.0.24 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 9.0.1.5, 9.2.0.8, 10.1.0.5, and 10.2.0.2 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.

Improve this answer
-2

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.

Improve this answer
0
-2

The most recent exploit I could find was https://technet.microsoft.com/en-us/library/security/3045755.aspx but there does not appear to be anything from the last 3 years on the NIST site which you can search here: https://web.nvd.nist.gov/view/vuln/search-results?query=SSP&search_type=last3years&cves=on

Since a new exploit could appear at any time this question is probably a good candidate to be closed

Improve this answer
0
-3

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"

Improve this answer
3
  • 12
    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
    Commented May 29, 2013 at 14:04
  • 2
    I didn't downvote, but I suspect whoever did did so because you didn't provide any evidence for your claims.
    – Polynomial
    Commented May 29, 2013 at 14:06
  • Classic misunderstanding/confusion between social engineering and impersonation.
    – injector
    Commented Jul 4, 2014 at 23:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .