nginx漏洞复现

vulhub漏洞环境

https://vulhub.org/#/environments/nginx/nginx_parsing_vulnerability/

Nginx 解析漏洞复现

版本信息：

Nginx 1.x 最新版
PHP 7.x最新版

该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。

1、由于nginx.conf的错误配置导致nginx把以".php"结尾的文件交给fastcgi处理,为此可以构造http://172.168.30.190/uploadfiles/hacker.png/XXXX.php ,其中hacker.png是我们上传的 包含PHP代码的图片文件。

2、但是fastcgi在处理"XXXX.php"文件时发现文件并不存在，这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置用于修复路径,如果 当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了"/test.png"。

3、 最重要的一点是php-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型(即指定什么类型的文件当做代码解析),此项设置为空的时候才允许fastcgi将".png"等文件当做代码解析。

注：限制 fpm 允许解析的脚本扩展名。此设置可以预防web服务器配置的错误。应当限制fpm仅仅解析.php扩展名,阻止恶意用户使用其他扩展名运行php代码。默认值:.php

漏洞复现----------------------------------------------------------

直接执行docker-compose up -d启动容器，无需编译。

访问http://your-ip/uploadfiles/nginx.png 和 http://your-ip/uploadfiles/nginx.png/.php即可查看效果。

正常显示：
增加/.php后缀，被解析成PHP文件：

访问 http://your-ip/index.php 可以测试上传功能，上传代码不存在漏洞，但利用解析漏洞即可 getshell：

不知道别人为啥能复现成功。。我图片里面加php代码后，就上传不了

漏洞修复：---------------------------

1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0

2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php

https://blog.csdn.net/weixin_42345596/article/details/120660845

Nginx 配置错误导致漏洞

https://vulhub.org/#/environments/nginx/insecure-configuration/

docker-compose up -d

运行成功后，Nginx将会监听 8080/8081/8082 三个端口，分别对应三种漏洞。

1. CRLF注入漏洞

CRLF是”回车+换行” (\r\n)的简称,其十六进制编码分别为0x0d和0x0a

Nginx会将$uri进行解码，导致传入%0a%0d即可引入换行符，造成CRLF注入漏洞。

漏洞原理：----------------------

错误的配置文件示例（原本的目的是为了让http的请求跳转到https上）：

1、 修改nginx.conf
return 302 https://$host$uri; 此配置实现了强制跳转的功能,当用户访问nginx服务器时由于此配置的存在会被强制跳转到以https协议访问之前访问的链接。

location / {
    return 302 https://$host$uri;
}

2、上面的配置的关键利用点由两个:
一是配置中的 u r l 是 我 们 可 以 控 制 的 ，这样我们就可以在url处填入CRLF,然后对服务器进行访问实现头部注入。
二是服务器会返回一个302跳转给用户,所以我们注入的头部参数又会返回到客户这边。

Payload：http://your-ip:8080/%0a%0dSet-Cookie:%20a=1，可注入Set-Cookie头。

为啥我一访问，就直接跳转，没有返回包？

利用《Bottle HTTP 头注入漏洞探究》中的技巧，即可构造一个XSS漏洞：

https://blog.csdn.net/weixin_40412037/article/details/106217834

xss原理 参见 目录–》HTTP头注入

2. 目录穿越漏洞

Nginx在配置别名（Alias）的时候，如果忘记加 /，将造成一个目录穿越漏洞。

错误的配置文件示例（原本的目的是为了让用户访问到/home/目录下的文件）：

location /files {
    alias /home/;
}

Payload: http://your-ip:8081/files…/ ，成功穿越到根目录：

直接访问 /files/ 就直接显示files下的文件

另说 漏洞原理：-------------------------------------------

Nginx服务器默认是不允许用户以浏览目录的方式去访问资源的。
如果想让nginx这种WEB服务器能实现类似FTP服务器下载功能，Nginx是提供相应的配置去实现的，在nginx配置文件的http模块或相应的server及location模块下添加以下配置语句就可以实现。

配置命令如下：

  #目录浏览功能（默认off）
    autoindex on;
     
    #默认on：显示文件的确切大小，单位bytes；
    #改为off：显示文件大概大小，根据文件大小显示合适单位大小（KB，MB或者GB）。
    autoindex_exact_size off;
     
    #默认off：显示文件时间为GMT时间
    #给为off：显示文件时间为文件的服务器时间
    autoindex_localtime on;
     
    #文件名为中文时转码
    charset utf-8;

修复方法：修复on改为off即可。

3. add_header被覆盖

Nginx配置文件子块（server、location、if）中的add_header，将会覆盖父块中的add_header添加的HTTP头，造成一些安全隐患。

如下列代码，整站（父块中）添加了CSP头：

add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options DENY;

location = /test1 {
    rewrite ^(.*)$ /xss.html break;
}

location = /test2 {
    add_header X-Content-Type-Options nosniff;
    rewrite ^(.*)$ /xss.html break;
}

但/test2的location中又添加了X-Content-Type-Options头，导致父块中的add_header全部失效：

Nginx越界读取缓存漏洞（CVE-2017-7529）

Nginx range 过滤器整形溢出漏洞
Nginx在反向代理站点的时候，通常会将一些文件进行缓存，特别是静态文件。缓存的部分存储在文件中，每个缓存文件包括“文件头”+“HTTP返回包头”+“HTTP返回包体”。如果二次请求命中了该缓存文件，则Nginx会直接将该文件中的“HTTP返回包体”返回给用户。

如果我的请求中包含Range头，Nginx将会根据我指定的start和end位置，返回指定长度的内容。而如果我构造了两个负的位置，如(-600, -9223372036854774591)，将可能读取到负位置的数据。如果这次请求又命中了缓存文件，则可能就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

漏洞原理

在Nginx的range filter中存在整数溢出漏洞，可以通过带有特殊构造的range的HTTP头的恶意请求引发这个整数溢出漏洞，并导致信息泄露。

影响版本：Nginx 0.5.6 – 1.13.2

漏洞概述：当使用Nginx标准模块时，攻击者可以通过发送包含恶意构造range域的header请求，来获取响应中的缓存文件头部信息。在某些配置中，缓存文件头可能包含后端服务器的IP地址或其它敏感信息，从而导致信息泄露。

访问http://your-ip:8080/，即可查看到Nginx默认页面，这个页面实际上是反向代理的8081端口的内容。

调用python3 poc.py http://your-ip:8080/，读取返回结果：

可见，越界读取到了位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

如果读取有误，请调整poc.py中的偏移地址（605）。

https://cert.360.cn/warning/detail?id=b879782fbad4a7f773b6c18490d67ac7

Nginx 文件名逻辑漏洞（CVE-2013-4547）

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞原理-----------------------------------

这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的URI，错误地获取到用户请求的文件名，导致出现权限绕过、代码执行的连带影响。

举个例子，比如，Nginx匹配到.php结尾的请求，就发送给fastcgi进行解析，常见的写法如下：

location ~ \.php$ {
    include        fastcgi_params;

    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

正常情况下（关闭pathinfo的情况下），只有.php后缀的文件才会被发送给fastcgi解析。

而存在CVE-2013-4547的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。

fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。

所以，我们只需要上传一个空格结尾的文件，即可使PHP解析之。

再举个例子，比如很多网站限制允许访问后台的IP：

location /admin/ {
    allow 127.0.0.1;
    deny all;
}

我们可以请求如下URI：/test[0x20]/../admin/index.php，这个URI不会匹配上location后面的/admin/，也就绕过了其中的IP验证；但最后请求的是/test[0x20]/…/admin/index.php文件，也就是/admin/index.php，成功访问到后台。
（这个前提是需要有一个目录叫“test ”：这是Linux系统的特点，如果有一个不存在的目录，则即使跳转到上一层，也会爆文件不存在的错误，Windows下没有这个限制）

环境启动后，访问http://your-ip:8080/即可看到一个上传页面。

这个环境是黑名单验证，我们无法上传php后缀的文件，需要利用CVE-2013-4547。我们上传一个“1.gif ”，注意后面的空格：

HTTP头注入

https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html

在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。
所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。

对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。

举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。

当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。

比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：

http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

我们的返回包就会变成这样：

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 154 
Connection: close 
Location:

<img src=1 onerror=alert(/xss/)>

之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里这个标签就会显示出来，造成一个XSS。