Orange: Let’s Dance in the Cache - 破坏微软IIS哈希表的稳定性！

这是Orange的分享 :)

2022年8月18日星期四

大家好，这是我第五次在Black Hat USA和DEFCON演讲。您可以在以下链接获取幻灯片和视频：

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

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

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

CVE-2022-22025 - Microsoft IIS哈希洪水拒绝服务攻击
CVE-2022-22040 - Microsoft IIS缓存投毒攻击
CVE-2022-30209 - Microsoft 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: Let’s Dance in the Cache - 破坏微软IIS哈希表的稳定性！

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

2. IIS缓存投毒攻击

3. IIS认证绕过

时间线