Citrix CVE-2022-27518 漏洞分析

漏洞介绍

Citrix在2022年12月份发布了CVSS评分9.8的CVE-2022-27518远程代码执行漏洞通告，距今已经过去两个多月了，由于漏洞环境搭建较为复杂，一直没有相关的分析文章。经过一段时间的diff分析及验证后，发现漏洞成因在于Citrixnetscaler在解析SAMLxml时对SignatureValue字段校验不严格导致了栈溢出。

漏洞影响版本：

CVE-ID

Description

CWE

AffectedProducts

Pre-conditions

CVE-2022-27518

Unauthenticatedremotearbitrarycodeexecution

CWE-664:ImproperControlofaResourceThroughitsLifetime

CitrixGateway,CitrixADC

CitrixADCorCitrixGatewaymustbeconfiguredasaSAMLSPoraSAMLIdP

根据披露信息，只有当ADC或者Gateway配置为SAMLSP（资源提供方服务器）或者SAMLIdP（身份认证服务器）时，才会受到漏洞影响。

不熟悉SAML协议流程的可以参考[1][2]，本文不再详细阐述，基本的认证流程如下：

漏洞环境搭建

漏洞环境搭建非常复杂（甚至比漏洞分析分析耗时久:(），在查阅大量资料后，我使用CitrixGateway作为SAMLSP，使用MicrosoftAzure作为SAMLIDP（可能需要高级账号）构建了SAML单点登录环境。如果使用虚拟机搭建CitrixSAML服务，需要三台虚拟机，同时比较麻烦的一点是，Citrix的SAML服务只有铂金版、企业版才能提供，因此需要相应的高级版本激活码，可以去闲鱼上找一找，好在404师傅们直接把激活流程给hack了(Orz。

具体搭建过程可以参考后面的文章。

配置详情

配置后的网络拓补图如下[3]，三台虚拟机在同一内网环境中，分别对应NSIP、MIP(SNIP)、VIP。其中NSIP是CitrixADC/Gateway设备的自身IP，用于管理、对NetScaler自身进行常规访问以及在高可用性配置中实现设备间通信的IP地址；MIP是映射IP，是设备向后端真实服务器发送请求包中的源地址。VIP是虚拟服务器IP，客户对可以对其直接进行访问，真正响应的请求是其后端的众多真实服务器。管理多种流量的一个设备可配置有多个VIP。

还需要一台域控服务器用来给Citrix服务器发放证书。（理论上来说自签名证书也可以，我直接构建了一个DNS通配符证书，可以参考CreateaWildcardCertificateusingMMCinWindowsServer2019-YouTube）

在我的环境中配置清单如下：

IP地址

域名

用途

10.0.25.171

NSIP

10.0.25.172

MIP

10.0.25.173

VIP

WindowsServer2019

10.0.25.174

域控服务器，用于给Citrix服务器发放证书

Windows11

10.

本机Client机器，能够访问CitrixVIP即可

由于SAML服务需要使用域名进行访问，还需要在本机hosts文件中新加入一个DNS解析条目

访问方式

当我们访问时，浏览器会自动跳转到Microsoft的认证界面

输入用户名密码后，会重定向到Gateway的管理界面，到这里就算搭建成功了。

测试方式

推荐使用BurpSuite的SAMLRaider:SAML2BurpExtension插件进行渗透测试[4]，可以很方便地编码解码并修改认证请求包和认证响应包，我们可以设置参数过滤只用来捕获SAML认证过程中的SAMLResponse包，这是IDP认证后通过浏览器发给登录服务的认证响应包，包含了关键的身份认证信息。

如下所示，这个插件可以很方便地修改SAML断言信息，还可以进行常用的SAML攻击。（在Citrix环境下，我测试了所有的这些攻击，都能够被Citrix过滤）

定位漏洞程序

在漏洞通告刚发布时，Citrix官网删除了受漏洞影响版本的上一版本的下载链接，给漏洞diff分析造成了一定困难，而近期Citrix官网放出了距受漏洞影响版本的较近版本12.1-64.17，故重新从diff层面对其分析。

下载（受影响）和（修复版本）对应的虚拟机镜像，运行后尝试通过挂载提取文件，由于文件系统不同，此种方法较为复杂。所幸Gateway支持ssh连接，可以通过ssh提取出相关文件。

根据NSA披露的缓解措施[5]判断很可能是netscaler组件的nsppe文件出问题，如下图所示。同时根据信息可以推断很可能是缓冲区溢出类型的漏洞。

漏洞分析绕过看门狗进程pitboss

CitrixGateway虚拟机中自带gdb工具，虽然版本有点低而且缺少很多命令，但也将就能用。当我尝试用gdb对nsppe进程进行attach时，发现一旦attach该进程，该进程就会自动重启，看来是有反调试。

通过查看dmesg系统日志得知，有一个pitboss进程会接收nsppe进程的心跳包，如果心跳包丢失超过一定阈值，pitboss进程会向nsppe进程发信号终止掉进程然后重启该进程，当gdb对nsppe进程attach时导致nsppe进程被挂起，pitboss进程接收不到心跳包了也就重启nsppe进程，这就导致无法正常调试nsppe进程。

推测系统应该有自带的工具可以更改这些策略。找了一下果然发现netscaler目录下的pb_policy程序可以设置这些策略，忽略进程挂起的命令如下所示：

root@ns00x0000000000bebfb4inns_aaa_saml_entity_encode_decode()20x0000000000c216cainns_aaa_saml_process_data()40x0000000000c25842inns_aaa_saml_auth()60x000000000080a326inns_aaa_cookie_valid()80x0000000001c2e6a1innshttp_input()100x00000000016e495einns_async_restart_http()120x000000000079ab48innsaaa_handler()140x0000000001c59e0ainhandleL4Session()160x00000000010cf0ebinvmpe_intf_loop_rx_proc()180x00000000015b5ae3inns_netio()200x00000000019bd9a3inns_enter_main()0x26084a0cur_as_partition0xbec16ans_aaa_saml_entity_encode_decode+442:mov0x10(%rax),%rax0xbec16ens_aaa_saml_entity_encode_decode+446:mov0x8(%rax),%rdi0xbec172ns_aaa_saml_entity_encode_decode+450:mov%rbx,%rdx0xbec175ns_aaa_saml_entity_encode_decode+453:mov$0x5,%esi0xbec17ans_aaa_saml_entity_encode_decode+458:callq0x1b4b2a0astr_destroy0xbec17fns_aaa_saml_entity_encode_decode+463:jmp0xbec187ns_aaa_saml_entity_encode_decode+4710xbec181ns_aaa_saml_entity_encode_decode+465:mov$0x0,%r12d(gdb)x/10gx$rdi0x1115fe018:0x50573441575967530x356e674e666232690x1115fe028:0x7155336a5a4653350x2f5a6c72724836530x1115fe038:0x544247674f624d770x337a446e397758500x1115fe048:0x654765743451734b0x30756d4e5a536b4c0x1115fe058:0x346680x5a38303835356d64(gdb)setprintelements0(gdb)x/s$rdi0x1115fe018:"SgYWA4WPi2bfNgn55SFZj3UqS6HrrlZ/wMbOgGBTPXw9nDz3KsQ4teGeLkSZNmu0hFvGIGa4dm55808Zuikx4s1rIbTiuyw1z5VkZGuXLl31mObPvrbowtqoBgaeTfAwImtJrw4g2kQoe35b/Z0AgSlu9/LxKRKTaG1jYk6chGNJpKTBCmEqRWKFtJsPjnB9xkAiYspO1T2AsgR9KAq9+cV93X/ZtPkfutRj4IaI3LcMnDxQ+9Pb75HYBZ9LYVqOPGowGVf/Opz40VU6xyWzRlg45ouEHTFS45xCPCe/eQe3mPjsp/kMGsM2e6611stx3Isu+GMgwDGd5hlRp4lFdQ=="

复制的源数据是一串字符串，我们前往burp中看一下流量包刚好是SignatureValue字段中的数据，因此很自然地想到构造超长字符串替换SignatureValue标签的内容。

前面我们看到v78变量距离栈底部0x890字节，因此构造如下内容：'A'*0x890+'B'*8+'C'*8放入SignatureValue标签中，然后在ns_aaa_saml_verify_signature函数最后一条ret指令打个断点

成功验证了栈溢出漏洞存在

漏洞利用

查看下nsppe进程的保护机制，没有canary，栈可执行，程序没有aslr无需泄露基址，可控栈空间很大，似乎是很容易利用。

但很快就发现事情似乎没那么简单，Citrix接收到html中的SAMLResponse响应后，将响应base64解码后转换为xml文本，而根据W3C的标准，以下\x00-\x08?\x0b-\x0c?\x0e-\x1f16进制的字符是不被允许出现在XML文件中的，即使放在![CDATA[]]中，也不能幸免。

也就是说，我们只能控制栈变量到返回地址之间的栈空间，且可控的栈内容不能包含以上字符，因此只能放入经过编码的shellcode。而我们的程序高地址都是\x00，也无法在栈中构造ROP链，只有一次覆盖返回地址低位3字节的机会。

可以寻找到合适的gadget将控制流转移到可控栈空间内实现RCE，也可以控制返回地址到大部分任意函数进行恶意操作。

参考文章

from

很赞哦!（73）