..

kibana console api LFI (CVE-2018-17246)

背景

该漏洞由 CyberArk Labs 实验室 Nethanel Coppenhagen 发现 （https://www.cyberark.com/threat-research-blog/execute-this-i-know-you-have-it/），原文介绍该漏洞可能会导致远程代码执行，这是相当严重的问题，因为我们知道可以执行代码往往意味着也可以执行操作系统命令，既远程命令执行，不过深入了解后发现如果要达到远程命令执行其实十分困难，对目标环境有较为苛刻的要求。【且听我娓娓道来】

影响范围

kibana version < 6.4.3 kibana version < 5.6.13

可能是因为kibana大版本升级会有兼容性问题，企业内kibana几乎都是集群搭的，所以kibana 很贴心对于 5.x 版本也提供了修复补丁，很赞

漏洞成因

对于漏洞成因网上已经有分析或者翻译文章，这里只简单说一下

如下图， require 函数接收一个变量 name ，和 ./ 进行拼接，并且没有任何检查，require() 函数支持使用 ../ 的方式完成跳目录 （ http://nodejs.cn/api/modules.html#modules_require ）所以LFI利用便呼之欲出。

然后如下图，在api类里 line:60 ~ 66 是 asJson 函数

然后如下图，line: 22 AND 42，实例导出api类，提供了可控的漏洞触发点

漏洞复现

搭环境，docker 一把梭

docker pull sebp/elk:642

存在漏洞的url，参数是 apis ，用 ../ 实现跳目录读取，因为读到 /etc/passwd ，nodejs 会抛出异常（因为不是正常的js文件嘛）不过还是证明是存在漏洞的，但是无法将读到的文件回显出来

如果有办法向kibana 服务器上传一个 js 文件，使 nodejs 读取执行，就可以rce了，但是很遗憾，nodejs 并不像 php 那样灵活，nodejs 对于 require() 的文件内容有格式要求，所以像php那些类似 lfi 姿势都无法使用。

http://127.0.0.1:32770/api/console/api_server?sense_version=%40%40SENSE_VERSION&apis=es_6_0

扫描检测

服务指纹，指纹方面大版本之间会有很大差异，下面两种方法比较通用。

response Header

request Header

验证方法：

  1. 方法一，对比request Header中的版本
  2. 方法二，先请求 【http://127.0.0.1:32770/api/console/api_server?sense_version=%40%40SENSE_VERSION&apis=es_6_0】是否会返回json，如果会则发出 payload ，返回包可能会超时也可能会返回http500，基本可以确定存在漏洞，如果返回包是空json，大概率是不存在漏洞的。

修复建议

  1. ACL，设置访问来源白名单
  2. 升级到新版本
  3. 禁用Kibana Console插件， kibana.yml > console.enabled：false
  4. 登录鉴权，https://www.elastic.co/guide/en/x-pack/6.0/xpack-security.html