Orange: 让我们在缓存中起舞 - 破坏微软IIS哈希表的稳定性！

这是Orange的发言 :)

CVE-2022-22025 - 微软IIS哈希洪水拒绝服务攻击

很难想象在2022年我们还能在IIS中看到如此经典的算法复杂性攻击——哈希洪水攻击。尽管微软配置了每30秒删除过期记录的线程来缓解攻击，但我们仍在实现中发现了一个关键分割错误，能将我们的攻击威力放大10倍以上，通过零哈希击败防护机制。通过此漏洞，我们可以让默认安装的IIS服务器在大约每秒30个连接的情况下变得无响应！

由于此漏洞符合Windows Insider Preview赏金计划的要求，我们因此获得了30,000美元的赏金。这是拒绝服务类别的最高赏金！

CVE-2022-22040 - 微软IIS缓存投毒攻击

与其他出色的缓存投毒研究相比，这个漏洞相对简单。该漏洞发现在输出缓存组件中，该模块负责缓存动态响应以减少Web堆栈上昂贵的数据库或文件系统访问。

输出缓存使用了一个有问题的查询字符串解析器，当查询字符串键重复时，它只将第一次出现作为缓存键。这种行为本身并不是问题。然而，从整个架构与后端ASP.NET的角度来看，这就成了麻烦。后端将所有重复键的值连接在一起，这导致了解析器行为之间的不一致。因此，经典的HTTP参数污染可以使IIS缓存错误的结果！

CVE-2022-30209 - 微软IIS认证绕过

这可能是本次演讲中最有趣的漏洞。LKRHash是微软在1997年设计和获得专利的哈希表算法。它基于线性哈希，由微软研究院的Paul Larson以及IIS团队的Murali Krishnan和George Reilly创建。

LKRHash旨在在多线程和多核环境下构建可扩展且高并发的哈希表。创建者付出了大量努力使此实现具有可移植性、灵活性和可定制性，以适应微软的多个产品。应用程序可以定义自己的表相关函数，例如哈希函数、键提取函数或键比较函数。这种可扩展性为漏洞挖掘创造了许多机会。

由于"登录"是一个昂贵的操作，为了提高性能，IIS默认缓存所有基于密码认证的令牌，例如基本认证，我们这次发现的漏洞位于发生冲突时的键比较函数逻辑中。

如果登录尝试的哈希命中了缓存中已存在的键，LKRHash会进入应用程序特定的pfnEqualKeys函数来确定键是否正确。TokenCacheModule的应用程序特定逻辑如下：

由于该逻辑比较多个部分来做出决定，很奇怪为什么IIS比较了两次用户名。我猜最初的意图是比较密码。然而，开发人员复制粘贴了代码但忘记替换变量名。这导致攻击者可以使用随机密码重用另一个用户的登录令牌。

为了构建最小的PoC来测试，您可以创建一个测试账户并在IIS上配置基本认证。

如您所见，攻击者可以使用哈希值与原始密码相同的另一个密码登录用户orange。然而，碰撞哈希并不容易。每次尝试的概率仅为1/2^32，因为哈希是32位整数，而且攻击者无法知道现有缓存键的哈希值。利用这个漏洞就像买彩票一样。唯一的优点是尝试没有任何成本，而且您有无限次尝试！

为了使这个漏洞更具实用性，我们提出了几种中奖的方法，例如：

• 增加碰撞几率 - LKRHash结合了LCGs来扰乱结果，使哈希更加随机。然而，我们可以降低键空间，因为LCG在32位整数下不是一一映射。必须有一些结果永远不会出现，因此我们可以预计算一个排除哈希不在结果中的密码的字典，并将成功率至少提高13%！
• 重获主动权 - 通过理解根本原因，我们头脑风暴了几个可以永远在内存中缓存令牌而不再等待用户交互的用例，例如IIS功能"Connect As"或利用软件设计模式。

我们还证明了这种攻击自然适用于Microsoft Exchange Server。通过利用默认激活的Exchange Active Monitoring服务，我们可以在没有密码的情况下进入HealthMailbox的邮箱！这种无需认证的账户劫持对于进一步的利用（如钓鱼或链接另一个认证后RCE）非常有用！

时间线

• 2022年3月16日 - 我们通过MSRC门户向微软报告了IIS缓存投毒
• 2022年4月9日 - 我们通过MSRC门户向微软报告了IIS哈希洪水拒绝服务攻击
• 2022年4月10日 - 我们通过MSRC门户向微软报告了IIS认证绕过
• 2022年7月12日 - 微软在7月的补丁星期二修复了所有问题

P.S. 本博客中涉及的所有漏洞均已负责任地向微软报告，并于2022年7月修补。