我正在开发使用 Windows 身份验证的 ASP.NET 应用程序。我已将文件设置web.config为拒绝所有未经身份验证的用户，并且仅允许具有特定角色的用户。
使用 Fiddler，我能够模糊我的会话 ID，重放请求，并且仍然得到响应200 OK......显然无需任何重新协商。
我认为基于 NTLM 的身份验证的凭据与底层 TCP 连接相关联。首先，这是真的吗？这是一个真正的安全威胁吗？如果是这样，个人需要采取什么步骤来劫持这样的连接以冒充其他用户的身份？
答案1
Internet Explorer 可以执行透明的 NTLM 身份验证。我很少使用 Fiddler，也不知道它是否会显示对话的这一部分。我猜您的浏览器正在透明地对您进行身份验证，但我不能肯定。
您可以尝试使用 Wireshark 或类似工具嗅探浏览器/服务器流量，看看是否发生了这种情况。客户端和 IIS 之间的 NTLM 身份验证是在 TCP 连接中带内完成的，而不是作为与 TCP 连接启动相关的某些带外过程的一部分。如果存在，您就会看到它。
您没有看到 TCP 劫持。您看到的是透明身份验证的结果，或者您的应用程序实际上不需要身份验证。
直接谈 TCP 劫持（TCP 排序等）：要劫持 TCP 连接，攻击者必须预测序列和确认号，并以客户端的身份伪造流量。通常，这最终会成为盲目攻击，因为来自服务器计算机的回复最终会返回到真正的客户端。（如果将 TCP 排序与 ARP 缓存中毒相结合，则可以进行双向劫持，但这通常会将攻击限制在与客户端或服务器位于同一子网上的计算机上的攻击者。）除非攻击者已经破坏了客户端和服务器之间的瓶颈，否则很难通过 Internet 对客户端和服务器之间的实时连接进行 TCP 排序。
盲 TCP 排序攻击利用连接来利用对协议的信任（Kevin Mitnick 对 Shimomura 的工作站发起的攻击，在其上放置了一个 .rhosts 文件），这是通过可猜测的初始序列号实现的，与直接劫持略有不同。
SSL、IPSEC 或其他加密隧道协议是阻止 TCP 劫持的好帮手。一般来说，即使您使用非明文质询/响应系统（如 NTLM、NTLMv2 等）进行身份验证，TCP 连接仍然容易受到劫持。
答案2
回答你的最后一个问题，使用 Cain 进行 arp 中毒是一件相对简单且微不足道的事情。话虽如此，它确实需要以下两个条件之一才能实现：物理访问你的网络或无线访问你的网络。
一旦 arp 中毒，并且 Cain 收集了足够的数据，就可以在 Cain 内部破解 NTLM 哈希。当然，密码越强，破解所需的时间就越长。