分享PHP场景中getshell防御思路

1 背景概述

web应用漏洞导致的入侵时有发生，扫描器和waf并不能解决所有的问题，于是尝试在主机侧针对php环境做了一个防御方案。很荣幸的邀请到tsrc部分白帽子做了一次对抗演习，本文主要分享一下防御思路。

防御方案主要想解决的问题是getshell、主机敏感文件泄漏等问题。于是乎出了下面这样一个题目：部署了防御方案的nginx + php 的web环境，提供一个上传入口，可上传任意文件。找到web目录下的一个flag文件读取到内容即算突破。

2 php扩展

防御方案使用了php扩展来完成阻断。php内核支持c/c++开发一些扩展功能，并且提供了一个框架 – ext_skel帮助生成基本的代码简化开发，由于php扩展并不涉及底层的资源管理，所以编写一个php扩展和编写一个c应用程序是一样的。下图展示了php扩展所处的结构层次，扩展位于php内核zend 和 php应用层代码之间，那么利用php扩展可以：

1) 监控php应用层代码的执行细节，包括执行cgi、函数名、参数等;

2) 调用php内核zend提供的api接口，包括禁用类、修改配置选项等。

图1 php语言的结构

3 相关知识

3.1 hookphp代码

php是解释型语言，代码被翻译为中间字节码由zend引擎解析执行。php把中间字节码称之为opcode，每个opcode对应zend底层的一个处理函数，zend引擎最终执行这个处理函数。实现hook功能只需要改变hook opcode对应的处理函数即可，而zend预先就提供了一个现成的接口：zend_set_user_opcode_handler。防御方案只需要hook以下三个opcode：

zend_include_or_eval — eval、require等

zend_do_fcall — 函数执行system等

zend_do_fcall_by_name — 变量函数执行 $func = “system”;$func();

举例：

zend_do_fcall这个opcode对应的功能是函数调用，如果需要hook所有的函数调用：

1) 在模块初始化函数中使用zend_set_user_opcode_handler修改zend_do_fcall新的处理函数为mysub：

php_minit_function(phpips){

zend_set_user_opcode_handler(zend_do_fcall, mysub);

return success;

}

2) 在自定义函数中实现自己需要的功能并返回原来的处理函数：

void mysub(){

自定义功能;

return zend_user_opcode_dispatch;

}

3.2 zend接口

hook之外还需要获取一些基本信息或功能，比如：

1) 获取执行的php脚本名，可调用zend的接口zend_get_executed_filename：

char *cgi_name = (char*)zend_get_executed_filename(tsrmls_c);

2) 禁用一些类库，可使用zend_disable_class接口;

zend提供了很多丰富的接口，可根据需求选择调用。

3.3 数据结构

php是弱类型语言，其上层并不区分变量类型，变量底层对应的是一个union结构体，以php-5.3.6版本举例，结构体在zend/zend.h文件中定义;内容如下：

typedef union _zvalue_value {

long lval; /* longvalue */

double dval; /* double value */

struct {

char *val;

int len;

} str;

hashtable *ht; /* hash table value*/

zend_object_value obj;

} zvalue_value;

php是在底层区分开了变量类型;在union结构体中有个非常重要的结构体hashtable，php中的数组结构就是利用hashtable这个结构体实现，如果变量是个数组，获取变量内容需要遍历这块hashtable，数据结构这块不做太多介绍。zend底层用zval这个结构体存储变量，同时zend提供了几个宏可以方便的转换zval到具体的数据类型，比如把zval类型转换为字符串 – zval el; z_strval_p(el)，常用的还有：

z_lval_p、z_dval_p、z_arrval_p等，以上宏列表在 zend/zend_operators.h有定义。

4 规则策略

4.1 基本思路

我们需要解决的问题是getshell、主机敏感文件泄漏等问题。如果限制住php脚本执行命令 和 翻阅文件的功能，就达到了目的。同时，由于读取文件的接口非常多，使用场景也较多，因此采取禁用打开目录接口来侧面达到禁止翻阅文件的目的，不能遍历目录便无法得到文件名，可以有效的达到目标。故最终形成的最终策略如下：

1) 禁用掉执行命令的接口

2) 禁用掉打开目录的接口

禁用函数有一些需要注意的问题：

1) php接口还是比较繁多复杂的，除了system、exec、opendir、scandir常用函数之外，一些生僻函数比如glob等函数都要考虑全面，另外还有一些回调函数、反射类(ps：部分考虑不全被blackeye和雪人绕过)

2) php spl提供的一些类库有文件管理的功能，也需要禁止，比如directoryiterator(不过好像没有白帽子使用过spl)

4.2 对抗变形

php使用assert或preg_replace /e执行代码，调用zend_get_executed_filename获取的php脚本名中会带有辨别标识，assert对应的是assert code，preg_replace对应的是regexp code;当发现这些特殊的脚本执行了system等4.1中提高的高危函数直接阻断。以下图的nonalphanumeric -webshell举例：

变形webshell解析后的形式和$_get[1]($_get[2])类似，比如传入1=assert&2=system(whoami)执行代码，php扩展层监控到system函数执行，并且发现php脚本名带regexp code标识，清晰的知道是preg_replace的代码执行了调用了system，阻断system。assert函数同理。总结：扩展并不关注在静态层如何编码运算或加密，扩展只监控最后的行为，所以可以很好的解决目前的变形难题。

图2nonalphanumeric – webshell

4.3 减少误杀

有时正常的php脚本也需要用到命令执行的功能，如何保证其正常运行，不被我们的防御策略阻断呢?这里提供三种思路：

1) 写入权限和执行命令权限互斥

考虑到入侵者利用上传漏洞或者其他0day getshell得到的文件大多会有w写权限，防御方往往希望阻止这部分文件拥有过高的权限。

那么，我们可以去除正常php脚本的可写权限，然后只对有写权限的php脚本实施命令执行等防御策略的阻断逻辑。这样即不会影响到业务的使用，又达到了预设场景的防护目标。不过这样的思路，需要禁用chmod等可以修改文件权限的函数。

2) 使用白名单逻辑

粗暴一点的可以用文件名白名单，也就是业务报备过的文件不受阻断，其它不认识的文件一律禁止。优雅一点的可以对函数参数做白名单，比如提取正常php脚本执行命令的参数或者代码特征，对其进行放行，不认识的特征一律阻断。

3) 使用黑名单逻辑

设定一些已知恶意脚本的黑特征参数，类似于杀毒软件早期的特征码思路。

上述思路在企业推广时，需要和业务有足够充分的配合，也都有不完美的地方，如果大家有更多方案或者思路，欢迎与我共同探讨。

5 未来

利用php扩展可以做的事情还是比较多，比如在漏洞检测方面、对数据库函数参数过滤、阻断sql注入、阻断存储型xss等场景都有非常大的想象空间。甚至在代码审计这块也可以考虑，国内有个大牛已经有比较成熟的开源产品，taint (作者：laruence)，大家可能都已经比较熟悉了，就暂时不做赘述了。

行文比较仓促，有不足的地方请谅解，有任意疑问或建议欢迎联系pandas(小毛驴)切磋交流。