作者:hanwang@知道创宇404实验室
日期:2023年2月17日
漏洞介绍
-
Citrix ADC and Citrix Gateway 13.0 before 13.0-58.32 -
Citrix ADC and Citrix Gateway 12.1 before 12.1-65.25 -
Citrix ADC 12.1-FIPS before 12.1-55.291 -
Citrix ADC 12.1-NDcPP before 12.1-55.291
漏洞环境搭建
漏洞环境搭建非常复杂(甚至比漏洞分析分析耗时久:( ),在查阅大量资料后,我使用Citrix Gateway作为SAML SP,使用Microsoft Azure作为SAML IDP(可能需要高级账号)构建了SAML单点登录环境。如果使用虚拟机搭建Citrix SAML服务,需要三台虚拟机,同时比较麻烦的一点是,Citrix的SAML服务只有铂金版、企业版才能提供,因此需要相应的高级版本激活码,可以去闲鱼上找一找,好在404师傅们直接把激活流程给hack了(Orz。
-
配置详情
IP地址 | 域名 | 用途 | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-
访问方式
-
测试方式
定位漏洞程序
漏洞分析
-
绕过看门狗进程pitboss
root@ns# /netscaler/pb_policy -h nothing
Current pitboss policy is 0x29b4 (10676):
PB_ABRT_CULPRIT | PB_RESTART_CULPRIT | PB_RESTART_SYSTEM | PB_KILL_USER_PROCS | PB_WAIT_CORES | PB_REBOOT_ON_SLOW_WARMSTART | PB_REBOOT_ON_INCOMPLETE_REG
Hung processes will be sent a SIGABRT (PB_ABRT_CULPRIT).
Monitored processes which exit will be restarted up to 5 times, except for
packet engines (PB_RESTART_CULPRIT).
If pitboss decides not to restart some failing process(es) all non-failing
processes will be sent a SIGKILL (PB_KILL_USER_PROCS).
Pitboss will then wait for all core dumps to complete (PB_WAIT_CORES) and then
do a warm restart (if a packet engine failed) and otherwise reboot the system (PB_RESTART_SYSTEM).
If startup failure is detected do nothing.
If warmstart takes too long pitboss will reboot the system (PB_REBOOT_ON_SLOW_WARMSTART).
On incomplete registration of mandatory processes after warmstart pitboss will
reboot the system (PB_REBOOT_ON_INCOMPLETE_REG).
Log messages from pitboss will take the default path.
New pitboss policy is 0x29b0 (10672):
PB_RESTART_CULPRIT | PB_RESTART_SYSTEM | PB_KILL_USER_PROCS | PB_WAIT_CORES | PB_REBOOT_ON_SLOW_WARMSTART | PB_REBOOT_ON_INCOMPLETE_REG
Hung processes will be ignored.
Monitored processes which exit will be restarted up to 5 times, except for
packet engines (PB_RESTART_CULPRIT).
If pitboss decides not to restart some failing process(es) all non-failing
processes will be sent a SIGKILL (PB_KILL_USER_PROCS).
Pitboss will then wait for all core dumps to complete (PB_WAIT_CORES) and then
do a warm restart (if a packet engine failed) and otherwise reboot the system (PB_RESTART_SYSTEM).
If startup failure is detected do nothing.
If warmstart takes too long pitboss will reboot the system (PB_REBOOT_ON_SLOW_WARMSTART).
On incomplete registration of mandatory processes after warmstart pitboss will
reboot the system (PB_REBOOT_ON_INCOMPLETE_REG).
Log messages from pitboss will take the default path.
执行命令后就可以愉快的调试nsppe进程了,对freebsd的内核交互机制不太熟悉,因此就没再详细分析这种看门狗机制,后面有时间可以研究下怎么实现的。
-
diff分析
__int64 __fastcall ns_aaa_saml_entity_encode_decode(__int64 a1, __int64 a2, int a3, __int64 a4)
{
__int64 v5; // rax
__int64 v6; // rbx
__int64 v7; // rbx
int v8; // r9d
int v9; // r9d
unsigned __int16 v10; // ax
unsigned int v11; // eax
unsigned int v12; // r12d
__int64 v14; // [rsp+18h] [rbp-58h] BYREF
__int64 v15[2]; // [rsp+20h] [rbp-50h] BYREF
int v16; // [rsp+30h] [rbp-40h]
int v17; // [rsp+34h] [rbp-3Ch]
int v18; // [rsp+38h] [rbp-38h]
int v19; // [rsp+3Ch] [rbp-34h]
int v20; // [rsp+40h] [rbp-30h]
v15[0] = 0LL;
v15[1] = a1;
v16 = a3;
v17 = a3;
v18 = 4;
v19 = 22;
LOBYTE(v20) = v20 & 0xE0;
v20 = (32 * ASTR_NOT_REF_COUNTED) | v20 & 0x1F;
v5 = astr_canonicalize(*(_QWORD *)(*((_QWORD *)cur_as_partition + 2) + 8LL), 5LL, v15, a4, 0LL, 0LL);
v6 = v5;
if ( v5 )
{
ns_bcopy_(*(_QWORD *)(v5 + 8), a2, *(unsigned int *)(v5 + 16));
v12 = *(_DWORD *)(v6 + 16);
astr_destroy(*(_QWORD *)(*((_QWORD *)cur_as_partition + 2) + 8LL), 5LL, v6);
}
else
{
......// 日志记录
return 0;
}
return v12;
}
新版本12.1-65.25反汇编代码: __int64 __fastcall ns_aaa_entity_encode_decode(__int64 a1, __int64 a2, int a3, unsigned int a4, unsigned int a5)
{
__int64 v7; // rax
__int64 v8; // r12
__int64 v9; // rbx
int v10; // r9d
int v11; // r9d
unsigned __int16 v12; // ax
unsigned int v13; // eax
unsigned int v14; // ebx
unsigned int v15; // eax
__int64 v16; // rbx
int v17; // r8d
int v18; // r9d
int v19; // r8d
int v20; // r9d
unsigned __int16 v21; // ax
unsigned int v22; // eax
char v24; // [rsp+0h] [rbp-80h]
char v25; // [rsp+0h] [rbp-80h]
char v26; // [rsp+0h] [rbp-80h]
char v27; // [rsp+0h] [rbp-80h]
__int64 v28; // [rsp+18h] [rbp-68h] BYREF
__int64 v29[2]; // [rsp+20h] [rbp-60h] BYREF
int v30; // [rsp+30h] [rbp-50h]
int v31; // [rsp+34h] [rbp-4Ch]
int v32; // [rsp+38h] [rbp-48h]
int v33; // [rsp+3Ch] [rbp-44h]
int v34; // [rsp+40h] [rbp-40h]
v29[0] = 0LL;
v29[1] = a1;
v30 = a3;
v31 = a3;
v32 = 4;
v33 = 22;
LOBYTE(v34) = v34 & 0xE0;
v34 = (32 * ASTR_NOT_REF_COUNTED) | v34 & 0x1F;
v7 = astr_canonicalize(*(_QWORD *)(*((_QWORD *)cur_as_partition + 2) + 8LL), 5LL, v29, a5, 0LL, 0LL);
v8 = v7;
if ( v7 )
{
v15 = *(_DWORD *)(v7 + 16);
if ( v15 <= a4 )
{
ns_bcopy_(*(_QWORD *)(v8 + 8), a2, v15);
v14 = *(_DWORD *)(v8 + 16);
astr_destroy(*(_QWORD *)(*((_QWORD *)cur_as_partition + 2) + 8LL), 5LL, v8);
}
else
{
...... //日志记录
astr_destroy(*(_QWORD *)(*((_QWORD *)cur_as_partition + 2) + 8LL), 5LL, v8);
return 0;
}
}
else
{
...... //日志记录
return 0;
}
return v14;
}
可以发现,新版本的ns_aaa_entity_encode_decode函数多了一个a4参数,只有v15变量小于传入的a4参数值,才进行后面的ns_bcopy_内存复制函数,将astr_canonicalize函数返回的结构体偏移0x8位置指向的内存复制到参数a2指向的内存中,复制长度是上面astr_canonicalize函数返回的结构体偏移0x10的成员。对比下两个版本的astr_canonicalize函数并无明显差异。因此继续分析上层函数,查看ns_aaa_entity_encode_decode函数的交叉引用,有不少位置调用了该函数。 我们尝试在该ns_aaa_entity_encode_decode函数打个断点,通过访问https://gateway.nstest.local看能不能断下来。 (gdb) b ns_aaa_saml_entity_encode_decode
Breakpoint 1 at 0xbebfb4
(gdb) c
Continuing.
Breakpoint 1, 0x0000000000bebfb4 in ns_aaa_saml_entity_encode_decode ()
(gdb) bt
#0 0x0000000000bebfb4 in ns_aaa_saml_entity_encode_decode ()
#1 0x0000000000bf8356 in ns_aaa_saml_verify_signature ()
#2 0x0000000000c216ca in ns_aaa_saml_process_data ()
#3 0x0000000000c25577 in ns_aaa_process_saml_req ()
#4 0x0000000000c25842 in ns_aaa_saml_auth ()
#5 0x00000000007c6a45 in ns_vpn_process_unauthenticated_request ()
#6 0x000000000080a326 in ns_aaa_cookie_valid ()
#7 0x000000000081ca31 in ns_aaa_client_handler ()
#8 0x0000000001c2e6a1 in nshttp_input ()
#9 0x0000000001c2433b in nshttp_handler ()
#10 0x00000000016e495e in ns_async_restart_http ()
#11 0x0000000000bfaf40 in ns_aaa_saml_canon_resp_handler ()
#12 0x000000000079ab48 in nsaaa_handler ()
#13 0x0000000001c6d149 in nstcp_input ()
#14 0x0000000001c59e0a in handleL4Session ()
#15 0x0000000001c5724f in dispatch_tcp ()
#16 0x00000000010cf0eb in vmpe_intf_loop_rx_proc ()
#17 0x0000000001c55472 in vc_poll ()
#18 0x00000000015b5ae3 in ns_netio ()
#19 0x00000000015baf4b in packet_engine ()
#20 0x00000000019bd9a3 in ns_enter_main ()
#21 0x00000000019c1fe9 in main ()
成功断了下来,通过调用栈可以看出来这里是处理SAML响应的流程,到这里可以基本判定这里是漏洞点了。 我们继续分析新版本上层ns_aaa_saml_verify_signature函数,可以发现传入的第四个参数(即用来长度比较的参数)是0x800,第二个参数v78(即内存复制目的位置的参数)是一个栈变量,栈空间刚好是0x800大小。 而老版本直接传入了栈变量v78,到这里栈溢出已经呼之欲出了。 通过逆向分析得知该函数是对SAMLResponse进行签名验证,我们在调用ns_bcopy_位置处打个断点看看复制的源内存是什么数据。
(gdb) b *0xBEC15A
Breakpoint 1 at 0xbec15a
(gdb) c
Continuing.
Breakpoint 1, 0x0000000000bec15a in ns_aaa_saml_entity_encode_decode ()
(gdb) x/10i $rip
0xbec15a <ns_aaa_saml_entity_encode_decode+426>:
callq 0x1c5e390 <ns_bcopy_>
0xbec15f <ns_aaa_saml_entity_encode_decode+431>: mov 0x10(%rbx),%r12d
0xbec163 <ns_aaa_saml_entity_encode_decode+435>:
mov 27378486(%rip),%rax # 0x26084a0 <cur_as_partition>
0xbec16a <ns_aaa_saml_entity_encode_decode+442>: mov 0x10(%rax),%rax
0xbec16e <ns_aaa_saml_entity_encode_decode+446>: mov 0x8(%rax),%rdi
0xbec172 <ns_aaa_saml_entity_encode_decode+450>: mov %rbx,%rdx
0xbec175 <ns_aaa_saml_entity_encode_decode+453>: mov $0x5,%esi
0xbec17a <ns_aaa_saml_entity_encode_decode+458>:
callq 0x1b4b2a0 <astr_destroy>
0xbec17f <ns_aaa_saml_entity_encode_decode+463>:
jmp 0xbec187 <ns_aaa_saml_entity_encode_decode+471>
0xbec181 <ns_aaa_saml_entity_encode_decode+465>: mov $0x0,%r12d
(gdb) x/10gx $rdi
0x1115fe018: 0x5057344157596753 0x356e674e66623269
0x1115fe028: 0x7155336a5a465335 0x2f5a6c7272483653
0x1115fe038: 0x544247674f624d77 0x337a446e39775850
0x1115fe048: 0x654765743451734b 0x30756d4e5a536b4c
0x1115fe058: 0x3461474947764668 0x5a38303835356d64
(gdb) set print elements 0
(gdb) x/s $rdi
0x1115fe018: "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,也可以控制返回地址到大部分任意函数进行恶意操作。
参考文章
[1] 进宫 SAML 2.0 安全 https://paper.seebug.org/2006/ [2] How to Hunt Bugs in SAML; a Methodology – Part I https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/ [3] CitrixADC 四种常见的拓扑模式以及MIP,SNIP的区别 https://blog.csdn.net/caizhih/article/details/121261670 [4] How to Hunt Bugs in SAML; a Methodology – Part II https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/ [5] APT5: Citrix ADC Threat Hunting Guidance https://media.defense.gov/2022/Dec/13/2003131586/-1/-1/0/CSA-APT5-CITRIXADC-V1.PDF
作者名片
END
往 期 热 门 (点击图片跳转)
戳“阅读原文”更多精彩内容! 原文始发于微信公众号(Seebug漏洞平台):原创Paper | Citrix CVE-2022-27518 漏洞分析