遭受webshell

凌晨三点，遭受服务器监控面板上突然跳出一条告警——某个本不该有写入权限的遭受目录里，多了一个名为“cache.php”的遭受文件。点开一看，遭受十七行混淆过的遭受代码，头部还贴心地加了注释：/* nothing here */。遭受这就是遭受webshell，一个藏在正常业务文件堆里的遭受后门，体积往往不超过2KB，遭受却能让你整台服务器的遭受控制权像递烟一样递到别人手里。

我见过最离谱的遭受一次，攻击者把shell写进了网站logo的遭受EXIF注释里。图片能正常显示，遭受浏览器能正常渲染，遭受连文件大小都没变多少。遭受要不是那天运维顺手跑了条grep -r "eval"，这玩意儿能在生产环境里躺到服务器报废。webshell的狡猾之处就在这儿：它不跟你正面刚，不弹窗、不占CPU、不写系统日志。它就安安静静地等，等一个POST请求带着密码过来，然后替你执行任意代码。

常见的手法分两种。一种是大马，功能齐全，文件管理、数据库查询、命令执行一应俱全，体积几十KB，特征明显但架不住有人把它改得面目全非。另一种是小马，一行代码，，丢进任何可写目录就能用。小马通常只用来上传大马，用完即删，跟间谍接头似的。去年某电商平台被拖库，溯源发现入口就是一个伪装成404.php的小马，上传时间戳显示它在服务器上活了整整47天，期间没有任何异常流量——因为攻击者只在凌晨两点到四点之间操作，每次不超过三分钟。

怎么进来的？八成的webshell跟文件上传漏洞有关。你那个“仅允许jpg/png”的前端校验，改个Content-Type就绕过去了。后端要是只检查扩展名，那就更简单，shell.php.jpg走起。还有更省事的：直接找编辑器漏洞。FCKeditor、UEditor这些老牌富文本编辑器，历史上爆过的任意文件上传漏洞能列一长串。很多网站图省事，编辑器版本几年不升，等于给攻击者留了扇没锁的后门。

检测这事儿，说难也难，说简单也简单。难在webshell可以变形——base64、gzinflate、字符串拼接、回调函数，随便哪种都能让特征匹配失效。简单在，大部分入侵者其实很懒。他们用的还是那几套现成的马，改个变量名就扔上来了。我习惯用find配合grep先扫一遍最近修改过的php文件，再拿stat看创建时间。如果某个文件的时间戳跟其他业务文件差了几个月，里面又出现了system、passthru、popen这些函数，基本可以断定有问题。

另一个容易被忽略的点是权限。很多运维图方便，给web目录设了777，或者让php进程以root身份跑。一旦webshell落地，攻击者连提权都省了，直接cat /etc/shadow。我自己的习惯是：web目录属主跟php-fpm运行用户分开，上传目录禁止执行php，disable_functions里把exec、shell_exec、proc_open全禁掉。这些措施挡不住0day，但能挡住99%的脚本小子。

最后说个真事。某次应急响应，客户坚持说服务器没被入侵，因为“杀毒软件没报毒”。我登上去翻了翻/tmp，发现一个叫.ICE-unix的目录，里面藏着三个webshell，修改时间都是半年前。杀毒软件确实没报——因为那些马是PHP写的，而服务器上根本没装PHP。攻击者传上来之后才发现环境不对，索性丢在那儿没管。你看，有时候不是攻击有多高明，纯粹是防守方自己都没搞清楚服务器上跑了什么。

webshell这东西，说到底就是个工具。它不神秘，也不高级，就是一把插在门缝里的螺丝刀。你要做的不是天天盯着门缝看，而是先把门锁换了。

本文地址：http://www.79wt.cn/news/1501d1099839.html