Windows更新-拦截

Question

我试图监视在执行Windows时发出的HTTP请求/响应。

我有一台Windows 8机器，在IE中配置了一个代理。我还通过netsh为winhttp导入了：

netsh winhttp导入代理source=ie

代理在端口8080上的另一台计算机上运行，并被配置为拦截SSL。

我已经尝试过使用Burp代理或普通Squid代理(使用ssl_bump)。根CA证书安装在受信任根CA下的本地机器存储区中的Windows 8计算机上。如果我从IE或Chrome浏览，我可以在没有警告的情况下访问https站点(因为提供的服务器证书是由代理CA签名的)。

但是，如果我尝试使用Windows，则会得到一个错误：

“检查更新时出现了问题”

这是一个已知的问题，Bluecoat建议为Windows Update添加SSL截获异常：

https://kb.bluecoat.com/index?page=content&id=KB3959&actp=RSS

微软对TMG也提出了同样的建议：

http://support.microsoft.com/kb/949104

因此，Windows Update服务似乎不只是以通常的方式检查证书，它实际上是根据不同的CA列表进行验证，或者特别需要从Windows站点获得特定的服务器证书。

问题是，我如何解决这个问题，以便能够看到Windows发出的HTTP请求？

Answer 1

这个问题已经向我提出了一段时间的挑战，但确实找到了解决办法。通常显示为Windows错误80245006或803D000A。

我在2015年3月编写了一个名为SuperPhishers DetermineSubCAIdentity.py的工具，它允许您绕过windows内部检查，确认证书确实来自微软。这个名字是当时联想( SuperFish )对联想的争议中的一出戏。

简单的部分是让您的SSL代理生成一些最新的东西:比如RSA>=2048和SHA256RSA等等。我使用sslsplit并对它进行了修改以生成SHA256摘要。Windows在更新和存储证书时需要SHA256，否则就会在0x803D000中失败

最困难的部分是绕过Windows检查CA证书是否为Microsoft：

基本上，有两个函数实现了对CA证书是否合法的检查。它们在wuaueng.dll中都被称为wuaueng.dll，在storewuauth.dll中使用Nektra Deviare2，函数DetermineSubCAIdentity是连接起来的，所以它总是完成离开EAX=3。这允许微软通过检查，并且更新或存储函数继续正常运行。

如果在两个dll中修补此函数，则允许拦截Windows通信量。检查您截获的流量或运行通过ICAP重写乐趣。

我在这里做了一个视频：https://www.youtube.com/watch?v=EyDaTkU2sKY

代码和技术编写如下：https://github.com/MiWCryptAnalytics/DetermineSubCAIdentity

Thomas是正确的，因为你需要修改dll的--当我在磁盘上修改dll的时候，证监会确实用好的dll代替了它们。然而，在内存中将Deviare2注入到系统进程中，Windows8.1似乎并不在意。

希望这能帮上忙，而且第一次看到Windows更新的流量是透明的，这是很愉快的。

Answer 2

可能的更新包括对信任存储本身的默认内容进行更新。如果Windows正在使用默认的信任存储，那么该存储中的任何CA都可以编辑一个伪造的更新，从而驱逐其竞争对手。它还可以改变操作系统的任何部分。对于操作系统，更新路径非常敏感。将更新的权力授予大约100个CA是非常危险的，并不是所有这些都能真正被信任来正确地完成他们的工作(灾难已经发生，不经常发生，但.)。

您可以尝试将Windows服务器的假证书添加到“受信任的出版商”存储区(“本地计算机”的证书)。包括假服务器证书本身，而不是由Burp控制的CA，它实时发布假证书(我不知道Burp是否可以对给定的服务器使用特定的非动态假证书)。这个存储库通常用于验证驱动程序上的签名，而不是SSL服务器，但考虑到Microsoft处理证书的方式，它可能会正常工作，并能做您想做的事情(我现在还没有一台Windows机器可以方便地进行此操作)。

如果Windows代码不使用易于访问的信任存储，而是对Windows服务器的可接受证书列表进行硬编码，那么您将不得不求助于DLL修改，就像恶意软件写代码一样。操作系统将试图积极防御这一点。