关于 Nginx 0day 漏洞，需要采取哪些措施？

我的小碗汤

发布于 2023-03-19 17:41:20

1.6K0

发布于 2023-03-19 17:41:20

背景

今早有群友提到：

今早上，某 GY 项目信息部要求所有服务商确认 nginx 版本，一上班就开始找问题。在内网和外网都翻了一下，没看到明确的问题呢？截止目前了解到的情况，如果有问题也是 Nginx 的 ldap 插件有问题，好像也不会构成全面 nginx 的 0day 漏洞吧。有大佬了解情况么？

紧接着另一位群友喷到：

MD, 今天早上才找你算是仁慈了。我周六晚上就被找过来了，折腾了一天

我顿时懵了！Nginx 如果有严重 0day 漏洞，影响范围就是核弹级别的。现在接收消息如此滞后了？

中午时看朋友圈也有发，Nginx 有个代码执行漏洞。于是赶紧网上找一波，说是 0day。

可能是大多数人才知道吧，早在 4 月 9 日，黑客组织 BlueHornet 在推特上发布了有关 NGINX 1.18 的实验性漏洞，并警告受其影响的公司。4 月 10 日，BlueHornet 声称利用 NGINX 漏洞入侵了瑞银证券中国分行。

在 4 月 11 日，NGINX 发文[1] 回应称，经过调查，发现该问题仅影响参考实现。具体来说，NGINX LDAP 参考实现使用 LDAP 来验证被 NGINX 代理的应用程序的用户。NGINX Open Source 和 NGINX Plus 本身不受影响，如果您不使用参考实现，则无需采取任何纠正措施。

漏洞

NGINX LDAP 参考实现使用轻量级目录访问协议 (LDAP) 来验证由 NGINX 代理的应用程序的用户。它在nginx-ldap-auth[2]作为 Python 守护进程和相关的 NGINX 配置发布，其用途和配置这里有详细描述[3]。

注意：LDAP 参考实现是作为参考实现发布的，它描述了集成如何工作的机制以及验证集成所需的所有组件。它不是生产级 LDAP 解决方案。例如，用于示例登录页面的用户名和密码没有加密，安全通知对此进行了说明。

配置 LDAP 参考实现的主要方法是使用许多 proxy_set_header 指令。但是，也可以在初始化 Python 守护程序的命令行上设置配置参数。这些漏洞存在于未经处理的输入可用于更改或设置 LDAP 配置参数的方式中。

NGINX 博客指定了要利用漏洞需要满足的情况：

命令行参数用于配置 Python 守护进程
有未使用的可选配置参数
LDAP 身份验证取决于特定的组成员身份

如果满足上述任何条件，攻击者可能会通过发送特制的 HTTP 请求标头来覆盖配置参数，甚至绕过组成员资格要求以强制 LDAP 身份验证成功，即使经过错误身份验证的用户不属于该组。

NGINX Web 服务器项目的维护者已经发布了缓解措施，以解决其轻量级目录访问协议 LDAP 参考实现中的安全漏洞。

缓解条件

1

配置 LDAP 参考实现的主要方法是使用 示例配置[4] 和 ldap auth 配置文档[5] 中详细的 proxy_set_header[6] 指令。但是，配置参数也可以在初始化 Python 守护进程 nginx-ldap-auth-daemon.py的命令行上设置。

在命令行上指定配置参数时，攻击者可以通过传递特制的 HTTP 请求标头来覆盖其中的部分或全部。为了防止这种情况，请确保在身份验证期间忽略任何无关的请求标头，方法是将以下配置添加到location = /auth-proxyNGINX 配置中的块：

location = /auth-proxy {
    # ...
    proxy_pass_request_headers off;
    proxy_set_header Authorization $http_authorization; # If using Basic auth
    # ...
}

2

与条件 1 一样，攻击者可以传递特制的 HTTP 请求标头来覆盖某些配置参数。例如，如果未在配置中明确设置，则可能会覆盖 LDAP 搜索模板。通过将以下配置添加到location = /auth-proxy NGINX 配置中的块中，以与条件 1 相同的方式进行防御。

location = /auth-proxy {
    # ...
    proxy_pass_request_headers off;
    proxy_set_header Authorization $http_authorization; # If using Basic auth
    # ...
}