Def Con 22: Millionen DSL-Router durch TR-069-Fernwartung kompromittierbar

frickl · 19 Aug 2014

koyaanisqatsi schrieb:
Moin

Sehr lustig, folgendes kann jeder der eine 1&1 Box hat mal antesten ...
Die /var/flash/tr069.cfg sieht auch wieder so aus wie vorher, die Änderungen wurden also verworfen.

Was steht/stand bei dir unter

Code:

tr069discover_active = yes;

yes oder no?

koyaanisqatsi · 19 Aug 2014

Ich wusste jetzt nicht in welcher Datei, grep hilft...

Code:

grep tr069discover /var/flash/*
/var/flash/ar7.cfg:        tr069discover_active = yes;
/var/flash/ar7.cfg:        tr069discover_without_dhcpoption = no;
/var/flash/ar7.cfg:        tr069discover_forced = no;
/var/flash/ar7.cfg:        tr069discover_vlancfg_list {
/var/flash/ar7.cfg:        tr069discover_vlancfg {
grep: /var/flash/aura-usb: No such file or directory
grep: /var/flash/browser-data: No such file or directory
grep: /var/flash/cert.cfg: No such file or directory
grep: /var/flash/debug.cfg: No such file or directory
grep: /var/flash/maild.xml: No such file or directory
grep: /var/flash/modulemem: No such file or directory
grep: /var/flash/net.update: No such file or directory
grep: /var/flash/timeprofile.cfg: No such file or directory
grep: /var/flash/xdslmode: No such file or directory

Also: yes

Hast du einen Vorschlag für mich?

PeterPawn · 19 Aug 2014

koyaanisqatsi schrieb:
Die /var/flash/tr069.cfg sieht auch wieder so aus wie vorher, die Änderungen wurden also verworfen.

Solange Du bei den Zugangsdaten 1&1 als Anbieter eingestellt läßt (active_provider in der ar7.cfg), wird der TR-069-Zugang bei jedem Start der FRITZ!Box neu eingerichtet. Es hilft nur, den Anbieter auf "Andere ..." zu stellen (ggf. auch nachträglich durch Änderung in der ar7.cfg z.B. auf "oma_lan" oder "other", wenn man erst einmal automatisch konfigurieren lassen will) und die Konfiguration der Daten von Hand vorzunehmen. Das ist schon seit geraumer Zeit so, wobei offenbar die Stelle, an der diese "Grunddaten" wiederhergestellt werden, gewechselt hat. Die Änderungen werden auch nicht einfach vor dem Reboot noch einmal vom ctlmgr überschrieben, was man durch das Löschen des char-Devices für die tr069.cfg vor dem Reboot prüfen kann (oder einfach durch Ziehen des Netzteils) und auch durch ein frühes Protokollieren des Inhalts der tr069.cfg nach einen Neustart sieht (also vor dem Start des ctlmgr).

Ich kann das zwar nur für die 7390/7490 ziemlich sicher sagen, es sollte bei einer 736x aber auch nicht anders sein.

Bei der manuellen Konfiguration mit "Anderer Anbieter" muß dann allerdings wohl der Parameter "vdsl_resalearch" bei Deiner VDSL-1&1-Leitung noch zusätzlich auf "yes" gesetzt werden, sonst kommt vermutlich keine PPPoE-Verbindung zustande. Danach bleibt dann TR-069 auch wirklich deaktiviert ... auch vollkommen unabhängig vom Branding der Box. Wobei ein AVM-Branding auch nicht schadet ...

Zumindest in den Standard-Einstellungen und den Webserver-Lua-Skripten (also dem lesbaren Teil der Firmware) unterscheiden sich die Dateien z.B. für die drei Brandings einer 7390 nur sehr marginal. Eigentlich ist nur das m-net-Rootzertifikat für TR-069 im 1und1-Branding nicht enthalten, im avm-Branding schon. Das otwo-Branding enthält dann noch einige zusätzliche Zertifikate in der root_ca.pem und die Einstellung "voip_assi_enabled = yes;" in voip.cfg wurde entfernt. Beim Inhalt der GUI-Dateien besteht zwischen den Brandings gar kein Unterschied mehr. Eine Box mit 1und1-Branding wird also vom "Code" in /usr/www/1und1 genauso behandelt wie vom Code in /usr/www/avm.
Das dürfte - angesichts der AVM-Philosophie der monolithischen Firmware, wo z.B. eine 7490 auch unnötigerweise den Lua-Code für DOCSIS-Boxen von KDG enthält - bei anderen Box-Modellen auch nur wenig anders sein. Lediglich die Standard-Einstellungen in /etc/default.Fritzbox... sind offenbar boxspezifisch, da könnten sich also bei einem anderen Modell doch Unterschiede zwischen den Brandings ergeben.

Früher war - da bin ich mir fast sicher, müßte aber erst das passende Referenz-Image suchen - die Wiederherstellung der Provider-Einstellungen sogar in den Shell-Dateien irgendwo in /etc enthalten, in neuer Firmware wird dort bei einer konfigurierten Box nichts ausgeführt. Dafür bügelt jetzt immer der ctlmgr die Provider-Einstellungen über eine Box.

Rein dem Zeitstempel der letzten Änderung (am Anfang der Datei, das char-Device hat keinen echten Zeitstempel) an der tr069.cfg nach zu urteilen, wird die Standard-Einstellung vom ctlmgr irgendwann nach dem Start restauriert (bei meiner 7390 48 Sekunden danach). Nachdem der ctlmgr aber die zentrale Komponente für den Zugriff auf die Konfigurationsdateien ist, könnte ihn u.U. auch irgendeine andere Komponente dazu auffordern. Welche das genau sein könnte, ist etwas schwierig zu ermitteln, solange man kein Freetz-Image auf der Box hat und die Interprozess-Kommunikation zu diesem Zeitpunkt beobachten kann.

Die "Quelle" der restaurierten Einstellungen ist jedenfalls die Datei "/etc/default.Fritz_Box_*/*/providers-049.tar", wo im Unterverzeichnis "<active_provider>" liegende cfg-diff-Files (zu diff-Files s. allcfgconv) mit den Einstellungen wohl immer angewendet werden. Dieses tar-File wird inzwischen vom ctlmgr selbst nach /var/tmp entpackt und nach dem Lesen der Einstellungen dort wohl auch wieder gelöscht (wenn das im ctlmgr eingebaute Löschkommando nicht nur dem Saubermachen vor dem Auspacken dient).

Beim Erstellen eines eigenen Images könnte man also dieses tar-File entsprechend ändern und ist das Problem auch los. Den Mechanismus im ctlmgr an sich kann man durch "Freetzen" ja nicht mehr einfach abstellen und an den Dateien in /etc/init.d kann man neuerdings patchen, was man will ... der Mechanismus im ctlmgr greift trotzdem.

Die ctlmgr-Einstellungen in "desc.txt" werden aber offenbar nur dann angewendet, wenn man diesen Provider "neu" einstellt, z.B. über das GUI.

Die "zwangsweisen" TR-069-Einstellungen für 1&1 sehen z.B. so aus:

Code:

tr069cfg {
        enabled = yes;
        igd {
            DeviceInfo {
                ProvisioningCode = "000.000.000.000";
                }
            managementserver {
                url = "https://acs1.online.de/";
                dnsprefer = tr069dnsprefer_ipv6;
            }
        }
        ACS_SSL {
                     verify_server = yes;
             trusted_ca_file = "/etc/default/1und1/root_ca.pem";
        }
        Download_SSL {
             verify_server = yes;
             trusted_ca_file = "/etc/default/1und1/root_ca.pem";
        }
}

Der Verbindungsaufbau kam also von "Innen".

Nochmal: Bei TR-069 kommt der Verbindungsaufbau immer von innen, wenn es um das Abholen von Konfigurationsdaten oder die Frage nach neuer Firmware oder das Abliefern von Statistikdaten geht. Der von außen erreichbare Port nimmt nur den "Rückrufwunsch" des ACS entgegen, die Verbindung wird danach immer vom Client (also der FRITZ!Box) aufgebaut.
Insofern ist dieser offene Port auch nur bei falscher Implementierung der Behandlung des "Connection Requests" oder bei falsch konfigurierter ACS-Adresse (die Rückrufnummer) ein zusätzliches Risiko. Wenn der ACS die Box nicht seinerseits zur Kontaktaufnahme auffordern kann, muß er eben bis zum nächsten Neustart der Box und der dann von ihr automatisch ausgeführten Kontaktaufnahme warten. Für die generelle Funktion von TR-069 ist der offene Port und ein "ACS initiated connection request" vollkommen Bummi.

andilao schrieb:
Anscheinend übertreibt man es bei 1&1 mit der Big-Brother-TR-069-"Active Notification".

Man kann 1&1 auch nur insoweit die "Schuld" geben, als ihnen dieses Verhalten der Firmware sicherlich bekannt ist. Ansonsten ist diese ganze Geschichte erst einmal schon seitens AVM in der Firmware verankert, was man durch einfaches Ausstecken des WAN-Anschlusses beim Neustart nach dem Löschen der TR-069-Daten leicht prüfen kann. Wenn die Box gar keinen Kontakt zum 1&1-ACS aufnehmen kann, muß ja jede Änderung schon aus der Firmware kommen.

Daß der 1&1-ACS nach der Kontaktaufnahme der Box die Konfigurationsdaten neu übermittelt, ist ja "by design" und sicherlich nicht zu bemängeln. Das Problem liegt eher in der Tatsache, daß die Firmware so geändert wurde, daß sie (und zwar egal, ob es sich um ein OEM-Modell handelt oder um ein "originales" AVM-Modell) immer wieder ungefragt die Einstellungen für den Provider neu setzt, egal was der Besitzer nachträglich verändert hat.

Gleichzeitig streut man - meiner Meinung nach - dem Kunden Sand in die Augen, indem man ihm diese "Anbieterdienste"-Seite vorsetzt. Ich habe es oft genug schon geschrieben, betone es aber gerne noch einmal: Das Ausschalten der Providerkonfiguration (erster Punkt in diesem GUI-Teil) schaltet nicht das TR-069 komplett ab (wenn es dort überhaupt möglich und nicht "ausgegraut" ist), es wird nur ein "Litemode" (was das heißt, gibt AVM auch auf Anfrage per E-Mail nicht preis) eingeschaltet. Bei mir ist bei der 7390 das Ausschalten der Providerkonfiguration aber auch deaktiviert, jedenfalls solange man als Provider 1und1 eingestellt hat und die Box noch keinen Kontakt zum ACS hatte. Ob sich das nach einer ersten erfolgreichen Kontaktaufnahme mit dem ACS ändert, konnte ich mangels 1&1-DSL noch nie richtig testen.

Fakt ist aber, das ist nun einmal kein 1&1-spezifisches Phänomen/Vorgehen und diese "litemode"-Einstellung beim TR-069 wurde wohl von AVM extra deshalb eingeführt, damit man über die "enabled"-Einstellung in den Default-Diffs auch dann TR-069 aktivieren kann (in welchem Umfang ist eben unklar), wenn der Besitzer nur den "Litemode" (erster Punkt in "providerservices.lua") aktiviert hat ... also den Haken entfernt hat, das ist etwas verworren dort.

Die Liste der Provider-Einstellungen mit aktiviertem TR-069 umfaßt auch nicht nur 1&1 und m-net. Bei welchen Providern AVM TR-069 "zwangsweise" einschaltet, kann sich jeder in der providers-049.tar selbst ansehen.

Es gibt auch irgendwo eine TR-069-Dokumentation für Provider von AVM ... die Frage ist nur, wie man da rankommt. Es sind mindestens 4 PDF-Dateien, die die vom FRITZ!OS unterstützten TR-069-Techniken (da ist ja ein ganzer Strauß von Schnittstellen in dieser Richtlinie, es ist ja nur ein Pseudo-Standard) und die verwendbaren Parameter beschreiben, diese werden aber offenbar als "confidential" angesehen und auch als direkter Käufer einer AVM-FRITZ!Box kommt man da offenbar nicht ran. Warum das so ist, weiß wohl nur AVM selbst ... es ist ja letzten Endes eine offene Spezifikation und die Information, welche Parameter man bei einem AVM-Router darüber aus der Ferne beeinflussen kann, kann ja schlecht als Wettbewerbsnachteil angesehen werden, solange nicht irgendwelche "Schweinereien" dort implementiert sind, mit denen der Besitzer der Box eigentlich nicht rechnen mußte. Insofern führt diese Geheimniskrämerei natürlich automatisch zu Spekulationen. :crazy:

koyaanisqatsi schrieb:
Sie ist schon auf avm gebrandet.

Das Branding spielt bei der Angelegenheit mit den Providers-Einstellungen keine Rolle (s.o.)

EDIT: Nach einem - dann doch ziemlich simplen - weiteren Test bin ich mir eigentlich sicher, daß die ganze Geschichte mit der providers-049.tar doch direkt vom ctlmgr ausgeht. Wenn man den ctlmgr stoppt, die Datei /var/flash/tr069.cfg mit einer Kopie ohne ACS-Serveradresse überschreibt und den ctlmgr dann neu startet, wird umgehend wieder der ACS-Server eingetragen ... damit wird das "externe Anstoßen" dieses Vorgangs eher unwahrscheinlich.

koyaanisqatsi · 19 Aug 2014

Oje, OK, also werd ich mal auf "koysnet" umstellen und berichten.
Aber erst heut Abend, ich brauch ein paar Stunden Sekundenschlaf.

Vielleicht fällt mir ja noch irgendetwas im Traum ein.

JohnDoe42 · 19 Aug 2014

PeterPawn schrieb:
Die "Quelle" der restaurierten Einstellungen ist jedenfalls die Datei "/etc/default.Fritz_Box_*/*/providers-049.tar", ...
Beim Erstellen eines eigenen Images könnte man also dieses tar-File entsprechend ändern und ist das Problem auch los.

Könntest Du das ggfs. hinsichtlich einer Überarbeitung des Remove-TR069-Patches in Freetz präzisieren ? Genügt ein plumpes Löschen des TAR-Files in der originalen AVM-FW (vor dem Zusammenbau des Freetz-Images) und/oder Anlage eines gleichnamigen Files mit 1 Byte, oder müßte man das ähnlich handhaben wie der ctlmgr, also entpacken und anstelle des active_provider manuell irgendwas setzen ?
Bei mir (an einer Alice-DSl-Leitung) ist übrigens (trotz des Remove TR069)

Code:

ar7cfg {
        mode = dsldmode_router;
        active_provider = "tonline";

Code:

voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", 
                            "tcp 0.0.0.0:5060 0.0.0.0:5060", 
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";
        voip_ip6_forwardrules = "udp 5060,7078-7110", "tcp 5060";
        tr069_ip6_forwardrules = "tcp 8089";

Code:

tr069discover_active = yes;
        tr069discover_without_dhcpoption = no;
        tr069discover_forced = no;
        tr069discover_vlancfg {
                vlanencap = vlanencap_none;
                vlanid = 0;
                vlanprio = 0;
        }

Code:

{
                enabled = yes;
                name = "tr069";
                type = qos_cfg_hidden;
                iface = qos_local;
                rule = "localmark sipdns,ntpdns,tr069dns,tr069";
                result {
                        tos = -1;
                        vlan_prio = -1;
                        queueref = "hprio";
                }

Grüße,

JD.

vanButen · 19 Aug 2014

Ich habe eine (rote) 7390 auf dem "freien Markt" (Amazon) erstanden und bin der Einrichtung "Unitymedia" gefolgt. Nachgesehen bei den "Anbieterdiensten" waren alle Häkchen gesetzt.
Zurück und unter "anderer Anbieter" nun eingerichtet. Die Häkchen erschienen wieder automatisch (neue IP wurde zugewiesen).
Ich hätte eigentlich gedacht, dass bei einer solchen Box eine "Vorbelegung" nicht aktiv ist.

koyaanisqatsi · 19 Aug 2014

Ah, heul...

Das ändern des Profils von "1und1" auf "koysnet" hat es nicht gebracht.

Nach dem Neustart sah es erstmal gut aus, doch...

1. Obwohl Internet auch über IPv6 angezeigt wurde, gab es keine IPv6 Verbindung mehr und der Fallback auf IPv4 dauerte ewig.
2. Die tr069.cfg habe ich auch geändert, nach Neustart wurde die Box wieder neu konfiguriert!
3. Musste die Box mit einer Sicherung wieder in den "normalen" Zustand zurücksetzen.
4. Der Reiter für Anbieter-Dienste ist dauerhaft verschwunden (Screenshot), TR-069 ist aber aktiv.

Code:

flipflop_tr6469.sh status # ctlmgr_ctl Abfrage
TR-064 ist aus
TR-069 ist ein

PeterPawn · 19 Aug 2014

vanButen schrieb:
Ich hätte eigentlich gedacht, dass bei einer solchen Box eine "Vorbelegung" nicht aktiv ist.

Die diff-Files in den Provider-Einstellungen sind additiv oder ersetzen vorhandene Einstellungen. Es werden keine Einstellungen gelöscht.

Wenn man also eine Box für UM einrichtet und anschließend ohne Reset auf "anderer Anbieter" umstellt, werden nur die bei "anderer Anbieter" hinterlegten Einstellungen (praktisch also keine) neu gesetzt und die alten UM-Einstellungen bleiben erhalten.

JohnDoe42 schrieb:
Könntest Du das ggfs. hinsichtlich einer Überarbeitung des Remove-TR069-Patches in Freetz präzisieren ?

Wenn man unter "remove TR-069" dann "deactivate TR-069" verstehen will (der alte Patch entfernt(e ?) ja auch noch einige andere Dateien wie tr069fwupdate u.a., was dann ggf. zum Absturz führen kann, wenn der ctlmgr sie aufrufen will), dann würde ich hingehen und die Datei "providermap.txt" (auch im tar-Archiv) soweit ausdünnen, daß dort nur noch "anderer Anbieter" und "LAN1" bzw. "WLAN" als Provider drin stehen und dann sollten sich bei einer derartigen Box eigentlich auch nur noch diese "Provider" einstellen lassen (müßte man sicherlich erst einmal testen, damit die Einstellungsseite für die Zugangsdaten dann nicht durchdreht).

In den dann verbleibenden Unterverzeichnissen für diese Zugänge einfach keine cfg-diff-Files hinterlegen bzw. sogar diff-Files, die vorhandene Einstellungen mit leeren Werten ersetzen. Noch eine passende "desc.txt" in jedes Unterverzeichnis und die Datei wieder einpacken.

Wenn ich das richtig sehe (nicht getestet), baut der ctlmgr beim Start auch gleich noch seine komplette Providerliste (die das Webinterface bei ihm per LUA abholt und die man per "ctlmgr_ctl r providerlist settings/providerlist/count" (ff.) auch abfragen kann) daraus auf. Wenn man nur die TR-069-Einstellungen ändern (und die Providerliste drinlassen) will, wären tr069cfg-diffs, die die Werte auf "" setzen (auch bisher nicht getestet), sicherlich auch eine Möglichkeit. Wobei es bei einigen Providern ohne TR-069 wohl wirklich nichts wird ...

koyaanisqatsi schrieb:
Das ändern des Profils von "1und1" auf "koysnet" hat es nicht gebracht.

Auch wenn ich keine Ahnung habe, was Du bei "koysnet" eingestellt hast, warum versuchst Du es nicht einmal mit "Anderer Anbieter" ? Dabei aber "vdsl_resalearch" im Auge behalten (die richtige Einstellung steht ja jetzt in der ar7.cfg), falls der dann nicht richtig gesetzt ist.

HabNeFritzbox · 19 Aug 2014

Seid ihr bald fertig mit dem Konfig Battle?

Der einfache Anwender wird weder in der Konfig was modifizieren, noch remove Script mit Freetz laufen lassen. Ist doch eher was für die "Bastel Freaks".

Zumal der Port ja mit aktueller FW ja dicht ist, bei der 7490 und damit auch neusten Beta bei den anderen FB´s. Und 1&1 bzw. FB hier nichtmal direkt betroffen sind, und eher andere Hersteller in Frage kommen, welche diese Technik auch einsetzen.

koyaanisqatsi · 19 Aug 2014

Stimmt, hast Recht.
Lass uns lieber banalisieren.

TR-069 ist doof!

PeterPawn · 19 Aug 2014

HabNeFritzbox schrieb:
Zumal der Port ja mit aktueller FW ja dicht ist

Was hat denn der Port jetzt mit TR-069 zu tun und der Tatsache, daß die TR-069-Funktion der Box sich nicht richtig abschalten läßt ?

Offenbar hat AVM da mit dem plakativen Schließen des Ports ja doch bei einigen Leuten einen Nerv getroffen, wenn diese dann denken: "Der Port ist zu, also alles schön ..."

Die Release-Notes sagen eindeutig:

Verbesserung - Bei deaktiviertem TR-069 ist der Connection Request Port 8089 nun geschlossen

Da steht aber nicht, bei geschlossenem Port ist TR-069 jetzt deaktiviert.

Und hier geht es im Moment ja darum, daß sich TR-069 eben nicht ohne weiteres deaktivieren läßt, wenn man bestimmte Anbieter bei den "Zugangsdaten" einstellt.

Noch mal zum Nachvollziehen:

Code:

# grep active_provider /var/flash/ar7.cfg
        active_provider = "1und1";
# ctlmgr_ctl r tr069 settings/enabled
1
# sed -n -e '8,12p' /var/flash/tr069.cfg
tr069cfg {
[COLOR="#0000FF"]        enabled = yes;
        litemode = no;
[/COLOR]        tr181_support = no;
        dhcp43_support = yes;
# cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
[COLOR="#0000FF"]tcp 0.0.0.0:8089 192.168.132.1:8089 0  (tr069)
[/COLOR]tcp 0.0.0.0:49647 192.168.132.1:49647 0  (normal)
tcp 0.0.0.0:21 192.168.132.1:21 0  (normal)
---------------------------
# netstat -anp | grep 8089
[COLOR="#0000FF"]tcp        0      0 :::8089                 :::*                    LISTEN      20360/ctlmgr
[/COLOR]# ctlmgr_ctl w tr069 settings/enabled 0 [COLOR="#FF8C00"]<=== das passiert beim Löschen des "Hakens" bei "Providereinstellungen zulassen"[/COLOR]
... einige Zeilen gelöscht
# sed -n -e '8,12p' /var/flash/tr069.cfg
tr069cfg {
[COLOR="#0000FF"]        enabled = yes; 
        litemode = yes;[/COLOR]
        tr181_support = no;
        dhcp43_support = yes;
# cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
tcp 0.0.0.0:49647 192.168.132.1:49647 0  (normal)
tcp 0.0.0.0:21 192.168.132.1:21 0  (normal)
---------------------------
# netstat -anp | grep 8089
#

TR-069-Port ist sichtbar geschlossen, hat aber nur eine untergeordnete Bedeutung.

Warum das so ist, kann man hier auf Seite 15 (Abschnitt 2.3.4) nachlesen. Die Verfügbarkeit dieser Funktion ist also "nice to have", hat aber mit der grundsätzlichen Funktion von TR-069 nur sehr wenig zu tun.

HabNeFritzbox · 20 Aug 2014

Bei Heise steht auch dass AVM da keine Gefahr sieht derzeit. http://www.heise.de/newsticker/meld...-Fernwartungsluecke-keine-Gefahr-2294267.html

RalfFriedl · 20 Aug 2014

Das ist eine seltsame Argumentation von AVM:

keine umittelbarer (sic) Gefahr für Fritzboxen. "Die Schwachstellen betreffen die Software, die auf den ACS-Servern laufen"..., das Thema sei "endgeräteunabhängig".
...
AVM betont: "In Deutschland verwendet die überwiegende Anzahl der Anbieter HTTPS-verschlüsselte Verbindungen.

Einerseits ist es technisch korrekt, es in diesem Fall geht es nicht um eine unmittelbare Gefahr für Fritzboxen, sondern um eine mittelbare Gefahr für Fritzboxen. Da fühlt man sich doch gleich viel sicherer. Anscheinend ist ihnen diese Aussage so schwer von der Feder gegangen, dass sie es nicht einmal geschafft haben, das Wort "unmittelbar" richtig zu schreiben. Das Thema ist tatsächlich unabhängig vom Endgerät, daher ist die Frage, was die folgenden Aussagen von AVM dazu sollen.

Wenn die "überwiegende Anzahl der Anbieter" HTTPS verwendet, dann tun dies offensichtlich nicht alle, sonst wäre es auch so formuliert worden.

sf3978 · 20 Aug 2014

RalfFriedl schrieb:
Wenn die "überwiegende Anzahl der Anbieter" HTTPS verwendet, dann tun dies offensichtlich nicht alle, ...

KabelBW tut es nicht:

url = "http://acs.prov.kabelbw.de:7547/live/.../.../genericTR69";

JohnDoe42 · 20 Aug 2014

PeterPawn schrieb:
... dann würde ich hingehen und die Datei "providermap.txt" (auch im tar-Archiv) soweit ausdünnen, daß dort nur noch "anderer Anbieter" und "LAN1" bzw. "WLAN" als Provider drin stehen...

Also so ?

Code:

NAME=LAN
{
ID=lan;
}
NAME=WLAN
{
ID=wlan;
}

PeterPawn schrieb:
In den dann verbleibenden Unterverzeichnissen für diese Zugänge einfach keine cfg-diff-Files hinterlegen bzw. sogar diff-Files, die vorhandene Einstellungen mit leeren Werten ersetzen. Noch eine passende "desc.txt" in jedes Unterverzeichnis und die Datei wieder einpacken.

Bei mir existieren, zumindest nach Anwendung des Remove-TR069-Patches, keine solchen Diff-Files, und die desc.txt sieht überall gleich aus:

Code:

box:settings/opmode=opmode_standard
connection0:pppoe:settings/username=
connection0:pppoe:settings/password=
connection0:pppoe:settings/idle=300
connection0:pppoe:settings/mode=lcp
connection0:settings/ProviderDisconnectPrevention/Enabled=1
connection0:settings/ProviderDisconnectPrevention/Hour=3

Grüße,

JD.

PeterPawn · 20 Aug 2014

JohnDoe42 schrieb:
Also so ?

Jein, ich würde das auch nicht gleich in "freetz" gießen.

Zuerst muß man mal testen, welche der (explizit als nicht getestet gekennzeichneten) Annahmen denn auch stimmt.

Wenn es möglich ist, durch das Setzen von leeren Einträgen in den cfg-Diffs vorhandene Einstellungen "zu löschen", dann würde ich die Providerliste per se drin lassen (für die meisten sicherlich nicht falsch) und nur die TR-069-Settings überschreiben (eben durch leere Einträge und ggf. enabled=no).

Als Option für den Patch kann man dann ja noch das Entfernen der Providerliste anbieten. Allerdings braucht es sicherlich in den meisten Fällen mind. 3 Einträge: 1x LAN, 1x WLAN und - nicht zu vergessen - 1x "echtes" WAN (egal ob DSL/LTE oder sonstwas).

Von anderer Stelle darauf angesprochen möchte ich noch einmal darauf hinweisen, daß es sich nicht um herkömmliche "diff"-Files handelt (die werden m.W. bei freetz eingesetzt zum Speichern von Einstellungen), es sind lediglich kleine Dateien mit wenigen Einträgen im Format einer normalen AVM-Konfigurationsdatei, die nur in einem speziellen Modus eingespielt werden und damit nicht die modifizierte Konfigurationsdatei als ganzes ersetzen, sondern nur die in ihnen definierten Einstellungen hinzufügen oder ersetzen.

Bei mir existieren, zumindest nach Anwendung des Remove-TR069-Patches, keine solchen Diff-Files, und die desc.txt sieht überall gleich aus:

Warum schaust Du dann nicht vor dem Anwenden des Remove-Patches nach ?

Die desc.txt enthält praktisch Kommandos für den ctlmgr, die man auch über "ctlmgr_ctl" absetzen könnte (der Doppelpunkt wird zum Leerzeichen).

Je nachdem, was für ein "Modus" der ausgewählte "Provider" dann ist (router/bridge/etc.), kann/muß man natürlich den "op_mode" der Box auch ändern. Aber das ist eine Entscheidung anhand des Providers und die von Dir zitierten Einstellungen passen m.E. mehr zu einer Box an einem DSL-Anschluß (opmode_standard und pppoe auf der DSL-Seite) als zu einer an LAN1.

Willst Du am Ende eigentlich eine für Deine Zwecke passende Variante haben oder eher einen Patch für freetz.org ?
Ich frage deshalb, weil man im zweiten Fall vielleicht noch andere Meinungen einholen sollte, wie weit der Patch gehen soll (Providerliste ja/nein).

HabNeFritzbox · 20 Aug 2014

Wenn ihr mit euren Konfigvergleich und so eine konkrete Lücke oder Angriffsszenario habt, meldet es ruhig der Heise Security und AVM.

Entwarnung bei deutschen Providern

Nach der Überprüfung der eigenen Fernwartungs-Server haben deutsche Netzanbieter weitgehend Entwarnung gegeben. So ist die Deutsche Telekom nach eigenen Angaben von der beschriebenen Sicherheitslücke nicht betroffen und verweist hierzu auf die eigenen Sicherheitsstandards. Auch bei Kabel Deutschland gehe man davon aus, nicht betroffen zu sein, da man die genannte Open-Source-Software nicht verwende. Ähnlich verhält es sich bei 1&1, Unity Media und Kabel BW, die am Freitagmittag noch die eigenen Server überprüften.

Quelle: http://www.wbs-law.de/it-recht/sicherheitsluecken-entwarnung-bei-der-fernwartung-55390/

Ansonsten sind die Aussagen in den News wie andiling schon anmerkte was merkwürdig oder schwammig.
Weitgehend = nicht alle
eigene Standards = Irgendwas man sich selbst ausgedacht oder vorgenommen hat
gehe von aus = oder auch nicht, wer weiß es schon, man versteht davon wohl eh nichts

:wiejetzt::gruebel:

PeterPawn · 20 Aug 2014

tl;dr:
Was ist dran an den Behauptungen von AVM im heise.de-Artikel und wo sind die Widersprüche/Beweise in der AVM-Firmware zu finden?
Die einzelnen Aussagen stimmen jeweils für sich betrachtet, der dadurch hervorgerufene Gesamteindruck ist aber irreführend.
So im Tenor: "Wir hören Fr. Merkel zur Zeit nicht ab, sie telefoniert nämlich gerade nicht.".

RalfFriedl schrieb:
Das ist eine seltsame Argumentation von AVM:

Danke, ich kam mir jedenfalls beim Lesen schon vor wie im falschen Film.

So nimmt eine FB natürlich mit einem ACS auch dann Kontakt auf, wenn der kein HTTPS fordert. Das Beispiel KBW hat ja schon jemand genannt, bei KDG sieht es auch nicht anders aus:

http://axs.technik.<domain>:7547/live/CPEManager/CPEs/genericTR69 (geändert, nicht aus Geheimhaltung, nur damit niemand dort klickt)

Dann noch das:

heise.de schrieb:
"So überprüft die Fritzbox standardkonform die Authentizität des ACS mittels Zertifikaten und anhand einer fest eingestellten Liste vertrauenswürdiger Zertifizierungsstellen, ähnlich wie Browser dies beim Online-Banking machen. Nur bei positiver Prüfung wird die Verbindung weiter aufgebaut und dem ACS vertraut. Die Liste vertrauenswürdiger Zertifizierungsstellen kann zur Laufzeit nicht verändert werden."

Bei schon mindestens zwei Providern mit HTTP ohne S beim TR-069 ist es zwar schon fast egal, aber die FB (konkret aktuelle Labor für 7390) enthält z.B. folgende Zertifikate:

Code:

================================
issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
578d5c04
================================
issuer= /O=Arcor AG Co. KG/CN=acs.arcor-ip.de
subject= /O=Arcor AG Co. KG/CN=acs.arcor-ip.de
67440fd9
================================
issuer= /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
subject= /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
98ec67f0
================================
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
415660c1
================================
issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2c543cd1
================================
issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
b204d74a

Da das - mit Ausnahme des Arcor-selfsigned - alles offzielle CAs sind, dürfte es nicht allzu schwer sein, ein Zertifikat zu beantragen, was von einer dieser CAs ausgestellt wurde. Wenn es dann noch zum Namen des eingetragenen ACS-Servers paßt (dazu komme ich gleich noch), sehe ich irgendwie nicht so richtig, wo da der Sicherheitsgewinn der Aussage

heise.de schrieb:
"Der Standard sieht eine starke Authentifizierung des ACS gegenüber dem CPE mittels Zertifikaten vor."

seitens AVM eigentlich liegen soll. Und wie wir gleich sehen werden, ist auch das die volle Wahrheit, der Standard sieht (Seite 12, Abschnitt 2.1, Abbildung 2) wirklich Verschlüsselung per SSL/TLS zwischen der HTTP-Schicht und dem TCP-Stack vor (wir setzen jetzt der Einfachheit halber mal Verschlüsselung und Authentifizierung gleich, da das eine ohne das andere nicht funktionieren wird), gleichzeitig wird das jedoch auf Seite 20 in Abschnitt 3.3 wieder relativiert:

TR-069-Spezifikation schrieb:
The use of SSL/TLS to transport the CPE WAN Management Protocol is RECOMMENDED, although the protocol MAY be used directly over a TCP connection instead.

Da steht dann eben auch, es geht notfalls auch ohne Verschlüsselung. Wenn man AVM nun blind vertrauen will, kann man ja mal für einen Augenblick annehmen, AVM würde das so interpretieren, daß sie (der Client (das CPE) ist schließlich tonangebend beim TR-069) sich auf unverschlüsselte (und damit natürlich automatisch auch nicht über Zertifikate authentifizierte) Verbindungen gar nicht erst einlassen. Wie wir oben schon gesehen haben, ist das offenbar nicht so, zumindest für KabelBW und Kabel Deutschland. Zwar haben wir es hier im Moment mit zwei Kabelanbietern zu tun und dort kann man in gewissen Grenzen sogar von einem abgeschotteten System ausgehen, da DOCSIS-Geräte i.d.R. das TR-069 in einer gesonderten virtuellen Verbindung betreiben, aber das ist in der AVM-Firmware eben nicht nur für Kabelanbieter so eingestellt.

Bei 1und1 (auf die besorgten Anfragen dieser Kunden haben sie wohl reagiert, vermute ich einfach mal) ist das noch etwas anders, da wird über "certificate pinning" die Angriffsfläche - dem Anschein nach - weiter eingeschränkt:

Code:

        ACS_SSL {
                     verify_server = yes;
             trusted_ca_file = "/etc/default/1und1/root_ca.pem";
        }
        Download_SSL {
             verify_server = yes;
             trusted_ca_file = "/etc/default/1und1/root_ca.pem";
        }

Das erfolgt aber auch nur für die Provider 1&1, GMX, M-net (VDSL) und O2. Bei allen anderen gelten die "normalen" CAs im AVM-Zweig.

Warum schreibe ich nun aber: dem Anschein nach ?
Weil dieses Zertifikat-Pinning auch nur Augenwischerei ist. In der Datei /etc/default/1und1/root_ca.pem liegen nämlich genau dieselben Zertifikate wie in der Datei im avm-Zweig. Das heißt dann eben auch wieder, jedes von einer dieser 6 CAs unterschriebene Zertifikat - ich hoffe mal, wenigstens der Name muß wirklich stimmen -> "goto fail;" bei Apple war ja auch keine Absicht - wird für einen ACS akzeptiert von der Box.

Der einzige Provider, bei dem das wohl wirklich so könnte, wie es behauptet wird (Prüfung des CN vorausgesetzt), ist M-net:

Code:

================================
issuer= /C=DE/L=Muenchen/O=M-net Telekommunikations GmbH/OU=Internet Services/CN=CA/[email protected]
subject= /C=DE/L=Muenchen/O=M-net Telekommunikations GmbH/OU=Internet Services/CN=CA/[email protected]
ec346328

Bei der Auswahl dieses Providers (nur die VDSL-Variante, die in der Providerliste einer 7390 weder in der deutschen noch der internationalen Version auftaucht) wird zwar theoretisch für die ACS-Prüfung nur ein einziges CA-Zertifikat zugelassen (s.o), leider ist für dieses jedoch auch noch der Pfad (der Auszug stammt aus der deutschen Version) falsch, denn das Verzeichnis "avme" existiert bei einer deutschen Firmware gar nicht:

Code:

  ACS_SSL {
    verify_server = yes;
    trusted_ca_file = "/etc/default/avme/root_ca_mnet.pem";
  }

Also, sorry AVM, aber da stimmt so einiges hinten und vorne nicht.

Einschub: Da beginnen dann teilweise auch die Schwierigkeiten beim Entfernen eines Brandings. In den Konfigurationsfiles in der providers-0xx.tar wird eben auch bei AVM-Branding das root_ca.pem-File in dem Ordner vom 1und1-Branding gesucht, wenn man 1und1 als Provider wählt. Da ist AVM selbst nicht so ganz sattelfest (s. avme oben) und beim Entfernen eines Brandings (bei O2 gilt ähnliches für den Pfad bei einer 7390) macht man dann eben auch mal die Provider-Konfiguration teilweise kaputt. Nachdem inzwischen eigentlich alle echten "Branding"-Files ohnehin identisch sind, macht das Anwenden des "Remove branding"-Patches in freetz nur noch bedingt Sinn. Bei Packen des SquashFS werden ohnehin alle Dateien per Hash auf doppeltes Auftauchen geprüft und nur einmal wirklich ins Image geschrieben. Wenn man also den "Overhead" durch die Verzeichnisstrukturen ertragen kann, bringt das Entfernen eines Brandings (nicht das Ändern, bitte nicht verwechseln) aus der Firmware nur noch sehr marginale Vorteile.

Wieso dann die (mal angenommene) Sicherheit über die Identität eines kontaktierten Servers automatisch auch zu einer Garantie wird, daß dieser Server nur in der Hand des Providers liegt, begreife ich bei der ganzen AVM-Argumentation nicht wirklich. Es ist sicherlich sehr heroisch, sich mit

heise.de schrieb:
"Zumindest in Deutschland seien diese Auto Configuration Server Teil einer Infrastruktur mit hohen Anforderungen an das Schutzniveau..."

für die Provider in die Breche zu werfen, aber irgendwie erinnert mich das an andere "technisch hohe Standards in D" (wo man in der Schweiz schon mal die Feuerlöscher dranmontiert). Und die hohen Anforderungen mag es ja geben, das heißt aber leider noch lange nicht, daß sie auch erfüllt werden.

Und beim Vortrag von Shahar Tal ging es eben nie um direkt angreifbare CPEs, es ging um angreifbare ACS-Software und wie AVM da für alle in der Firmware mit "Zwangs-TR069" hinterlegten Provider die Hand ins Feuer legen will, ist mir schleierhaft. Der ACS ist in keiner Weise seitens der FRITZ!Box (oder irgendeiner anderen CPE) vor Angriffen geschützt, das muß er schon selbst in die Hand nehmen.

Unter diesem Aspekt ist und bleibt es eine unschöne Angelegenheit (man muß nicht gleich Skandal rufen), wenn AVM das TR-069 quasi "durch die Hintertür" in jedem Falle aktiviert, wenn bestimmte Provider eingestellt werden. Welcher Funktionsumfang sich hinter diesem "Litemode" verbirgt, wird ja auch nicht offen gelegt. Jetzt kommt dann noch die Möglichkeit zum Aktivieren eines ACS-Servers per DHCP-Offer dazu (als neues Feature dokumentiert) und dann haut da so ein blöder Sicherheitsforscher dazwischen ...

Nur mal so zum Spaß - für die, die diese Information ansonsten nicht finden - die in der 7390-Labor hinterlegten ACS-Einstellungen für die Provider:

Code:

1und1 -> https://acs1.online.de/;
1und1_lte -> https://acs1.online.de/;
ewetel_adsl -> http://80.228.251.206/live/CPEManager/CPEs/Auth_Basic/avm;
ewetel_lan1 -> http://80.228.251.206/init/avm;
ewetel_smart -> http://80.228.251.206/init/avm;
ewetel_smart_vdsl -> http://80.228.251.206/init/avm;
ewetel_xdsl -> http://80.228.251.206/live/CPEManager/CPEs/Auth_Basic/avm;
gmx -> https://acs1.online.de/;
htpdsl_adsl -> https://acs.htp-apv.de:7547;
htpdsl_vdsl -> https://acs.htp-apv.de:7547;
htpngn_adsl -> https://acs.htp-apv.de:7547;
htpngn_fiber -> https://acs.htp-apv.de:7547;
htpngn_vdsl -> https://acs.htp-apv.de:7547;
kielnet -> http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm;
kielnet_gf -> http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm;
kielnet_vdsl -> http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm;
mnet_vdsl -> https://acs.mnet-online.de;
netcologne_netaachen_dsl1 -> http://trixi.netcologne.de/initial;
netcologne_netaachen_dsl2 -> http://trixi.netcologne.de/initial;
netcologne_netaachen_vdsl1 -> http://trixi.netcologne.de/initial;
netcologne_netaachen_vdsl2 -> http://trixi.netcologne.de/initial;
o2_7270_native -> https://acs.o2online.dnbbs/tr69;
o2_7570_native -> https://acs.o2online.de/nbbs/tr69;
o2_lte -> https://acs.o2online.de/nbbs/tr69;
otwored -> https://acs.o2online.de/nbbs/tr69;
telefonica -> http://acs.be-converged.com:9675;
telefonica_fttb -> http://acs.be-converged.com:9675;
telefonica_fttx -> http://acs.be-converged.com:9675;
vodafone_bytr069_adsl -> https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt;
vodafone_bytr069_vdsl -> https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt;
vodafone_lte6810 -> https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt;
vodafone_lte6840 -> https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt;
wobcom -> https://autoconf.wobline.de:7547/live/CPEManager/CPEs/genericTR69;

- gesamt: 65 Einträge - ( oma_(w)lan + other(_lte) ) = 61 Provider-Einträge
- davon 33 mit aktiviertem TR-069, die Einstellung wird auch immer wieder aktiviert vom ctlmgr
- bei den 33 Providern dann immerhin 15, die nur eine http-URL für den ACS konfiguriert haben

Da hat die ungenannte Quelle bei AVM ja gerade noch einmal Glück gehabt, daß 18 > 15 ist und man unterstellen darf, die Aussage bezog sich auf AVM-Firmware.

heise.de schrieb:
AVM betont: "In Deutschland verwendet die überwiegende Anzahl der Anbieter HTTPS-verschlüsselte Verbindungen."

Das ist ja wirklich "die überwiegende Anzahl der Anbieter" ... :mrgreen:

Etwas unverschämt wird es dann aber doch, wenn man mal die anderen Einstellungen auch noch überprüft und dann folgendes findet:

Code:

        ACS_SSL {
                verify_server = no;
        }
        Download_SSL {
                verify_server = no;
        }

Ich stelle jetzt einfach mal die Behauptung auf (den Beweis versuche ich hinterher zu erbringen), daß da genau die Identitätsprüfung des ACS-Servers seitens der Box abgeschaltet wird und das gilt wohl für die Provider:

Code:

htpngn_fiber
netcologne_netaachen_(v)dsl(1|2) <- das sind 4 verschiedene Einträge, aber ein Provider
wobcom

Das sind - nach meiner Lesart - schon mal 3 Provider (mit 6 Einträgen, damit auch 6 von 33 der TR-069-Provider von oben = 18%), bei denen eben keine Identität durch die Box geprüft wird, das wäre dann - Beweis meinerseits steht noch aus - eine glatte Lüge seitens AVM (vollst. Zitat weiter oben): "Nur bei positiver Prüfung wird die Verbindung weiter aufgebaut und dem ACS vertraut."
Schon die Möglichkeit, es bei einigen Providern offenbar auszuschalten, setzt ja einen anderen Kenntnisstand bei AVM voraus.
Jenseits von SSL-Verschlüsselung und Authentifizierung mit Zertifikaten gibt es dann bei TR-069 eigentlich nur noch die Übertragung von Dateien vom ACS zum CPE, wo eventuell durch den Einsatz des "Signed Package Formats" noch so etwas wie eine Authentifizierung der Quelle (ACS) anhand der Signatur möglich wäre (Anhang E der Spezifikation). Warum nun aber gerade an dieser Stelle die bis dahin eher "schludrige" Sicherheit auf dieser Basis realisiert sein sollte, kann ich nicht so richtig sehen.

Was man dann von

heise.de schrieb:
Via TR-069 können bei der Fritzbox die meisten Zugangsdaten nur gesetzt werden. Ein Auslesen zum Beispiel von VoIP-Credentials ist nicht möglich.

halten soll, muß jeder selbst einschätzen. Wenn ich aber Erfahrungsberichte von 1&1-Kunden berücksichtige, bei denen der Kundenberater (mit Zustimmung des Kunden, aber die ist eher "pro forma" und nicht ein "Freischalten") auch das kundeneigene WLAN-Kennwort auslesen konnte, dann bin ich persönlich (obwohl nicht betroffen) so skeptisch, daß ich diese Aussage ganz genau lese. Und da steht dann eben "die meisten Zugangsdaten" und beim Nichtauslesen nur "VoIP-Credentials". Angesichts der Tatsache, daß bei den meisten Providern die VoIP-Credentials auch von diesen selbst bereitgestellt werden, bin ich sogar bereit, das zu glauben ... es macht ja keinen Sinn, da irgendwelche Daten abzuholen, die man selbst hinterlegt hat.
Hinsichtlich anderer Daten beruhigt mich das aber keineswegs ... TR-069 sieht jedenfalls explizit den Upload von Dateien von einem CPE zum ACS vor und welche Dateien AVM da in Betracht zieht für eine Übermittlung zum Provider, kann man nur raten.

Was ich unbesehen glaube, ist die Behauptung, daß man der Box über TR-069 kein unsigniertes Firmware-Image unterjubeln kann, bei einem Fernwartungsaccount bin ich mir da schon nicht mehr sicher und mit dem geht dann sicherlich noch einiges mehr für einen Angreifer.

Auch die Geschäftbedingungen einiger Anbieter legen eigentlich eine andere Lesart nahe, wenn dort dann steht, der Anbieter darf die Einstellungen des Kunden auslesen, ändern und zurückspielen, wenn dieser seine Zustimmung erteilt. Da stellt sich mir dann die Frage, mit welchen übernatürlichen Kräften die Kundendienst-Mitarbeiter der Anbieter ausgestattet sein müssen, wenn ihnen das ohne das Auslesen der Einstellungen des Kunden über die AVM-Firmware gelingt.

Egal, nachdem jetzt das Zuweisen eines ACS auch per DHCP funktionieren soll, werde ich das einfach einmal probieren mit einer Box an LAN1 (das müßte - wie hinter einem Kabelmodem auch - ja funktionieren ) und dann schaue ich mir einmal genau an, was die Box da so von sich aus mitteilt. Einige ACS-Implementierungen sind ja frei verfügbar, für eine Basisanalyse sollte das ausreichend sein. Dabei teste ich dann auch die verschiedenen ACS_SSL-Einstellungen mal mit, damit die oben von mir aufgestellte Behauptung bestätigt oder widerlegt werden kann.

andiling · 21 Aug 2014

Leute, ich lese hier ganz eifrig mit, mangels eigener Erfahrung kann ich hier nicht viel zu beitragen, aber bei mir stellt sich die Frage, welcher Schaden hier eigentlich konkret verrichtet werden kann?!?!? (und ich will das Problem nicht verharmlosen, ich sehe es, verstehe es aber nicht vollständig)

TR-069 eignet sich zum Provisioning und um Updates anzustoßen.

Ersteres sollte ja ohne Relevanz sein, denn wer die Zugangsdaten haben will und den ACS-Server bereits gehackt hat, braucht nicht mehr an die Box ran. Trotzdem: kann nur konfiguriert oder auch ausgelesen werden? (können z.B. anbieterfremde Konten im Klartext gelesen werden?)

Dass man eine kompromittierte Firmware einspielen kann, leuchtet mir ein. Nur könnte man dieser Möglichkeit entgegnen, indem die Images signiert werden und z.B. nicht freigegebene Software angestossen über TR-069 gar nicht erst installiert werden kann. Da wäre der Hardwarehersteller auch in der Pflicht, das zu unterbinden. Würde man bei der Fritzbox überhaupt eine manipulierte Firmware ohne explizite Bestätigung installiert bekommen?

Ansonsten sollte doch TR-069 keinen Zugriff aufs Dateisystem oder gar auf persönliche Dateien gewähren, oder?

Danke im Voraus!

koyaanisqatsi · 21 Aug 2014

Naja, den Hackern wird es darum gehen was technisch möglich ist.
Nicht, was sich ethisch/moralisch verbietet.

Und: Selbst die Wikipedia reiht TR-069 in folgende Kategorie ein...
Kategorien: Internet-AnwendungsprotokollHTTPSicherheitslücke
...und verweist auch auf den Heise Artikel.

Def Con 22: Millionen DSL-Router durch TR-069-Fernwartung kompromittierbar

Neuer User

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Aktives Mitglied

vanButen

Guest

IPPF-Urgestein

IPPF-Urgestein

HabNeFritzbox

Guest

IPPF-Urgestein

IPPF-Urgestein

HabNeFritzbox

Guest

IPPF-Urgestein

IPPF-Promi

Aktives Mitglied

IPPF-Urgestein

HabNeFritzbox

Guest

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

Statistik des Forums