Kibana脱库过程全解析：一次真实环境下的漏洞复现与反思
大家好呀，今天想跟你们聊聊一个挺敏感但又不得不重视的话题——Kibana脱库过程，说实话，写这篇文章的时候我内心挺复杂的，因为这事儿吧，往好了说是安全研究，往坏了说那就是在危险的边缘疯狂试探，但作为一个搞安全的老司机，我觉得还是有必要把这事儿掰开揉碎了讲清楚,让更多运维和开发同学知道自己的ES集群到底有多脆弱。
先喝口水,咱们慢慢聊。
啥是Kibana？为啥它能"脱库"？
Kibana这玩意儿，搞过ELK（Elasticsearch + Logstash + Kibana）的同学肯定不陌生，它就是个可视化面板，让你能通过浏览器查ES里的数据，做图表、看日志啥的，用起来是真的爽，但问题来了——爽的同时，它也是一扇门。
你想想，Kibana默认连的是Elasticsearch，而ES里存的是啥？日志、业务数据、用户信息……公司里几乎所有的"家底"都可能在里面，如果Kibana没有做好权限控制，或者版本存在漏洞，那攻击者就能通过它直接"搬空"整个数据库，这就是所谓的Kibana脱库过程。
Kibana脱库过程：一步一步拆给你看
我拿一个真实的测试环境（当然是我自己的靶场哈，别乱想）来演示，整个Kibana脱库过程大概分这么几步：
第一步：信息收集，找入口
先扫端口呗，Kibana默认跑在5601端口，一个nmap下去，看到5601/tcp open，眼睛就亮了，然后浏览器访问 http://target:5601，如果直接进去了，没有登录框——恭喜你,门没锁。
第二步：确认版本，找漏洞
在Kibana页面按F12，看响应头或者访问 /api/status，版本号一目了然，比如6.5.x、7.10.x这些老版本，存在不少已知问题，CVE-2019-7609那个原型链污染RCE，还有未授权访问,都是经典。
第三步：利用接口，读取数据
Kibana自己有一堆API，/_cat/indices、/api/console/proxy 这些，如果没鉴权,直接构造请求：
GET /api/console/proxy?path=/_cat/indices&method=GET哎呀，索引列表全出来了，接着遍历索引、_search查询，数据就哗啦啦往外流，要是ES本身也没开X-Pack安全,那基本等于裸奔。
第四步：批量导出，完成脱库
写个Python脚本，循环调_search接口，分页拉数据，写入本地文件，整个Kibana脱库过程快的话几分钟就能搞定,几百万条数据说没就没。
为什么这事儿这么容易发生？
说实话,我见过太多公司这么干了：
- Kibana直接暴露公网，防火墙都不带加的
- ES和Kibana之间没有TLS，没有认证
- 觉得"内网就安全"，结果内网横向一打一个准
唉，每次看到这种配置,我都替他们捏把汗。
怎么防？
- 升级版本，别用老版本了,官方补丁该打就打。
- 开启认证，X-Pack也好，Nginx反代加Basic Auth也好,总得有一层。
- 网络隔离，Kibana别暴露公网,内网也做ACL。
- 审计日志，谁查了啥,得留痕。
最后说两句
写这篇Kibana脱库过程的文章，真不是为了教人干坏事，我是希望每个看到的人都能回去检查一下自己的Kibana，看看有没有"裸奔"，安全这事儿，不怕你懂,就怕你不当回事。
好了，今天就唠到这儿，有啥问题欢迎留言，咱们一起交流，记住啊，Kibana脱库过程听起来很酷，但防守才是真本事,拜拜~