Ankündigung: Sicherheitsvorfall 2026-08-14

Allgemein
1

Update 1 (siehe nächsten Post unten): Ankündigung: Sicherheitsvorfall 2026-08-14 - #4 von flx

In der Nacht vom 13.08.2026 auf den 14.08.2026 haben unbekannte Dritte auf zahlreichen Knoten unseres Freifunk Darmstadt Netzwerks ein Update über die Autoupdaterfunktion aufgespielt, das weder von uns erstellt noch authorisiert wurde. Im Zuge dieses unauthorisierten Updates kam es zu einer Netzwerkstörung. Diese ist inzwischen behoben, allerdings benötigen beeinträchtigte Knoten einen Neustart.

Wir haben am heutigen Vormittag ein Update auf verbleibende Knoten, die von dieser Handlung nicht betroffen waren, mit Autoupdaterfunktion ausgerollt. Dieses ist unter https://firmware.darmstadt.freifunk.net erhältlich. Mehr Informationen darüber, wie es händisch installiert werden kann, sind weiter unten zu finden. Die Release Notes sind hier 3.2.0 - Gluon v2025.1.1 - Kritisches Update .

Da wir aktuell über die “Freifunk Darmstadt“ GitHub Organisation ( Freifunk Darmstadt · GitHub ) keine Kontrolle mehr haben, liegen die zugrundeliegenden Repositories und Sources für die Firmware unter einer temporären Organisation ( ffda-tmp · GitHub ).

Folgender Thread ist für Diskussion und Fragen: Diskussion: Sicherheitsvorfall 2026-08-14

Initialer Post (klicken)

Ich komme aus einer anderen Community als Freifunk Darmstadt. Muss ich mir sorgen machen?

Nach unseren Analysen waren für den Angriff mehrere Voraussetzungen notwendig um diesen durchzuführen. Auch wenn der Autoupdater dazu verwendet wurde das Update aufzuspielen, sind uns diesbezüglich keine hierfür relevanten sicherheitskritischen Probleme bekannt. Es besteht für andere Freifunk Communities keine akute Gefahr. Wir werden ausführliche Details in einem separaten Post dazu veröffentlichen.

Ist mein Knoten betroffen?

Betroffen sind ausschließlich Knoten, die ursprünglich mit Freifunk Darmstadt Firmware bespielt wurden und damit die W-LAN SSID / Bezeichnung darmstadt.freifunk.net verwenden.

Mittels der Firmwareversion lässt sich überprüfen, ob ein Knoten betroffen ist:

  • Gefährdet: 3.0.9 und älter, 3.1~20260121
  • Sicher: 3.2. (stable, beta), 3.3-20260811 (testing)
  • Unauthorisierte: 4.0.1, 4.0.1~20260815-14c7852, 4.1~20260810

Genauere Details über einen Knoten lassen sich über unsere Karte einsehen. Dafür kannst du entweder einen Knoten auf der Karten anklicken oder alternativ mittels dem Knotennamen in der Suche links auffinden. https://meshviewer.darmstadt.freifunk.net

Unter der IP Adresse beginnend mit 2001 ist die Statusseite von einem spezifischen Knoten aufrufbar und dort sind noch andere Details zu finden. “Freifunk Darmstadt” als Site ist korrekt.

Mein Knoten ist betroffen. Was muss ich tun?

Bei gefährdeten Knoten mit alter Firmwareversion reicht es vorerst aus, den Auto-Updater auszuschalten. Falls nicht klar ist wie das geht oder um auf Nummer sicher zu gehen, dann kann der Knoten natürlich auch vorerst abgeschaltet werden.

Wir raten dringend dazu, Knoten mit unauthorisierter Firmwareversion vom Netz zu nehmen und manuell mit dem neuen Firmwareupdate zu bespielen.

Die unauthorisierte Firmware ist offen einsehbar ( GitHub - fnsh/site · GitHub , http://updates.as62028.de/), bislang sind folgende Änderungen zu erkennen:

  • Die URL für Updates wurde geändert, sodass diese Geräte keine Updates von unserem Updateserver mehr erhalten.
  • Unsere Signaturen wurden entfernt, sodass wir keine Firmware-Updates für diese Geräte signieren können und diese Geräte unsere Firmwareupdates nicht mehr akzeptieren.

Aktuell sind kompromittierte Knoten noch in unserem Netz eingebunden und der Netzwerkverkehr ausgehend von diesen Knoten wird durch unsere Gateways durchgeleitet. Es ist möglich, dass auf diesen Knoten ein weiteres Firmware-Update ausgerollt wird, das z.B. den Netzwerkverkehr umleitet oder Backdoors enthält.

Nach aktuellem Kenntnisstand ist dies bislang nicht erfolgt, und wir schätzen die Gefahr dafür aktuell als gering ein.

Wir beobachten die Situation fortlaufend und werden hier über etwaige Updates informieren.

Wie kam es zu dem Zwischenfall?

Ein detailiertes Writeup über die Situation wird folgen, wir bitten um etwas Geduld. Aktuell liegt unser Fokus auf dem Sichern der Infrastruktur und der Kommunikation mit Nutzenden und relevanten Behörden.

Das Bundeskriminalamt, die Bundesnetzagentur, das Bundesamt für Sicherheit in der Informationstechnik und die Landesdatenschutzbeauftragten sind über den Vorfall informiert.

Sichere Version installieren

Config Mode

  1. Über https://firmware.darmstadt.freifunk.net die Upgrade Variante für dein Modell herunterladen. Bitte achte darauf, dass du das korrekte Modell

  2. Während der Knoten läuft etwa drei sekunden den Reset (oder WPS bzw. DECT, je nach Modell) Knopf drücken

  3. Der Knoten startet neu und du kannst dich über die LAN Ports über http://192.168.1.1 mit der Konfigurationsoberfläche verbinden.

  4. Dort oben rechts “Erweiterte Einstellungen”, dann “Firmware Aktualisieren” und dort unter beibehaltung der Einstellungen das neue Image hochladen

Autoupdater deaktivieren über Web Configmodus

Schritte 1-3 von “Config Mode” folgen. Danach oben rechts “Erweiterte Einstellungen”, dann “Automatische Updates” und dort deaktivieren:

Autoupdater deaktivieren über CLI Configmodus:

uci set autoupdater.settings.enabled=0
uci commit autoupdater
4

Update-Post

TL;DR: Es besteht kein akuter Handlungsbedarf mehr! Die entsprechenden Knoten mit Firmware-Version 4.0.1 werden zeitnah ein Update auf 4.0.2 erhalten. Dadurch wird Freifunk Darmstadt wieder in die Lage versetzt, Updates auszurollen. Desweiteren werden wir in einem zukünftigen Update die Signaturschlüssel rotieren.

Hintergrund

Der Vorfall wird überschattet von der Trennung des - zum CCC Darmstadt e.V. gehörenden - Freifunk Darmstadt Projekts und dem Freie Netze Südhessen e.V. Wir haben keinesfalls die Absicht hier interne Streitigkeiten auszutragen. Die folgenden inhaltlichen Punkte dienen dazu, eine Einordnung des Geschehens zu ermöglichen.

Nach über einem halben Jahr an unüberwindbaren Differenzen, und nachdem sich schon länger abzeichnete, dass die Kooperation der beiden Vereine nicht weiter Bestand haben würde, beschloss der Vorstand des Chaos Computer Club Darmstadt e.V. am Dienstag, den 11.08.2026, die offizielle Beendigung der Kooperation.

Noch am gleichen Abend hat der FNSH seine am 20.07.2026 gebaute Firmwareversion 4.0.1 fertig signiert und auf von den FNSH betriebenen Knoten ausgerollt.

Dadurch, dass die Firmwarekonfiguration der FNSH einen Fork von Freifunk Darmstadt darstellt, wurden Signaturschlüssel weiterverwendet, die auch weiterhin für Freifunk Darmstadt gültig waren. Dadurch waren die Signaturen auf Version 4.0.1 auch hinreichend um Knoten von Freifunk Darmstadt zu aktualisieren. Es wurde hier versäumt die Signaturschlüssel zu rotieren.

Sicherheitsvorfall (Kurzfassung)

Am 13.08.2026 im Zeitraum von 22:45 bis 0:50 am Folgetag, wurde die Firmware-Version 4.0.1 der FNSH auf mehreren hundert Freifunk Darmstadt Knoten ausgerollt. Der folgende Graph zeigt den zeitlichen Verlauf dieses Updates:

Entgegen anderer Behauptungen hat sich diese Firmware zu keinem Zeitpunkt auf unserem Update-Server befunden. Der Update-Vorgang hin zu dieser Firmware wurde auch nicht durch uns veranlasst.

Nach mehrtägiger Recherche sind wir überzeugt, dass die Adressen unserer DNS-Resolver gespoofed wurden. Dadurch konnte der DNS-Name des Update-Servers übernommen werden, um Firmware-Version 4.0.1 von einem fremden Update-Server auszuliefern. Wir können mit Sicherheit sagen, dass das Update an unserem Update-Server vorbei ausgerollt wurde.

Die in der Nacht vom Donnerstag auf Freitag gemeldeten Internetausfälle sind auf eben diesen Angriff auf die Namensauflösung im Freiunk-Netz zurückzuführen.

Wie dies technisch geschehen sein könnte, erläutern wir weiter unten. Zum jetzigen Zeitpunkt können wir den vermutlichen Ablauf anhand einiger Indizien skizzieren.

Weiteres Vorgehen

Uns ist weiterhin unklar, von wem oder mit welchem Ziel die Firmware-Version 4.0.1 im Freifunk Darmstadt Netz ausgerollt wurde.

Wir stehen mit dem FNSH in Kontakt und bewerten die derzeit ausgerollte Firmware-Version 4.0.1 als vertrauenswürdig.

Es gibt keine Anzeichen, dass die Firmware dazu genutzt werden könnte, anschließend weitere, möglicherweise unautorisierte Firmware auf die Geräte zu bringen.

Es besteht kein akuter Handlungsbedarf mehr.

Bereits in der aktuellen Woche sind weitere Firmwareupdates geplant, um alle zu Freifunk Darmstadt gehörenden Knoten wieder mit unserer Firmware zu versehen:

  • Zunächst wird es ein Update 4.0.2 seitens der FNSH geben, mit dem unsere Signaturschlüssel hinzugefügt und unsere Update-Server konfiguriert werden.
  • Ab dann können wir ein eigenes Update bereitstellen, um unsere Firmware auf Freifunk Darmstadt Knoten auszurollen sowie die Signaturschlüssel zu rotieren.
  • Darüber hinaus entwickeln wir ein Konzept wie die Sicherheit der DNS-Namensauflösung gegen derartige Angriffe zukünftig abgesichert werden kann

Sicherheitsvorfall (Detailversion)

Im Folgenden präsentieren wir unser bisheriges Verständnis und die daraus resultierende Hypothese, die wir auch erfolgreich in einem Testnetzwerk überprüft haben. Der wahrscheinliche Hergang stellt sich nach unseren bisherigen Erkenntnissen daher wie folgt dar:

Unser Netz ist in 18 Layer 2 Segmente, im Folgenden Domains, aufgeteilt. Über acht Gateways (Server) können sich freigeschaltete Knoten mit den Domains verbinden. Die Gateways sind auch für die Vermittlung des Internetverkehrs verantwortlich und verteilen außerdem IPv4-Adressen mittels DHCP.
Die VPN-Verbindungen werden mittels fastd orchestriert. Hierfür besteht eine asymmetrisches Krytographieverfahren; jeder Knoten besitzt also einen öffentlichen sowie einen privaten Schlüssel. Der öffentliche Schlüssel ist die Zeichenkette, die man bei der Ersteinrichtung zur Freischaltung einschickt.

Am Donnerstag, 13.08.2026 ab 20:00, sehen wir, dass ein Gerät mit einem freigeschalteten Schlüsselpaar VPN-Verbindungen zu mehreren Gateways und Domains gleichzeitig aufgebaut hat. Anfänglich immer nur für kurze Zeiträume, ab etwa 22:51 dann für rund zwei Stunden zu allen unseren Gateways und dort jeweils zu den meisten Domains.
Diese VPN-Verbindungen terminieren gegen 00:40. Insgesamt überlappt dieses Zeitfenster deutlich mit dem Ausrollen des nicht autorisierten Firmware-Updates.
Ein Knoten mit derart vielen Verbindungen ist außergewöhnlich, denn normalerweise verbindet sich ein Knoten mit regulärer Freifunk Darmstadt Firmware nur mit einem Gateway bzw. einer Domain gleichzeitig.

Im Graph lässt sich das beschriebene Verhalten leicht ablesen:

Über dieses Gerät wurden höchstwahrscheinlich Router Advertisements für das Präfix fd01:67c:2ed8:a::/64, in dem sich unsere DNS-Resolver befinden, versendet.
Diese Router Advertisements wurden ungefiltert über unsere Gateways zu allen verbundenen Knoten geschickt. Die Knoten haben daraufhin auf ihrem br-client Interface eine IPv6-Adresse aus diesem Bereich konfiguriert und DNS-Anfragen nicht mehr über ihre Default-Route versendet.

Unsere Freifunk-Knoten haben generell, also unabhängig der Domain, die folgenden beiden DNS Resolver in der Firmware fest konfiguriert:

  • fd01:67c:2ed8:a::55:1
  • fd01:67c:2ed8:a::56:1

Die beiden IP-Adressen liegen in genau dem Netzwerkpräfix, das durch Router Advertisement übernommen wurde. Verbindungen zu den DNS-Servern erfolgten ab dann nicht mehr gerouted über das Default Gateway. Stattdessen haben die Knoten versucht die IPv6-Adresse lokal (in ihrem Layer-2 Segment) zu erreichen. Die Routingtabelle enthielt dann zeitweise die folgenden Routen:

fd01:67c:2ed8:a::/64 dev br-client  metric 256
unreachable fd01:67c:2ed8:a::/64 dev lo  metric 2147483647

Hierüber konnte der DNS-Traffic entführt und manipuliert werden, was auch die Namensauflösung von updates.ffda.io beeinträchtigte. Auf welche IP-Adresse bzw. welchen Server updates.ffda.io von dem Rogue DNS-Server umgeleitet wurde, können wir im Nachinein nicht mehr nachvollziehen.

Konkret bedeutet das, dass in diesem Zeitraum zahlreiche Freifunk Darmstadt Knoten ein Update von einem fremden Update-Server bezogen haben, auf dem die Firmware-Version 4.0.1 der FNSH lag.

Hätte man beim Fork der Site-Konfiguration von Freifunk Darmstadt zu FNSH die Signaturschlüssel rotiert, dann wäre dieses Update nicht von den Freifunk Darmstadt Knoten akzeptiert worden, und der Vorfall wäre deutlich weniger gravierend ausgefallen.
Stattdessen wurde nun diese Firmware auf zahlreiche Freifunk Darmstadt Knoten ausgerollt, womit wir die Kontrolle über diese und die Möglichkeit für weitere Firmware-Updates verloren haben.

Nachdem die VPN-Verbindungen durch den Angreifer getrennt wurden, begann die Restlaufzeit des Router Advertisements auszulaufen. Es ist möglich, aber unklar, ob das Präfix mit einer Lifetime von 0 deannounced wurde.

Mit Ablauf des Router Advertisements haben die Knoten ihre IP-Adresse aus dem entführten Präfix verloren. Die unreachable Route, die von OpenWrt für alle lokalen Präfixe anlegt wird, blieb jedoch dauerhaft bestehen und konnte im Nachgang noch am Folgetag beobachtet werden:

unreachable fd01:67c:2ed8:a::/64 dev lo  metric 2147483647

Infolge dessen blieben Freifunk Darmstadt Knoten nach diesem Vorfall ohne funktionierende DNS-Namensauflösung zurück. Das ist auch die erkennbare Ursache für die beobachtbaren Internetausfällen seit Beginn des Vorfalls.

In der Firmware setzen wir seit vielen Jahren auf gluon-ebtables-source-filter um solche Angriffe aus dem Client-Netz abzuwehren. Außerdem nutzen wir gluon-radv-filterd, damit Router Advertisements nur vom im Routingprotokoll selektieren Gateway akzeptiert werden. Eine Filterung von Router Advertisements von Node zu Node über das Gateway findet bisher nicht statt.

Künftig wird man schauen müssen, wie man eine Filterung von Router Advertisements auch auf den Gateways sinnvoll realisieren kann. Dies wird sicherlich auch andere Communities betreffen, und wir hoffen darauf dort gemeinsam eine sinnvolle Lösung auszuarbeiten.

Kann es nicht sein, dass die Verteilung doch über unseren eigenen Update-Server passiert ist?

Nach Auswertung der OpenSSH und nginx Logs ist das ausgeschlossen. Außerdem können wir über die täglichen Backups nachvollziehen, dass Firmware 4.0.1 niemals auf dem Update-Server vorhanden war. Zusätzlich war unser Update-Server nach einer kürzlichen Migration von Debian zu NixOS dysfunktional, da das Einrichten des Virtual Hosts für updates.ffda.io vergessen wurde. Das wurde erst jetzt in [ nginx/firmware_darmstadt_freifunk_net: add updates.ffda.io (9cfb0ba8) · Commits · ffda / infra / nixos-config · GitLab ] behoben.

Aber warum sagen Leute, die Firmware sei nachweislich von updates.ffda.io gekommen?

Während des Angriffs zeigte updates.ffda.io zeitweise nicht auf unseren eigenen Update-Server, sondern auf einen anderen Server außerhalb unserer Kontrolle. Dies wurde durch die Manipulation der DNS-Auflösung verursacht.

Warum hat das so lange gedauert mit den weiteren Infos?

Wir arbeiten praktisch seit mehreren Tagen ununterbrochen an der Lösung dieser Situation. Unser Anspruch ist ein möglichst vollständiges Bild der Situation berichten zu können. Das bedeutet jedoch einen enormen Zeitaufwand in unserer Freizeit, um Logs auszuwerten, Theorien aufzustellen, Hypothesen zu testen und diese sachgerecht zu dokumentieren.

Weitere Gedanken

Der primäre Schutzmechanismus für Updates sind die Signaturen. Hier war eindeutig ein Fehler, dass zwei getrennte Firmwareprojekte sich teilweise Signaturschlüssel geteilt haben.
Gleichzeitig besteht weiterhin kein direkter Schutz gegen DNS-Spoofing, so wie es bei uns passiert ist.

Generell bringen große Layer 2 Netze, so wie es das Freifunk-VPN ist, Risiken mit sich, die im aktuellen Setup nur teilweise mitigiert werden.