CVE-2018-0296 Cisco ASA 拒绝服务漏洞分析

发表于 更新于 分类于 评论：

漏洞简介

CVE-2018-0296是思科ASA设备Web服务中存在的一个拒绝服务漏洞，远程未认证的攻击者利用该漏洞可造成设备崩溃重启。该漏洞最初由来自Securitum的安全研究人员Michal Bentkowski发现，其在博客中提到该漏洞最初是一个认证绕过漏洞，上报给思科后，最终被归类为拒绝服务漏洞。据思科发布的安全公告显示：针对部分型号的设备，该漏洞可造成设备崩溃重启；而针对其他型号的设备，利用该漏洞可获取设备的敏感信息，造成信息泄露。

针对该漏洞，目前已有公开的PoC脚本，可用于获取设备的敏感信息如用户名，或造成设备崩溃重启。经过实际测试，在公开PoC中造成该漏洞的关键url如下。

1
https://<ip>:<port>/+CSCOU+/../+CSCOE+/files/file_list.json?path=/

下面利用思科ASA设备和已有的PoC脚本，对该漏洞的形成原因进行分析。

背景知识

在实际对漏洞进行分析的过程中，发现思科ASA设备的lina程序中，存在大量的Lua脚本以及对Lua api的调用。为了便于理解，下面对Lua脚本的相关知识进行简单介绍。

Lua脚本和C/C++交互

Lua是一个小巧的脚本语言，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。Lua脚本可以很容易被C/C++代码调用，也可以反过来调用C/C++的函数，这使得Lua在应用程序中可以被广泛使用。不仅可作为扩展脚本，也可以作为普通的配置文件，代替XML、ini等文件格式，并且更容易理解和维护。

Lua和C/C++通信的主要方式是一个虚拟栈，其特点是后进先出。在Lua中，Lua栈就是一个struct，栈的索引可以是正数也可以是负数，其中正数索引1永远表示栈底，负数索引-1永远表示栈顶，如下图所示。

Lua中的栈在stack_init()函数中创建，其类似于下面的定义。

1
TObject stack[BASIC_STACK_SIZE + EXTRA_STACK]

在Lua中，可以往栈上压入字符串、数值、表和闭包等类型，最后统一用Tobject这种数据结构进行保存，如下。TObject结构对应于Lua中所有的数据类型，是一个{值，类型}结构，它将值和类型绑在一起。其中用tt表示value的类型，value是一个联合体，共有4个域，说明如下。

  • p：可以保存一个指针，实际上指向Lua中的light userdata结构
  • n：保存数值，包括int、float等类型
  • b：保存布尔值
  • gc：保存需要内存管理垃圾回收的类型如string、table、closure等
1
2
3
4
5
6
7
8
9
10
11
12
// lua 数据类型
#define LUA_TNONE			(-1)

#define LUA_TNIL			0	// 空值
#define LUA_TBOOLEAN			1
#define LUA_TLIGHTUSERDATA		2
#define LUA_TNUMBER			3
#define LUA_TSTRING			4
#define LUA_TTABLE			5
#define LUA_TFUNCTION			6
#define LUA_TUSERDATA			7
#define LUA_TTHREAD			8

Lua 栈操作常用api

Lua中提供了一系列与栈操作相关的api，常用的api如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 压入元素
void lua_pushnil (lua_State *L);
void lua_pushboolean (lua_State *L, int bool);
void lua_pushnumber (lua_State *L, double n);
void lua_pushlstring (lua_State *L, const char *s, size_t length);
void lua_pushstring (lua_State *L, const char *s);

// 检查一个元素是否是一个指定的类型
int lua_is* (lua_State *L, int index);	// *可以是任何类型

// 获取元素
int           lua_toboolean (lua_State *L, int index);
double        lua_tonumber (lua_State *L, int index);
const char *  lua_tostring (lua_State *L, int index);
size_t        lua_strlen (lua_State *L, int index);

环境准备

调试环境搭建

由于该漏洞在不同型号设备上表现的行为不一致，这里分别选取了32位的设备和64位的设备，相关信息如下。其中，前面2个设备用于漏洞分析，设备asav9101用于补丁分析。

  • 真实设备ASA 5505，镜像为asa924-k8.bin ，32bit
  • GNS3仿真设备，镜像为asav962.qcow2，64bit
  • GNS3仿真设备，镜像为asav9101.qcow2，64bit

ASA设备中内置了gdbsever，但默认不启动。为了对设备进行调试，需要修改镜像文件以启动gdbserver。同时，由于ASA设备会对镜像文件进行完整性校验，所以修改后的镜像文件无法直接通过tftp或ASDM工具传入设备。ASA使用CF卡作为存储设备，可以通过用CF卡读卡器直接将镜像写入CF卡中的方式绕过校验，因为ASA没有对CF中的镜像进行校验。

详细的调试环境搭建和镜像修改等内容可以参考nccgroup的系列博客.

设备配置

思科ASA设备会在443端口提供Web服务。笔者在进行测试时，对设备的WebVPN功能(Clientless SSL VPN)进行了配置，使得可以访问Web服务，进而触发该漏洞。详细的配置操作可参考思科相关文档。

漏洞分析

环境搭建好后，运行已有的PoC脚本，针对asa924设备，会造成敏感信息泄露，而针对asav962设备，会造成设备崩溃重启。下面基于asav962设备，重点对拒绝服务漏洞进行分析。

崩溃分析

运行PoC脚本，在gdb中捕获到如下错误。可以看到，崩溃点在libc.so.6库中的strlen()函数里，由于在0x7ffff497699a处尝试访问一个非法的内存地址0x13，故产生Segmentation fault错误，而rax的值来源于strlen()函数的参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1677]
0x00007ffff497699a in strlen () from ***/_asav962.qcow2.extracted/rootfs/lib64/libc.so.6
(gdb) x/10i $rip
=> 0x7ffff497699a <strlen+42>:  movdqu xmm12,XMMWORD PTR [rax]
   0x7ffff497699f <strlen+47>:  pcmpeqb xmm12,xmm8
   0x7ffff49769a4 <strlen+52>:  pmovmskb edx,xmm12
   0x7ffff49769a9 <strlen+57>:  test   edx,edx
   0x7ffff49769ab <strlen+59>:  je     0x7ffff49769b1 <strlen+65>
   0x7ffff49769ad <strlen+61>:  bsf    eax,edx
   0x7ffff49769b0 <strlen+64>:  ret
   0x7ffff49769b1 <strlen+65>:  and    rax,0xfffffffffffffff0
   0x7ffff49769b5 <strlen+69>:  pcmpeqb xmm9,XMMWORD PTR [rax+0x10]
   0x7ffff49769bb <strlen+75>:  pcmpeqb xmm10,XMMWORD PTR [rax+0x20]
(gdb) i r $rax
rax            0x13     19
(gdb) bt
#0  0x00007ffff497699a in strlen () from ***/_asav962.qcow2.extracted/rootfs/lib64/libc.so.6
#1  0x0000555557ee51ce in lua_pushstring ()
#2  0x00005555583c87d2 in webvpn_file_name ()
#3  0x0000555557eec43b in luaD_precall ()
#4  0x0000555557efc258 in luaV_execute ()
#5  0x0000555557eeced0 in luaD_call ()
#6  0x0000555557eebeda in luaD_rawrunprotected ()
#7  0x0000555557eed323 in luaD_pcall ()
#8  0x0000555557ee5de6 in lua_pcall ()
#9  0x0000555557f00821 in lua_dofile ()
#10 0x000055555822053b in aware_run_lua_script_ns ()
#11 0x0000555557dc6e3d in ak47_new_stack_call ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

根据栈回溯信息，查看函数lua_pushstring()和webvpn_file_name()，其部分伪代码片段如下。在函数webvpn_file_name()中，将v1 + 0x13这个指针作为参数传递给lua_pushstring()，最终传递给strlen()函数。崩溃点处访问的非法内存地址为0x13，说明v1=0，即在webvpn_file_name()中lua_touserdata()返回值为NULL(也就是0)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
_DWORD *__fastcall lua_pushstring(__int64 a1, const char *a2)
{
  size_t v2; // r14
  __int64 v3; // r13
  _DWORD *result; // rax

  if ( a2 )
  {
    v2 = _wrap_strlen(a2);
    // ...
}

signed __int64 __fastcall webvpn_file_name(_QWORD *a1)
{
  signed __int64 v1; // rax

  v1 = lua_touserdata(a1, 1);
  lua_pushstring((__int64)a1, (const char *)(v1 + 0x13));
  return 1LL;
}

由前面lua的相关知识可知，函数lua_touserdata()用于获取栈底数据。因此，很自然的想法就是分析这个NULL值是从哪里来的，即在什么地方通过调用lua_pushnil()往栈上压入了NULL值。

静态分析

通过查找字符串/+CSCOE+/files/file_list.json的交叉引用定位到aware_webvpn_content()函数。在该函数中可以看到有很多请求url的字符串，同时还包含很多lua脚本的名称，猜测该函数应该是负责对这些请求进行处理，根据不同的请求url执行对应的lua脚本。示例如下。

查看files_list_json_lua脚本的内容，其主要功能是列出当前路径下的目录或文件，依次调用了Lua中的OPEN_DIR()、READ_DIR()、FILE_NAME()、FILE_IS_DIR()等函数。而在aware_addlib_netfs()函数中，建立了Lua函数和C函数之间的对应关系，示例如下。

1
2
3
4
5
// Lua函数与C函数对应关系
OPEN_DIR()  	<--->		webvpn_open_dir()
READ_DIR()		<--->		webvpn_read_dir()
FILE_NAME()		<--->		webvpn_file_name()
FILE_IS_DIR()	<--->		webvpn_file_is_dir()

在查看对应的C函数时，在webvpn_read_dir()函数中，有一个对lua_pushnil()函数的调用。根据函数的调用顺序，猜测webvpn_file_name()函数中获取到的NULL值来自于这里。

动态分析

根据之前的猜测，尝试在调用lua_pushnil()处下断点，然后查看Lua栈上的数据，如下。

其中，rdi指向的数据结构的定义大致如下，这里主要关注其中的lua_stack_top_ptr和lua_stack_base_ptr两个指针，分别指向Lua栈的栈顶和栈底，栈中的元素就是前面提到的{类型，值}结构。

1
2
3
4
5
6
7
8
9
10
11
struct {
    uint64 xxx;
    uint64 xxx;   
    uint64 lua_stack_top_ptr;    // 指向栈顶   (空栈，即始终指向刚入栈元素的下一个位置)
    uint64 lua_stack_base_ptr;   // 指向栈底   (栈地址由低向高增长)
    uint64 xxx;
    uint64 xxx;
    uint64 xxx;
    uint64 xxx;
    ... 
}

之后在webvpn_file_name()中调用lua_touserdata()函数前下断点，查看此时Lua栈上的内容，如下。此时，lua_touserdata()函数的第2个参数为1，即获取Lua栈底的数据，而此时栈底的数据为NULL。

继续单步执行程序，查看函数lua_touserdata()的返回值。可以看到，其返回值确实为NULL，之后将一个非法内存地址0x13作为参数传入了lua_pushstring()，最终导致Segmentation fault错误。

但是，这里的NULL值并不是来自之前lua_pushnil()压入的nil值，而是位于其下面的栈元素。在下断点调试的过程中，发现设置的2个断点均只命中一次就触发了问题，极大地缩小了调试的范围。同时，在2个断点处Lua栈的地址是一样的，因此可以在第1个断点命中后，对相应的Lua栈地址设置硬件断点，看在哪个地方对其值进行了修改。

在gdb中设置硬件断点后，继续执行时提示如下错误。网上查找相应的解决方案，建议使用set can-use-hw-watchpoints 0，但实际测试时貌似也存在问题。最后采用hook-stop的方式来观察指定地址处的内容。

1
2
3
define hook-stop
	x/2gx <addr>
end

通过设置断点并查看相应地址处的内容，最终定位到修改内容的地方位于luaV_execute()中。对照lua-5.0源码，luaV_execute()函数是Lua VM执行字节码的入口，修改内容的地方位于OP_GETGLOBAL操作码的处理流程中。

asav962与asa924执行流程对比

前面的分析定位到了luaV_execute()函数中，而该函数属于Lua VM的一部分，难道是因为files_list_json_lua脚本存在问题，而导致Lua VM执行字节码时出现错误？由于该拒绝服务漏洞对型号为asa924的设备没有影响，下面对asa924设备上对应的执行流程进行分析。

根据前面的分析思路，在webvpn_file_name()中设置断点，发现其流程与asav962类似，lua_touserdata()函数的返回值同样会为NULL，而asa924设备却不会发生崩溃。2个webvpn_file_name()的对比如下。

通过调试可知，针对32位程序(asa924)，lua_touserdata()函数的返回值为指向字符串的指针。当该指针为空时，其直接作为参数传入lua_pushstring()，而在lua_pushstring()中会对参数是否为空进行判断。而针对64位程序(asav962)，lua_touserdata()函数的返回值为指向某个结构体的指针。当该指针为空时，传入lua_pushstring()的参数为0x13，从而”绕过“了lua_pushstring()中的校验，最终造成非法内存地址访问。

至此，分析清楚了该拒绝服务漏洞产生的原因，主要是由于32位程序和64位程序中lua_touserdata()函数的返回值代表的结构不一致造成的。

补丁分析

在镜像asav9101.qcow2中该漏洞被修复了。基于前面对漏洞形成原因的分析，下面以asav9101.qcow2镜像为例，对漏洞的修复情况进行简单分析。

目录遍历漏洞补丁分析

通过动态调试分析，对请求url的解析在UrlSniff_cb()函数中完成，其中增加了对./和../的处理逻辑，部分代码如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
v16 = *v5;		// v5 指向请求url
v17 = v5;
v18 = v5;
LABEL_45:
while ( v16 )
{
if ( v16 == '.' )
{
    v20 = v18[1];
    switch ( v20 )
    {
    case '.':
        v9 = (unsigned __int8)v18[2];
        if ( !(_BYTE)v9 )
        goto LABEL_75;
        if ( (_BYTE)v9 == '/' )
        {
        v20 = v18[3];	// 匹配到"../"
        v18 += 2;
LABEL_75:
        ++v18;
        v16 = v20;
        goto LABEL_45;
        }
        break;
    case '/':
        v16 = v18[2];	// 匹配到"./"
        v18 += 2;
        goto LABEL_45;
    case '\0':
        ++v18;
        goto LABEL_60;
    }
    do
    {
LABEL_48:

拒绝服务漏洞补丁分析

根据前面的分析可知，拒绝服务漏洞的触发位置在函数webvpn_file_name()中。在镜像asav9101.qcow2中，该函数内容如下，可以看到并没有对该函数进行更改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
webvpn_file_name proc near
; __unwind {
push    rbp
mov     esi, 1
mov     rbp, rsp
push    rbx
mov     rbx, rdi
sub     rsp, 8
call    lua_touserdata
mov     rdi, rbx
lea     rsi, [rax+13h]
call    lua_pushstring
add     rsp, 8
mov     eax, 1
pop     rbx
pop     rbp
retn
; }

在字符串列表中查找/+CSCOE+/files/file_list.json显示没有结果，表明在该镜像中将这个接口去掉了。同时根据之前files_list_json_lua脚本的内容进行查找，在该镜像中仍然可以找到对应的lua脚本内容，但是找不到对该脚本的交叉引用，进一步证实该接口/+CSCOE+/files/file_list.json被去掉了。

小结

  • 利用CVE-2018-0296漏洞，远程未认证的攻击者可以对目标设备实施拒绝服务攻击，或从设备获取敏感信息。
  • 拒绝服务漏洞的形成原因是由于32位程序和64位程序中lua_touserdata()函数的返回值代表的结构不一致造成。
  • 在镜像asav9101.qcow2中已经修复了该漏洞，其中拒绝服务漏洞的修复方式是去掉了触发了该漏洞的请求url接口。

相关链接

  • Cisco Adaptive Security Appliance Web Services Denial of Service Vulnerability
  • Error description CVE-2018-0296 - bypassing authentication in the Cisco ASA web interface
  • Cisco Adaptive Security Appliance - Path Traversal
  • Test CVE-2018-0296 and extract usernames
  • Lua和C++交互详细总结
  • 网络设备漏洞分析技术研究
  • Cisco ASA series part one: Intro to the Cisco ASA

本文首发于安全客，文章链接：https://www.anquanke.com/post/id/171916