漏洞描述

组件: Citrix:NetScaler ADC 13.1-FIPS, Citrix:NetScaler ADC 12.1-FIPS, Citrix:NetScaler ADC 12.1-NDcPP, Citrix:NetScaler ADC 和 NetScaler Gateway

漏洞类型: 越界写入, 越界读取

实际影响: 信息泄漏

主要影响: 敏感数据窃取

CVSS评分：9.4

简述: 该漏洞存在于Citrix NetScaler ADC 和 Gateway 设备中，是一个信息泄露漏洞。要利用该漏洞，需要将设备配置为网关（VPN 虚拟服务器、ICA 代理、CVPN、RDP 代理）或授权和计费 (AAA) 虚拟服务器。未授权的远程攻击者可通过利用此漏洞，窃取敏感信息。

修复版本 13.1 49.13/49.15 - 更新日期：2023.10.10

参考链接：https://support.citrix.com/article/CTX579459/netscaler-adc-and-netscaler-gateway-security-bulletin-for-cve20234966-and-cve20234967

本篇漏洞分析很多地方也得益于与ChaMD5的其他师傅的讨论、帮助和发现！

补丁DIFF

DIFF了13.1 49.13和13.1 49.15中的nsppe二进制程序后，bindiff的结果如下，再以aaa作为关键字筛选一波，逐个查看则很容易发现可疑的Patch点，添加了经典的长度检查。

漏洞点Patch确认

其中有两个函数：ns_aaa_oauthrp_send_openid_config和ns_aaa_oauth_send_openid_config函数跟AAA相关并且其Diff的位置非常可疑；如下两个图中所示，红框内为新版本增加的对于snprintf返回的完成拼接后字符串的长度限制的条件判断；

关于snprintf的第二个参数的长度限制和snprintf的返回值的差别，可以参考这篇文章（https://blog.51cto.com/u_15006953/2552122）。

我们关注到snprintf中第二个参数的0x20000仅仅是把拼接后的字符串截取前0x20000字节的内容存储到print_temp_rule变量中，仅起到这这样的限制作用；

而其snprintf的返回值则是将字符串完成格式化拼接和填充后整个字符串（不会截取）的长度。

因此在拼接的字符串超过0x20000的时候，print_temp_rule字符串大小为0x20000，而v12（图3）的值则大于0x20000，而ns_vpn_send_response函数则是打印内存中以print_temp_rule为起始地址，v12为打印长度的所有内存信息，因此会将print_temp_rule后面的内存信息也泄露出来。

漏洞函数uri确认

上层函数巨大无比，IDA反编译得十多分钟，但跟到上一层就可以直接确定访问接口

因此很容易确认以上两个patch，对应着以下两个url（192.168.147.111为Citrix的gateway口，配置方法这里省略）：

https://192.168.147.111/oauth/idp/.well-known/openid-configuration
https://192.168.147.111/oauth/rp/.well-known/openid-configuration

尝试访问这两个URL可以确认起返回的内容就是snprintf拼接后的字符串信息。

这里有两个Patch，但只有idp那个url能泄露出来cookie，往下看就知道了，因为他会格式化字符串拼接6次IP/域名，导致泄露后面更多的信息，而另外一个只会拼接3次！

调试

nsppe调试需要解决看门狗，参考这篇文章（https://paper.seebug.org/2049/#pitboss）来解决即可，目前在Citrix上似乎用不了gdbserver来调试nsppe，能用的师傅教教！！

不过这个洞调试或者不调试都无关紧要，可以以下三个关键位置下了断点，主要可以用来观察，泄露的内存信息

# cmp v13 - r
b *0x13A8FB6

# call snprintf
b *0x13A9049

# call ns_vpn_send_response; set $rcx=0x90000
b *0x13a906d

通过调试或者猜测他们所拼接的是请求头中Host字段的内容，则我们尝试将其使用超长字符串进行Padding，我们通过反复测试，最后发现，Host字段最多仅能设置长度为0x60ec的字符串，因此我们构造了以下Packet：

GET /oauth/idp/.well-known/openid-configuration HTTP/1.1
Host: a <repeated 0x60ec times>
Connection: close

使用bp执行，返回结果如下：

由此可看，我们可以泄露一些内存上的值，大约是额外0x4900字节的内存信息。另外，我们在调试这个洞的过程中，发现如果能泄露更长的内容的话（可以用gdb把泄露长度改大），甚至可以泄露出web管理员界面的明文密码，这也是一个非常吸引人的能力，但我们想了很多方法都没办法获得更长的内存泄露。

基于目前的漏洞能力，我们猜测如果能成功登录gateway的话，或许我们能实现cookie的泄露，并实现会话劫持的效果，因此我们需要一个更完善的环境，至少是一个可以成功登录的环境。

环境搭建与漏洞复现

比对和CVE-2023-3519的漏洞信息，发现先决条件一致，因此也需要配置gateway口。

这里省略这块的配置，可以参考这篇文章（https://blog.51cto.com/181647568/2483430），这一步环境配置相对比较繁琐。

另外关于在虚拟机环境配置中，由于涉及到cookie的泄露，因此大概率需要登录成功，才能泄露cookie。那怎样添加用户来使得可以成功登录，这里总结了几个需要注意的地方，这里是用本地用户进行认证（LDAP、AAA那些环境搭建更复杂一些）：

需要在Citrix Gateway选项卡中配置AAA Group和AAA User

1. 注意配置AAA Group中需要配置Policies（随便select一个，比如ns_true），然后再随便bind一个就行其实，不然会报以下第一张截图的错误；
2. 注意配置AAA Group中需要配置一个Intranet IP，不然登录会报以下第二张错误，IP随便配一个就行，比如10.10.0.1，255.255.255.0
3. 完成配置后登录，出现以下第三张截图就算登录成功了，这时候再攻击已经能泄露出来cookie了

成功登录后，测试，成功泄露cookie！！！这里可以看到cookie是65位的（好像也有32位的），我们可以简单写一个cookie的正则匹配就可以实现一个自动化泄露cookie的脚本

最后，我们验证泄露的cookie是否能成功登录gateway：