公開された 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 の UI は読み込まれ、あらゆるインデックスがクエリ可能で、保存済みオブジェクトも列挙でき、しかもすべて認証情報ゼロでできてしまった。
• 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、複数チェーンにまたがるソフトペッグのタスク、そしてキルスイッチの 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 UI を世界に向けて開いたデータベースに等しい。
• ログストアは、そこに到達できる者なら誰でも読めるものとして扱うこと。認証情報がログ行に紛れ込みうるなら、必ず読まれると想定すること。
• 認証オブジェクトやリクエストオブジェクトを丸ごとログに出さないこと。識別子だけを記録し、秘密そのものは決して記録しないこと。鍵照合の経路は、まさにこれが破綻しやすい場所だ。
• インデックス名やサービス名はシステムを言い表すことを忘れないこと。それらが置かれる場所はプライベートに保つこと。
• 古い環境を棚卸しすること。ここでの名前には uat-v1、uat-v2、staging、shadow といったタグが付いており、長年積み重なってきたテスト環境の層をなしていた。忘れ去られた一つこそ、たいてい最後に公開されてしまうものだ。

謝辞

迅速かつプロフェッショナルな対応と、本報告に何を書けて何を書けないかについて協力してくれた native.org チームに感謝する。