Zurück zu Beiträgen
Forschungsarchiv

OpenClaw-Gateways über mDNS erkennen

Erkennung der Exposition von OpenClaw-, Clawdbot- und Moltbot-Gateways durch Abhören von mDNS-Service-Ankündigungen mit einem JavaScript-Protokoll-Nuclei-Template.

openclawnucleiexposuremdnsudpdetectionai-security

OpenClaw hat seinen Moment. Der autonome KI-Agent — vielleicht kennen Sie ihn als Clawdbot oder Moltbot, je nachdem, wann Sie ihm zuerst begegnet sind — ist in den letzten Wochen in den GitHub-Charts rasant aufgestiegen, und überall werden Instanzen aufgesetzt. Seit letzter Woche erlebt er auch seinen ersten echten Sicherheitsmoment: CVE-2026-25253 wurde veröffentlicht, ein 1-Klick-RCE, mit einem Patch, der erst wenige Tage später eintraf. Wenn Sie diese Instanzen betreiben oder für ein Netzwerk verantwortlich sind, wo jemand das tun könnte, ist jetzt der richtige Zeitpunkt herauszufinden, wo sie sich befinden.

Kurzer Hintergrund

OpenClaw verbindet LLMs (Claude, GPT-4, Googles Modelle) mit Ihrer Maschine und einem echten Browser und lässt einen Agenten Aufgaben in Ihrem Namen erledigen — chatten über Telegram/Slack, Web-Aufgaben ausführen, Befehle ausführen. Die Komponente, um die es diesem Template geht, ist der Gateway-Dienst, der sich zur lokalen Entdeckung über Multicast-DNS (mDNS) auf Port 5353/UDP ankündigt.

Ein Hinweis zur Benennung, weil die Matcher davon abhängen: Das Projekt heißt jetzt OpenClaw, wurde aber als Clawdbot und früher als Moltbot veröffentlicht — dieselbe Codebasis, und die mDNS-Dienstnamen tragen noch immer das alte Branding (_clawdbot-gw, _openclaw-gw). Das Template matched auf beide, damit die Umbenennung es nicht blind macht.

Das Template

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._-]+)'

Wie es funktioniert

Es ist ein JavaScript-Protokoll-Template, kein HTTP. Die meisten Exposure-Templates senden ein GET und matchen den Antwort-Body. Dieses verwendet die nuclei/net-Bibliothek von Nuclei, um einen Raw-Socket zu öffnen und direkt ein binäres Protokoll zu sprechen — notwendig, weil mDNS etwas ist, das sich nicht mit HTTP-Matchern ausdrücken lässt.

Die Vorbedingung steuert den gesamten Prozess. isUDPPortOpen(Host, Port) prüft, ob 5353/UDP tatsächlich lauscht, bevor ein Paket gesendet wird. Ist er geschlossen, bricht das Template ab und Sie verschwenden keine Anfrage — was Scans kostengünstig hält, wenn Sie dies auf einen großen Bereich richten, wo die meisten Hosts keinen Gateway betreiben werden.

Der Code sendet eine rohe mDNS-Abfrage und liest die Antwort. Er öffnet eine UDP-Verbindung zu Host:5353, sendet ein hexadezimal kodiertes DNS-Paket mit SendHex und liest bis zu 2048 Bytes zurück. Der dekodierte Payload ist eine DNS-SD-Service-Enumerierungs-Abfrage — eine PTR-Frage für _services._dns-sd._udp.local, die Standard-Meta-Abfrage „Liste alles auf, was du ankündigst". Ein Host, der den Gateway betreibt, antwortet mit seinen angekündigten Diensten, und der OpenClaw/Clawdbot-Dienstname erscheint in dieser Antwort.

Die Matcher bestätigen, dass es ein Gateway ist. Zwei DSL-Prüfungen, or-kombiniert: contains(response, '_openclaw-gw') oder contains(response, 'clawdbot'), jeweils an success == true geknüpft, damit ein halb offener Socket oder eine leere Lesung keinen falsch-positiven Treffer produzieren kann. Entweder eine der Zeichenketten in der mDNS-Antwort bestätigt, dass Sie einen OpenClaw-Gateway vor sich haben, welches Branding er auch trägt.

Der Extractor zieht den Anzeigenamen des Geräts. Ein Regex holt displayName=... aus der Ankündigung und zeigt ihn als server in Ihrer Ausgabe. Ein Treffer ist also nicht nur „ein Gateway existiert" — Sie erhalten den menschenlesbaren Namen, den der Betreiber ihm gegeben hat, was für Inventar und Triage Gold wert ist.

Der Schweregrad ist info, CWE-200. Das ist die ehrliche Klassifizierung: Das Template erkennt eine Informations-Exposition (CWE-200, Information Exposure) — ein Gateway, das seine Konfiguration ankündigt, wo es das nicht sollte — keine aktive Ausnutzung. mDNS, das auf eine erreichbare Schnittstelle leckt, ist der Befund; was ein Angreifer als nächstes tut, ist ein separates Problem.

verified: true bedeutet, dass das Template gegen eine echte Instanz bestätigt wurde, nicht nur nach Spezifikation geschrieben — ein Treffer ist also vertrauenswürdig.

Warum mDNS-Erkennung es wert ist

HTTP-Fingerprinting ist der offensichtliche Weg, diese zu finden, und es funktioniert. Aber mDNS erfasst eine andere Scheibe. Ein Gateway kann Service-Discovery auf ein Netzwerksegment leaken, das ein Angreifer erreichen kann, auch wenn die HTTP-Seite durch eine Firewall, hinter einem Proxy oder auf einem nicht standardmäßigen Port gesperrt ist, den Ihr HTTP-Scan nicht abgedeckt hat. Es ist besonders relevant für interne Bewertungen und flache Netzwerke, wo Multicast fröhlich Segmente überquert, die es nicht sollte, und der Gateway effektiv ankündigt „Ich bin hier, und das ist mein Name" an alles im Netzwerk. Führen Sie dies zusammen mit einem HTTP-Fingerprint aus und Sie erhalten eine Abdeckung, die keiner von beiden allein hat.

Im großen Maßstab ausführen

Zuerst Ihr eigenes Netzwerk und Perimeter — klarste Autorisierung, und mDNS-Befunde sind am ehesten umsetzbar in Netzwerken, die Sie kontrollieren.

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

Das Template fixiert Port 5353 bereits in seinen args, und die isUDPPortOpen-Vorbedingung bedeutet, dass Sie ihm eine breite Host-Liste zuwerfen können, ohne etwas zu bombardieren — geschlossene Ports werden übersprungen, bevor ein Paket gesendet wird.

Vorfiltern mit einem UDP-Scan für große Bereiche. UDP-Scanning ist langsamer als TCP, daher lohnt es sich bei großen Umfängen, zuerst die aktiven 5353-Lauscher zu finden und nur diese an Nuclei weiterzugeben:

# 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

Internetweit auf Scan-Daten setzen. Senden Sie nicht aktiv UDP quer durch das Internet — es ist laut, langsam und rechtlich heikel. Verwenden Sie die im Template eingebetteten metadata-Abfragen (product:openclaw auf Shodan, body="ClawdBot" auf FOFA), um exponierte Instanzen aufzuzählen, und führen Sie das Template dann nur gegen Kandidaten in Ihrem autorisierten Scope aus.

Führen Sie es kontinuierlich aus, nicht einmalig. Die Installationsbasis von OpenClaw wächst gerade täglich, was bedeutet, dass ständig neue Gateways auftauchen — ein einmaliger Scan wird schnell veraltet. Und verknüpfen Sie jeden Treffer mit zwei Maßnahmen: Entfernen Sie den Gateway von jeder erreichbaren Schnittstelle, und rotieren Sie die Zugangsdaten, die er enthält.

Warum das wichtig ist

mDNS-Leakage ist der Befund, den das Template produziert, aber der Grund, sich jetzt gerade darum zu kümmern, ist das, was hinter einem exponierten Gateway steckt.

Das Timing ist die Geschichte. CVE-2026-25253 wurde am 26. Januar bekannt gegeben und in OpenClaw 2026.1.29 gepatcht, das Ende letzter Woche veröffentlicht wurde. Es ist eine 1-Klick-Remote-Code-Execution: Die Control UI akzeptiert eine gatewayUrl aus einem URL-Query-String und öffnet automatisch einen WebSocket dazu ohne Bestätigung, wodurch der Auth-Token der Instanz an denjenigen weitergegeben wird, der diese URL kontrolliert. Token stehlen, WebSocket kapern, Befehle ausführen. Es erfordert keine vorherige Authentifizierung, ist mit CVSS 8.8 bewertet (CWE-669, Incorrect Resource Transfer Between Spheres), und — das Unangenehme daran — es funktioniert sogar gegen Instanzen, die nur auf localhost laufen, weil der Angriff über den eigenen Browser des Opfers pivotiert. Forscher nennen es eine „1-Klick-RCE-Kill-Chain". Proof-of-Concept-Code ist bereits öffentlich, und breite Presseberichterstattung beginnt gerade erst zu kommen, während ich das schreibe.

Das ist das akute Problem, aber das anhaltende ist die Exposition im Allgemeinen. OpenClaw speichert Zugangsdaten für die Cloud-Modelle, die es steuert — Claude, OpenAI, Google AI — plus Tokens für alle Messaging- und Tooling-Integrationen, die Sie eingebunden haben. Ein exponierter Gateway ist SSH offen ohne Passwort, außer dass das Passwort ein Haufen bezahlter KI-Zugangsdaten und ein Foothold auf dem Host ist. Und weil ein Agent eine Identität mit Zugang ist, erbt derjenige, der einen übernimmt, seine Tokens und OAuth-Grants und kann ihm Anweisungen geben, die er ohne Nachfrage ausführen wird. Die Zugangsdaten sind der unmittelbare Preis; der persistente Foothold innerhalb eines privilegierten Agenten ist der nachhaltige. Ein Gateway, das seinen eigenen displayName über mDNS überträgt, macht sich nur leichter auffindbar. Das ist die Lücke, für die dieses Template gedacht ist.

Mitigation

Wenn Sie OpenClaw betreiben, die To-do-Liste dieser Woche:

  1. Jetzt patchen. Aktualisieren Sie auf 2026.1.29 oder neuer — es behebt CVE-2026-25253. Patchen macht frühere Exposition nicht rückgängig, also behandeln Sie es als Schritt eins, nicht als die ganze Aufgabe.
  2. Den Gateway-Token und alle gespeicherten Zugangsdaten rotieren. Neuer authToken, neue API-Schlüssel für Claude/OpenAI/Google AI, und Nutzungslogs prüfen. Wenn er erreichbar war, gehen Sie von einer Kompromittierung aus.
  3. Von jeder erreichbaren Schnittstelle entfernen. An Loopback binden, oder hinter ein VPN, einen Bastion oder ZTNA stellen, und 5353/UDP an Segmentgrenzen blockieren, damit mDNS aufhört, Netzwerke zu überqueren, wo es nichts verloren hat. Loopback ist der Boden, nicht die Decke — der RCE pivotiert durch den Browser, also ist nur-localhost kein Freifahrtschein.
  4. Den Agenten mit minimalen Rechten ausführen. Kein „Gottmodus". Schränken Sie seinen System-, Datei- und Schlüsselzugriff ein und überwachen Sie ihn wie jedes Konto mit dauerhaften API- und OAuth-Grants.
  5. Das Exploit-Muster überwachen. Unerwartete WebSocket-Verbindungen von Browsern zu externen Domains kennzeichnen und bei Gateway-Konfigurationsänderungen alarmieren.

Die Erkennung selbst ist nicht exotisch — eine Vorbedingung, eine rohe mDNS-Abfrage, zwei String-Matcher. Der Wert liegt im Timing: Es erfasst Gateways, die sich im Netzwerk ankündigen, auch wenn die HTTP-Seite gesperrt ist, genau dann, wenn ein öffentliches 1-Klick-RCE das Finden dringend macht. Früh ausführen, oft ausführen, Schlüssel bei jedem Treffer rotieren. Agenten-Runtimes sind Identitäten mit Schlüsseln; die exponierten schnell zu finden ist das ganze Spiel.