技术解析

网站被传了后门,php 代码写在一个 gif 后缀的文件里面, nginx 怎么写 deny 规则
0
2021-05-25 17:33:20
idczone
程序是个 DEDE, 我只是禁止了一些比较敏感的目录.

想对文件国外服务器类型对做一下限制,求个规则
location ~ /attachments/.*\.(php|php5)?$ {
deny all;
}
http://drops.wooyun.org/tips/1323

这个是目录限制,我有的. 但是如果这目录里面有一个 gif 文件被植入了 php 代码,怎么禁止呢?

应该不能被执行吧?
你只对以.php 进行解析就好了。

是对.php 解析的. 但是还是被执行了


0x05 需要解决的常见问题
0x06 Nginx 安全配置方案

应该是之前 pathinfo 的漏洞吧, 禁用 pathinfo 吧

装个安全狗扫下不是更简单嘛?

这应该是禁用的吧?

location ~ [^/]\.php(/|$)
{
comment try_files $uri =404; to enable pathinfo
try_files $uri =404;
fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_index index.php;
include fastcgi.conf;
pathinfo.conf;
}

http://www.laruence.com/2010/05/20/1495.html

fix_pathinfo=0 是关闭的

上传个样本和被执行的请求吧。



ico-mood-16.gif 修改为 PHP 以后是这样的:


有没有人能解释一下,为什么.gif 文件会被 php 执行呀?

include/require 某个文件,如果文件有就当成 PHP 来执行了


这行代码是哪个文件里的:

.gif 文件本身没有被执行,而是引入该 gif 的文件被 php 执行。
你禁止 templets 目录不会有任何作用。
建议按这样两个原则:
1 有 php 执行权限的目录,不允许 web 账号( php-fcgi 进程)的写入权限
2 有 web 账户有写入权限的目录(如模板目录,附件上传目录),不允许 php 执行权限。

你只是看到里面有 PHP 代码,还是直接访问这个 gif 会被当成 php 执行
17 楼的 require_once 是哪个文件里面的


这里只是用了读取权限

http://www.tntsec.com/439.html
从入侵谈防御之“黑不掉”的网站,论网站攻防,公测版

include/require 肯定就被执行了啊。。。跟目录和什么文件类型没关系。。。

如果 ico-mood-16.gif 是本来就会有的文件,那么限制修改权限,不归所有。如果 ico-mood-16.gif 本来就是不能有的。那么查出他为什么会被上传。如果其所在目录是不需更改的,限定它。

能去 include/require 的,肯定具有 php 执行权限了,他把本来没有权限的文件读到其附属内存里,继续读,不就可以执行了。。所以问题不是出在,你那没有权限的文件。而是你为何当前 php 文件要去包含该文件,如果确信这是必须包含的(我反正没听说会在 php 里 include/require 一个图片文件),那么就要处理图片所在目录的实际权限了。

比较怪,从没见过图片要这样

我倒是觉得一开始就被留后门,哈哈。毕竟有权限修改 php ,还去上传什么图片。。

include/require 里只要有 都会被执行的

上传的目录别给执行权限呗

location ~ \.php {
fastcgi_index index.php;
/> if ($request_filename ~* (.*)\.php) {
set $phpFile $1;
}
if (!-e $phpFile.php) {
return 403;
}
fastcgi_pass 127.0.0.1:9000;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
}
我们项目的坑里是这么解决这个漏洞的。
在 php 的执行检查里面加上类型检查。
/> if ($request_filename ~* (.*)\.php) {
set $phpFile $1;
}
if (!-e $phpFile.php) {
return 403;
}
这样可以保证非 php 文件不会被执行。

你这段代码是哪里的?
```

```
及时 gif 就是图片, php 为什么要去 require 一个图片文件?
如果是为了输出文件同时保护文件路径,那就改成读取内容然后输出。直接 reqire 简直开玩笑啊。

我的疑惑和大家是一样的....既然能上传一个 require 了 gif 的 php 文件,那何必再上传 gif 呢,直接利用上传的 PHP 不就可以了.....除非这个是预先就留下的后门

看来那个能 require xxx.gif 的是后门吧。然后通过正规渠道上传 gif 来入侵。

还是有人没有仔细看 lostsnow 给的链接啊。
那个链接把原理说得挺清楚了,在默认配置下,可以让 PHP 解释器执行后缀为图片类型或者其它任意类型的文件。
所以攻击原理就是把 PHP 攻击代码以图片文件的形式传到服务器上面再构造执行请求,就可以执行任意 PHP 代码。能执行代码的情况下,再生成什么文件都很正常。
所以只要有上传图片的接口可以用,很可能是通过图片执行漏洞去创建的 PHP 文件。

在图片那个目录禁止执行 php 即可

当年 所谓 lnmp 的安全漏洞么?

文件包含吧

纯图片的话,应该是图片木马。
可看到楼主说又 require ,这个就不是单纯的图片木马了。应该是从其他方面入侵的。 require 函数不一定加载 PHP 后缀文件的。楼上已经有人说了

上安全狗 nginx 版

常规入侵的时候由于代码限制只能上传图片的话,就可以用 php 代码以 gif 等 jpg 类型上传,稍微高级点可以使用 burpsuite 截断攻击,上传的时候是图片文件,截断后改为 jsp php 等等可执行脚本,这个是很老的一个技术了;所以你还是上一个网马防护软件吧

单纯的 deny 是治标不治本。找到程序的漏洞出在哪里,才能真正解决此问题。

查 log ,找出漏洞利用的地方,想办法修复。其他方法扯淡

谢谢大家

好典型的 LFI

加个 try_files ,访问不存在的直接返回 404 。类似这种 1.jpg/1.php 尝试, 1.jpg 就不会被解析了。
location ~ \.php$ {
try_files $uri = 404;
fastcgi_pass 127.0.0.1:9000;
...
}

通过 pathinfo 执行的,是 nginx 配置的问题。
比如一个包含 php 代码的 gif : http://target/test.gif
通过类似: http://target/test.gif/not_exists.php 来执行

常言道:喝酒不开车,开车不喝酒。哦串词了,是上传不运行,运行不上传
为何不用 example.com 而要用 target

这种是文件包含执行的木马隐藏方式,你禁用 gif 的执行没有用,因为调用 gif 的是 php 文件

这都是用包含了

exploit 类的文章喜欢写成 target

楼主试试
http://www.yoursite.com/yourpath/file.gif?file.php
http://www.yoursite.com/yourpath/file.gif/file.php
这两个哪个能执行
如果这两个都不能执行,那十有八九只是人家在测试攻击并失败而已。

表示关注

location ~ ^[^.]+\.php(/|$) {
...
fastcgi_split_path_info ^(.+?\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
...
}
使用 fastcgi_split_path_info 也可以解决上面的问题,保证 SCRIPT_FILENAME 是一个 PHP

1.gif 的内容是典型的一句话木马,利用 preg_replace 函数中第一个参数后面的 /e,来把替换后的字符串当代码执行,str_rot13('riny')就是 eval 了,密码就是 good,利用经典的中国菜刀就可以连接上了.
http://php.net/manual/zh/function.preg-replace.php
http://php.net/manual/zh/reference.pcre.pattern.modifiers.php
2.
这句肯定是黑客加上去的,require 和 include 文件,会执行 gif 里面的 php 代码
http://php.net/manual/zh/function.include.php
当一个文件被包含时,语法解析器在目标文件的开头脱离 PHP 模式并进入 HTML 模式,到文件结尾处恢复。由于此原因,目标文件中需要作为 PHP 代码执行的任何代码都必须被包括在有效的 PHP 起始和结束标记之中
3.这个 gif 是利用 dedecms 上传上去的,例如简单图片上传功能,把 php 文件改个扩展名成 gif,然后上传模块中只是简单的检查下扩展名,而不试着获取下图片宽高来判断是真的图片,导致上传成功
4.dedecms 代码不严谨,有任意包含文件漏洞
比如
$file = $_GET['file'];
include $file;
只需要填写 gif 被上传后的路径,即可导致 gif 文件内容被解析成 php 代码执行.
至于网站的路径有多种方法探测,例如报错信息
你现在设置规则我觉得已经来不及了,上周我就和同事配合搞了像这样的应急响应,phpcms 的任意文件包含漏洞,被上传了一大堆马,抓了好几天,在 nginx 的日志中记录 post 内容,去分析了 n 个 php 文件,才清完

楼楼把 nginx 日志丟上来吧。。

忘了说一个问题。上传文件被包含执行的话,直接把上传的 base 目录放到 open_basedir 之外,放到独立的 vhost 最好

感觉是利用解析上传漏洞,上传 webshell , 然后写入一句话小马 gif
透过 require 运行 , 用 gif 方便让后门隐藏,也许是让 webshell scaner 忽略,
或目录中多个 php 来的容易察觉.
deny 目录不治本,因为还是可跨目录上传文件

php 文件包含, 没有什么好的防御办法, 楼主上权限白名单吧 XD:

数据地带为您的网站提供全球顶级IDC资源
在线咨询
专属客服