nginx文件名逻辑漏洞_CVE-2013-4547漏洞复现

一、漏洞描述

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

二、漏洞原理

举个例子,比如,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

Nginx 1.5.0~1.5.7

四、漏洞环境搭建和复现

1、使用docker搭建vulhub漏洞环境,启动漏洞环境

docker-compose build

docker-compose up -d

2、浏览器访问http://172.17.0.1:8080/,测试环境是否搭建成功

  

3、 看一下后端过滤

  

4、上传一个mu.jpg,里面的内容还是<?php phpinfo();?>,注意后面的空格,发现上传成功

  

5、构造mu.jpg[0x20][0x00].php来造成Nginx解析漏洞,使我们的mu.jpg被解析成php

在burp抓取的数据包中把mu.jpg后面的两个空格 [0x20][0x20] ---> [0x20][0x00] ,发现成功上传

  

  

6、访问http://172.17.0.1:8080/uploadfiles/1.gif[0x20][0x00].php,即可发现PHP已被解析

  

五、漏洞防御

1、升级版本

--------------------------------------------------------------------------------------------------

参考资料: https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2013-4547

原文地址:https://www.cnblogs.com/yuzly/p/11221564.html

时间: 2024-07-29 11:29:31

nginx文件名逻辑漏洞_CVE-2013-4547漏洞复现的相关文章

实战经验丨业务逻辑漏洞探索之活动类漏洞

活动类的漏洞大家一定听说过,比如之前拼多多APP出现重大BUG,用户可以在任何没有限制的情况下无限领取100元无门槛优惠券.据不完全统计,一晚上的时间直接导致了拼多多200多亿的优惠券面额损失. 其实很多平台都会通过参与活动赢取奖励的方式来吸引用户,或是使用资金.虚拟货币.积分等进行交易,然而如果这些功能没有设计好,会很容易造成重大的经济损失,比如像上述的拼多多案例. 那么今天我们就来学习一下业务逻辑漏洞探索之活动类漏洞的相关内容,希望对大家有所帮助. 注:本文中提供的例子均来自网络已公开测试的

典型漏洞归纳之解析漏洞

0x00 总览说明 服务器解析漏洞算是历史比较悠久了,但如今依然广泛存在.在此记录汇总一些常见服务器(WEB server)的解析漏洞,比如IIS6.0.IIS7.5.apache.nginx等方便以后回顾温习. 一.IIS5.x-6.x解析漏洞 使用iis5.x-6.x版本的服务器,大多为windows server 2003,网站比较古老,开发语句一般为asp:该解析漏洞也只能解析asp文件,而不能解析aspx文件. IIS 6.0解析利用方法有两种 1.目录解析 /xx.asp/xx.jp

乌云主站所有漏洞综合分析&amp;乌云主站漏洞统计

作者:RedFree 最近的工作需要将乌云历史上比较有含金量的漏洞分析出来,顺便对其它的数据进行了下分析:统计往往能说明问题及分析事物的发展规律,所以就有了此文.(漏洞数据抓取自乌云主站,漏洞编号从1-121018,抓取用时8h.)  1.漏洞总数SELECT count(*) FROM AllBugs     漏洞总数59630,编号数121018,所以审核通过率=59630/121018=0.49.27%.想想审核也够苦B的,每两个漏洞就有一个不合格…… 2.漏洞数量分析(sql没学好,不要

网站漏洞修复之UEditor漏洞 任意文件上传漏洞 2018 .net新

UEditor于近日被曝出高危漏洞,包括目前官方UEditor 1.4.3.3 最新版本,都受到此漏洞的影响,ueditor是百度官方技术团队开发的一套前端编辑器,可以上传图片,写文字,支持自定义的html编写,移动端以及电脑端都可以无缝对接,自适应页面,图片也可以自动适应当前的上传路径与页面比例大小,一些视频文件的上传,开源,高效,稳定,安全,一直深受站长们的喜欢. 百度的UEditor文本编辑器,近几年很少被曝出漏洞,事情没有绝对的,总会有漏洞,这次被曝出的漏洞是.net版本的,其他的php

漏洞大爆光:QQ漏洞、飞秋漏洞、360浏览器劫持…

?? 随着互联网应用的快速发展,信息安全已深入到诸多领域,前段时间发生的"Struts 2"漏洞及"心脏出血"漏洞影响了二亿中国网民的信息安全,原因是程序员缺少仔细的安全检查导致的.作为程序员,此时我们应该更加关注程序的安全性才对,但现实情况是程序员关注的依然是程序功能的实现,仍然忽视了程序的安全性,以至于很多程序都存在安全漏洞.下面是传智播客C/C++学院仅仅学习了5个月C/C++语言的学生发现的部分软件漏洞:(更多软件漏洞将会持续发布...) 1.飞秋远程溢出漏

【0Day】栈溢出漏洞基础——简单输入漏洞 &amp; 修改返回函数

最近再次利用零零散散的时间,把第二章学完了. 感觉实验成功之后,还是非常开心的!嘿嘿. 书本上的理论可以很快的看完,但是真正实践的时候还是会出现一点问题的.一点点总结将在后面一起分享出来. 自己构造的漏洞代码,如果使用VS编译的话,debug版溢出了会报错,release版它自己把代码优化了,消除了溢出的漏洞. 看来好几年前的技术现在已经被防护的很彻底了呀.  所以说,学技术不能死学,要学习思想. 0x00 堆栈的基本原理 在调用一个call之后,堆栈的情况是这样的. call中记录的是前栈帧的

Apache Struts最新漏洞 远程代码执行漏洞预警 2018年11月08日

2018年11月8日,SINE安全监控检测中心,检测到Apache Struts官方更新了一个Struts漏洞补丁,这个漏洞是Apache Struts目前最新的漏洞,影响范围较广,低于Apache Struts 2.3.35的版本都会受到此次Struts漏洞的攻击,目前apache官方更新的漏洞补丁,主要是修复commonsfileupload上传库出现的安全问题,这个库可以远程执行代码,上传木马后门到网站服务器中去. Apache Struts 漏洞描述 某知名的安全组织向Apache St

nginx 源码安装openssl修复Heartbleed漏洞

如果你的nginx使用的是动态的openssl库,直接升级openssl,如果你的nginx使用的是静态的openssl库,那就要重新编译安装nginx. PHP编译修复 1. nginx使用的是动态的openssl库,直接升级openssl    1.1 源码安装openssl1.0.1g版本        先下载openssl 1.0.1g版本,命令如下:            #wget  -c    https://www.openssl.org/source/openssl-1.0.1

nginx 配置不当导致目录遍历下载漏洞

今天做百度杯的时候发现一个题很有意思. 点进题目,发现了一个js重定向到login.php,抓包发现请求的header中cookie=0,做过这种类似的题目,o==false,在请求头里面将cookie=1,结果就进去了后台,(login.php中没有发现什么信息),进入后台, 点开Manage,如上图,网址的构造是module=index$name=php 推测是文件包含,我将index改成flag,说明flag在flag.php中我们所要做的就是提取出flag.php中的内容 思路1 用ph