0x01 Free


[root@template tmp]# free -m

             total       used       free     shared    buffers     cached

Mem:         15724        840      14883          0        213        214

-/+ buffers/cache:        412      15311

Swap:         4999          0       4999

这里先说一下buffer与cache

buffers 就是存放要输出到disk(块设备)的数据,缓冲满了一次写,提高io性能(内存 -> 磁盘)

cached 就是存放从disk上读出的数据,常用的缓存起来,减少io(磁盘 -> 内存)

 

然后我们看一下每个值具体的含义:

Mem

Mem:表示物理内存统计

-/+ buffers/cached:表示物理内存的缓存统计

Swap:表示硬盘上交换分区的使用情况

 

系统的总物理内存:15724M,注意第一行的Free并非是真正可用的内存。我们来看下每个值具体的含义

total1:表示物理内存总量

used1:表示总计分配给缓存(包含buffers 与cache )使用的数量,但其中可能部分缓存并未实际使用

free1:未被分配的内存

shared1:共享内存

buffers1:系统分配但未被使用的buffers 数量

cached1:系统分配但未被使用的cache 数量

 

-/+buffers/cache

used2:实际使用的buffers 与cache 总量,也是实际使用的内存总量。

free2:未被使用的buffers 与cache 和未被分配的内存之和,这就是系统当前实际可用内存。

 

具体计算方式如下:

total1 = used1 + free1

total1 = used2 + free2

used1 = buffers1 + cached1 + used2

free2 = buffers1 + cached1 + free1

 

0x02 Top


[root@template tmp]# free -k        

             total       used       free     shared    buffers     cached

Mem:      16101816    1029264   15072552          0     220152     386804

-/+ buffers/cache:     422308   15679508

Swap:      5119992          0    5119992

[root@template tmp]#  top | head -n 5

top - 14:48:29 up 23:53,  3 users,  load average: 0.00, 0.01, 0.00

Tasks: 142 total,   1 running, 141 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.2%us,  0.1%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:  16101816k total,  1029388k used, 15072428k free,   220128k buffers

Swap:  5119992k total,        0k used,  5119992k free,   386800k cached

显示的值实际与我们使用Free第一行显示的数据几乎一致,但是top无法给出free 第二行的 -/+ buffers/cache 数据。所以top命令不能完全反映出物理内存的实际使用量,推荐用free查看物理内存的实际使用量。

 

0x03 Htop


查看内存显示的实际内存用量,与used2一致。

[root@template tmp]# yum install htop

[root@template tmp]# free -m

             total       used       free     shared    buffers     cached

Mem:         15724       1005      14719          0        214        377

-/+ buffers/cache:        412      15312

Swap:         4999          0       4999

 

0x01 概述


Nginx的解析漏洞都是与CGI接口有关,PHP5.3.3之后就自带了PHP-FPM。

另外现在网上的资料都是说从5.3.9开始,php官方加入了一个配置”security.limit_extensions”,默认状态下只允许执行扩展名为”.php”的文件。

可以查看/etc/php-fpm.d/www.conf

; Limits the extensions of the main script FPM will allow to parse. This can

; prevent configuration mistakes on the web server side. You should only limit

; FPM to .php extensions to prevent malicious users to use other extensions to

; exectute php code.

; Note: set an empty value to allow all extensions.

; Default Value: .php

security.limit_extensions = .php .php3 .php4 .php5

可以看到默认值为.php。这样其实下面的解析漏洞是不受影响的。

不过现在CentOS6下通过yum安装的php-fpm:

[root@kafka112 ~]# yum install php-fpm -y

版本是5.3.3

[root@kafka112 ~]# rpm -qa | grep php-fpm

php-fpm-5.3.3-49.el6.x86_64

默认值为.php

[root@kafka112 php-fpm.d]# grep -B 1 'limit_extensions' www.conf

; Default Value: .php

;security.limit_extensions = .php .php3 .php4 .php5

与网上说法不太一致,测试需要注意。

 

0x02 fix_pathinfo


漏洞测试:

访问http://www.target.com/robots.txt

返回头Content-Type: text/plain

访问http://www.target.com/robots.txt/x.php

返回头Content-Type: text/html

也就是robots.txt被当做PHP解析。那么问题就来了,如果用户上传包含恶意代码的头像文件,然后利用该方法解析为PHP,那么就能轻松拿到shell。

其实该问题的根本原因在于php.ini中的cgi.fix_pathinfo配置,我们来看下cgi.fix_pathinfo配置

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's

; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok

; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting

; this to 1 will cause PHP CGI to fix it's paths to conform to the spec.  A setting

; of zero causes PHP to behave as before.  Default is 1.  You should fix your scripts

; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.

cgi.fix_pathinfo=0

如果开启了这个选项, 那么就会触发在PHP中的如下逻辑:

/*

 * if the file doesn't exist, try to extract PATH_INFO out

 * of it by stat'ing back through the '/'

 * this fixes url's like /info.php/test

 */

if (script_path_translated &&

     (script_path_translated_len = strlen(script_path_translated)) > 0 &&

     (script_path_translated[script_path_translated_len-1] == '/' ||

....//以下省略.

可以看到如果文件不存在,则会PATH_INFO作为PHP解析。

 

修复方案如下:

1)修改php.ini文件,将cgi.fix_pathinfo的值设置为0,完成后重启PHP-FPM。此操作可能会响应到正常功能。

2)在Nginx配置文件中添加以下代码:

  if ( $fastcgi_script_name ~ \..*\/.*php ) {

           return 403;

  }

 

0x03 空字节


漏洞描述:

在使用PHP-FastCGI执行php的时候,URL里面在遇到%00空字节时与FastCGI处理不一致,导致可在非php文件中嵌入php代码,通过访问url+%00.php来执行其中的php代码。如:http://local/robots.txt%00.php会把robots.txt文件当作php来执行。

影响版本:

nginx 0.5.*

nginx 0.6.*

nginx 0.7 <= 0.7.65

nginx 0.8 <= 0.8.37

漏洞利用:

1.上传经过处理的包含php一句话木马的图片文件.

2.访问http://target.com/pathtopic/nginx.jpg%00.php获得shell

修复方案:

升级Nginx

 

0x04 CVE-2013-4547


影响版本
nginx 0.8.41 – 1.5.6

测试版本
nginx 1.2.9

漏洞测试
1)访问到不可访问文件
nginx中添加配置

location /vinc/ {
    deny all;
}
[root@vincent nginx]# curl 172.16.100.161/vinc/1.txt -I
HTTP/1.1 403 Forbidden

创建一个包含空格的目录test

[root@vincent html]# ls -F
50x.html index.html test / vinc/

然后通过curl访问就可以

[root@vincent vinc]# curl "172.16.100.161/test /../vinc/1.txt" 
hello

2)将非PHP文件解析为PHP

Linux环境+PHP5.5.38


这里先说明下php从5.3.3版本开始引入php-fpm。
从5.3.9开始,php官方加入了一个配置”security.limit_extensions”,默认状态下只允许执行扩展名为”.php”的文件。如果发送给Fastcgi的文件非.PHP,则会报错Access denied.
所以测试前提是配置
security.limit_extensions =
然后重启php-fpm。
创建文件1.txt (需要注意末尾有空格)我们修改1.txt ,内容为PHP代码:

<?php
    phpinfo();
?>

我们构造一个伪造请求,请求的地址为”/1.txt \0.php”,注意其中的空格没有编码。然后可以看到phpinfo解析了。

所以利用前提
1)构造文件名末尾带空格的文件,所以在实际环境中基本是不可能的。
2)php-fpm配置了security.limit_extensions =

Windows环境+PHP5.6.32


这个漏洞在Windows环境下的利用价值就大大增强了
1)测试发现Windows下php-fpm默认就可以解析其他类型文件,不是默认只解析PHP文件。
2)Windows会自动忽略对应文件名后的空格,所以文件名末尾带空格的文件不再需要。
也就是说在Windows环境下,用户上传包含Webshell的头像文件,就可以直接Getshell了。

创建文件1.txt(末尾不带空格),我们修改1.txt ,内容为PHP代码:

<?php
    phpinfo();
?>

我们构造一个伪造请求,请求的地址为”/1.txt \0.php”,结果如下:

 

 

0x01 概述


apache解析php可以通过加载module或者cgi的方式,我们通常说的apache解析漏洞是因为apache的配置错误导致的。

 

0x02 解析漏洞(一)


CentOS6下通过yum安装apache。

测试版本:2.2.15

yum安装php后,会生成配置文件/etc/httpd/conf.d/php.conf

内容如下:

[root@kafka111 html]# grep -v '^$' /etc/httpd/conf.d/php.conf | grep -v '^#'

<IfModule prefork.c>

  LoadModule php5_module modules/libphp5.so

</IfModule>

<IfModule worker.c>

  LoadModule php5_module modules/libphp5-zts.so

</IfModule>

AddHandler php5-script .php

AddType text/html .php

DirectoryIndex index.php

可以看到加载了php模块,另外

AddHandler php5-script .php

所有包含.php的文件都会被当做php来解析,如果没有该配置的话,PHP的源码就会被打印出来。

另外需要注意这里并非是以.php结尾的文件,为什么这么说呢。

[root@kafka111 html]# mv info.php info.php.jpg

访问发现还是可以解析php的。这个问题在2.4版本修复了。

这里我找一台CentOS7的机器,安装apache

测试版本:2.4.6

yum安装php后,会生成配置文件/etc/httpd/conf.d/php.conf

内容如下:

[root@localhost html]# grep -v '^$' /etc/httpd/conf.d/php.conf | grep -v '^#'

<FilesMatch \.php$>

    SetHandler application/x-httpd-php

</FilesMatch>

AddType text/html .php

DirectoryIndex index.php

php_value session.save_handler "files"

php_value session.save_path    "/var/lib/php/session"

可以看到这里原来

AddHandler php5-script .php

替换为

<FilesMatch \.php$>

    SetHandler application/x-httpd-php

</FilesMatch>

做了正则匹配,只有以.php结尾时才会当做php解析,从而避免了这个问题。

 

0x03 解析漏洞(二)


还是以apache版本2.2.15为例,为了避免上面提到的配置影响到PHP的解析,我们修改一下PHP解析的配置

注释掉/etc/httpd/conf.d/php.conf

#AddHandler php5-script .php

#AddType text/html .ph

然后添加一条PHP解析的配置

AddType application/x-httpd-php .php

apache安装后会有一个/etc/mime.types文件,文件内容如下:

# MIME type                                   Extensions

application/3gpp-ims+xml

application/activemessage

application/andrew-inset                    ez

application/applefile

application/atom+xml                         atom

该漏洞就是如果扩展名没有在mime.types出现,那么扩展名会左移查找下一个。我们修改一下扩展名

[root@kafka111 html]# mv info.php.jpg info.php.xxoo

首先xxoo肯定不是一个正常的扩展名,不在mime.types中,那么apache就会左移并将该文件以php解析。如下图所示