Apache mod_proxy SSRF CVE-2021-40438

何为SSRF攻击：

SSRF(Server-Side Request Forgery:服务器端请求伪造)

  1.攻击者构造的请求传递给服务端，服务器端对传回的请求未作特殊处理直接执行而造成的。

  2. SSRF攻击的目标是从外网无法访问的内部系统。

   （它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）

Apache官方发布了Apache httpd mod_proxy SSRF漏洞CVE-2021-40438，影响v2.4.48及以下版本。
 

漏洞产生的原因：请求 uri-path 可以导致 mod_proxy 将请求转发到远程用户选择的源服务器，

攻击者可以通过制作请求来利用此漏洞uri路径，这导致 mod_proxy将请求转发到攻击者选择的源服务器。

制造怎样的请求：大佬的代码审计

对cve-2021-40438的理解 | Atmujie

大致思路：

      php底层对unix反代请求的解析代码里有一个fix_uds_filname的函数，传入参数r中filename,它来自于proxy_http_cannon函数，在这个函数中它首先获取到组成URL变量，然后将其拼接。

（可以对URL变量进行着控制）。

  r->filename = apr_pstrcat(r->pool, "proxy:", scheme, "://", host, sport,
            "/", path, (search) ? "?" : "", (search) ? search : "", NULL);

      因此由于fix_uds_filename函数缺陷，通过人为的写入path或者search ，就可以控制反代的后端地址。

例如：发出这样的请求

         GET /？unix:/var/run/test.sock|http://example.com/ HTTP/1.1

         它会将请求发送到套接字，所以我们需要绕过套接字，将其发送到http://example.com.

        如何绕过：会用到arp_filepath_merge函数，后端对传入路径的长度进行了处理。

rootlen = strlen(rootpath); // 得到跟路径的长度 
maxlen = rootlen + strlen(addpath) + 4; // 得到传入路径的总长
// 4表示开始、根之后和结束时的斜杠，加上尾部的null
if (maxlen > APR_PATH_MAX) { // 判断得到的总长是否大于APR_PATH_MAX
    return APR_ENAMETOOLONG; // 是则返回路径过长
}

       所以当我们传入的内容长度大于APR_PATH_MAX定义的长度，uds_path就会为空

       Apache不再发送请求给unix套接字，此时就可以执行SSRF。

          例如：当目标环境使用了mod_proxy做反向代理.

          比如ProxyPass / "http://localhost:8000/"，

          此时通过请求http://target/?unix:{'A'*5000}|http://example.com/

          即可向http://example.com发送请求，造成一个SSRF攻击。

浅浅了解一下mod_proxy:模块实现了Apache的代理/网关。

代理指令:

1. ProxyPass ：将一个远端服务器映射到本地服务器的URL空间中，它主要是用作URL前缀匹配，不能有正则表达式。

语法：ProxyPass [path] !|url     

• 直接使用某个协议反代到某个IP和端口，比如ProxyPass / "http://localhost:8080"
• 使用某个协议反代到unix套接字，比如ProxyPass / "unix:/var/run/www.sock|http://localhost:8080/"

第一个就是正常的代理语句，反代网站根目录下的内容到http://localhost:8080

第二个则是unix套接字语句，将网站根目录内容反代到unix的/var/run/，www.sock文件通过管道符传输给http://localhost:8080

2. ProxyPassReverse ：它一般和ProxyPass指令配合使用，此指令使Apache调整HTTP重定向应答中Location, Content-Location, URI头里的URL，这样可以避免在Apache作为反向代理使用时，后端服务器的HTTP重定向造成的绕过反向代理的问题。

语法：ProxyPassReverse [path] url 

HTTP重定向：

在默默学习一下什么是HTTP重定向：

apache重定向功能需要调用mod_rewrite模块.

一种是针对整个apache服务器的配置，此种配置的Rewrite规则是直接在httpd.conf下书写。

(1)去除httpd.conf文件中"#LoadModule rewrite_module modules/mod_rewrite.so"前面的"#"号;
(2)然后再在httpd.conf中书写如下规则：
RewriteEngine on
#当访问任何以t_开头，以.html结尾的文件时，将$1用与(.*)匹配的字符替换后，访问相应的test.php页面
RewriteRule ^/t_(.*).html$ /test.php?id=$1

另一种是针对apache服务器下的某一目录的配置，此种配置的Rewrite规则需在此目录下建立一个.htaccess文件来书写。

(1)去除httpd.conf文件中"#LoadModule rewrite_module modules/mod_rewrite.so"前面的"#"号;
(2)修改httpd.conf文件中的"AllowOverride None"为"AllowOverride all",同时最好将Options也置为"all",否则可能会出问题。
(3)在目录中建立.htaccess文件，并用记事本打开，书写如下规则:
RewriteEngine on
RewriteRule ^/t_(.*).html$ /test.php?id=$1

3. ProxyPassMatch ： 这个实际上是url正则匹配，而不是简单的前缀匹配，匹配上的regex部分是会带到后端的url的，这个是与ProxyPass不同的。

语法：ProxyPassMatch [regex] !|url

这个实际上是url正则匹配，而不是简单的前缀匹配，匹配上的regex部分是会带到后端的url的。

详细了解：

ProxyPass与ProxyPassReverse及ProxyPassMatch的概述_invalid proxypass|proxypassmatch parameter. parame_冯立彬的博客-CSDN博客

Apache Rewrite url重定向功能的简单配置_Linux_脚本之家hh