Apache mod_proxy SSRF（CVE-2021-40438）的一点分析和延伸

phithon

2021 十月 18 10:05

阅读：431

网络安全

周五晚上开始学习Apache HTTP Server（后文简称为Apache）mod_proxy的SSRF漏洞（CVE-2021-40438），并在星球简单介绍了一下编译、调试Apache服务器的方法，今天继续深入分析一下这个漏洞的成因，以及一些延伸的问题研究。

我很久不发漏洞分析了，因为不是自己挖的漏洞，我自己的思考其实是不够的，再加上很多出漏洞的软件我都没用过，也更谈不上深入的理解，很容易落俗套变成流水账；另外这些年网友们也很积极，不缺我的一篇漏洞分析文章，所以我就写的少了。不过最近Apache HTTP Server出的几个漏洞，还是值得分析一下。

另外，阅读本文前，建议按照我在这两篇帖子里发的方式https://t.zsxq.com/RvfmEu3、https://t.zsxq.com/7qNfeie下载好apr、apr-util、apache的源码并编译，便于后续调试以理解文章。

0x01 Apache Module综述

如果我们要部署一个PHP运行环境，且将Apache作为Web应用服务器，那么常用的有三种方法：

Apache以CGI的形式运行PHP脚本
PHP以mod_php的方式作为Apache的一个模块运行
PHP以FPM的方式运行为独立服务，Apache使用mod_proxy_fcgi模块作为反代服务器将请求代理给PHP-FPM

第一种方式比较古老，性能较差，基本已经淘汰；第二种方式在Apache环境下使用较广，配置最为简单；第三种方法也有较大用户体量，不过Apache仅作为一个中间的反代服务器，更多新的用户会选择使用性能更好的Nginx替代。

这其中，第三种方法使用的mod_proxy_fcgi就是本文主角mod_proxy模块的一个子模块。mod_proxy是Apache服务器中用于反代后端服务的一个模块，而它拥有数个不同功能的子模块，分别用于支持不同通信协议的后端，比如常见的有：

mod_proxy_fcgi 用于反代后端是fastcgi协议的服务，比如php-fpm
mod_proxy_http 用于反代后端是http、https协议的服务
mod_proxy_uwsgi 用于反代后端是uwsgi协议的服务，主要针对uWSGI
mod_proxy_ajp 用于反代后端是ajp协议的服务，主要针对Tomcat
mod_proxy_ftp 用于反代后端是ftp协议的服务

除去mod_proxy_fcgi用于反代PHP，我们在使用Node.js、Python等脚本语言编写的应用也常常会使用mod_proxy_http作为一层反代服务器，这样中间层可以做ACL、静态文件服务等。

这次的SSRF漏洞是出在mod_proxy这个模块中的，我们就来从代码的层面分析一下它的原理是什么，究竟影响有多大。

《Building a POC for CVE-2021-40438》这篇文章中提到了这个漏洞的复现方法：当目标环境使用了mod_proxy做反向代理，比如ProxyPass / "http://localhost:8000/"，此时通过请求http://target/?unix:{'A'*5000}|http://example.com/即可向http://example.com发送请求，造成一个SSRF攻击。

这里面，Apache代码中犯得错误是在modules/proxy/proxy_util.c的fix_uds_filename函数：

/*
 * In the case of the reverse proxy, we need to see if we
 * were passed a UDS url (eg: from mod_proxy) and adjust uds_path
 * as required.  
 */
static void fix_uds_filename(request_rec *r, char **url) 
{
    char *ptr, *ptr2;
    if (!r || !r->filename) return;

    if (!strncmp(r->filename, "proxy:", 6) &&
            (ptr2 = ap_strcasestr(r->filename, "unix:")) &&
            (ptr = ap_strchr(ptr2, '|'))) {
        apr_uri_t urisock;
        apr_status_t rv;
        *ptr = '\0';
        rv = apr_uri_parse(r->pool, ptr2, &urisock);
        if (rv == APR_SUCCESS) {
            char *rurl = ptr+1;
            char *sockpath = ap_runtime_dir_relative(r->pool, urisock.path);
            apr_table_setn(r->notes, "uds_path", sockpath);
            *url = apr_pstrdup(r->pool, rurl); /* so we get the scheme for the uds */
            /* r->filename starts w/ "proxy:", so add after that */
            memmove(r->filename+6, rurl, strlen(rurl)+1);
            ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
                    "*: rewrite of url due to UDS(%s): %s (%s)",
                    sockpath, *url, r->filename);
        }
        else {
            *ptr = '|';
        }
    }
}

Apache在配置反代的后端服务器时，有两种情况：

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

第一种情况比较好理解，第二种情况的设计我觉得不是很好，相当于让用户可以使用一个Apache自创的写法来配置后端地址。那么这时候就会涉及到parse的过程，需要将这种自创的语法转换成能兼容正常socket连接的结构，而fix_uds_filename函数就是做这个事情的。

使用字符串文法来表示多种含义的方式通常暗藏一些漏洞，比如这里，进入这个if语句需要满足三个条件：

r->filename的前6个字符等于proxy:
r->filename的字符串中含有关键字unix:
unix:关键字后的部分含有字符|

当满足这三个条件后，将unix:后面的内容进行解析，设置成uds_path的值；将字符|后面的内容，设置成rurl的值。

举个例子，前面介绍中的ProxyPass / "unix:/var/run/www.sock|http://localhost:8080/"，在解析完成后，uds_path的值等于/var/run/www.sock，rurl的值等于http://localhost:8080/。

看到这里其实都没有什么问题，那么我们肯定会思考，r->filename是从哪来的，用户可控吗，为什么？

这时就要说到另一个函数，proxy_hook_canon_handler，这个函数用于注册canon handler，比如：

可以看到，每一个mod_proxy_xxx都会注册一个自己的canon handler，canon handler会在反代的时候被调用，用于告诉Apache主程序它应该把这个请求交给哪个处理方法来处理。

比如，我们看到mod_proxy_http的proxy_http_canon函数：

static int proxy_http_canon(request_rec *r, char *url)
{
    // ...
    // first part
    if (strncasecmp(url, "http:", 5) == 0) {
        url += 5;
        scheme = "http";
    }
    else if (strncasecmp(url, "https:", 6) == 0) {
        url += 6;
        scheme = "https";
    }
    else {
        return DECLINED;
    }
    port = def_port = ap_proxy_port_of_scheme(scheme);

    // second part
    ap_proxy_canon_netloc(r->pool, &url, NULL, NULL, &host, &port);
    switch (r->proxyreq) {
    default: /* wtf are we doing here? */
    case PROXYREQ_REVERSE:
        if (apr_table_get(r->notes, "proxy-nocanon")) {
            path = url;   /* this is the raw path */
        }
        else {
            path = ap_proxy_canonenc(r->pool, url, strlen(url),
                                     enc_path, 0, r->proxyreq);
            search = r->args;
        }
        break;
    case PROXYREQ_PROXY:
        path = url;
        break;
    }

    if (path == NULL)
        return HTTP_BAD_REQUEST;

    if (port != def_port)
        apr_snprintf(sport, sizeof(sport), ":%d", port);
    else
        sport[0] = '\0';

    if (ap_strchr_c(host, ':')) { /* if literal IPv6 address */
        host = apr_pstrcat(r->pool, "[", host, "]", NULL);
    }

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

这个函数中有三个主要的部分，第一部分检查了配置中的url的开头是不是http:或https:，如果不是，说明这个请求不该由mod_proxy_http模块处理，后续的过程跳过；第二部分，用各种方式获取到scheme、host、port、path、search等几个URL的组成变量；第三部分，拼接proxy:、scheme、://、host、sport、/、path、search，成为一个字符串，赋值给r->filename。

这里面，scheme、host、sport来自于配置文件中配置的ProxyPass，而path、search来自于用户发送的数据包。也就是说，r->filename中的后半部分是用户可控的。

那我们回看前面的fix_uds_filename函数，它在r->filename中查找关键字unix:，并将这个关键字后面直到|的部分作为unix套接字地址，而将|后面的部分作为反代的后端地址。

我们可以通过请求的path或者search来控制这两个部分，控制了反代的后端地址，这也就是为什么这里会出现SSRF的原因。

0x03 限制绕过

当然，这里面有一个问题，那就是Apache在正常情况下，因为识别到了unix套接字，所以会把用户请求发送给这个本地文件套接字，而不是后端URL。

可以来做个测试，我们发送这样一个请求：

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

此时会得到一个503错误，错误日志会反馈这样的结果：

[Mon Oct 18 00:14:38.634795 2021] [proxy:error] [pid 782180:tid 140737306797824] (2)No such file or directory: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/test.sock (192.168.1.1) failed
[Mon Oct 18 00:14:38.634875 2021] [proxy_http:error] [pid 782180:tid 140737306797824] [client 192.168.1.142:59696] AH01114: HTTP: failed to make connection to backend: httpd-UDS

找不到unix套接字/var/run/test.sock，这是当然。

我们不能让他把请求发送到unix套接字上，而是发送给我们需要的|后面的地址。

国外那位作者给出了一个非常巧妙的方法，在fix_uds_filename函数中，unix套接字的地址来自于下面这两行代码：

char *sockpath = ap_runtime_dir_relative(r->pool, urisock.path);
apr_table_setn(r->notes, "uds_path", sockpath);

如果这里ap_runtime_dir_relative函数返回值是null，则后面获取uds_path时将不会使用unix套接字地址，而变成普通的TCP连接：

uds_path = (*worker->s->uds_path ? worker->s->uds_path : apr_table_get(r->notes, "uds_path"));
if (uds_path) {
    if (conn->uds_path == NULL) {
        /* use (*conn)->pool instead of worker->cp->pool to match lifetime */
        conn->uds_path = apr_pstrdup(conn->pool, uds_path);
    }
    // ...
    conn->hostname = "httpd-UDS";
    conn->port = 0;
}
else {
    // ...
    conn->hostname = apr_pstrdup(conn->pool, uri->hostname);
    conn->port = uri->port;
    // ...
}

那么如何让ap_runtime_dir_relative的返回值是null？ap_runtime_dir_relative函数最后引用了apr库中的apr_filepath_merge函数，它的主要作用就是路径的join，用于处理相对路径、绝对路径、../连接。

这个函数中，当待join的两段路径长度+4大于APR_PATH_MAX，也就是4096的时候，则函数会返回一个路径过长的状态码，导致最后unix套接字的值是null：

rootlen = strlen(rootpath);
maxlen = rootlen + strlen(addpath) + 4; /* 4 for slashes at start, after
                                             * root, and at end, plus trailing
                                             * null */
if (maxlen > APR_PATH_MAX) {
    return APR_ENAMETOOLONG;
}

也就是说，我们只需要在unix:与|之间传入内容长度大概超过4092的字符串，就能构造出uds_path为null的结果，让Apache不再发送请求给unix套接字。

最后，这样构造出的请求成功触发SSRF漏洞：

Apache官方对这个漏洞的修复也比较简单，因为用户只能控制r->filename的后半部分，而前半部分proxy:{scheme}://{host}{sport}/来自于配置文件，所以最新版改成检查其开头是不是proxy:unix:，这一部分用户无法控制。

0x04 mod_proxy_fcgi是否存在漏洞？

我们前文都以mod_proxy_http作为例子来研究，而在Apache+PHP环境下，mod_proxy_fcgi的使用频率更高，那么它是否也会被SSRF漏洞影响呢？

这个漏洞出现在modules/proxy/proxy_util.c的fix_uds_filename函数，理论上是mod_proxy的漏洞，那么它的子模块应该都会被影响，但这个漏洞中有一个很关键的变量是r->filename，他是否可控决定了后面的利用是否可以成功。

我们看一下mod_proxy_fcgi的canon函数：

static int proxy_fcgi_canon(request_rec *r, char *url)
{
    char *host, sport[7];
    const char *err;
    char *path;
    apr_port_t port, def_port;
    fcgi_req_config_t *rconf = NULL;
    const char *pathinfo_type = NULL;

    if (ap_cstr_casecmpn(url, "fcgi:", 5) == 0) {
        url += 5;
    }
    else {
        return DECLINED;
    }

    // ...

    if (apr_table_get(r->notes, "proxy-nocanon")) {
        path = url;   /* this is the raw path */
    }
    else {
        path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
                             r->proxyreq);
    }
    if (path == NULL)
        return HTTP_BAD_REQUEST;

    r->filename = apr_pstrcat(r->pool, "proxy:fcgi://", host, sport, "/",
                              path, NULL);
    // ...
}

可见，这里的r->filename等于proxy:fcgi://{host}{sport}/{path}，相比于mod_proxy_http少了search。不过，path仍然是用户可以控制的，我们可以尝试发送这样的数据包：

GET /unix:testtest|http://example.com/1.php HTTP/1.1
...

经过调试可见，path中的|被ap_proxy_canonenc函数编码成了%7C：

没有|，后面也就无法完成SSRF利用了。

0x05 哪些模块受到影响

那么，我们其实可以认为，如果r->filename有部分可控，且可控的部分没有被编码（不是path），这个模块就会受到SSRF漏洞的影响。

对这个结论我没有逐一测试考证，我仅挑选另一个较为常用的模块mod_proxy_ajp来复现漏洞。

mod_proxy_ajp是用于反代Tomcat的一个Apache模块，Tomcat在8.5.51版本以前默认会开启两个端口8080和8009，分别对应HTTP协议和AJP协议。HTTP协议好理解，AJP协议是一个二进制协议，通信协议相比起来效率更高。所以以前很多运维人员会将Tomcat假设在Apache之后，然后二者之间使用AJP协议通信。

Tomcat 8.5.51之后的版本受到Ghostcat漏洞影响不再默认开放8009端口。

Apache下有两个模块能实现AJP的反代通信：

mod_proxy_ajp 这就是mod_proxy的一个子模块，由Apache HTTPd官方维护
mod_jk 这是Tomcat官方维护的一个Apache模块，更加出名用户也更多

由于mod_jk不是用mod_proxy的代码，所以不受到影响，我们今天仅测试mod_proxy_ajp。

简单部署一个开放8009端口的Tomcat服务器，并配置好mod_proxy_ajp进行调试，可见其proxy_ajp_canon函数r->filename中是包含search的：

static int proxy_ajp_canon(request_rec *r, char *url)
{
    char *host, *path, sport[7];
    char *search = NULL;
    const char *err;
    apr_port_t port, def_port;

    /* ap_port_of_scheme() */
    if (strncasecmp(url, "ajp:", 4) == 0) {
        url += 4;
    }
    else {
        return DECLINED;
    }

    // ...
    r->filename = apr_pstrcat(r->pool, "proxy:ajp://", host, sport,
                              "/", path, (search) ? "?" : "",
                              (search) ? search : "", NULL);
    return OK;
}

那么按照我们的预测，这里也会存在SSRF漏洞。果然测试成功：

那么，mod_proxy_http2、mod_proxy_balancer、mod_proxy_wstunnel等这些模块也会受到影响，而mod_proxy_uwsgi、mod_proxy_scgi等模块不受影响。我没有严格验证，有兴趣的同学可以自己下去调试一下，也许还能找到绕过方法。

0x06 几个常见问题和总结

一个大家问的比较多的问题：这个SSRF漏洞是否能够POST？答案是肯定的，理解了原理的同学肯定能明白，我们实际上是控制了反向代理的目标服务器地址。既然是反向代理，那么实际上用户请求的大部分原始数据都会被直接转发给后端，所以，我们只需要发送POST请求，即可让执行POST的SSRF，比如：

另一个，这个SSRF漏洞是否可以打本地的unix socket？答案是肯定的。原本这个漏洞的第一请求目标就是本地的unix套接字，我们使用4092个超长search绕过了这个限制让他可以打任意远程地址，只要让它回归原本的方法就可以打本地的unix套接字了：

打本地unix套接字的好处是可以攻击类似于Docker、Supervisor这样的本地服务。

最后一个问题，这个SSRF漏洞是否可以攻击一些非HTTP协议的服务？答案也是肯定的。TCP是一个数据流，即使我们打出的数据包前面有HTTP头，这并不影响后续正常的满足二进制协议的数据流的发送与接收。不过有一个例外情况，如果目标服务有一些特殊的操作，类似于高版本redis读取到一些特殊的HTTP数据段就断开TCP连接这样的操作，那么可能需要进行一些额外绕过了。

总结一下，这个SSRF漏洞的本质是Apache在解析反代服务URL的时候，由于对unix:位置要求不严格，导致用户的输入可以控制反代的逻辑，最终导致反代URL被控制，造成SSRF漏洞。

参考链接：

Apache mod_proxy SSRF（CVE-2021-40438）的一点分析和延伸

Apache mod_proxy SSRF（CVE-2021-40438）的一点分析和延伸

0x01 Apache Module综述

0x02 漏洞原理分析

0x03 限制绕过

0x04 mod_proxy_fcgi是否存在漏洞？

0x05 哪些模块受到影响

0x06 几个常见问题和总结

Recommend

两枚塑料蛋蛋，正在维护美国宪法第一修正案

研究发现拼车服务增加了污染和拥堵

比特币在 24 天内上涨 50%，突破 6 万美元

《银河系漫游指南》出版 42 周年

GasNow 关闭服务后，以太坊还有哪些 Gas 价格预测工具替代品？

火星云矿将在12月31日前清退中国大陆挖矿资产和服务

ABAP at SAP TechEd in 2021

Release Status on Manage Customer Returns App

当堪比“本子”里的情节发生在游戏主播和声优身上

Sports and Digital Transformation Lessons Learned

About Joyk