微软仍在使用RC4

美国参议员Ron Wyden已要求联邦贸易委员会就微软继续使用RC4加密算法一事展开调查。该信件提及一种名为Kerberoasting的黑客技术，该技术利用了Kerberos认证系统的漏洞。

标签：算法, 微软, 勒索软件, RC4
发布时间：2025年9月16日上午7:06 • 11条评论

用户评论

Wayne • 2025年9月16日上午9:47
我上周读到相关报道时非常惊讶。微软支撑着全球基础设施，结果却发现它如此脆弱，这有点讽刺。如果在90年代被问及此类问题，我们很多人可能会说"嗯，很有可能"。既然这个隐患已广为人知，微软的修复时间表确实需要加快。我想知道有哪些缓解措施可以防御这种攻击。

Will Fiveash • 2025年9月16日上午10:11
处理Kerberos使用的加密算法（如RC4或单DES等）并发现其脆弱性并非易事。Kerberos广泛应用于多种操作系统（Solaris、Linux、Windows、macOS等）的混合环境中，这使得将脆弱的Kerberos加密类型无缝迁移到更强加密类型变得非常困难。如果操作不当，认证系统会停止工作，系统管理员很快就会收到各种无法正常工作的投诉。我不同情那些处理这些问题的微软工程师。

TimH • 2025年9月16日上午10:31
微软在允许弱加密方面有前科。对于Bitlocker，他们移除了Elephant Diffuser PRNG，默认使用AES-128。在全盘加密之前，谁会知道要改为AES-256呢？

JR • 2025年9月16日上午11:13
RC4，哇。几年前他们还有一个用RC3签名的SSL证书。该证书用于在Azure的Linux系统上运行的waagent。注意Azure有多个环境。我使用的环境本应是安全的，但却是最后一个获得更新的。他们在公共Azure中修复了证书，却一直说我们错了。当Linux机器处于FIPS模式时，他们的代理无法正常工作。

Wannabe Techguy • 2025年9月16日上午11:48
IT专业人士怎么会对微软的任何行为感到惊讶？考虑到Windows更新的所有问题，我对他们的低质量工作（懒惰？）并不感到意外。然而，人们仍然信任他们。

Clive Robinson • 2025年9月16日中午12:09
@所有人，
需要注意一点…
RC4仍然可用于许多场景，包括"通信白化"（生成噪声）和"模拟"（如蒙特卡洛模拟）。
然而，像许多"简单的洗牌算法"一样，RC4已不再被认为具有密码学安全性，即使用于保护你妹妹的日记也不安全，何况她现在把日记存在电脑上…
我认为可以肯定地说，除特殊类别外的所有加密算法都会面临这个问题。
这只是时间问题。
这当然引出了我多年来一直提到的"嵌入式"和"网格"系统问题…

KC • 2025年9月16日下午3:47
2014年创造Kerberoasting术语的Tim Medin也对Wyden的信件做出了回应，并对微软的回应进行了剖析。
正如Clive所提到的，基于AES的Kerberos票据仍然容易受到Kerberoasting攻击。根据Tim运行的基准测试，破解AES128和AES256票据的速度分别慢约350倍和700倍。
https://redsiege.com/blog/2025/09/kerberoasting-microsoft-and-a-senator/

Blaziken • 2025年9月16日晚上10:15
@Clive
同意RC4仍可用于许多场景…
类似地，SHA-1将凭借RFC5280第4.2.1.2节永远存在，但这不应构成安全问题，因为哈希冲突只会导致信任路径构建失败，不应导致证书验证错误，除非是最糟糕的实现。

Clive Robinson • 2025年9月17日上午4:42
@KC, 所有人，
关于"基于AES的Kerberos票据仍然容易受到Kerberoasting攻击"，据我分析实际上应该是"所有方式都会…"
这是由于设计中的根本问题（也影响许多其他系统[1]）。
但如果改变这些根本问题：

它不仅不再是Kerberos，而且不会兼容。
使其兼容会打开其他安全漏洞。
新漏洞几乎肯定会形成攻击类别。
这些是即使技术人员也不愿讨论的问题，而Kerberos是世界上部署最广泛的同类系统之一…
[1] 奇怪的是我在几天内两次谈到这个问题，但人们说"随机事物倾向于聚集"（或者是人类😉）
人们必须学习一些痛苦的教训，否则可能承受后果。
一个经常出现的问题是"离线认证"。底线是，要进行任何类型的认证，都需要一个唯一且不可伪造的ID-验证器对，所以我们有我们都熟悉和讨厌的一种变体——太容易识别的"用户名和密码"，以及银行卡号、验证器和PIN码等。
虽然ID可以是公开的，但验证器应始终是"共享秘密"，这不仅意味着它应该是唯一和不可伪造的，更重要的是除了必要的验证过程外，应对其他所有方保密。
如果不是这样，“游戏就结束了”。
那么，考虑一个相当常见的情况：一个系统中有用户"必须被认证，但不能也不应被信任"。他们必须既"持有和控制"共享秘密，又"不知晓/访问"它…
在线双方向系统有办法实现，但离线和有效的三方向…
这就是当"共享秘密"被"假定为敌对的用户"知晓时，机顶盒和CD/DVD等视频分发系统总是会失败的原因。
这是较容易看到的认证系统失败案例，还有太多其他例子…

ResearchetZero • 2025年9月22日凌晨1:09
他们的Entrance ID系统也坏了。由于旧版Graph API未正确验证原始租户，攻击者可以使用"Actor Token"获得任何AD租户的全局管理员权限。
此授权还允许修改设置，包括用户ID、应用程序和权限、组、服务主体等。
https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/

ResearcherZero • 2025年9月22日凌晨1:11
*Entra ID（拼写检查器）