TR069 mal umgekehrt - ein Gedankenspiel

Ich sag mal: eher nicht.

Ein TR-069-Dialog wird zwar immer vom Client aus "geführt", d.h. er stellt die Verbindung zum Server her, aber er hat nur bedingt "das Sagen".

Wenn dann in so einem Dialog aus der Sicht des Clients alles erledigt ist, sendet er einen leeren Request an den Server als Zeichen, daß er "fertig hat".

Jetzt hat der Server seinerseits die Chance, dem Client seine Absichten mitzuteilen, zu diesen Absichten kann es auch gehören, den Client zum Download (und zur Installation) einer neuen Firmware aufzufordern.

Ob und wann der Server eine solche Aufforderung sendet, kann der Client aber eigentlich nicht beeinflussen ... höchstens noch "provozieren", indem er falsche Angaben zur derzeit installierten Version macht.

Wenn man aber erst einmal die Download-Adresse für so ein Firmware-Image ermittelt hat, sollte es machbar sein, dieses Image dann auch mehrfach zu laden ... in der Regel ist das nicht "clientspezifisch" und ob der ACS da nur zeitweise die IP-Adresse eines Clients als "berechtigt" freischaltet, würde ich stark bezweifeln (ohne es aber ausschließen zu wollen). Unter Umständen ist es sogar möglich, aus einer bekannten URL für den Download einer Firmware auf andere gültige Pfade zu schließen.

Zur rechtlichen Seite kann ich zwar nichts Definitives sagen, aber warum sollte ein Download einer Datei von einer bekannten URL ein Problem sein? Normalerweise würde ich erwarten, daß man eine FRITZ!Box auf der "Routing-Schnittstelle" da auch belauschen kann ... zumindest dann, wenn für die Verbindung zum ACS kein TLS verwendet wird.

Theoretisch kann zwar vom ACS zusammen mit der Aufforderung zum Download auch ein Benutzername und ein Kennwort übermittelt werden, aber solange das vom ACS gesendet wird, ist das ja auch nicht auf "unlauterem" Weg ermittelt und anders als eine clientspezifische Konfigurationsdatei ist eine Firmware-Datei nun eigentlich kein großes Geheimnis ... ja, unter bestimmten Umständen ist der Anbieter oder der Hersteller ja sogar verpflichtet, diese Datei auf Aufforderung im Quellcode zur Verfügung zu stellen. Wenn der Anbieter so eine Datei schützen will, muß er eben auch entsprechende Vorkehrungen treffen und da wäre eine clientspezifische Identifikation beim Download ja das Mindeste nach dem Stand der Technik. Wenn ein Anbieter das so regelt, wirst Du auch Probleme haben, an diese Datei zu kommen.

Für die Client-Seite einer TR-069-Kommunikation gibt es eine Python-Bibliothek, wie die genau heißt, müßte ich auch erst suchen ... das findest Du mit einer Suchmaschine bestimmt auch selbst.

Auch wenn es bei der Frage vielleicht nicht vordergründig um eine FRITZ!Box geht ... dort könnte man mit ein paar Änderungen an der Firmware (in erster Linie einem Tausch von CA-Zertifikaten) auch einen Man-in-the-middle-"Angriff" (bitte als Lausch"angriff" verstehen) starten. Das geht sogar ohne echte Änderungen an der Firmware, da die erforderlichen Daten für die Anmeldung am ACS (inkl. der Adresse des ACS) ja alle in der tr069.cfg enthalten sind, ebenso der komplette Pfad zu der Datei mit den Zertifikaten der vertrauenswürdigen CAs, den man damit auch auf den USB-Speicher "umbiegen" könnte.

(Netzfund) c't: o2-VoIP-Daten konnten von Dritten ausgelesen werden

"Der c't-Bericht geht zurück auf die Versuche eines Aachener Sicherheitsforschers, der sich mit den Kollegen in Verbindung gesetzt hat. Er wollte das TR-069-Protokoll, über dass die Mietrouter von o2 ihre Zugangsdaten automatisch zugewiesen bekommen, auslesen, um an seine VoIP-Daten zu gelangen. TR-069 sorgte schon in der Vergangenheit für Probleme. Die VoIP-Zugangsdaten gibt o2 seinen Kunden nicht bekannt, übermittelt sie aber aufgrund der zugewiesenen IP-Adresse über einen Auto Configuration Server (ACS) an das Modem des Kunden.

Bei seinen Versuchen machte er einen Fehler: Er ließ die ihm zugewiesene IP-Adresse als feste IP in dem Gerät, das ihm die übertragenen Daten lieferte. Am nächsten Tag fand er dann nicht mehr seine Zugangsdaten, sondern die eines fremden vor. Der Grund: Nach einer nächtlichen Zwangstrennung hatte er eine andere IP-Adresse bekommen, seine Adresse vom Vortag nutzte jetzt auch ein anderer Kunde. Und dessen VoIP-Zugang wurde ihm automatisch übermittelt. Bei weiteren Test mit einem Bekannten gelangte er auf diesem Weg auch an dessen Zugangsdaten und konnte sogar über dessen Leitung telefonieren - auf dessen Kosten."

[...]

in dem Artikel steht das Problem sei behoben - würde mich interessieren wie. ich tippe mal auf Seriennummer oder MAC-Adresse. vielleicht ist das einer der Gründe warum o2 ständig neue Hardware versendet...

Ne, das wäre sinnlos, dann würden die selbstgekaufen FBs nicht mehr funktionieren. Sie werden wohl nur die passenden IP-Adresse zulassen.

Warum so umständlich? Wenn ich lokal bin, kann ich doch gleich direkt auf die Fritzbox zugreifen und die gesamte Konfiguration abrufen.

Nicht jeder Client im lokalen Netz kann TR-069 machen...

Dann ist das Sicherheitsloch bei der Telekom noch viel größer, da kann jeder Client in lokalen Netz T-VoIP machen, da kein Passwort notwendig.

Machbar ist es schon, meines Wissens kann man z.B. bei den KNBs aus dem LAN einer FRITZ!Box nicht ohne weiteres auf den ACS zugreifen, weil die FRITZ!Box das auf die öffentliche IP-Adresse NATten sollte (müßte man glatt noch mal probieren) und der Zugriff auf das zweite logische Interface (voip+tr069, hier benutzt man private IP-Adressen) aus dem LAN geblockt werden sollte. Damit geht die Kommunikation mit dem ACS nur direkt vom CPE aus und nicht aus dem LAN dahinter. So weit die Theorie, ob das tatsächlich von AVM verhindert wird, müßte man - wie gesagt - noch mal testen.

Auch auf dem BRAS ließe sich mit einer anderen VLAN-ID für den TR-069-Traffic zum ACS noch etwas blockieren, wenn dann einfach jeder Verkehr mit dem ACS als Ziel, der nicht die richtige VLAN-ID hat (weil er aus dem LAN kommt), gedroppt wird. Solche Späße wie die Abfrage einer MAC-Adresse bringen hingegen wenig, weil das einfach immer eine Angabe des CPE sein muß, denn für die echte MAC-Adresse ist am BRAS Schluß mit lustig, ab da nur noch ab OSI-L3.

Oder man macht eine VPN-Verbindung zum ACS auf, die ist aber wieder aus dem LAN hinter dem CPE zu emulieren, es erhöht nur den Aufwand.

1&1 geht ja ganz simpel hin und verlangt das Einwahl-Kennwort für die TR-069-Konfiguration. Das verhindert zwar nicht das "Abgreifen" der Daten durch den berechtigten Kunden mit einem anderen TR-069-Client, aber ein Angreifer im LAN bräuchte schon erst mal dieses Einwahlkennwort, bevor er die VoIP-Credentials in Erfahrung bringen könnte.

Das ist ja auch das eigentliche Problem (ich nehme mal nicht an, daß o2 für die Zeit bis zum Inkrafttreten der FTEG-/TKG-Änderungen noch viel Aufwand treiben würde, um die Daten vor den eigenen Kunden zu verheimlichen), daß da jeder beliebige Angreifer im LAN, nur weil er von der richtigen IP-Adresse kommt, nach wie vor die VoIP-Credentials bei o2 abgreifen könnte. Solange die auch an anderen o2-Anschlüssen gültig sind, ist das Telefonieren auf Kosten eines anderen o2-Kunden möglich ... ich vermute auch eher, daß da das endgültige Ziel liegen wird, daß nur noch vom richtigen Anschluß aus diese Daten zu benutzen sind, dann ist es auch egal, wenn jemand im LAN die ermitteln kann (mit Ausnahme der Rufnummer, die bleibt ein Problem).