开放的 Kibana 暴露了 native.org 的交易技术栈

协调披露，本着善意报告，不涉及任何赏金或报酬。native.org 已修复该问题并批准本文发布。受影响的主机地址已隐去。

摘要

• 207暴露的索引模式
• 21恢复的有效 API 密钥
• 8,700+每 15 分钟日志条目

一个 native.org 的 Kibana 实例，对该公司横跨 staging 与 UAT 环境的交易基础设施进行了索引，共计 207 个索引模式，而其背后的 API 网关正在以明文记录有效的 API 密钥。

native.org 是一个 DeFi 流动性平台。其链上 RFQ（询价）系统从私有做市商处获取报价，并跨链提供给交易者，由此产生的交易流在中心化交易所进行对冲。被暴露的实例属于一个 UAT 环境。native.org 确认泄露的密钥均未在生产环境中使用，已为该实例添加了身份验证，并轮换了密钥。

暴露在外的 Kibana 实例很常见。这里有两点更值得关注：一个开放的可观测性技术栈会泄露什么，以及导致密钥泄露的那个错误有多么平常。

要点

• 该实例无需任何身份验证。无需任何凭据，Kibana 界面即可加载，每个索引都可查询，保存的对象也可枚举。
• 这 207 个索引名称就是整个业务的地图：定价、对冲、风险、清算、结算、链上监控、中心化交易所集成、跨链锚定，以及紧急停止控制。无需打开任何一份文档，你就能读懂其架构。
• 该 API 网关将原始 API 密钥记录到其输出中，并随之流入 Elasticsearch。我们从实时日志流中恢复了 21 个密钥。当时，某个索引每 15 分钟接收超过 8,700 条日志条目，因此该系统显然处于运行状态。

一个开放的仪表盘会泄露什么

索引名称本应是运营层面的管道，而不是威胁面。一份完整且具名的服务清单，会准确地告诉攻击者一个系统是如何构建的。就 native.org 而言，这些名称从头到尾描述了整个交易技术栈：quote-order-task 和 order-manager 负责订单流，pricer 和 quote-ticker 负责定价，risk-manager 和 liquidation-price-task 负责风险，trade-hedger-task 和 hedge-signer 负责对冲，cex-monitor 和 cex-position-monitor 负责中心化交易所集成，settlement 负责清算，跨多条链的软锚定（soft-peg）任务，以及负责紧急开关的 emergency-stop-task 和 emergency-paused-task。

这一切都不需要任何文档或凭据。仅这份索引名称清单本身，就是一次设计评审。对于任何策划攻击的人来说，这等于大部分功课都已经替他们做完了。

泄露的内容不止于架构。同样这些名称还道出了策略：用于套利、配对交易、市场冲击估计和跨链锚定的索引，会告诉竞争对手这家公司如何赚钱，而这往往是更有价值的那一半。这个集群里也不只有交易数据。它还存放着公司自己的安全遥测数据：主机、网络和端点审计日志，以及用于发现入侵者的告警。任何读到这些的人，都能看出防御方能发现什么、又发现不了什么。

甚至连更细小的运营细节也会透过命名渗出来：托管区域、云服务商、正在用新语言重写过半的组件，以及在用的内部协议。其中任何一项单看都只是琐碎信息。但合在一起，就把攻击者本来需要自己完成的侦察工作拱手相送。

这些名称本身没有问题。它们正是任何团队都会采用的那种清晰、合理的命名。真正出错的是：承载它们的那个仪表盘对任何人都是开放的。

日志里的密钥

更直接的问题出在 API 网关的日志里。该网关的密钥查询函数在每次成功查询时都会记录完整的密钥对象，而这些日志行和其他所有内容一样进入了 Elasticsearch。打开网关索引并按该函数过滤，就会返回一连串如下的条目：

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

我们以这种方式恢复了 21 个不同的密钥。这是最常见的日志记录错误之一：调试时把整个请求或认证对象记录下来，然后忘了它会被发往一个别人也能读取的存储中。于是，凭据和你存放日志的地方，变成了同一样东西。

客观评估影响

这是一个 UAT 环境，native.org 也确认这些密钥并未用于生产环境。这一点很重要，我们也不会把它粉饰成一次发生在实盘交易台上的「险些酿祸」。它并不是那种情况。

但它依然严重。一个面向互联网、无需身份验证、正在运行的实例，正以明文记录真实凭据，并暴露了一个资金处理平台的完整设计。这些密钥虽然是 UAT 密钥，但该索引每隔几分钟就接收数千条日志行，说明流量是真实的；而它所暴露的架构，与生产系统运行的是同一套。「这只是 UAT」和「它就暴露在公网上、还在记录有效密钥」之间的这道鸿沟，才是问题的全部。

概念验证

该实例在其 HTTP 端口上响应未经身份验证的请求。确认这一点只需三步，所用工具不过是 curl 或浏览器：

• GET /api/status 无需任何凭据即可返回 Kibana 版本和节点名称。
• GET /api/saved_objects/_find?type=index-pattern&per_page=500 返回了全部 207 个索引模式。
• 在 Discover 中打开网关索引，并按密钥查询函数过滤，就显示出了被记录的密钥。

该主机 443 端口上的一张 TLS 证书（CN=*.native.org，由 Cloudflare Origin CA 签发）确认了该实例属于 native.org。

披露时间线

• 2026年6月2日我们在威胁情报研究中发现了这个暴露的实例，并向 native.org 报告，附上了受影响的端点、索引清单、被记录密钥的脱敏样本，以及修复建议。
• 2026年6月18日native.org 确认了此次暴露。他们为该实例添加了身份验证，轮换了受影响的密钥，确认该实例和密钥均属于 UAT 环境、不涉及任何生产密钥，并提出了他们希望在发布时进行的脱敏处理。
• 2026年6月19日在 native.org 的参与下发布，并按其要求进行了脱敏处理。

native.org 响应迅速，修复了问题，并与我们一同完善了这篇文章。我们之所以提出此事，是因为这次暴露确实严重、他们需要知情，而不是为了任何回报。协调披露本就应该如此。

给运行同类技术栈的团队

• 把 Kibana 和 Elasticsearch 置于身份验证之后。启用 xpack.security.enabled，并让 HTTP 端口远离公网。一个没有身份验证的 ELK 技术栈，就是一个把 Web 界面向全世界敞开的数据库。
• 把你的日志存储当作：凡是能访问到它的人都能读取。如果某个凭据可能出现在某行日志里，就假定它一定会被读到。
• 不要记录完整的认证对象或请求对象。只记录标识符，绝不记录机密本身。密钥查询这条路径，正是最容易在此出错的地方。
• 记住：你的索引名和服务名描述了你的系统。让承载它们的地方保持私有。
• 盘点你那些旧环境。这里的名称带有诸如 uat-v1、uat-v2、staging 和 shadow 之类的标记，是长年累积下来的一层层测试环境。被遗忘的那一个，往往就是最终暴露在公网上的那一个。

致谢

感谢 native.org 团队快速、专业的响应，也感谢他们与我们一同商定了哪些内容可以、哪些不可以写入本报告。