2020年1月6日，青藤云安全宣布即将推出WebShell强对抗检测平台，日前已开启定向邀测。据悉，目前已经邀请了众多安全圈大咖参与检测，未来将进一步放开权限进行公测。
在安全圈，针对产品发起邀测或者公测时常有之，为何此次邀测能够引起业界关注呢?究其原因，主要是因为WebShell检测已经是安全圈多年一大顽疾，很难解决，所有安全从业者都迫切希望能早日解决该问题。
正可谓是“安全圈苦WebShell久矣”。众所周知，WebShell具有潜在的简单性和易修改性，隐藏在正常的网页文件中，传统安全工具很难检测到它们。例如，杀毒类产品在检测WebShell方面基本处于无效状态。
问 WebShell 为何物？
WebShell脚本通常被上传到Web服务器中用于对机器进行远程管理，受感染的机器可以是面向互联网的主机，也可以是通过WebShell感染的企业内部机器。WebShell可以用目标Web服务器支持的任何语言编写，例如PHP、ASP最为常用。恶意攻击者可通过扫描器等侦查工具识别那些可被利用的漏洞，从而安装WebShell。
攻击者可以利用常见的漏洞，如SQL注入、远程文件包含(RFI)、FTP，甚至使用跨站点脚本(XSS)作为攻击的一部分，以上传恶意脚本。一旦成功上传，攻击者就可以使用WebShell并配合其它技术进行提权或远程发出命令。这些命令可直接链接到Web服务器可用的特权和功能，包括添加、删除和执行文件等能力。
在没有较好的WebShell检测产品之前或者误报较高情况下，WebShell检测就需要专家资源和人工支持。专家凭借经验，如果在服务器上发现下述这些特征，表明极有可能被WebShell感染。当然这些特征也有可能是正常文件的特征，因此需要在具体场景下进行筛选，进一步检查或验证。
不正常的高使用率(包括潜在的上传和下载活动)。
包含不寻常时间戳的文件(例如，在最新安装Web应用文件后出现了新文件)。
可实现互联网访问的Web根目录中的可疑文件。
包含对可疑关键字(如cmd.exe或eval)引用的文件。
日志中的异常连接。例如从内部子网到DMZ服务器的可疑登录，反之亦然。
任何可疑命令的证据，例如Web服务器进程的目录遍历。
传统WebShell检测的六个常见方案
为解决WebShell检测问题，常用的WebShell检测方法包括人工识别、静态检测、动态检测、日志分析检测、基于语法检测和统计学检测等。
第一种也是最早的WebShell检测采用的是人工识别的方法。这是检测WebShell最古老、最传统的方法，对网站的管理员要求很高。管理员应全面掌握网站文件，对一些新增的异常文件如passby.php、pass.asp、a.jsp等命名的文件有较高的识别能力。这些小文件应该小心处理，极有可能是木马。在发现可疑文件后，需要分析文件的内容。最彻底的方法是仔细查看整个文件，但这将花费大量时间。更好的方法是搜索一些敏感的函数，比如exec()、shell_exec()、system()，并仔细检查它们的参数。
第二种检测方法，在人工识别之后，就出现了基于静态特征WebShell检测，也是当前研究的一个方向。这是手动识别的升级版，从某种程度上说它们几乎完全相同，都是基于特征。虽然检测速度较快，但是需要人工提取特征，而且仅仅通过特征匹配来检测，只能检测出已知特征的WebShell，不适用于检测未知的WebShell。由于WebShell特征复杂多变，所以经常需要使用机器学习来提高效率和准确性。
第三种检测方法，由于WebShell制作者会采用混淆和加密的方式绕过静态特征检测。但是当WebShell运行时，必须向系统发送系统命令，以达到操作数据库甚至系统的目的。动态特征检测正是使用WebShell使用的系统命令、网络流量和状态异常来确定动作的威胁级别。该方法通过检测系统调用来监视甚至拦截系统命令，并从行为模式深入检测脚本的安全性。例如在沙箱中执行可疑脚本文件，通过查看系统状态是否发生改变来判断该脚本是否恶意。但是因为需要执行和运行系统状态，必然导致资源的浪费。此外针对一些特殊的特洛伊木马，使用沙箱也基本无果。
第四种是日志分析检测，正常网页脚本文件通常相互都是存在连接关系的，但是恶意文件通常是处于“孤岛”状态，不与别的文件发生连接。使用WebShell一般不会在系统日志中留下记录，但是会在网站的Web日志中留下WebShell页面的访问数据和数据提交记录。日志分析检测技术通过大量的日志文件建立请求模型从而检测出异常文件，称之为HTTP异常请求模型检测。例如：一个平时是GET的请求突然有了POST请求并且返回代码为200。但是该方法无法解决内置在正常文件中的WebShell，而且黑客使用WebShell之后会清除对应日志记录。
第五种是统计学检测，也是目前使用较为广泛的一种方法。通过提取文件中特征代码，针对某些变形恶意脚本效果较好，但是误报和漏报非常高。目前，市场上有五种统计学方法可在脚本文件中搜索潜在的被混淆或被编码的恶意代码。
信息熵(Entropy)：通过使用ASCII码表来衡量文件的不确定性。
最长单词(LongestWord)：最长的字符串也许潜在的被编码或被混淆。
重合指数(Indexof Coincidence)：低重合指数预示文件代码潜在的被加密或被混淆过。
特征(Signature)：在文件中搜索已知的恶意代码字符串片段。
压缩(Compression)：对比文件的压缩比。
采用这种检测方法也存在明显的弱点，它的检测重心在于识别混淆代码，它常常在识别模糊代码或者混淆编排的木马方面表现良好。未经模糊处理的代码极可能无法被识别出来。
第六种是属性判断，主要是基于WebShell文件属性的判断，例如创建时间、修改时间、所属者等，这类方法并不针对文件本身进行检查，只能做为一个参考信息。
未来可期，青藤 WebShell 检测方案
上述六种方法都依赖于人工提取特征，自动化程度较低，而且非常容易被绕过。那么青藤究竟采用了什么样的技术能够解决安全圈多年顽疾呢?青藤定向邀测结果又如何呢?敬请大家关注下期文章《经过10位被邀测的骨灰级技术大咖验证：青藤WebShell检测创史上最强……》。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
