nginx目录遍历_nginx可能在您不知道的情况下保护了您的应用程序免受遍历攻击...

nginx目录遍历

By Danny Robinson and Rotem Bar

丹尼·鲁宾逊和Rotem Bar

As a security team within a rapidly growing company, we encounter lots of different types of vulnerabilities. We have numerous in-house development teams, all running full speed to build new features into their products, which inevitably also leads to the introduction of security bugs.

作为一家快速发展的公司中的安全团队，我们遇到许多不同类型的漏洞。 我们有许多内部开发团队，他们全速运行以在其产品中构建新功能，这不可避免地也导致了安全漏洞的引入。

Our mission is to prevent, detect and remediate all security issues within our environment. Our goal is to enable rather than block our developers’ work. In order to achieve this, our strategy has been to share our knowledge through building new processes and systems that help our developers release their latest feature safely without introducing vulnerabilities into our production systems.

我们的任务是预防，检测和补救环境中的所有安全问题。 我们的目标是实现而不是阻止开发人员的工作。 为了实现这一目标，我们的策略是通过构建新的流程和系统来共享我们的知识，这些流程和系统可以帮助我们的开发人员安全地发布其最新功能，而不会在我们的生产系统中引入漏洞。

This is a story about a traversal vulnerability, how we handled it and why it can also impact your organization.

这是一个关于遍历漏洞的故事，我们如何处理它以及为什么它也会影响您的组织。

背景： (BACKGROUND:)

We found a Traversal Vulnerability in one of our application services through our in-house scanner Jirachi (more on this in another post). Although it was a simple traversal attack and seemed easy to exploit, for some reason when testing through our staging site our Proof Of Concept kept failing.

我们通过内部扫描器Jirachi在我们的一项应用程序服务中发现了遍历漏洞(更多内容请参见另一篇文章)。 尽管这是一个简单的遍历攻击，并且似乎易于利用，但是由于某些原因，当通过我们的登台站点进行测试时，我们的概念证明一直失败。

We were able to exploit the directory traversal vulnerability when communicating directly with the service, and thought that this should be an easy Jira ticket to write up. However, when we went to write the full end-to-end POC, the exploit kept failing. We looked at the only other component that had changed between the two tests, and we found that the service was behind an AWS Application Load Balancer (ALB). However, there were no rules, no Web Application Firewall (WAF), nothing — so we couldn’t figure out why the load balancer was preventing our POC.

当直接与服务通信时，我们能够利用目录遍历漏洞，并认为这应该是编写Jira的简单方法。 但是，当我们编写完整的端到端POC时，漏洞利用一直失败。 我们查看了两次测试之间唯一更改的其他组件，发现该服务位于AWS Application Load Balancer(ALB)的后面。 但是，没有规则，没有Web应用程序防火墙(WAF)，也没有任何内容，因此我们无法弄清为什么负载平衡器阻止了POC。

Investigating the AWS ALB further, we found an HTTP 400 error response that had similarities with an error response in NGINX that we found in a git commit. We quickly downloaded the latest version of NGINX, and digging through the commit history, we found that there was a configuration option called merge_slashes. When we set merge_slashes to “off”, we saw the same behaviour as we did with the ALB. We came to the realisation that the AWS ALB url parsing shares similar functionality as NGINX. Furthermore it was this functionality that was responsible for sending the http 400 error response and not allowing the request to reach the vulnerable application.

进一步调查AWS ALB，我们发现了一个HTTP 400错误响应，该响应与git commit中发现的NGINX中的错误响应具有相似性。 我们Swift下载了最新版本的NGINX，并仔细研究了提交历史，发现有一个名为merge_slashes的配置选项。 当将merge_slashes设置为“ off”时，我们看到的行为与ALB相同。 我们意识到，AWS ALB网址解析与NGINX具有相似的功能。 此外，正是此功能负责发送http 400错误响应，并不允许请求到达易受攻击的应用程序。

We couldn’t give up there though. We had to find a way to get our request to the vulnerable application!

我们不能在那里放弃。 我们必须找到一种方法来将我们的请求发送给易受攻击的应用程序！

技术POC：通过NGINX URL解析器进行遍历攻击 (Technical POC: Traversal Attack through NGINX URL parser)

To demonstrate how we can get the malicious request through the NGINX url parser, we put together a sample application.

为了演示如何通过NGINX网址解析器获取恶意请求，我们将一个示例应用程序组合在一起。

As you can see below, We created a sample web server code which has a Local File Inclusion vulnerability

如下所示，我们创建了一个示例Web服务器代码，该代码具有本地文件包含漏洞

const express = require('express');
const app = express();
const port = 80;
const fs = require('fs');


app.get('*', (req, res) => {
    const data = fs.readFileSync('secure/' + req.url)
    res.send(data);
})

app.listen(port, () => {
    console.log(`Vulnerable App listening at http://localhost:${port}`)
})

The server accepts a GET request. The user-supplied url is concatenated with the ‘secure’ string and that file is then sent back to the user.

服务器接受GET请求。 用户提供的URL与“安全”字符串连接在一起，然后将该文件发送回用户。

As an example sending a request to http://server/1.txt will cause the server to send back a file from <CurrentWorkingDirectory>/secure/1.txt

例如，向http：//server/1.txt发送请求将导致服务器从<CurrentWorkingDirectory> /secure/1.txt发送回文件。

In order to demonstrate this, we send a GET request directly to the server and in the response we get the content of file 1.txt.

为了证明这一点，我们直接将GET请求发送到服务器，并在响应中获得文件1.txt的内容。

Vulnerable application

脆弱的应用程序

In order to exploit the traversal vulnerability in this app, we can request a file from a directory one level up by using the ‘../’ notation. Here we request the index.js file directly from the server .

为了利用此应用程序中的遍历漏洞，我们可以使用'../'符号从上一级目录中请求文件。 在这里，我们直接从服务器请求index.js文件。

POC —

POC —

Carrying out the same traversal attack through AWS ALB, we received a 400 bad request

通过AWS ALB进行相同的遍历攻击，我们收到了400个错误的请求

However, after some research we found that we can get our malicious request through the url parser by using multiple slashes (‘/’).

但是，经过一些研究，我们发现我们可以使用多个斜杠('/')通过url解析器获取恶意请求。

In order to demonstrate this point further, the below image shows an attempt at retrieving the /etc/passwd file through an AWS ALB. Once again, we get a 400 bad request.

为了进一步说明这一点，下图显示了通过AWS ALB检索/ etc / passwd文件的尝试。 再一次，我们收到了400个错误的请求。

As before, we’re able to reach the vulnerable application by appending more slashes (‘/’).

和以前一样，我们可以通过添加更多的斜杠('/')来访问易受攻击的应用程序。

根本原因分析 (Root Cause Analysis)

我们如何知道AWS ALB在URL解析中与NGINX共享相似的功能？(How did we know AWS ALB shares similar functionality in url parsing as NGINX?)

When the requests were blocked we saw a certain pattern.

当请求被阻止时，我们看到了某种模式。

The 400 bad request response from the AWS ALB above had a distinctive html signature:

上面的AWS ALB的400错误请求响应具有独特的html签名：

<body bgcolor=”white”> …

After simple Google search and digging in GitHub we found that this signature is used by NGINX.

通过简单的Google搜索并在GitHub中进行挖掘，我们发现该签名已由NGINX使用。

Specifically, we’re able to find which commit and version this error signature was removed in.

具体来说，我们能够找到该错误签名被删除的提交和版本。

https://github.com/NGINX/NGINX/commit/8117b3f5a06b68afb292ddd19bf6ee6000707232#diff-05d6b8ae21d192f78b349319edaeb9bf

https://github.com/NGINX/NGINX/commit/8117b3f5a06b68afb292ddd19bf6ee6000707232#diff-05d6b8ae21d192f78b349319edaeb9bf

Fun fact:

有趣的事实：

body bgcolor=white was pretty common in the past as IE rendered pages by default in light gray, other browsers let the user select a default background such as black and there was large inconsistency between browsers. Putting bgcolor=white ensured that all browsers display the background as white.

过去，body bgcolor = white很常见，因为IE默认将页面呈现为浅灰色，其他浏览器允许用户选择默认背景(例如黑色)，并且浏览器之间存在很大的不一致。 放置bgcolor = white可以确保所有浏览器将背景显示为白色。

我们如何确定merge_slashes为“ off”： (How did we determine that merge_slashes is ‘off’:)

Within the NGINX documentation, we are able to see that the merge_slashes default value is “On”. Therefore two or more ‘/’ characters will be normalized into one ‘/’ character.

在NGINX文档中，我们可以看到merge_slashes的默认值为“ On”。 因此，两个或更多的“ /”字符将被标准化为一个“ /”字符。

http://NGINX.org/en/docs/http/ngx_http_core_module.html#merge_slashes

http://NGINX.org/en/docs/http/ngx_http_core_module.html#merge_slashes

Enables or disables compression of two or more adjacent slashes in a URI into a single slash.

启用或禁用将URI中的两个或多个相邻斜杠压缩为单个斜杠。

Syntax: merge_slashes on | off;
Default: merge_slashes on;
Context: http, server

When the merge_slashes configuration is turned on, using multiple slashes ‘///’ did not allow us to exploit that vulnerability successfully.

打开merge_slashes配置后，使用多个斜杠“ ///”不允许我们成功利用该漏洞。

尝试绕过NGINX最新版本： (Trying out our bypass on latest version of NGINX:)

The following shows the POC carried out on the latest stable version of NGINX (v1.18.0) with merge_slashes ‘off’.

下面显示了在最新稳定版本的NGINX(v1.18.0)上执行的POC，其中merge_slashes为“ off”。

识别NGINX问题： (Identification of NGINX issue:)

In order to better understand how NGINX handles the url, we built a program to test the parsing function within the ngx_http_parse file:

为了更好地理解NGINX如何处理url，我们构建了一个程序来测试ngx_http_parse文件中的解析功能：

ngx_http_parse_complex_uri(ngx_http_request_t *r, ngx_uint_t merge_slashes)

Within this function, the handling of state == sw_dot_dot at https://github.com/NGINX/NGINX/blob/master/src/http/ngx_http_parse.c#L1581 is what our tests focus on.

在此函数中，测试的重点是在https://github.com/NGINX/NGINX/blob/master/src/http/ngx_http_parse.c#L1581处理状态== sw_dot_dot。

This shows the code written for testing the parsing function.

这显示了为测试解析功能而编写的代码。

Here we can see when we run the test with a regular traversal attack, we get an error and return code 11.

在这里，我们可以看到以常规遍历攻击运行测试时，出现错误并返回代码11。

Here we can see that when we run the test with extra slashes, we return 0.

在这里我们可以看到，当使用额外的斜杠运行测试时，我们返回0。

有什么影响？ (What is the Impact?)

这里的影响很复杂 (The impact here is complicated)

Looking at CVE’s we saw about 4000 known directory traversal CVE’s dating from 1999 to 2020. Directory Traversal attacks are here to stay!

纵观CVE，我们发现大约有4000种已知的遍历CVE的历史可以追溯到1999年至2020年。目录遍历攻击将继续存在！

Furthermore, companies testing themselves behind any ALB or NGINX solution configured with merge_slashes ‘off’ will probably not find this bug so easily. However, more knowledgable or dedicated attacks would know how to get their malicious request through the url parsing mechanism.

此外，在任何配置了merge_slashes'off '的ALB或NGINX解决方案之后进行测试的公司可能不会轻易发现此错误。 但是，更多可理解的或专门的攻击将知道如何通过url解析机制来获取其恶意请求。

In order to get a better understanding of how wide-spread this issue is, we ran a search on github for merge_slashes ‘off’;. There are 549 Open Source Projects that use this configuration and unknowingly may be blocking malicious requests to applications that are vulnerable.

为了更好地了解此问题的传播范围，我们在github上搜索了merge_slashes'off ';。 有549个开源项目使用此配置，并且在不知不觉中可能阻止了对易受攻击的应用程序的恶意请求。

可以更改此阻止行为吗？ (Could this blocking behaviour be changed?)

Not really as we see it.

并非如我们所见。

If traversal is blocked within NGINX, then applications relying on “safe traversal as a feature” will start failing. This is critical for some businesses and therefore, we don’t see this behaviour being changed.

如果遍历在NGINX中被阻止，则依赖于“安全遍历作为功能”的应用程序将开始失败。 这对于某些企业而言至关重要，因此，我们看不到这种行为发生改变。

Is this a vulnerability?

这是一个漏洞吗？

NGINX as itself is not a protection solution and AWS ALB is not intended to protect your application. If you are looking for a protection solution, consider using a WAF.

NGINX本身不是保护解决方案，AWS ALB并非旨在保护您的应用程序。 如果您正在寻找保护解决方案，请考虑使用WAF。

What do we recommend?

我们推荐什么？

If possible, run your tests on the application directly without any load balancers in the middle. If you must test through load balancers, you should ensure that your testing takes into account this behaviour so you don’t miss any possible vulnerabilities.

如果可能，请直接在应用程序上运行测试，而中间无需任何负载均衡器。 如果必须通过负载平衡器进行测试，则应确保测试考虑了此行为，因此您不会错过任何可能的漏洞。

概要 (Summary)

This exercise showed us why it is important to always look around for additional attack vectors, never rely on one protection mechanism and always continue ramping up our security methods.

这项练习向我们展示了为什么始终四处寻找其他攻击媒介，永远不要依赖一种保护机制以及始终不断提高我们的安全性方法为何很重要。

We do not consider this a vulnerability within NGINX nor AWS Application Load Balancers. By taking this information public, we are hoping that we are able to make organizations more aware of the behaviour displayed in NGINX and ALB and allow them to better test their application to reduce their risks

我们认为NGINX和AWS Application Load Balancer中都不存在此漏洞。 通过公开这些信息，我们希望我们能够使组织更加了解NGINX和ALB中显示的行为，并允许他们更好地测试其应用程序以降低风险

Stay tuned for more information about our security efforts. In the following weeks, we will be releasing more security tools we built in house and would love to share with the community.

请继续关注有关我们安全工作的更多信息。 在接下来的几周内，我们将发布更多内部构建的安全工具，并希望与社区共享。

Want to be part of our security adventures? We’re hiring! Contact us at security@appsflyer.com

想要成为我们安全冒险的一部分吗？ 我们正在招聘！ 通过security@appsflyer.com与我们联系

TL; DR(TL;DR)

Add forward slashes at the beginning of your requests when testing directory traversal attacks through load balancers.

通过负载平衡器测试目录遍历攻击时，请在请求的开头添加正斜杠。

翻译自: https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d

nginx目录遍历