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

大家好，这是我在Black Hat USA和DEFCON的第五次演讲。你可以在这里获取幻灯片副本和视频：

在缓存中起舞 - 破坏微软IIS哈希表的稳定性（幻灯片）在缓存中起舞 - 破坏微软IIS哈希表的稳定性（视频-待定）

作为计算机科学中最基本的数据结构，哈希表被广泛应用于计算机基础设施中，如操作系统、编程语言、数据库和Web服务器。由于它的重要性，微软从很早阶段就设计了自己的哈希表算法，并大量应用于其Web服务器IIS中。

由于IIS不公开其源代码，我认为该算法实现细节应该是发现漏洞的未探索领域。因此，这项研究主要关注哈希表的实现及其使用方式。我们还研究了缓存机制，因为IIS中大多数哈希表使用都与缓存相关！

由于大多数细节都在幻灯片中，这次请原谅我仅提供简要说明而非完整博客文章。

CVE-2022-22025 - 微软IIS哈希洪水拒绝服务攻击 CVE-2022-22040 - 微软IIS缓存投毒攻击 CVE-2022-30209 - 微软IIS身份验证绕过

1. IIS哈希洪水拒绝服务攻击

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

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

你可以在此查看完整演示视频：[视频链接]

2. IIS缓存投毒攻击

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

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

3. IIS身份验证绕过

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


CLKRHashTable::CLKRHashTable(
    this,
    "TOKEN_CACHE",   // 用于调试的标识符
    pfnExtractKey,   // 从记录中提取键
    pfnCalcKeyHash,  // 计算键的哈希签名
    pfnEqualKeys,    // 比较两个键
    pfnAddRefRecord, // 在FindKey等操作中添加引用
    4.0,             // 平均链长度的界限
    1,               // 哈希表的初始大小
    0,               // 从属哈希表的数量
    0                // 允许多个相同键？
);

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

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

![逻辑流程图]

由于该逻辑比较多个部分以做出决定，很奇怪为什么IIS比较了两次用户名。

我猜最初的意图是比较密码。然而，开发人员复制粘贴了代码但忘记更改变量名。这导致攻击者可以使用随机密码重用另一个用户的登录令牌。

要构建最小的PoC来测试你自己的环境，你可以创建一个测试账户并在IIS上配置基本身份验证。

1
2
3
4
5
6


# 添加测试账户，请确保测试后删除
> net user orange test-for-CVE-2022-30209-auth-bypass /add

# 登录来源不重要，这可以在IIS外部完成。
> curl -I -su 'orange:test-for-CVE-2022-30209-auth-bypass' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK

在攻击者终端上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 完整性检查脚本
> type test.py
def HashString(password):
    j = 0    
    for c in map(ord, password):
        j = c + (101*j)&0xffffffff
    return j

assert HashString('test-for-CVE-2022-30209-auth-bypass') == HashString('ZeeiJT')

# 成功登录前
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 401 Unauthorized

# 成功登录后
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK

如你所见，攻击者可以使用哈希值与原始密码相同的另一个密码登录用户orange。

然而，碰撞哈希并不容易。每次尝试的概率仅为1/2^32，因为哈希是32位整数，而攻击者无法知道现有缓存键的哈希值。利用这个漏洞就像买彩票一样，唯一的优点是尝试没有任何成本，而且你有无限次尝试！

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

增加碰撞几率 - LKRHash结合了LCG来扰乱结果，使哈希更随机。然而，我们可以降低键空间，因为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月补丁星期二修复了所有问题

深入微软IIS缓存：哈希表漏洞分析与利用

本文深入分析了微软IIS服务器中哈希表实现的安全漏洞，包括哈希洪水拒绝服务攻击、缓存投毒攻击和身份验证绕过漏洞，揭示了这些漏洞的技术原理和实际影响，所有漏洞均已获得微软官方修复。

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

1. IIS哈希洪水拒绝服务攻击

2. IIS缓存投毒攻击

3. IIS身份验证绕过

时间线