docker复现Nginx错误配置漏洞

1.Nginx环境搭建

1.首先创建Nginx的目录：

mkdir /soft && mkdir /soft/nginx/
cd /soft/nginx/

2.使用wget命令在线获取Nginx安装包：

wget https://nginx.org/download/nginx-1.21.6.tar.gz

3.解压Nginx的压缩包：

tar -xvzf nginx-1.21.6.tar.gz

4.下载并安装Nginx所需的依赖库和包：

yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++
yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4
yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel
yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel

5.使用rpm命令安装所有依赖包：

rpm -ivh --nodeps *.rpm

6.进入nginx目录，安装其他依赖库，然后执行Nginx的配置脚本，为后续的安装提前配置好环境，默认位于/usr/local/nginx/目录下（可自定义目录）：

cd nginx-1.21.6
yum install pcre-devel
yum install zlib-devel
./configure --prefix=/soft/nginx/

7.编译并安装Nginx：

make && make install

8.修改conf目录下的nginx.conf配置文件：

#gzip on;

server{
	listen 80;
	server_name (这里填自己的ip);
	
	#charset koi8-r;

	#access_log logs/host.access.log main;

	location / {
		root html;
		index index.html index.htm;
	}

	#error_page 404              /404.html;

	# redirect server error pages to the static page /50x.html
	#
	error_page     500 502 503 504   /50x.html;
	location = /50x.html{
		root     html;
	}

9.制定配置文件并启动Nginx：

sbin/nginx -c conf/nginx.conf

2. docker环境搭建

2.1 安装docker

(1)Debian使用以下命令

apt-get update
apt-get install docker.io

(2)Redhat使用以下命令

yum install docker.io

2.2 下载并解压docker环境Nginx配置漏洞安装包

(1)cd到对应目录下，docker启容器

unzip vulhub-master.zip
cd /root/vulhub-master/nginx/insecure-configuration
docker-compose up -d

(2)安装好后，用docker ps -a查看容器运行情况

root@localhost:~/vulhub-master/nginx/insecure-configuration# docker ps -a
CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS          PORTS                                                                   NAMES
797f6975a01e   vulhub/nginx:1   "nginx -g 'daemon of…"   59 minutes ago   Up 59 minutes   80/tcp, 0.0.0.0:8080-8082->8080-8082/tcp, :::8080-8082->8080-8082/tcp   insecure-configuration_nginx_1

STATUS为up状态就表示容器正在运行

3.案例

3.1 $uri导致的CRLF注入漏洞

这个漏洞产生的原因是请求重定向的错误配置，导致在url中输入回车换行符可以控制http响应头部
比如：

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

原本的目的是为了让http的请求跳转到https上

但是$uri参数是不包含查询参数的，于是当我们在url中输入%0d%0a时，$uri参数不会将回车换行符传入，这就导致用户可以控制http响应头部

修复方法：把$url改为$request-uri，这个参数会传入完整的原始url请求，也就是说用户输入的所有内容都会被当做参数传入Location字段

3.2.目录穿越

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass传递给后端端口，而静态文件需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就需要用alias设置目录的别名：

www.xianoupeng.com/files

location /files/{
    alias /home/;
}
www.xianoupeng.com/files../

location /files/ {
	alias /home/	
}

此时，访问http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。

但我们注意到，url上/files没有加后缀/，而alias设置的/home/是有后缀/的，这个/就导致我们可以从/home/目录穿越到他的上层目录

进而我们获得了一个任意文件下载漏洞。

/user/share/nginx/html/config.php 有mysql配置 mysql 用户名和密码

修复方法：只需要保证location和alias的值都有后缀/或都没有这个后缀。

3.3 Http Header被覆盖的问题

众所周知，Nginx的配置文件分为Server、Location、If等一些配置块，并且存在包含关系，和编程语言比较类似。如果在外层配置的一些选项，是可以被继承到内层的。

但这里的继承也有一些特性，比如add_header，子块中配置后将会覆盖父块中的add_header添加的所有HTTP头，造成一些安全隐患。

如下列代码，Server块添加了CSP头：

server {
    ...
    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全部失效,我们成功触发XSS