安全是有分量的

防cc_加速cdn防御_怎么防

2022-01-12 00:50栏目:资讯

防cc_加速cdn防御_怎么防

在2020年1月14日星期二,微软发布了他们的第一个补丁2020年星期二,解决了NSA在Windows10、WindowsServer2016和2019版本的crypt32.dll中发现的一个严重缺陷,crypt32.dll是实现Windows的CryptoAPI的库。没过多久,它就被肯恩·怀特在博客中冠以"连锁工具"的称号(后来被Tal Be'ery更名为"曲线球"。

TL;博士:使用我们的测试网站测试您是否易受攻击!

让我们来解释这个缺陷,并用一个POC来演示它,我们提供了一个测试网站和所有在家里复制它的代码。

像往常一样,在密码社区,缺陷可能影响深远,我们披露了所有我们可以披露的细节,并在我们的Github页面上发布了我们的POC(这在这里尤其重要,由于Microsoft和NSA没有披露任何细节。)

Microsoft发布了有关该漏洞的以下信息:

Windows CryptoAPI(Crypt32.dll)验证椭圆曲线加密(ECC)证书的方式中存在欺骗漏洞。攻击者可以使用欺骗的代码签名来利用该漏洞对恶意可执行文件进行签名的证书,使其看起来文件来自可信的合法来源。用户将无法知道该文件是恶意的,因为数字签名似乎来自受信任的提供商。成功利用此漏洞还可以使攻击者进行中间人攻击,并解密与受影响软件的用户连接上的机密信息。

虽然这仍然相对模糊,但我们可以从CERT网站收集更多的情报:

因此,攻击者可以创建一个似乎能够追踪到可信根证书颁发机构的证书。任何依赖Windows CertGetCertificateChain()函数来确定X.509证书是否可以跟踪到受信任的根CA的软件(包括第三方非Microsoft软件)都可能会错误地确定证书链的可信度。支持带有指定参数的ECC密钥的证书的Microsoft Windows版本会受到影响。

最后但并非最不重要的是,我们从NSA自己那里得到了"网络安全建议"!这个建议更为详细,特别提到:

包含明确定义的椭圆曲线参数的证书仅部分匹配标准曲线是可疑的,特别是如果它们包含可信证书的公钥

这非常有趣!这使我们相信,国内外高防CDN,有可能使用ECC和显式参数来制作证书,这些参数与标准曲线不完全匹配!

强制召回

在ECDSA中,私钥是一个大整数,而公钥是椭圆曲线上的一个点,通过计算得出,对于一个大素数阶的曲线的生成器(通常与您使用的曲线一起标准化)。

根本原因

所以,这里的想法是,当在提供的证书中指定显式曲线参数时,加载证书的方式存在一些缺陷。许多人讨论了这个话题,最后每个人都同意脆弱性应该是什么。托马斯·普塔切克在《黑客新闻》上做了一个很好的总结。但别担心,我会在下面再次解释它。

具体来说,免费高防cdn申请,只要您不使用标准生成器,就可以为现有公钥创建私钥,但可以选择任何生成器。您可以在X.509证书中选择自己的生成器,方法是使用"显式参数"选项来设置它。

因为这样CryptoAPI似乎将证书与其缓存中的证书匹配,而不检查所提供的生成器是否与标准化的生成器匹配,它实际上会信任证书,就好像它已被正确签名一样(尽管不是完全的,因为系统仍然检测到根证书与根CA存储中的证书不同。也就是说:你不会在你的URL栏中得到你想要的这些漂亮的绿色锁,但是你仍然会得到一个没有任何警告的锁,这与使用自签名证书时不同,即使你自己制作了证书。)

重要的是要注意,问题不在这里的加密操作中。数学证明了这一点,并且您可以使用另一个生成器(而不是标准化的生成器)来创建与公钥匹配的签名这一事实在数学中不是问题。这里的问题实际上是CryptoAPI使用的CA证书缓存错误地认为,只要其公钥和序列号与证书缓存中已经存在的证书匹配,修改后的根CA就在CA证书存储中,忽略这样一个事实,即这个修改后的证书没有使用与其缓存中的曲线参数相同的曲线参数。

而且它碰巧非常容易计算出一个假生成器,我们可以知道与给定CA的公钥对应的私钥!事实上,如果我们使用现有的证书及其公钥和未知的密钥,那么我们就得到了它。现在只要取一些随机值就足够了,然后我们设置。然后,在使用新的生成器时,我们得到了新构造的密钥是公钥的有效密钥,因为我们得到了:

这有效地允许我们欺骗Microsoft CryptoAPI,使其相信我们确实知道某个CA证书的密钥,而实际上我们只知道它的密钥是在使用不同于标准化生成器的生成器时才知道的!

现在,这只是理论,对吧?但是,我们如何确定这实际上是CVE-2020-0601背后的问题呢?嗯…因为我们有一个概念验证工作,它只是大约50行的Python代码!