一、漏洞详情
影响版本 Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
通过%00截断绕过后缀名的限制,使上传的php内容文件被解析执行。
当Nginx得到一个用户请求时,首先对url进行解析,进行正则匹配,如果匹配到以.php后缀结尾的文件名,会将请求的PHP文件交给PHP-CGI去解析。
假设服务器中存在文件‘123.png ',则可以通过访问如下网址让服务器认为'123.png '的后缀为php
http://127.0.0.1/123.png \0.php
代码层面来说,我们请求的url中123.png[0x20][0x00].php正好与location模块中的.php相匹配,但进入该模块后Nginx确认为请求的文件名是'123.png ',就设置其为script_name的值交给CGI进行解析,最终造成解析漏洞。
二、复现过程
搭建docker环境
docker-compose up -d

访问8080端口

上传图片马
创建一个新文档,保存为123.png
内容为:
GIF98A
<?php phpinfo(); ?>

GIF98A可以将文件伪造成图片,从而绕过一些文件上传的限制
bp抓包


%00截断解析php文件
访问
http://192.168.239.128:8080/uploadfiles/123.png%20a.php
用bp抓包

a是占位符,把a的hex编码变为00(新版本的bp已经没有了之前的Hex选项,只能选中单个字符在右边的框里进行修改),点击apply changes
再把%20用一个空格代替
点击发送

phpinfo()被成功执行

三、总结
复现的过程卡在了bp上面
到现在也没弄懂为什么访问http://192.168.239.128:8080/uploadfiles/123.png时无法被抓包?

也算是个题外话,虚心求教🙏