跳转到帖子

Apache HTTP Server 路径穿越漏洞 CVE-2021-41773/CVE-2021-42013 验证与排查

精选回复

发布于

背景

Apache HTTP Server 2.4.49 在路径规范化逻辑中引入回归,攻击者可利用编码后的点号绕过目录穿越检查,对 Alias 或 ScriptAlias 映射目录之外的文件进行访问,对应 CVE-2021-41773。2.4.50 的修复不完整,仍可通过二次编码绕过,对应 CVE-2021-42013。上游在 2.4.51 中完成修复。

漏洞是否能实际利用,不只取决于版本。目标还需要存在可到达的 Alias、ScriptAlias 或类似映射,并且对应目录权限配置允许访问。若同时启用 CGI 执行能力,风险可能从任意文件读取扩大到命令执行。本文仅在授权测试环境中使用无敏感内容的标记文件验证文件越界访问,不提供命令执行载荷。

影响范围

  • Apache HTTP Server 2.4.49:受 CVE-2021-41773 影响。
  • Apache HTTP Server 2.4.50:受 CVE-2021-42013 影响。
  • Apache HTTP Server 2.4.51 及以上上游版本:已修复。
  • 2.4.48 及更早版本不受这次路径规范化回归影响,但仍应处理其他历史漏洞。
发行版经常对旧版本号进行安全补丁回移,因此不能只比较 httpd -v 的版本字符串。需要结合 RPM/DEB 安全公告、包修订号及变更记录判断。

问题定位

先确认实际运行的二进制、加载配置和模块,避免只检查安装包但遗漏容器、手工编译版本或旧进程。

apachectl -v 2>/dev/null || httpd -v
apachectl -V 2>/dev/null || httpd -V
apachectl -t -D DUMP_VHOSTS
apachectl -t -D DUMP_RUN_CFG

# Debian/Ubuntu
dpkg-query -W 'apache2*' 2>/dev/null
apt changelog apache2 2>/dev/null | grep -Ei 'CVE-2021-41773|CVE-2021-42013'

# RHEL/CentOS/Rocky/AlmaLinux
rpm -q httpd
rpm -q --changelog httpd | grep -Ei 'CVE-2021-41773|CVE-2021-42013'

如果服务位于容器中,还应在容器内部检查,而不是仅查看宿主机软件包:

docker ps --format '{{.ID}} {{.Image}} {{.Names}}'
docker exec <container_id> httpd -v
docker exec <container_id> httpd -M

关键配置排查

重点检查 Alias、ScriptAlias、Directory、Require、Options ExecCGI 和 CGI 模块。不同发行版配置目录不同,以下命令覆盖常见路径:

grep -RniE '^[[:space:]]*(Alias|ScriptAlias|Require|Options|AddHandler|SetHandler)' \
  /etc/httpd /etc/apache2 /usr/local/apache2/conf 2>/dev/null

apachectl -M 2>/dev/null | grep -Ei 'alias|cgi|cgid|proxy_fcgi'

find /etc/httpd /etc/apache2 /usr/local/apache2/conf \
  -type f \( -name '*.conf' -o -name 'httpd.conf' \) \
  -print 2>/dev/null

以下配置组合需要重点关注:

ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/

<Directory /usr/local/apache2/cgi-bin>
    Require all granted
    Options +ExecCGI
</Directory>

# 尤其危险:对文件系统根目录或过宽目录直接放行
<Directory />
    Require all granted
</Directory>

漏洞的核心是请求路径在解码、规范化和文件系统映射之间出现不一致。2.4.49 对编码点号处理不完整,2.4.50 又未完全覆盖二次编码场景。Alias 或 ScriptAlias 提供了文件系统映射入口,宽松的 Require 规则决定越界后的目标是否能被读取。

授权环境中的无害验证

验证前应确认目标属于测试范围,并优先在快照、容器或隔离虚拟机中进行。不要直接读取 passwd、SSH 密钥、应用配置或云凭据。可由系统管理员在服务器上创建专用标记文件:

printf 'CVE-41773-LAB-MARKER\n' > /tmp/cve-41773-marker.txt
chmod 0644 /tmp/cve-41773-marker.txt

针对明确为 Apache 2.4.49 的实验实例,可从已知 ScriptAlias 入口发出单次验证请求。curl 必须使用 --path-as-is,否则客户端可能先规范化路径。目录层数需要根据实际 ScriptAlias 路径调整:

curl --path-as-is -i \
  ' CVE-41773-LAB-MARKER,说明请求已越过映射目录并访问到文件系统中的标记文件,可判定漏洞利用条件成立。验证完成后删除标记文件:

rm -f /tmp/cve-41773-marker.txt

返回 403、404 或 500 不能单独证明不存在漏洞。403 可能表示 Directory 权限阻断,404 可能是入口或穿越层数不正确,500 则可能与 CGI 处理方式有关。最终结论应同时依据版本、补丁状态、配置和访问日志。

日志留痕与入侵排查

Apache 访问日志中的请求行通常保留原始编码形式,可以检索编码点号、二次编码以及针对 cgi-bin 的异常长路径。日志格式被代理或日志管道改写时,原始编码可能丢失,因此还应检查反向代理、WAF 和负载均衡日志。

# Debian/Ubuntu 常见路径
zgrep -Eai '(%2e|%252e|%%32%65|/cgi-bin/[^ ]*(\.\.|%2e|%25))' \
  /var/log/apache2/access.log* 2>/dev/null

# RHEL 系常见路径
zgrep -Eai '(%2e|%252e|%%32%65|/cgi-bin/[^ ]*(\.\.|%2e|%25))' \
  /var/log/httpd/access_log* 2>/dev/null

# 同时关注错误日志中的文件映射和 CGI 异常
zgrep -Eai '(AH[0-9]+|cgi|script|permission denied|not found|malformed)' \
  /var/log/apache2/error.log* /var/log/httpd/error_log* 2>/dev/null

发现可疑请求后,建议按时间窗口关联以下信息:

  • 同一源 IP 是否连续尝试不同编码方式、不同穿越层数和多个 Alias 路径。
  • 响应状态码及响应字节数是否明显异常,尤其是 200 响应。
  • 请求后是否出现 Apache 子进程创建 shell、下载工具或解释器进程。
  • Web 服务账户是否访问过 /etc、/proc、应用配置目录、SSH 目录或云凭据目录。
  • 主机是否出现异常外连、新增文件、计划任务、systemd 服务或 Web 目录改动。

在 systemd 环境可补充检查 Apache 服务日志和进程链:

journalctl -u apache2 --since '2021-10-01' 2>/dev/null
journalctl -u httpd --since '2021-10-01' 2>/dev/null

ps -eo pid,ppid,user,lstart,args --forest | grep -E 'httpd|apache2|cgi|sh|bash|curl|wget'
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls 2>/dev/null

如果主机启用了 auditd,可检索 Web 服务账户对敏感目录的访问记录。不同系统中的服务账户可能是 www-data、apache 或 daemon:

ausearch -ua www-data -ts recent 2>/dev/null
ausearch -ua apache -ts recent 2>/dev/null
ausearch -m EXECVE -ts recent 2>/dev/null | grep -Ei 'apache|httpd|www-data|curl|wget|bash|sh'

风险判断

  • 仅版本命中,但不存在可利用映射且根目录默认拒绝:仍需升级,当前可利用性相对较低。
  • 存在 Alias 或 ScriptAlias,且越界文件可读取:高风险,可能泄露配置、源码、密钥和数据库凭据。
  • 同时启用 CGI、ExecCGI 或可执行脚本处理:严重风险,应按可能命令执行和主机失陷进行响应。
  • 服务账户权限过高、运行在特权容器或挂载宿主机目录:影响范围可能扩大到宿主机或其他业务。

修复与加固建议

首选措施是升级到发行版提供的已修复软件包。对上游版本而言应升级到 2.4.51 或更高版本,但生产环境应以发行版安全公告和包修订号为准。升级后必须重启服务并确认旧进程已退出。

# Debian/Ubuntu
apt-get update
apt-get install --only-upgrade apache2
apachectl configtest && systemctl restart apache2

# RHEL 系
dnf update httpd
apachectl configtest && systemctl restart httpd

# 确认运行进程对应的新二进制
apachectl -v
systemctl status apache2 2>/dev/null || systemctl status httpd

无法立即升级时,可采用以下临时缓解措施,但不能替代补丁:

  • 保持文件系统根目录默认拒绝:Directory / 使用 Require all denied,仅对必要目录精确放行。
  • 删除未使用的 ScriptAlias、cgi-bin、mod_cgi 和 mod_cgid。
  • 业务不需要 CGI 时关闭 ExecCGI,并移除相关 AddHandler 或 SetHandler。
  • 限制 Apache 服务账户对应用密钥、备份、日志和系统配置的读取权限。
  • 在反向代理或 WAF 临时阻断包含异常编码点号、二次编码和多层穿越特征的请求,同时保留原始请求日志。
  • 容器场景避免特权运行、宿主机根目录挂载和敏感 Unix Socket 挂载。

推荐的权限基线如下:

<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory /var/www/app/public>
    Options -Indexes -ExecCGI
    AllowOverride none
    Require all granted
</Directory>

修复后应重新执行版本与配置检查,并使用原标记文件方法做回归验证。预期结果应为 403 或 404,同时确认正常业务路径未受影响。

总结

CVE-2021-41773 和 CVE-2021-42013 的排查不能停留在版本扫描。可靠结论需要同时核对补丁状态、Alias/ScriptAlias 映射、Directory 权限、CGI 能力及原始访问日志。验证时使用专用标记文件即可证明越界访问,无需读取真实敏感文件。若日志中已经出现成功响应或 CGI 异常,应将事件从漏洞修复升级为主机失陷排查,保全日志和磁盘证据后再进行凭据轮换与系统恢复。

服务器与云环境安全示意图
服务器、云资产与权限边界梳理示意
漏洞验证与修复流程示意图
漏洞成因、验证条件与修复闭环示意

排查时建议把“版本受影响”和“当前配置是否可利用”分开判断:CVE-2021-41773 对应 2.4.49,2.4.50 的修复不完整,又产生了 CVE-2021-42013。2.4.51 修复了这两个问题,但实际升级应选发行版仍维护的安全版本,并核对是否有补丁回移。

先确认正在运行的实例,别只看响应头里的 Server:

apachectl -v
apachectl -V
apachectl -M
apachectl -t -D DUMP_INCLUDES

部分发行版命令叫 apache2ctl。重点检查实际加载配置里的 Alias、ScriptAlias 和对应目录的授权规则。路径穿越不等于必然能执行命令;后者还涉及 CGI 模块、映射及执行权限。

如果是在授权靶场验证 2.4.49,建议用无敏感内容的标记文件,不要直接读系统账户文件。在服务器本地创建:

printf 'httpd-traversal-check\n' > /tmp/httpd-traversal-check.txt
chmod 644 /tmp/httpd-traversal-check.txt

假设实际存在 /cgi-bin/ 映射,可请求:

curl --path-as-is -i \
  '

--path-as-is 用来避免客户端先规范化路径。返回标记内容才是有效证据;403、404 都不能单独证明已修复,还可能是映射不同、文件权限限制或代理/WAF 拦截。这条请求也不能用来排除 2.4.50 的问题。

配置上应保留根目录默认拒绝,再对业务目录单独放行:

<Directory />
    AllowOverride None
    Require all denied
</Directory>

同时检查是否有更具体的目录配置放宽了权限。修改后先执行 apachectl -t,再重载并复测;测试结束删除标记文件。若前面有反向代理,最好分别验证入口与后端,结合访问日志确认请求到底在哪一层被处理。

创建帐户或登录后发表意见

最近浏览 0

  • 没有会员查看此页面。

SiteMap HACKHAT © 2026 All rights reserved.