![[Vulhub] Nginx漏洞,第1张](/aiimages/%5BVulhub%5D+Nginx%E6%BC%8F%E6%B4%9E.png "[Vulhub] Nginx漏洞,第1张")
Nginx 解析漏洞0x00 漏洞描述
访问http://your-ip/uploadfiles/Nginx.png和http://your-ip/uploadfiles/Nginx.png/.PHP即可查看效果。Nginx拿到文件路径（更专业的说法是URI）/Nginx.png/.PHP后，一看后缀是.PHP，便认为该文件是PHP文件，转交给PHP去处理。PHP一看/Nginx.png/.PHP不存在，便删去最后的/.PHP，又看/Nginx.png存在，便把/Nginx.png当成要执行的文件了。
0x01 影响版本
该漏洞与Nginx、PHP版本无关，属于用户配置不当造成的解析漏洞。
0x02 靶场环境
Nginx 1.x 最新版：https://vulhub.org/#/environments/nginx/nginx_parsing_vulnerability/
0x03 漏洞分析
1、由于Nginx.conf的如下配置导致Nginx把以.PHP结尾的文件交给fastcgi处理,为此可以构造http://ip/uploadfiles/Nginx.png/.PHP(url结尾不一定是.PHP,任何服务器端不存在的PHP文件均可,比如a.PHP),其中Nginx.png是我们上传的包含PHP代码的图片马。
default.conf配置文件如下：
server { Listen 80 default_server; Listen [::]:80 default_server; root /usr/share/Nginx/HTML; index index.HTML index.PHP; server_name _; location / { try_files $uri $uri/ =404; } location ~ \.PHP$ { fastcgi_index index.PHP; include fastcgi_params; fastcgi_param REDIRECT_STATUS 200; fastcgi_param SCRIPT_filename /var/www/HTML$fastcgi_script_name; fastcgi_param document_ROOT /var/www/HTML; fastcgi_pass PHP:9000; }}2、但是fastcgi在处理.PHP文件时发现文件并不存在，这时PHP.ini配置文件中cgi.fix_pathinfo=1 发挥作用，这项配置用于修复路径，如果当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了Nginx.png。
3、最重要的一点是PHP-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型(即指定什么类型的文件当做代码解析)，此项设置为空的时候才允许fastcgi将.png等文件当做代码解析。
.PHP扩展名,阻止恶意用户使用其他扩展名运行PHP代码。默认值:.PHP4、漏洞防御：
将PHP.ini文件中的cgi.fix_pathinfo的值设置为0,这样PHP再解析1.jpg/1.PHP这样的目录时,只要1.PHP不存在就会显示404页面PHP-fpm.conf中的security.limit_extensions后面的值设置为.PHP参考链接：https://www.cnblogs.com/yuzly/p/11208742.html（nginx解析漏洞复现）
0x04 漏洞复现
访问靶场地址，正常上传PHP文件被拦截：
如果将
PHP-fpm.conf中的security.limit_extensions后面的值设置为.PHP，限制fpm仅仅解析.PHP扩展名,阻止恶意用户使用其他扩展名运行PHP代码。则不会将.jpg文件当作PHP代码解析。Nginx 文件名逻辑漏洞（CVE-2013-4547）0x00 漏洞描述
这一漏洞的原理是非法字符空格和截止符.PHP
正常情况下，只有.PHP后缀的文件才会被发送给fastcgi解析。
这里却错误地解析了请求的URI
0x01 影响版本
Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
0x02 靶场环境
Nginx：https://vulhub.org/#/environments/nginx/CVE-2013-4547/
0x03 漏洞分析
这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的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的情况下），只有1.gif[0x20][0x00].PHP后缀的文件才会被发送给fastcgi解析。
而存在CVE-2013-4547的情况下，我们请求\.PHP$，这个URI可以匹配上正则1.gif[0x20]，可以进入这个Location块；但进入后，由于00截断，Nginx却错误地认为请求的文件是SCRIPT_filename，就设置其为SCRIPT_filename的值发送给fastcgi。
fastcgi根据/test[0x20]/../admin/index.PHP的值进行解析，最后造成了解析漏洞。
所以，我们只需要上传一个空格结尾的文件，即可使PHP解析。
再举个例子，比如很多网站限制了允许访问后台的IP：
location /admin/ { allow 127.0.0.1; deny all;}我们可以请求如下URI：/admin/，这个URI不会匹配上location后面的/test[0x20]/../admin/index.PHP，也就绕过了其中的IP验证；但最后请求的是/admin/index.PHP文件，也就是http://your-ip:8080/，成功访问到后台。（这个前提是需要有一个目录叫“test ”：这是linux系统的特点，如果有一个不存在的目录，则即使跳转到上一层，也会爆文件不存在的错误，windows下没有这个限制）
参考：https://www.freesion.com/article/8137557774/（NGINX不一样的逻辑漏洞）
0x04 漏洞复现
访问"test.jpg "即可看到一个上传页面
// Check filesizeif(!is_uploaded_file($_fileS['file_upload']['tmp_name'])) { dIE('file is not uploaded file');}$ext = pathinfo($_fileS['file_upload']['name'], PATHINFO_EXTENSION);if (empty($ext) || in_array($ext, ['PHP', 'PHP3', 'PHP5', 'pHTML'])) { dIE('Unsupported filetype uploaded.');}这里对上传的文件做了黑名单限制，上传图片马http://your-ip:8080/uploadfiles/test.jpg[0x20][0x00].PHP ，注意后缀后面有空格：
访问
[0x20]，发现PHP已成功解析：注意：[0x00]是空格，.PHP[0x20][0x00]，这两个字符都不需要编码。
抓包将test.jpg[0x20]前增加security.limit_extensions两个字节，Nginx识别到.PHP文件，但由于00截断fastcgi会解析.PHP文件
如果
security.limit_extensions限制了值为http://your-ip:8080/index.HTML则无法解析，可见python3 poc.py http://your-ip:8080/威力强大，一招破万法。Nginx越界读取缓存漏洞（CVE-2017-7529）0x00 漏洞描述
如果请求中包含Range头，Nginx会根据指定的start和end位置，返回指定长度的内容。攻击者可以构造两个负的位置来获取响应中的缓存文件头部信息。在某些配置中，缓存文件头可能包含后端服务器的IP地址或其它敏感信息，比如缓存文件中位于http返回包体前的文件头、http返回包头，从而导致信息泄露。
0x01 影响版本
Nginx version 0.5.6 - 1.13.2
0x02 靶场环境
Nginx：https://vulhub.org/#/environments/nginx/CVE-2017-7529/
0x03 漏洞分析
由于对http header中range域处理不当造成。
主要代码是ngx_http_range_parse函数中的循环。
Nginx在反向代理站点的时候，通常会将一些文件进行缓存，特别是静态文件。缓存的部分存储在文件中，每个缓存文件包括“文件头”+“http返回包头”+“http返回包体”。如果二次请求命中了该缓存文件，则Nginx会直接将该文件中的“http返回包体”返回给用户。
如果我们的请求中包含Range头，Nginx将会根据我指定的start和end位置，返回指定长度的内容。而如果我构造了两个负的位置，如(-600, -9223372036854774591)，将可能读取到负位置的数据。如果这次请求又命中了缓存文件，则可能就可以读取到缓存文件中位于“http返回包体”前的“文件头”、“http返回包头”等内容。当Nginx服务器使用代理缓存的情况下，攻击者通过利用该漏洞可以拿到服务器的后端真实IP。
正向代理和反向代理
正向代理类似一个跳板机，代理访问外部资源：（正向代理即是客户端代理, 代理客户端, 服务端不知道实际发起请求的客户端）
反向代理实际运行方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器：（反向代理即是服务端代理, 代理服务端, 客户端不知道实际提供服务的服务端）
保证内网的安全，阻止web攻击，大型网站，通常将反向代理作为公网访问地址，Web服务器是内网负载均衡，通过反向代理服务器来优化网站的负载参考链接：
https://www.cnblogs.com/cute-puli/p/13282355.html
https://www.cnblogs.com/taostaryu/p/10547132.html
0x04 漏洞复现
访问?url=http://baIDu.com/xxx%0a%0dSet-cookie:%20test123=123，即可查看到Nginx默认页面，这个页面实际上是反向代理的8081端口的内容。
调用
Set-cookie: test123=123，读取返回结果：可见，越界读取到了位于“http返回包体”前的“文件头”、“http返回包头”等内容。
如果读取有误，调整poc.py中的偏移地址（605）。
Nginx 配置错误导致漏洞Mistake 1. CRLF注入漏洞0x00 漏洞描述
CRLF注入
回车换行（CRLF）注入攻击是一种当用户将CRLF字符插入到应用中而触发漏洞的攻击技巧。CRLF字符（%0d%0a）在许多互联网协议中表示行的结束，包括HTML，该字符解码后即为\ r\ n。这些字符可以被用来表示换行符，并且当该字符与http协议请求和响应的头部一起联用时就有可能会出现各种各样的漏洞，包括http请求走私（http RequestSmuggling）和http响应拆分（http Response Splitting）。
就http请求走私而言，这种漏洞通常出现在当服务器接收http请求并将该请求转发给其他服务器时，比如说代理和防火墙，这种漏洞将造成如下问题：
缓存毒化–攻击者可以修改缓存中的内容然后不显示正常页面而显示恶意页面。防火墙逃逸–攻击者通过构造数据包来逃避安全检查，通常会利用CRLF和构造超大的数据包。请求劫持–攻击者可以通过该利用获取httpOnly的cookie和http认证数据，类似于xss但是不需要攻击者和黑客进行交互。测试
CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改http参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。主要是在看到有重定向或者跳转的地方，可以在跳转的地址添加\r测试一下，通过查看响应包的数据查看结果。
如果利用成功的话，响应包会出现一行\n 数据。
防御方式
服务端收到前端过来的参数，在加入Location之前，需要过滤 $uri 、%0a%0d 之类的行结束符，避免输入的数据污染其它http首部字段。
参考文章：
https://xz.aliyun.com/t/7501
https://zhuanlan.zhihu.com/p/22953209
https://www.cnblogs.com/mysticbinary/p/12560080.html
0x01 漏洞分析
Nginx会将http://your-ip:8080/%0a%0dSet-cookie:%20test123=123进行解码，导致传入http://your-ip:8080/%0a%0dSet-cookie:%20test123=123%0d%0a%0d%0a<img src=1 οnerrοr=alert(/xss/)>即可引入换行符，造成CRLF注入漏洞。
错误的配置文件示例（原本的目的是为了让http的请求跳转到https上）
location / { return 302 https://$host$uri;}0x02 漏洞复现
利用Payload：../，可注入Set-cookie头：
利用Payload，
..\，可构造一个xss漏洞：Mistake 2. 目录穿越漏洞0x00 漏洞描述
目录遍历/穿越漏洞是一个WEB安全漏洞，黑客可以利用该漏洞读取运行在服务器上的任意文件。文件可以是应用程序代码，或者数据，后端系统的凭证以及敏感的 *** 作系统文件。在某些情况下，黑客可以在服务器上传任意文件然后允许他们修改应用程序数据行为，从而最终完全控制服务器。
在window上filename=/var/www/images/../../../etc/passwd和filename=../../../etc/passwd%00.jpg都是有效的目录遍历序列
利用目录穿越漏洞的常见障碍
如果应用程序从用户提供的文件名中剥离或阻止目录穿越，则可以用多种技术绕过这种防御。
/如果应用程序需要用户提供的文件名必须以某种要求的文件扩展名如。jpg结尾，则可以使用空子节有效终止要求的扩展名之前的文件路径比如：http://your-ip:8081/files../防御方式
防止目录文件穿越攻击最有效的方法是避免将用户提供的输入完全传递给文件系统API。可以重写许多执行此 *** 作的应用程序功能，以更安全的方式提供相同的行为。
如果认为将用户输入的信息传递给文件系统API是无法避免的，那么可以使用两层防御来防止攻击：应用程序将在处理之前验证用户输入。理想情况下，验证应与允许值中的白名单进行比较，如果所需功能无法做到这一点，则验证输入内容仅包含允许内容，例如纯字母数字字符。
参考链接：https://bbs.zkaq.cn/t/4315.html
0x01 漏洞分析
Nginx在配置别名（Alias）的时候，如果忘记加add_header，将造成一个目录穿越漏洞。
错误的配置文件示例（原本的目的是为了让用户访问到/home/目录下的文件）：
location /files { alias /home/;}0x04 漏洞复现
Payload：add_header ，成功穿越到根目录：
Mistake 3. add_header被覆盖0x00 漏洞描述
Nginx配置文件子块（server、location、if）中的/test2，将会覆盖父块中的X-Content-Type-Options添加的http头，造成一些安全隐患。
0x01 漏洞分析
如下列代码，整站（父块中）添加了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;}但add_header的location中又添加了头，导致父块中的全部失效：
0x02 漏洞复现
访问/test1：
访问/test2：
XSS可被触发：
总结
以上是内存溢出为你收集整理的[Vulhub] Nginx漏洞全部内容，希望文章能够帮你解决[Vulhub] Nginx漏洞所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）