Rishi Security Research
Posts Article Labs
投稿に戻る
研究アーカイブ
Jan 26, 2026

mDNS 経由での OpenClaw ゲートウェイの検出

JavaScript プロトコル Nuclei テンプレートを使って mDNS サービスアドバタイズメントを監視し、OpenClaw・Clawdbot・Moltbot ゲートウェイの露出を検出する。

openclawnucleiexposuremdnsudpdetectionai-security

OpenClaw の時代が来た。この自律型 AI エージェント——最初に出会ったタイミングによっては Clawdbot や Moltbot という名前で知っているかもしれない——は、ここ数週間で GitHub のチャートを駆け上がり、至るところでインスタンスが立ち上げられている。先週以降、セキュリティ上の初の試練も訪れた。1 クリック RCE である CVE-2026-25253 が公開され、パッチはそのわずか数日後にリリースされた。これらのインスタンスを運用している、あるいは誰かが運用しているかもしれないネットワークを管理しているなら、今こそそれがどこにあるかを把握するときだ。

簡単な背景

OpenClaw は LLM（Claude、GPT-4、Google のモデル）をマシンと実際のブラウザに接続し、エージェントがユーザーに代わって仕事をこなせるようにする——Telegram/Slack でのチャット、ウェブタスクの実行、コマンドの実行など。このテンプレートが対象とするコンポーネントはゲートウェイサービスで、ポート 5353/UDP のマルチキャスト DNS（mDNS）を通じてローカル探索のために自身を告知する。

マッチャーがこれに依存しているため、命名について一言述べておく。プロジェクトは現在 OpenClaw だが、Clawdbot として、さらに以前は Moltbot としてリリースされた——同じコードベースであり、mDNS サービス名には依然として旧ブランド名（_clawdbot-gw、_openclaw-gw）が残っている。テンプレートは両方にマッチするため、名称変更によって検出が盲点になることはない。

テンプレート

id: openclaw-exposure
info:
  name: Openclaw (formerly Clawdbot / Moltbot) - Detect
  author: rxerium
  severity: info
  description: |
    Clawdbot Gateway service was detected exposing configuration information via mDNS including DNS settings, gateway details, and service configuration.
  classification:
    cwe-id: CWE-200
  metadata:
    verified: true
    max-request: 1
    shodan-query: product:openclaw
    fofa-query: body="ClawdBot"
  tags: network,openclaw,gateway,exposure,udp,mdns,js,discovery
javascript:
  - pre-condition: |
      isUDPPortOpen(Host,Port);
    code: |
      let c = require("nuclei/net");
      let conn = c.Open('udp', `${Host}:${Port}`);
      // mDNS query for _clawdbot-gw._tcp.local PTR record
      let packet = "000000000001000000000000095f7365727669636573075f646e732d7364045f756470056c6f63616c00000c0001"
      conn.SendHex(packet);
      let resp = conn.RecvString(2048);
      resp;
    args:
      Host: "{{Host}}"
      Port: 5353
    matchers:
      - type: dsl
        dsl:
          - "contains(response, '_openclaw-gw') && success == true"
          - "contains(response, 'clawdbot') && success == true"
        condition: or
    extractors:
      - type: regex
        part: response
        name: server
        group: 1
        regex:
          - 'displayName=([a-zA-Z0-9._-]+)'

動作の仕組み

これは HTTP ではなく JavaScript プロトコルテンプレートだ。 ほとんどの露出テンプレートは GET を送信してレスポンスボディをマッチングする。このテンプレートは Nuclei の nuclei/net ライブラリを使ってローソケットを開き、バイナリプロトコルを直接話す——mDNS は HTTP マッチャーで表現できないため、これが必要になる。

前提条件がすべてを制御する。 isUDPPortOpen(Host, Port) は、パケットを送出する前に 5353/UDP が実際にリッスンしているかを確認する。閉じていればテンプレートは短絡し、リクエストを消費しない——ほとんどのホストがゲートウェイを実行していない大規模な範囲に向ける場合にスキャンコストを抑えられる。

コードは生の mDNS クエリを送信してリプライを読む。 Host:5353 への UDP 接続を開き、SendHex で 16 進数エンコードされた DNS パケットを送り、最大 2048 バイトを読み返す。デコードされたペイロードは DNS-SD のサービス列挙クエリ——_services._dns-sd._udp.local への PTR 質問、つまり「あなたが告知しているすべてをリストアップしろ」という標準メタクエリだ。ゲートウェイを実行しているホストは告知しているサービスで応答し、OpenClaw/Clawdbot のサービス名がそのレスポンスに含まれてくる。

マッチャーがゲートウェイであることを確認する。 2 つの DSL チェックが or で結合されている：contains(response, '_openclaw-gw') または contains(response, 'clawdbot')、それぞれ success == true を条件としているため、半開ソケットや空の読み取りが偽陽性を生むことはない。mDNS レスポンスにいずれかの文字列があれば、どちらのブランド名を持つものであれ、OpenClaw ゲートウェイを見ていることが確認される。

エクストラクタがデバイスの表示名を引き出す。 正規表現がアドバタイズメントから displayName=... を取り出し、出力に server として表示する。つまり、ヒットは単に「ゲートウェイが存在する」というだけでなく——オペレーターが付けた人間が読める名前も取得できる。これはインベントリとトリアージにとって非常に価値がある。

深刻度は info、CWE-200 だ。 これが正直な分類である。テンプレートが検出するのは情報の露出（CWE-200、Information Exposure）——ゲートウェイが本来すべきでない場所で設定を告知している——であり、能動的な悪用ではない。到達可能なインターフェースへの mDNS リークが検出結果であり、攻撃者が次に何をするかは別の問題だ。

verified: true は、テンプレートが仕様に従って書かれただけでなく、実際のインスタンスに対して確認済みであることを意味する——したがってマッチは信頼できる。

mDNS 検出を持つことが重要な理由

HTTP フィンガープリンティングはこれらを見つける明白な方法であり、機能する。だが mDNS は異なるスライスを捉える。HTTP 側がファイアウォールで保護されていたり、プロキシの背後にあったり、HTTP スキャンがカバーしていない非標準ポートにあったりしても、攻撃者が到達できるネットワークセグメントにサービス探索をリークしているゲートウェイが存在し得る。これは特に内部評価やフラットネットワークに関連性が高い。マルチキャストは本来越えるべきでないセグメントを楽しそうに越え、ゲートウェイはネットワーク上のすべてに「私はここにいる、そしてこれが私の名前だ」と実質的に告知している。これを HTTP フィンガープリントと並行して実行すれば、どちらか単独では得られないカバレッジが手に入る。

大規模での実行

まず自分自身のネットワークと境界から——認可が最も明確であり、mDNS の発見結果は自分が管理するネットワーク内で最も対応しやすい。

nuclei -t openclaw-exposure.yaml -l targets.txt -o openclaw-hits.txt

テンプレートはすでに args でポート 5353 を固定しており、isUDPPortOpen の前提条件によって、パケットが送出される前に閉じたポートがスキップされるため、広いホストリストを投げ込んでも何も叩かない。

大きな範囲には UDP スキャンで事前フィルタリングする。 UDP スキャンは TCP より遅いため、大きなスコープでは先にアクティブな 5353 リスナーを見つけ、それだけを Nuclei に渡すのが効率的だ：

# naabu doesn't do UDP; use nmap for the 5353/udp sweep
nmap -sU -p 5353 --open -iL ranges.txt -oG - | awk '/Up$/{print $2}' > mdns-hosts.txt
nuclei -t openclaw-exposure.yaml -l mdns-hosts.txt -o openclaw-hits.txt

インターネット規模では、スキャンデータを活用する。 インターネット全体に UDP を積極的に送りつけないこと——ノイズが多く、遅く、法的リスクも伴う。テンプレートに組み込まれた metadata クエリ（Shodan の product:openclaw、FOFA の body="ClawdBot"）を使って露出インスタンスを列挙し、テンプレートは認可されたスコープの候補だけに対して実行する。

継続的に実行すること、一度きりにしないこと。OpenClaw のインストールベースは今まさに日々増加しており、常に新しいゲートウェイが出現している——一回限りのスキャンはすぐに陳腐化する。そして、すべてのヒットに 2 つのアクションを組み合わせること：ゲートウェイを到達可能なインターフェースから外し、そのゲートウェイが保持するクレデンシャルをローテーションすること。

なぜこれが重要か

mDNS リークがテンプレートが生み出す検出結果だが、今まさに気にすべき理由は、露出したゲートウェイの背後に何があるかだ。

タイミングがすべてを物語る。CVE-2026-25253 は 1 月 26 日に開示され、先週末にリリースされた OpenClaw 2026.1.29 でパッチが当たった。1 クリックのリモートコード実行だ：Control UI が URL クエリ文字列から gatewayUrl を受け取り、確認なしに自動的にそこへの WebSocket を開き、その URL を管理する者にインスタンスの認証トークンを漏洩させる。トークンを盗み、WebSocket をハイジャックし、コマンドを実行する。事前認証は不要で、CVSS 8.8（CWE-669、Incorrect Resource Transfer Between Spheres）と評価されており——そして厄介なことに——攻撃が被害者自身のブラウザを通じてピボットするため、localhost のみで動作しているインスタンスに対しても有効だ。研究者たちはこれを「1 クリック RCE キルチェーン」と呼んでいる。概念実証コードはすでに公開されており、私がこれを書いている今まさに広範なメディア報道が届き始めている。

これが急性の問題だが、継続的な問題は一般的な露出だ。OpenClaw は自身が扱うクラウドモデル——Claude、OpenAI、Google AI——のクレデンシャルを保存し、さらに組み込んだメッセージングやツール統合のトークンも保持している。露出したゲートウェイはパスワードなしで開いた SSH だが、そのパスワードが山積みの有料 AI クレデンシャルとホスト上のフットホールドだ。そしてエージェントはアクセスを持つアイデンティティであるため、乗っ取った者はそのトークンと OAuth グラントを引き継ぎ、何の疑問も持たずに実行する指示を与えることができる。クレデンシャルが即座の報酬であり、特権エージェント内の永続的なフットホールドが長期的なものだ。mDNS 上で自身の displayName をブロードキャストしているゲートウェイは、単に自分自身を見つけやすくしているだけだ。それがこのテンプレートが対処するギャップだ。

緩和策

OpenClaw を運用しているなら、今週のやることリスト：

  1. 今すぐパッチを当てる。 2026.1.29 以降にアップデートする——CVE-2026-25253 を修正する。パッチを当てても以前の露出は取り消せないため、ステップ 1 として扱い、作業全体とみなさないこと。
  2. ゲートウェイトークンとすべての保存済みクレデンシャルをローテーションする。 新しい authToken、Claude/OpenAI/Google AI の新しい API キー、そして使用ログを確認する。到達可能だったなら、侵害されたと想定すること。
  3. 到達可能なインターフェースから外す。 ループバックにバインドするか、VPN、踏み台ホスト、または ZTNA の背後に置き、セグメント境界で 5353/UDP をブロックして mDNS が本来越えるべきでないネットワークを越えるのを止める。ループバックは床であり天井ではない——RCE はブラウザを通じてピボットするため、localhost のみは免責にならない。
  4. 最小権限でエージェントを実行する。 「ゴッドモード」は不可。システム、ファイル、キーアクセスを制限し、常時 API および OAuth グラントを持つアカウントと同様に監視する。
  5. エクスプロイトパターンを監視する。 ブラウザから外部ドメインへの予期しない WebSocket 接続にフラグを立て、ゲートウェイ設定変更でアラートを出す。

検出自体は難解ではない——前提条件、生の mDNS クエリ、2 つの文字列マッチャー。価値はタイミングにある：HTTP 側がロックダウンされていても、ネットワーク上で自身を告知しているゲートウェイを捉える、ちょうど公開された 1 クリック RCE がそれらを見つけることを緊急にしているときに。早く実行し、頻繁に実行し、ヒットごとにキーをローテーションする。エージェントランタイムはキーを持つアイデンティティだ；露出しているものを素早く見つけることがゲームのすべてだ。