安全支持提供程序接口 (SSPI) 可能受到哪些攻击（如果有）？
最近，没有新的攻击、漏洞或漏洞利用，但在 2010 年和 2007 年出现了一些与 SSPI 相关的漏洞利用。
CVE-2010-0161：Windows Vista、Windows Server 2008 R2 和 Windows 7 上 Mozilla Thunderbird 2.0.0.24 之前和 SeaMonkey 1.1.19 之前的 extensions/auth/nsAuthSSPI.cpp 中的 nsAuthSSPI::Unwrap 函数允许远程 SMTP、IMAP , 和 POP 服务器导致拒绝服务（堆内存损坏和应用程序崩溃）或可能通过使用 SSPI 的会话中的精心制作的数据执行任意代码。
CVE-2007-2108：Windows 上的 Oracle 数据库 9.0.1.5、9.2.0.8、10.1.0.5 和 10.2.0.2 的核心 RDBMS 组件中存在未指定漏洞，允许远程攻击者产生未知影响，即 DB01。注意：截至 20070424，Oracle 对发生此问题的可靠声明没有异议，因为 NTLM SSPI AcceptSecurityContext 函数根据提供的用户名授予权限，即使所有用户都被验证为访客，这允许远程攻击者获得权限。
似乎有一个DEFCON 演示文稿，其中演示者在无法使用所有其他方法时攻击 SSPI 以获取密码哈希：
Anton Sapozhnikov 也为此撰写了一份白皮书，可在Github上找到。
根据论文利用的漏洞如下：
Microsoft 为用户身份验证开发了许多不同的接口，我们必须以某种方式利用它们。
我们创建的应用程序使用 SSPI 来验证当前用户，而不是在其他系统上，而是在用户的主机上。
SSPI 允许直接调用它的例程来获取请求/响应消息。假设应用程序本身应该以某种方式进一步传输消息，例如，通过网络。但是我们的应用程序不会通过网络传递它们。所有消息都将保留在应用程序内存中。
根据选择哪个 SSP 传输的消息会有所不同，因此如果我们选择 NTLM 应用程序将传输以下消息：
- NTLM_NEGOTIATE。客户端向服务器发送 Type 1 消息。这主要包含客户端支持和服务器请求的功能列表。
- NTLM_CHALLENGE。服务器以类型 2 消息进行响应。这包含服务器支持和同意的功能列表。然而，最重要的是，它包含由服务器生成的挑战。
- NTLM_AUTHENTICATE。客户端使用类型 3 消息回复质询。这包含有关客户端的几条信息，包括客户端用户的域和用户名。它还包含对第 2 类挑战的一个或多个响应。 [7]
由于所有交换都在内存中执行，因此无需通过网络传输任何数据并稍后拦截。这意味着我们不需要任何高级权限。SSPI 将为我们准备 Type1、2 和 3 消息，其中将包含所有必要的身份验证数据。只剩下获取身份验证数据了。
为了便于实施，我们不修改消息。为了改进攻击，我们可以生成它们并强制 SSPI 使用安全性较低的协议 NTLMv1 而不是 NTLMv2。
当收到挑战/响应时，我们可以对它们进行暴力攻击并获取用户密码。
由于散列传递攻击的广泛传播，有一种趋势是部分或完全禁用 NTLM 协议系列并过渡到 Kerberos，但在这种情况下，我们仍然有 RFC 2617 和 RFC 2069 中定义的协议摘要。
您可能会注意到，Digest 的速度是 NTLMv2 的两倍，这意味着我们可以使用它而不是 NTLMv2 来执行更有效的暴力攻击。
因此，在系统没有任何特权的情况下，我们能够获得本地用户的密码。然后我们可以使用恢复的密码从互联网连接到企业服务，如Webmail、VPN、Citrix等。
我能找到的最新漏洞利用是https://technet.microsoft.com/en-us/library/security/3045755.aspx但在 NIST 网站上似乎没有任何可以搜索的过去 3 年的东西这里：https ://web.nvd.nist.gov/view/vuln/search-results?query=SSP&search_type=last3years&cves=on
由于任何时候都可能出现新的漏洞利用，所以这个问题可能是一个不错的选择
关于 SSPI，我还没有看到任何可在野外利用的东西，但如果我猜的话，我会说冒充攻击来提升权限是可能的。前段时间有一个例子，WinSSPI 有一个问题：请参阅此处和此处。
我在这里突发奇想，认为 MS 使用SpGetContextToken的方式可以在本地（系统）被滥用：“模拟上下文的句柄。” ..“使用 N 用户的凭据执行此操作。” 从网络方面来说，如果有人拉出一个 NTLM 哈希，就没有必要再破解它了。一个人可以“通过哈希”