nginx漏洞复现（包含nginx的介绍，配置，访问控制等内容），是较全的nginx学习！

Nginx

补充：后面的漏洞复现来自vulhub的nginx漏洞复现
具体链接：https://vulhub.org/#/environments/nginx/CVE-2013-4547/
			    https://vulhub.org/#/environments/nginx/CVE-2017-7529/
			    https://vulhub.org/#/environments/nginx/insecure-configuration/
			    https://vulhub.org/#/environments/nginx/nginx_parsing_vulnerability/

Nginx简介

​ Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3) 代理服务器。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。

特性:
较好的扩展性模块化设计，

​ 高可靠性

​ 低内存消耗支持热部署: 不停机更新配置文件，升级版本，更换日志文件

正向代理

​ 我们常说的代理也就是指正向代理，正向代理的过程，它隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替来请求，某些科学上网工具扮演的就是典型的正向代理角色。用浏览器访问http://www.google.com时，被残忍的block，于是你可以在国外搭建一台代理服务器，让代理帮我去请求google.com，代理把请求返回的相应结构再返回给我。

反向代理

​ 反向代理隐藏了真实的服务端，当我们请求www.baidu.com的时候，背后可能有成千上万台服务器为我们服务，但具体是哪一台，你不知道，也不需要知道，你只需要知道反向代理服务器是谁就好了，www.baidu.com 就是我们的反向代理服务器，反向代理服务器会帮我们把请求转发到真实的服务器那里去。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。

nginx配置

nginx常见目录与配置

Nginx官方帮助文档: http://nginx.org/en/docs/ngx_core_module.html

主配置文件: /etc/nginx/nginx.conf(需要自己新建)

子配置文件: /etc/nginx/conf.d/*.conf

默认网站根路径: /usr/share/nginx/html

访问日志存放路径: /var/log/nginx/access.log

错误日志存放路径: /var/log/nginx/error.log

nginx主配置文件

​ Nginx配置文件主要分为三大块: 全局块，events块，http块

​ 全局块:从配置文件开始到events块开始之前的内容，都属于全局块，配置影响nginx全局的指令。一般有运行nginx服务器的用户组，允许生成的工作进程数，错误日志存放路径， nginx进程pid存放路径，配置文件引入等。

​ events块:配置影响nginx服务器或与用户的网络连接。例如:worker_connections 1024表示单个工作进程可以同时建立1024个外部连接

​ http块: 该模块是Nginx服务器配置中的重要部分，代理、缓存和日志定义等绝大多数的功能和第三方模块的配置都可以放在这个模块中。需要注意的是http块可以包括http全局块、server块

//nginx.conf过滤了注释后的
user www-data;
worker_processes auto; //默认为auto，服务器核数为几就会有几个worker进程(master进程用来管理它)，也可以手动设置，见下图
pid /run/nginx.pid;  //nginx运行起来后，会把pid写入这个文件当中
include /etc/nginx/modules-enabled/*.conf;//包含到了主配置文件
events {
        worker_connections 768;
}//网络连接数，一个worker进程可以同时进行多少个连接，总的连接数就是768*auto
http {
	log_format main
		"$remote addr//记录客户端ip - $remote user[$time_lqcal "$request//请求url"
		"$status $body_bytes_sent "$http_refeder"
		"$http_user_agent" "$http x forwarded for"';
	access_log /var/log/nginx/access.log main;//访问日志的存储位置
	sendfile  			  on;//提供文件传输的速度
	tcp_nopush			  on;//节省传输资源，等待
	tcp_nodelay			  on;//数据包发送不等待
	keepalive_timeout     65;长连接的超时时间
	types_hash_max_size   4096;//nginx中hash的最大大小
	include				  /etc/nginx/mime.types;//mime类型的一个表，文件后缀和处理程序的映射关系
	default_type          application/octet- stream;//如果在上个中，没有找到映射关系，用八进制处理方式
	include  /etc/nginx/conf.d/*.conf;
	server {
		listen   		80;//监听80
		listen   		[::]:80;//ipvp的80
		server_name		_;//_没有设置域名的意思
		root     		/usr/share/nginx/html;//网站根目录
		include 		/etc/nginx/default,d/*.conf;//
		error_page 404 /404.html;//到这为止是全局，//本行意思：定义了一个404页面，遇到404错误，会把这个返回给用户
		location = /404.html{		
		}
		error_page 500 502 503 504 /50x.html;//遇到这些时会把50x.html返回给用户
		location =50x,html{
		
		}
	}
}

nginx的访问控制

​ locaiton块的主要作用是基于nginx服务器接收到的请求字符串(例如:www.test.com/uri–string)，对虚拟主机名称 (也可以是IP)之外的字符串(例如:前面的/uri–string) 进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。

格式:location[=}_|*]uri{

}
#1、=:用于不含正则表达式的uri前，要求请求字符串与uri严格匹配，如果匹配成功，就停止继续向下搜索并立即处理请求。

#2、~:用于表示uri包含正则表达式，并且区分大小写。

#3、~*·用于表示uri包含正则表达式，并且不区分大小写

精准匹配，前缀为= 所谓精准匹配指的就是用户访问的 URI 与指定的 URI 完全一致的情况，才会执行其后的指令块。

示例1:禁止所有人访问/test/index.html文件

location = /test/index.html{
deny all;

}

示例2: 仅拒绝 192.168.0.100 访问 /test/index.html 文件

location = /test/index.html{

​	deny 192.168.0.100;

​	allow all;

}

示例3:仅允许192.168.0.100 访问 /test/index.html 文件

location = /test/index.html{

allow 192.168.0.100;

deny all;

}

正则匹配Nginx 配置文件中，多个正则 location 之间按照正则 location 在配置文件中的书写顺序进行匹配，且只要匹配成功就不会继续匹配后面定义的正则location。

示例如下:

location ~.htmlS {

		allow all;

}

location ~ /test/.* .htmlS {

deny all;

}
	解释下:比如访问ip/index.htmls不出意外肯定会正常访问，那么我们输入ip/test/htmls按照第二个匹配来说应该是拒绝的，但是因为上面说的只要匹配成功就不会继续匹配后面定义的正则location，所有ip/test/htmls也会访问成功。
	那么如果想ip/index.htmls访问成功，而ip/test/htmls访问不成功，我们只需要让这两个location交换位置就行

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

• referer：https://blog.werner.wiki/file–resolution-vulnerability-nginx/

漏洞描述

其实这个漏洞和代码执行没有太大的关系，主要的原因是错误的解析了请求的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下没有这个限制）

影响版本

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞复现

上传一个木马，发现上传失败

然后在”1.php“后改成加加空格“1.php “,就可以上传成功

但是却解析不出来

利用这种在后面空格能上传的特性，我们上传一个2.gif的木马，也是先用上面的方面，空格上传成功，但是执行不了php

我们再访问http://10.139.10.152:8080/uploadfiles/2.gif…php 多出来的俩个点是为了在hex里方便直接修改成20 00，修改后就成了/2.gif .php ，就可以成功解析。

知识补充：20 00表示的是 Unicode 编码字符集中的空格符，也称为 ASCII 码空格符，其对应的十进制数字是 32。其中的 “20” 是空格符在 ASCII 码表中所对应的十六进制数字。而 “00” 是它的后续字节，用来表示在 Unicode 字符编码集中的位置。

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

漏洞原理

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

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

漏洞复现

http://10.139.10.152:8080/访问，发现搭建成功，

vulhub下自带的poc，可以直接用

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

Nginx 配置错误导致漏洞（insecure-configuration）

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

1. CRLF注入漏洞

CR在十六进制中代表回车、LF在十六进制中代表换行，注入的原理就是用到就是用到了回车和和换行来构建新的数据包。

知识补充：

CRLF（回车换行符）注入漏洞是一种常见的网络攻击，它利用了某些应用程序未对用户输入进行充分验证和过滤的弱点。攻击者通过向 CRLF 注入恶意数据来篡改响应报头或正文中的内容，从而达到绕过身份验证、执行恶意代码、窃取敏感信息等目的。

具体来说，CRLF 注入攻击本质上是在原始请求或响应中插入回车换行符。如果攻击成功，这些字符将被解释为 HTTP 报头和正文中的换行符，从而使攻击者能够更改报头和正文中的任何部分内容。

例如，攻击者可以在 HTTP 响应头中注入额外的响应字段并控制它们的值，或者在报文中添加新的响应头，使得浏览器接收到的响应不是预期的结果。此外，攻击者还可以使用 CRLF 注入来实现其他类型的攻击，如 XSS、CSRF 和缓存投毒等。

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

原意是为了让HTTP请求跳转到HTTPS上，但是错误的配置导致nginx会将$uri解码，导致传入%0a%0d会导致换行，从而造成CRLF注入漏洞，可注入Set-cookie头/xss，

payload：http://your-ip:8080/%0a%0dSet-cookie:%20a=123  or  %0a%0d<script>alert(1)</script>

这里可以看到因为换行符，成功把setcookie换到了报文中，成为了http头的一部分

xss也成功执行

2. 目录穿越漏洞

location /files {
        alias /home/;
    }

“在Nginx的虚拟目录配置上，也就是Alias。Alias正如其名，alias指定的路径是location的别名，不管location的值怎么写，资源的真实路径都是Alias指定的路径”（看了两遍才看懂，可以注意点看这句话，很好理解）通俗来讲就是，当我访问http://your-ip/files/时真正访问的路径是/home/,而不是我们以为的/var/www/html/files/

http://your-ip/files…/–>http://your-ip/files/…/

访问到了/home/的上一个目录

3. add_header被覆盖

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

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

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

知识补充：在 Nginx 中，可以使用 add_header 指令在 HTTP 响应头中添加自定义的头信息。但是在某些情况下，可能会发生 add_header 指令被覆盖的问题。这种情况通常发生在 Nginx 配置中存在多个 server 或 location 块时。

当一份响应消息包含多个 add_header 指令时，如果多个指令名相同，则后面的指令会覆盖先前的指令。这个问题还有另外一个方面，可能会因为使用了代理或反向代理的功能而引起：被代理服务器发送的响应未必包含所有的 HTTP 头信息，因此用 add_header 添加自定义的头信息时，不会合并之前的头信息，而是覆盖之前的头信息。

csp相关资料

Nginx 解析漏洞复现

影响版本

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

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

​ 1、 由于nginx.conf的如下配置导致nginx把以’.php’结尾的文件交给fastcgi处理,为此可以构造http://your-ip/uploadfiles/2.png/1.php (url结尾不一定是‘1.php’,任何服务器端不存在的php文件均可,甚至.php比如’a.php’),其中2.png是我们上传的包含PHP代码的照片文件

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

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

漏洞复现

上传图片木马，然后链接后跟上.php就能成功执行

http://10.139.10.152/uploadfiles/2b22be7e2abe335544284604bafa000e.jpg/.php

代码007普通

打赏 收藏 海报 链接