Nginx 文件名逻辑漏洞(CVE-2013-4547)
影响版本:Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
漏洞原理:
这个漏洞其实和代码执行没有太大关系,其主要原因是错误地解析了请求的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;
}
只有.php后缀的文件才会被发送给fastcgi解析。
而存在CVE-2013-4547的情况下,我们请求1.gif[0x20][0x00].php,这个URI可以匹配上正则.php$,可以进入这个Location块;但进入后,Nginx却错误地认为请求的文件是1.gif[0x20],就设置其为SCRIPT_FILENAME的值发送给fastcgi。
fastcgi根据SCRIPT_FILENAME的值进行解析,最后造成了解析漏洞。
所以,我们只需要上传一个空格结尾的文件,即可使PHP解析之。(建议先去学习有关cgi,fastcgi的知识)
漏洞的两个必要条件:
1. 关于cgi.fix_pathinfo的配置
要关闭,如果cgi.fix_pathinfo被开启,将会先去判断文件是否存在。而不会直接去匹配location块进而被发送到fastcgi程序
2.关于高版本php"security.limit_extensions"的限制
如果配置为:
security.limit_extensions = .php
那么将只会把后缀为.php的文件当作是合法的php文件,进而我们的jpg空格文件将会被判定为不合法。进而不会被去当作php解析
漏洞演示
环境:vulhub docker
启动环境:
上传1.jpg空格文件:
访问上传的文件:
出现404的原因不是我们没用上传上去,而是在访问1.jpg空格时,空格被编码成为了%20我们没用1.jpg%20这个文件
我们通过burp抓包,改hex进行访问:
成功执行phpinfo
windows下
相比于如上使用的linux环境复现,在windows进行攻击,由于windows的特性攻击是更容易的。
**windows读取文件时的特点:**即文件系统api创建文件名或查找文件名时,默认会去掉文件名后的空格,再执行操作.
此时的攻击过程为:
1.上传任意文件(不需要带空格文件)
2.http://ip/a.jpg0x20x00.php(burp进行hex更改后访问)
即可攻击成功