- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,283
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Um es gleich am Anfang festzuhalten:
Was ist eigentlich TR-069?
TR-069 ist erst einmal nicht anderes als ein Standard, um Geräte aus der Ferne zu konfigurieren. Die aktuelle Fassung des Standards ist hier zu finden, die grundlegenden Funktionen sind aber schon mehrere Jahre weitgehend unverändert festgeschrieben. Auf der "Providerseite" erfolgt die Kommunikation über den "Automatic Configuration Server" (ACS) und die Technik auf der Kundenseite wird als "Customer Premises Equipment" (CPE, in Deutsche übersetzt ungefähr als "Technik auf dem Grundstück bzw. in den Räumen des Kunden") bezeichnet. Diese Abkürzungen werde ich in der Folge nutzen, sie ersparen langwierige Umschreibungen. Es gibt zwar auch andere - ähnlich gelagerte - "Technical Reports", in denen dann auch die Konfiguration weiterer Geräte hinter dem CPE definiert wird, aber der eigentliche TR-069-Standard beschäftigt sich nur mit dem "CPE WAN Management Protocol" (CWMP) und damit mit der Kommunikation eines "Internet Gateway Device" (IGD) mit dem ACS (s. Abbildung 1 in der TR-069-Spezifikation). Wenn sich jemand schon einmal mit TR-069 (oder auch TR-064) befaßt hat, wird er hier einige Abkürzungen wiedererkennen, die ihm z.B. als "CWMP-Account" einer FRITZ!Box oder als "Typ" für eine im Netzwerk gefundene FRITZ!Box (IGD) wahrscheinlich schon einmal begegnet sind.
Im Wesentlichen definiert der Standard folgende Operationen:
Welche Einstellungen damit konkret gesetzt und/oder abgefragt werden können und welche Daten/Dateien woher und wohin übertragen werden können, läßt der Standard genauso offen (oder definiert es als "optional"), wie die Sicherung einer Verbindung zwischen ACS und CPE über TLS, was in der Folge ja unmittelbar auch Auswirkungen auf die sichere Feststellung der Identität der jeweiligen Gegenstelle hat. Der Standard definiert zwar im Abschnitt "2.2 Security Mechanisms" eine mögliche Absicherung der Kommunikation mit TLS ("[...] is designed to allow a high degree of security [...]), er fordert sie aber nicht (z.B. "[...] is designed to ensure a high [...]") und bietet im zweiten Spiegelstrich (HTTP-Layer) zwar eine Authentifizierung über "shared secrets" an, erzwingt diese aber auch nicht.
Damit zielt die Aussage von AVM (diese ist für mich "weiblich", einmal als "Firma" und einmal als "Gesellschaft mbH") in ihrem Artikel
Hält denn AVM nun die oben gegebene Garantie auch tatsächlich ein?
Dazu genügt schon ein Blick in die Firmware, was bei einer "normalen" FRITZ!Box über den Telnet-Zugang ja jedem Kunden auch möglich ist. Es gibt dort eine Datei, die beim Einstellen eines Anbieters im HTTP-basierten Konfigurationsinterface einer FRITZ!Box (ab jetzt "Graphical User Interface" - GUI) zu Rate gezogen wird und für die angebotenen Provider u.a. auch die Angaben zur Verwendung von TR-069 und die dazu notwendigen Einstellungen (in erster Linie die URL des ACS) enthält. Ein Blick in diese Datei (bei einer FRITZ!Box 7490 mit Firmware-Version 06.23, diese Datei ist aber nahezu identisch bei fast jeder derzeit verfügbaren Firmware) offenbart dann dieses:
Noch schnell eine Gegenprobe, ob das nicht immer so ist bei der Angabe einer URL:
Nein, offenbar wird da tatsächlich (auch von mir so getestet, das ist hier nur Show, um es zu verdeutlichen) zwischen verschlüsselten und unverschlüsselten CWMP-Verbindungen unterschieden und eine "Garantie" kann AVM schon deshalb nicht geben, weil man (sei es der Provider oder der Kunde) offensichtlich auch - entgegen der oben zitierten Behauptung - eine ungeschützte Kommunikation benutzen könnte und es offenbar in einigen Fällen auch tut und zwar mit dem Wissen von AVM, denn die ungesicherten URLs sind in einer originalen AVM-Firmware enthalten. Der Fakt, daß bei einer ungesicherten Verbindung dann auch keine Echtheit des Servers mehr geprüft werden kann, verleiht dem dritten Satz zwar wieder eine "besondere Note", aber ich nehme einfach mal zugunsten des Autoren/der Autorin/der Autoren/der Autorinnen/der Autoren und Autorinnen/der Autorinnen und Autoren (habe ich eine Kombination unterschlagen?) an, daß sich dieser Satz 3 auf den Inhalt von Satz 2 beziehen soll und man damit keinesfalls noch einmal den Eindruck erwecken wollte, die TR-069-Kommunikation der FRITZ!Box wäre grundsätzlich so sicher wie Online-Banking.
Ob man das im Satz 1 nun als "Lüge" bezeichnen will oder als "gezielte Desinformation" oder als "unklare Ausdrucksweise", davon muß sich jeder selbst ein Bild machen. Ich verbuche das aber mal unter "Lüge 1", denn auch eine "versehentliche falsche Angabe" bleibt falsch und die sehr subtilen Formulierungen in den anderen Sätzen dieses Absatzes legen (wenn man mal den schweren Grammatikfehler nicht betrachtet) eigentlich eine entsprechend sorgfältige Planung dessen, was da gesagt/geschrieben werden sollte, nahe. Diese - jedenfalls für mein Empfinden - sorgfältigen Formulierungen, die immer haarscharf am technischen Sachverhalt vorbei gehen und doch nie als "komplett gelogen" entlarvt werden können, finden sich auch noch an diversen anderen Stellen:
Noch ein Beispiel?
Es fehlt eigentlich nur das Wort "ausschließlich" zwischen "der Provider" und "die ursprünglichen" und ich würde tatsächlich (mit einigen Abstrichen, die ich noch erläutern werde) Applaus spenden, weil alle diese Punkte zweifellos eine (unter bestimmten Randbedingungen) sinnvolle Anwendung von TR-069 sind.
Wenn dann auch noch alles nur im Sinne des Anwenders ist (natürlich nimmt jeder Leser an, er selbst wäre auch tatsächlich der Kunde, was bei den über Provider vertriebenen FRITZ!Boxen wohl AVM auch etwas anders sieht, aber sie schreiben ja auch von Anwender, ich in der Regel von Benutzer), dann wäre man ja offensichtlich verrückt, wenn man diese Chancen nicht nutzen würde.
Wenn das "bei weniger technikaffinen Nutzern" auch noch erfolgt, ohne diese damit behelligen zu müssen, dann ist ja alles gut.
Oder vielleicht ist ja doch nicht alles so rosarot, besonders dann, wenn der Anwender davon gar nichts bemerkt (ggf. nicht einmal bemerken kann)?
Um das noch einmal aufzudröseln, hier werden folgende Funktionen der TR-069-Implementierung beschrieben:
Das ist für unbedarfte (von AVM etwas weniger drastisch als "weniger technikaffine Nutzer" bezeichnete) Anwender vielleicht wirklich erforderlich, nach meiner Einschätzung sollte sich das dann aber auch auf diese Aufgaben und auf diese Zielgruppe beschränken.
Gerade die Möglichkeit, aus der Ferne auch ein "FactoryReset" auszulösen, hat schon bei einigen Kunden von Kabel Deutschland für heftigen Ärger gesorgt und meiner Meinung nach auch bei vielen anderen Providern. Der einzige Provider, den ich kenne und der höflicherweise wenigstens den Kunden um seine Zustimmung zum Zugriff auf den Router des Kunden bittet (oder zumindest bat, als ich da noch mit zu tun hatte), ist 1&1.
Kabel Deutschland mißinterpretiert absichtlich jede Supportanfrage des Kunden mit Bezug auf die FRITZ!Box als implizite Zustimmung zur eigenständigen "Behebung" durch KDG-Techniker und dazu gehört offenbar immer ein "FactoryReset", unabhängig davon, ob es theoretisch überhaupt möglich wäre, daß ein solches Vorgehen tatsächlich hilft. Dort hilft dann nicht einmal der vorher ausdrücklich (schriftlich) geäußerte Widerspruch gegen ein "FactoryReset", die Einstellungen des Kunden werden einfach kommentarlos gelöscht und wie er sie wieder in die Box bekommt, soll er gefälligst selbst sehen.
Hier sehe ich AVM tatsächlich in der (zumindest moralischen) Pflicht, dem Kunden eine eigene Möglichkeit zu verschaffen, sich gegen solche Eingriffe zu verwahren (das wäre bei der erfolgreichen Abschaltung von TR-069 ja auch der Fall), aber da ist dann ein Satz wie
Auch wenn sich Mietgeräte im Eigentum des Anbieters befinden mögen, ist der tatsächliche Besitz (d.h. die "tatsächliche Herrschaft über die Sache") - zumindest für mich - der entscheidende Punkt in dieser Angelegenheit und AVM unterstützt hier die regelmäßige Mißachtung der Arbeit des Anwenders (die momentane Konfiguration der FRITZ!Box, die ja weit mehr enthalten kann, als der Provider seinerseits konfiguriert hat). Wenn man so etwas unbedingt machen will, dann muß man eben eine Trennung der Einstellungen des Anwenders von denen des Providers vornehmen und dem Provider nur noch die Möglichkeit einräumen, auch seine eigenen Einstellungen zu löschen.
Das wäre für mich tatsächliche "Anwenderorientierung", so ist es eher eine Art perverse "Kundenorientierung", denn offenbar ist AVM dabei der Kunde Provider wesentlich wichtiger als der Anwender und Besitzer.
Selbst wenn man TR-069 nicht abschaltbar macht, könnte man immer noch das tatsächliche "FactoryReset" von einer Handlung des Besitzers abhängig machen. Zum Beispiel könnte nach einem providerseitigen Request für das Zurücksetzen auf Werkseinstellungen eine FRITZ!Box erst einmal ihrerseits mit einer rot blinkenden Info-LED ein solches Ansinnen signalisieren und der Kunde muß das dann innerhalb einer bestimmten Zeit durch das Drücken eines Buttons an der FRITZ!Box auch genehmigen.
Damit wäre beiden Seiten (dem Provider und dessen Kunden) geholfen, denn die wenigsten Kunden werden sich bei einer Fehlermeldung an den Provider nicht vor Ort befinden und wenn der Provider seinerseits in seiner Technik eine "asynchrone Abarbeitung" durchführt, dann muß eben der Kunde vom Techniker angerufen werden. Das würde dann sicherlich auch das Rücksetzen "auf Verdacht" signifikant ausdünnen.
Wenn man es auf die Spitze treiben will, baut man eine - dann auch wirklich immer verfügbare und wirksame - Einstellung "Support-Zugriff nur mit Zustimmung des Kunden" ein, damit auch die Kunden "bedient" werden können, bei denen die Sicherheit des Routers und der "Gluteus maximus" keine Beziehung haben, die man im geometrischen Sinne als "tangential" bezeichnen würde.
Bei einem Mietgerät ist das jedenfalls regelmäßig auch ein Eingriff in die tatsächliche Beschaffenheit der Mietsache (und den Gebrauchswert für den Besitzer) und das ist zumindest bei Kabel Deutschland (bei "vermieteten" Geräten, d.h. wenn ein Aufpreis für das Gerät verlangt wird) in den mir vorliegenden neuen AGB/BGB (hier zu finden) inzwischen tatsächlich so geregelt, daß sich KDG dort das Recht einräumt (das war früher noch anders formuliert) "die Konfigurationsdaten und die Betriebssoftware herunterzuladen und zu verändern, um den Dienst für den Kunden wiederherzustellen".
Die Einschränkung "Dabei werden die Konfigurationsdaten des Kunden nur insofern erfasst, wie es zur Wiederherstellung der ursprünglichen Konfiguration notwendig ist." kann man nun wieder unterschiedlich interpretieren (was ist denn die "ursprüngliche Konfiguration", die des Kunden oder die des Providers - sprich FactoryReset + Provisionierung über den ACS - und warum muß man für das Wiederherstellen der Providerkonfiguration die Konfiguration des Kunden herunterladen, wenn doch der Provider alle notwendigen Angaben selbst haben sollte), ob man sie tatsächlich glaubhaft findet, muß wieder jeder selbst entscheiden. Ich komme gleich dazu, was da wohl tatsächlich passiert oder passieren könnte bei einer FRITZ!Box.
Die angesprochene Beschränkung auf die Zielgruppe soll jedenfalls offenbar über die im AVM-Artikel unter
Mir würde es inzwischen schon reichen, wenn AVM in diesem Punkt eigentlich nicht meint, in FRITZ!OS 06.20 ließe sich TR-069 komplett abschalten (nebenbei gefragt, was ist eigentlich bei den anderen FRITZ!Boxen, für die es keine 06.20-Firmware gibt, wie zum Beispiel die "Homebox 1" von Kabel Deutschland?), sondern wenn da die Rede von ab oder seit wäre und man somit auch für künftige Versionen davon ausgehen könnte, daß sich TR-069 tatsächlich über die entsprechenden Einstellungen abschalten läßt und die Firmware nie wieder "nur so tut".
In diesen Kontext fällt dann auch das Starren auf den "offenen Port" für TR-069, das einige Anwender immer wieder befällt. Ob dieser Port nun offen ist oder nicht, spielt nur dann eine Rolle, wenn der ACS seinerseits das CPE zu einer Kontaktaufnahme auffordern will. Für sämtliche vom CPE selbst ausgehenden TR-069-Aktionen ist dieser Port vollkommen uninteressant, wenn ein Provider "etwas Geduld hat", kann er TR-069 auch ohne diesen offenen Port - mit genau denselben Gefährdungen wie mit offenem Port - betreiben. Der Port ist zwar ein ziemlich sicheres Anzeichen für aktiviertes TR-069, aber auch wenn er geschlossen ist, ist das noch lange kein Beweis für die tatsächliche Abschaltung von TR-069.
Da sogar die Adresse mindestens eines ACS (des von 1&1 - als "https://acs1.online.de" u.a. in 'ctlmgr' vorhanden, der auch das Auspacken der erwähnten Provider-Datenbank übernimmt) direkt in der Firmware hinterlegt ist, kann man eigentlich nicht einmal aus einer fehlenden URL für den ACS mit letzter Sicherheit darauf schließen, daß da tatsächlich "nichts läuft", das kann nur ein Packetdump (dann möglichst auch noch auf einem unabhängigen Gerät wie einem vorgeschalteten DSL-Modem) halbwegs verläßlich klären.
Wenn der Anwender etwas Pech hat, wurde nur der offensichtliche "litemode" in eine etwas weniger auffällige Form gebracht, die man von außen - eben ohne Packetdump, ich habe nur keinen 1&1-Anschluß, um das mal selbst zu verifizieren oder zu falsifizieren - nicht mehr ohne weiteres feststellen kann. Wobei das sicherlich in das Reich der Spekulation abdriftet, aber die Frage stelle ich mir schon, warum da der ACS direkt in der binären Firmware hinterlegt ist (das ist auch nicht vom Branding abhängig, der ctlmgr ist immer derselbe) und nicht wie bei anderen Providern entsprechend konfiguriert wird. Diese Sonderbehandlung erscheint mir schon etwas merkwürdig.
Zur Beschränkung auf die aufgeführten Aufgaben/Möglichkeiten von TR-069, wenn es der Anwender doch lieber eingeschaltet läßt, komme ich gleich, vorher fügt AVM den implementierten Möglichkeiten ja peu a peu weitere "Anwendungsfälle" hinzu:
Zu 3. stellt sich mir dann nur noch die Frage, warum AVM auch auf Nachfrage keine Informationen dazu (an Anwender, was bei einer im Einzelhandel erworbenen Box aber auch der Kunde sein sollte) herausgeben will, entsprechende E-Mails wurden (zumindest bei meiner Anfrage) nicht einmal einer Antwort gewürdigt. Vielleicht ist der genaue Umfang der Möglichkeiten über TR-069 AVM so peinlich, daß man lieber keine Diskussion darüber ermöglichen will und sich eher auf "Betriebsgeheimnisse" herausredet. Da bleibt also nur die eigene Recherche, die machen wir gleich gemeinsam.
Zu 2. und dem tatsächlichen Umfang der Logdateien kann man eigentlich nur Vermutungen anstellen, sollte es sich um die bekannten "Support-Daten" handeln, stehen auch da genug - ggf. auch private - Informationen drin, die ich persönlich meinem Provider nicht mitteilen will. Wenn es andere "Logdateien" sein sollten, stellt sich mir wieder die Frage, wo und wie die in der Firmware zusammengetragen werden. Das hinterfragen wir aber erst fast am Schluß noch einmal ...
Die oberflächliche Maskierung von Kennwörtern als "SECRET" in diesen Support-Daten kann auch nicht darüber hinwegtäuschen, daß dort z.B. auch die intern vorhandenen Clients mit zusätzlichen Informationen aufgelistet sind - von vielleicht eingerichteten "geheimen" Port-Forwardings auf solche Geräte ganz zu schweigen, auch wenn jeder selbst Schuld ist, wenn so etwas nicht zusätzlich gesichert wird und die Kenntnis des Ports schon ausreicht für einen Angriff oder sogar einen Mißbrauch.
Das ist auch nur ein Beispiel, über den Umfang der Support-Daten und die dort offengelegten Informationen (hat schon mal jemand erlebt, daß AVM einen Support-Fall mit technischem Hintergrund ohne - oder mit entsprechend manuell nachbearbeiteten - Support-Daten bearbeitet?) kann man problemlos noch einem weiteren Artikel verfassen.
In keinem Fall würde ich als Kunde jedenfalls wollen (auch nicht als Kunde "bei Anbietern, die FRITZ!Box als Mietgerät zur Verfügung stellen", wie AVM es formuliert), daß der Provider auch gegen meinen Willen Zugriff auf diese Informationen hat.
Aber dafür hat ja AVM schließlich auch Vorsorge getroffen und erklärt uns das auch:
Nun ist es gar nicht so einfach, diese Einstellungen tatsächlich zu Gesicht zu bekommen, wenn man kein Kunde bei so einem Provider ist. Ich habe dazu eine FRITZ!Box 7490 (Branding AVM) mit FRITZ!OS 06.23 an einem Telekom-Business-Anschluß verwendet und da muß man erst einmal ein paar Vorbereitungen treffen. Dazu braucht es zwei "Patches", die mit folgenden "Diff-File" beschrieben sind:
Wie ein geübter Lua-Programmierer und/oder FRITZ!OS-"Analysierer" schnell sieht, müssen schon einige Hürden genommen werden (Expertenansicht ohnehin vorausgesetzt), bis eine Box auch mal die TR-069-Einstellungen anzeigen will, als da wären:
Egal, weiter im eigentlichen Thema ... will man nun die etwas störrischen TR-069-Einstellungen doch mal angezeigt bekommen, führt man die folgenden Kommandos aus:
aus und wendet den oben angegebenen Patch auf die kopierten Dateien an. Wenn man kein "patch"-Kommando auf der Box hat (die AVM-Busybox enthält es meines Wissens nicht), kann man die wenigen erforderlichen Änderungen ja auch mit einem Editor vornehmen.
Das Ergebnis unterscheidet sich nur marginal von der Anzeige einer "originalen" Firmware mit aktiviertem (oder besser deaktiviertem) TR-069 und ist ausreichend genau, um es als Grundlage der weiteren Betrachtungen zu verwenden, auch wenn es nur durch Manipulation der Firmware zur Anzeige gelangte.
Somit erhält man dann immer die zusätzliche Anzeige der "Anbieterdienste", die bei mir dann so aussieht:
Anhang anzeigen 81691
Ich weiß ja nicht, wie es anderen geht, aber aus dem Text
Von den weiteren Möglichkeiten (da geht es noch gar nicht um Firmware-Updates), die AVM auf der Webseite dann noch "eingesteht", steht da irgendwie nichts oder ich finde es nur nicht.
Die Aussage
Ansonsten sieht das für mich wieder wie das schamhafte Verschweigen der Tatsache aus, daß eine FRITZ!OS-Version auch mal Fehler enthalten kann (sogar richtig kritische, wie wir inzwischen wissen) und daß dann ein Update seitens des Providers wünschenswert ist, wenn der Kunde sich nicht selbst kümmert. Dieses als "Verbesserung des Dienstangebots" zu verbrämen, ist für mein Empfinden schon etwas kühn.
Die dritte Einstellung (DHCP-Option 43) dürfte nur den wenigsten überhaupt etwas sagen, sie dient eigentlich nur zur Deaktivierung einer Lücke, bei der der ACS des Providers über ein zusätzliches Datenfeld in einer DHCP-Antwort gesetzt werden kann und das ist spätestens dann riskant, wenn der Provider diesen DHCP-Server nicht selbst betreibt. Über diese Option kann selbstverständlich auch die unverschlüsselte Kommunikation mit einem falschen ACS konfiguriert werden, der Angreifer müßte nur das (unverschlüsselte) DHCP-Paket mit der Antwort abfangen und entsprechend modifizieren. Ob so ein Angriff tatsächlich einmal stattgefunden hat, kann man nur raten ... diese Option ist jedenfalls noch nicht allzu alt.
Damit bleiben für mich bei einem "normalen" Anwender eigentlich nur noch zwei TR-069-spezifische Einstellungen im GUI übrig, diese beschreibt AVM mit
Viel bemerkenswerter finde ich es, daß es eben gerade keine Möglichkeit gibt, die möglichen Zugriffe (wenn man das abschaltbare Firmware-Update mal an dieser Stelle nicht allzu sehr in den Vordergrund rückt, es ist quasi nur ein Nebenkriegsschauplatz) durch den Provider in irgendeiner Form auf bestimmte Funktionen (meinetwegen "Fernkonfiguration" oder "Neustart" oder "Werkseinstellungen") zu beschränken. Wenn man TR-069 einschaltet (oder erst gar nicht vor diese Entscheidung gestellt wird, weil der Dienstanbieter sie für den Anwender trifft), dann nur alles oder nichts, eine Einstellung in mehreren Stufen ist das für mich eher nicht.
Aber auch das ist ja kein Problem, denn AVM hat uns ja ausdrücklich versichert:
Was uns AVM mit der Formulierung "in FRITZ!Box ist" am Ende sagen will, frage ich lieber gar nicht erst.
Was ist denn da nun tatsächlich dran?
Wir wagen mal einen Blick in die Firmware (alles folgende ist aus der 113.06.23) und schauen uns als erstes das Kommando "tr069fwupdate" an, das sich in /usr/sbin befindet.
Nun, die Warnung ist deutlich, wenn auch etwas verwirrend (packet und nicht tr069fwupdate), aber wir sind einmal mutig und ignorieren sie einfach.
Die erste Frage, die sich nun anschließt: Was könnte denn dieses Programm nun veranlassen, etwas mehr als nur diesen Text auszugeben? Dazu schauen wir einfach einmal in dieses Programm "hinein", am einfachsten funktioniert das mit einem Programm, das die dort enthaltenen Zeichenketten ausfiltert, dann müssen wir uns erst einmal nicht mit einem Hex-Viewer oder -Editor quälen.
Das Kommando dazu wäre "strings <dateiname>" und dessen Ausgabe sieht dann - auszugsweise, uninteressante Stellen habe ich ohne Kennzeichnung ausgelassen - so aus, ich habe einige Erklärungen (so wie ich sie mir vorstelle) hinzugefügt:
Das legt die Vermutung nahe, das Tool könnte einen Parameter "configexport" unterstützen.
Die Möglichkeit des Konfigurierens über USB hatten wir bereits an anderer Stelle (wofür ist ein USB-Stick an einer FRITZ!Box noch zu gebrauchen?) und die lasse ich hier mal außen vor.
Wenn ein Provider auch eine VPN-Verbindung importieren können sollte, ist das zwar etwas überraschend, aber ich kann mir tatsächlich Konfigurationen vorstellen, wo das Sinn machen würde. Die Frage bleibt, warum AVM das verschweigt, denn die Firmware identifiziert ja VPN-Verbindungen anhand des Namens und so könnte ein Import einer VPN-Verbindung ja eine vorhandene überschreiben, einerseits versehentlich, notfalls aber sogar gezielt.
Aber dazu müßte man über TR-069 ja erst einmal ermitteln, welche Verbindungen da überhaupt konfiguriert sind. Das wird ja nicht so einfach sein ... halt mal, steht nicht auch etwas dazu in den Support-Daten? Ein Glück, daß da der Provider niemals herankommen könnte, denn der hat ja nur Zugriff auf "Logdateien".
Vielleicht ist ein Import einer VPN-Verbindung ja auch gar nicht erst vorgesehen und ich sehe hier "rosa Elefanten", weil ich etwas Falsches geraucht habe? "vpn_config" muß ja noch lange nichts mit "vpn" und "config" zu tun haben, das kann ja auch etwas vollkommen anderes sein und wie sollte so eine Konfigurationsdatei überhaupt auf die FRITZ!Box kommen?
Ganz einfach, das steht auch in "tr069fwupdate":
Mit diesen Kommandos werden jeweils paarweise (einmal mit, einmal ohne zusätzliche Angabe von Credentials für den Download) die Dateien für verschiedene Zwecke (VPN, Firmware-Update und Konfigurationsimport) aus dem Netz geladen, einmal über eine unverschlüsselte Verbindung (bei Verwendung von "wget") und einmal über eine verschlüsselte Verbindung.
Wenn bei einem Download über eine verschlüsselte Verbindung tatsächlich die Identität des Servers geprüft werden sollte, würde mich das schon sehr verblüffen. Das "httpsdl"-Kommando kennt jedenfalls diese Parameter:
und wenn sich die Optionen "-v" oder "-t" nicht in dem ersten "%s" beim Download ohne Credentials verstecken sollten, sehe ich da nichts Passendes stehen.
Ich weiß auch nicht, wieviele Leute schon mal ihre eigenen Dateien über FTP oder HTTPS auf die Box übertragen haben, jedenfalls in der hier anzunehmenden Form der Angabe einer URL/Adresse für einen Download. Wir reden hier nicht über einen formularbasierten Upload mit einem Browser, die gezeigten Kommandos können verwendet werden, um solche Dateien von einer beliebigen Internet-Präsenz zu laden (wenn eine Internetverbindung besteht, aber das nehmen wir mal an, sonst kommt auch der Provider nicht rein).
Bei Firmware-Updates und Konfigurationen (dazu gleich) ist das vielleicht nur wenig überraschend, man könnte es tatsächlich aus den Texten im AVM-GUI schlußfolgern, auch wenn es da nicht steht und die Simplizität dieser Vorgänge (eigentlich reden wir ja über TR-069) schon etwas überrascht.
Aber daß so ein Download auch tatsächlich für eine VPN-Konfiguration vorgesehen ist, dürfte sicherlich einige überraschen, denn gemeinhin gilt nun mal eine VPN-Verbindung ja gerade als ein Mittel, den Verkehr durch das Netz des Providers zu verschlüsseln, damit dieser (und andere) nicht mitlesen können.
Wenn nun jemand den VPN-Verkehr auf einen Proxy umleitet (dafür braucht er nicht einmal zwingend einen Zugriff auf die Gegenseite, nur eine Kenntnis der VPN-Einstellungen), kriegt der Anwender davon am Ende gar nichts mit. Ob das tatsächlich jedem Anwender bei der "Freischaltung" von TR-069 für den Provider in der Konsequenz bewußt ist? Ich habe da so meine Zweifel.
Aber wir haben ja noch die Versicherung von AVM, daß es vollkommen unmöglich ist, über TR-069 an irgendwelche gespeicherten Zugangsdaten zu gelangen. Die Möglichkeit, daß der Provider tatsächlich Zugriff auf dieselben Support-Daten wie der Anwender hat und daß AVM das mit "Logdateien" meinen könnte, ist ja nur eine Annahme meinerseits und selbst dort sind die "geheimen" Daten ja als SECRET getarnt. Also alles halb so wild ... was soll die "Panikmache".
Wir waren ja bei den Möglichkeiten, die das Programm "tr069fwupdate" so zu bieten hat. Nun ist es ja eher unwahrscheinlich, daß vom Provider wirklich eine komplette Zeile mit einem Aufruf von "tr069fwupdate" übermittelt wird, wenn das zu irgendwelchen Aktionen benutzt werden soll.
Also ist es nur logisch, daß es wohl irgendwo in der Firmware eine oder mehrere andere Stellen geben muß, wo dieses Programm aufgerufen wird. Suchen wir doch einmal danach ... ich habe es der Einfachheit und der Geschwindigkeit halber nicht auf einer FRITZ!Box gemacht (ein "grep -r", das über "/proc" laufen soll, geht in der Box ohnehin schief), sondern mit einer ausgepackten Firmware, wie sie u.a. beim Erstellen eines Freetz-Images auf dem Build-Host vorliegt:
Wir haben also - wenig überraschend - das Programm selbst, den ctlmgr mit ein paar seiner Bibliotheken/Plugins (in /usr/shar/ctlmgr) und das Update für die DECT-Firmware (einmal vom USB-Stick und einmal aus dem Netz), wo bei der Syntax dann auch klar wird, daß das vorhin erwähnte "packet" gar nicht der Programmname sein sollte, sondern auch ein möglicher Parameter.
Offenbar kann man das Tool auch benutzen, um Dateien von irgendwelchen Adressen im Internet auf eine FRITZ!Box zu übertragen ... was es am Ende mehr kann als "wget" (vielleicht die automatische Auswahl von httpsdl, wenn die URL mit HTTPS beginnt?), ist für uns erst einmal egal.
Wie sehen denn solche Aufrufe an anderen Stellen nun tatsächlich aus, bisher wissen wir ja nur, daß sie überhaupt vorhanden sein könnten.
Ok, die erste Zeile merken wir uns mal, das könnte ja etwas werden ... wie sieht es denn an anderen Stellen aus?
Ok, das sind nun zwei der o.a. Parameter, geht da noch mehr?
Das wären dann schon 4 von 5 Aufrufen, nur "vpn_config" war noch nicht dabei, dafür haben wir "packet" dazugelernt. Aber alles bisherige (gerade das letzte) hatte ja auch nur am Rande mit TR-069 zu tun, wenn man den Dateinamen irgendeine Bedeutung beimessen will. Wie sieht es denn nun im "Arbeitspferd" des TR-069 aus?
Siehe da, hier treffen wir auf Bekanntes und bisher eher noch Unbekanntes.
"configimport" ist wenig überraschend, wir haben es in libtr069.so ohne Parameter (das ist das "%s" dahinter in libtr064.so, wobei die Anführungszeichen unsere Aufmerksamkeit verdienen) und in libtr064.so eben mit.
"configexport" finden wir nur in libtr069.so, einmal mit und einmal ohne Parameter, auch hier ist das Einschließen von '%s' in Hochkommata auffällig, die Ausgabe erfolgt offenbar auf stdout, daher die Umleitungen beim Aufruf.
Dann fangen wir doch erst einmal mit dem Test der Variante ohne Parameter an, dazu müssen wir zurück auf die FRITZ!Box (das "more" zeigt die Ausgabe seitenweise an, sie ist ansonsten recht lang, auch für einen Scrollback-Buffer eines Terminals):
Irgendwie kommt mir das - mit Ausnahme der ersten drei Zeilen - ziemlich bekannt vor. :gruebel:
Eine über das GUI exportierte Einstellungssicherung sieht ja genauso aus. Nun könnte es auch sein, daß dieser Export über das GUI in Wirklichkeit genau durch den internen Aufruf dieses "tr069fwupdate" ausgeführt wird und ich mich da nur zu sehr auf den Namen versteife. Das läßt sich ja leicht ermitteln:
Wenn jetzt beim Export der Einstellungen intern das "tr069fwupdate" tatsächlich aufgerufen wird, sollte ein Export über das GUI nun eigentlich nicht mehr funktionieren.
Das macht er aber weiterhin, selbst wenn man "tr069fwupdate" in der Firmware von Beginn an durch einen Dummy ersetzt, klappt der Export weiterhin. Diese Funktion kann also eigentlich nichts mit der im GUI zu tun haben, außer daß sie beide am Ende dasselbe Format verwenden.
Wofür könnte aber dann dieser zusätzliche Parameter, der offenbar durch das %s in einigen Fällen noch entsteht, dienen? Es ist ganz simpel die Möglichkeit, auch hier eine Export-Datei mit einem eigenen Kennwort zu erzeugen.
Das erklärt auch die Anführungszeichen bzw. Hochkommata um diesen Parameter, denn ein solches Kennwort könnte ja seinerseits auch ein Leerzeichen enthalten und das würde die fertige Zeile durcheinander bringen.
Welche Konsequenzen die "Klammerung" in Anführungszeichen an der überwiegenden Anzahl der Fundstellen haben kann (das hängt stark vom verwendeten Aufrufmechanismus ab), kann sich jeder Shell-Anfänger schon vorstellen.
Wenn man einen solchen Aufruf dann tatsächlich mal ausführt und die entstandene Ausgabedatei (die drei obersten Zeilen natürlich nicht) wieder über das GUI importiert, merkt man auch, daß es exakt dasselbe Format ist (ein Vergleich zweier Dateien wird immer einen Unterschied ergeben, da die verschlüsselten Daten jedesmal anders dargestellt werden) und sich problemlos auch mit einem Kennwort importieren läßt.
Die Form ohne Parameter erzeugt dann wieder eine Datei, die (angeblich) nur auf derselben Box wieder entschlüsselt (ergo erfolgreich importiert) werden kann.
Ob es am Ende mit diesem Kommando und "check_configimport '%s'" tatsächlich möglich ist, ein Kennwort für eine fremde Konfiguration durch "brute force" - also eigentlich Ausprobieren - zu ermitteln, hängt sicherlich von der Stärke des Kennworts ab und von der Offenherzigkeit von "tr069fwupdate" in Bezug auf die konkrete Ursache eines Problems, ich habe es auch nie probiert. Aber "123456" ist wahrscheinlich ohnehin kein gutes Kennwort für so eine Export-Datei?
Wir wissen also jetzt definitiv, daß mit dem Kommando "tr069fwupdate configexport" eine exakte Kopie einer Export-Datei erstellt wird, wie wir sie auch über das GUI erhalten würden. Wenn ich mich nicht sehr irre, stehen da durchaus Zugangsdaten von mir drin und zwar für vollkommen verschiedene Dienste, die auch garantiert nicht das Geringste mit meinem Provider zu tun haben.
Kommt da die oben zitierte Aussage von AVM etwa ins Wanken? Aber die Möglichkeit der Erzeugung so einer Datei muß ja noch lange nicht heißen, daß sie auch in die Hände des Providers gelangt, auch wenn sich mir die Frage schon stellt, warum sie dann in einem "TR-069-Kontext" überhaupt erzeugt wird. Wir haben ja das "Versprechen" von AVM, daran sollten wir uns orientieren.
Haben wir eigentlich irgendwelche Aufrufe von "tr069fwupdate configexport" noch nicht genauer betrachtet?
Ja, haben wir und zwar diese in libtr069.so:
Na, das konnte ja nun wirklich niemand ahnen ... (irgendwo habe ich ähnliche Formulierungen schon mal gelesen, ich klaue nicht, ich lasse mich inspirieren).
Wenn ich es nicht schwarz auf weiß von AVM hätte, würde ich glatt behaupten, daß da tatsächlich die exportierten Einstellungen (wie die aussehen, wissen wir ja inzwischen) entweder über HTTPS (damit dann wenigstens verschlüsselt) oder sogar über FTP (somit unverschlüsselt) an eine Internet-Adresse übertragen werden können.
Ich habe jedenfalls in meinem Netzwerk keinen Host, auf dem ein httpsdl-Kommando mit "-U"-Option die Einstellungen irgendeiner FRITZ!Box sichern müßte.
Selbstverständlich hat das auch überhaupt nichts mit TR-069 zu tun, es befindet sich nur zufällig in einer extra dafür benötigten Komponente. Bestimmt wissen auch die Provider gar nicht, wie man einen solchen Upload auslösen sollte ... außer Kabel Deutschland vielleicht?
Was die Verschlüsselung der Einstellungen mit den "Eigenschaften" der FRITZ!Box wert ist, habe ich schon mit der Camouflage-Möglichkeit in "decode_passwords" (in Freetz als "decrypt_fritzos_cfg" enthalten) gezeigt.
Wenn man bei einer DSL-Box den WLAN-Startkey kennt, braucht man noch die "maca"-Adresse. Der WLAN-Startkey steht hinten auf einer Box auf dem Aufkleber, der findet sich natürlich auch beim ersten Kontakt der Box mit dem Provider noch in den Einstellungen und ist sogar richtig über GetParameterValues per TR-069 abzufragen, später könnte er dann zwar vom Anwender auf einen eigenen Wert gesetzt werden, nach "FactoryReset" ist es aber wieder der ursprüngliche Key. Was für ein Glück, daß der Provider keine Möglichkeit hat, so ein "FactoryReset" auszuführen.
Die "maca"-Adresse steht entweder in den Support-Daten (ob der Provider die nun tatsächlich hat, wissen wir ja nicht genau), sie steht aber auch in direktem Zusammenhang zur auf der DSL-Schnittstelle verwendeten MAC-Adresse und läßt sich daraus ableiten.
Hat der Provider dann vor dem "FactoryReset" schon die Einstellungen gesichert und spielt diese Konfiguration hinterher wieder ein, hilft nur noch ein wirklich tiefer Blick in die Protokolle einer FRITZ!Box, um einen Restart in der Nacht überhaupt festzustellen. Ein richtig böswilliger Angreifer kann dann tatsächlich sogar das Ereignisprotokoll einer FRITZ!Box so manipulieren, daß am Ende der Restart verschleiert wird.
Kommen wir noch einmal kurz auf die Frage zurück, was denn nun "Logdateien" sein könnten. Im FRITZ!OS werden die Support-Daten durch den Aufruf von /bin/supportdata generiert und von diesem Kommando (ein Shell-Skript, das weitere aufruft, wo die Daten aus verschiedenen Quellen zusammengefügt werden) auf stdout ausgegeben. Wenn es also in einer TR-069-Komponente einen Aufruf dafür geben sollte, ist die Annahme, daß sich hinter den "Logdateien" eigentlich die Support-Daten (mit allen Konsequenzen, inkl. nicht abstellbarer und nicht protokollierter Abrufe durch den Provider) verbergen könnten, wohl nicht von der Hand zu weisen:
Nach meinem Dafürhalten sollte das zumindest als "Anscheinsbeweis" ausreichend sein, ansonsten stellt sich wieder die Frage, was TR-069 überhaupt mit einem solchen Aufruf anfangen sollte.
Damit bleibt mir als Fazit leider nur die Feststellung, daß an der Behauptung, über TR-069 wäre das Auslesen von Zugangsdaten nicht möglich, wohl etwas nicht so ganz stimmen dürfte.
Das ist nur die Formulierung im Konjunktiv ... ich halte sogar die Behauptung, daß AVM den Anwender hier nach Strich und Faden hintergeht, für vertretbar. Die offiziellen Aussagen passen offenbar nicht zum Inhalt der Firmware, soweit man das mit forensischen Mitteln ergründen kann. Da es sich bei diesen Komponenten um "Closed Source" handelt, ist eine unabhängige Untersuchung auch nicht möglich, damit ist es für mich auch legitim, beim Vorliegen so massiver Indizien einen solchen Verdacht zu formulieren.
Welche zusätzlichen Daten, die den Provider nun wirklich nichts angehen (VPN hatten wir schon, das ist bei aktiviertem TR-069 damit aus prinzipiellen Erwägungen schon Schrott), jeder in der eigenen FRITZ!Box gespeichert hat und ob er tatsächlich das (spurenlose) Kopieren der Daten vom USB-Stick der Box zum Provider in der Nacht bemerken würde, muß am Ende jeder selbst entscheiden. So eine Push-Mail ist schon praktisch, bestimmt ist mit dem in der FRITZ!Box hinterlegten Kennwort für den Versand der E-Mail aber gar kein Abruf von Mails möglich. Auch ein "Cloud"-Speicher, der ja auf dem eigenen Server (mit OwnCloud) sicher ist, denn es kommt ja keiner an die Zugangsdaten, ist schon schön, man sollte ihn aber wohl besser nicht in eine FRITZ!Box per WebDAV einbinden, wenn man nicht möchte, daß der Provider dort auch mitlesen kann.
Was ich mir denke, wenn wieder mal jemand (von AVM oder nicht) über die doch so praktischen Anwendungen von TR-069 und die hohen Sicherheitsanforderungen dort schwadroniert, muß ich sicherlich nicht extra ausführen.
Im nächsten Beitrag werden wir uns dann mal näher mit den DOCSIS-Boxen und der Frage, warum dort zwar der Provider einen Telnet-Zugang braucht, aber der Anwender keinen erhalten soll, beschäftigen. Dabei geht es dann aber auch nicht im Detail darum, wie man selbst einen Telnet-Zugang erhält. Ich will nur die Frage klären, ob in der Firmware irgendwelche Vorbereitungen für den Start eines Telnet-Daemons für und durch den Provider vorhanden sind und wofür man diese dann wieder nutzen könnte. Was man mit einzelnen Kommandos ansonsten noch so anfangen kann, habe ich hoffentlich hier gezeigt ... mit einem Telnet-Zugang hilft dann auch ein abschaltbares CWMP nicht mehr.
- Das wird ein längerer Beitrag - meinetwegen mehr ein Aufsatz - und wer kein Interesse an dem Thema hat, sollte spätestens hier mit dem Lesen aufhören.
- Das ist kein "HowTo", daher gibt es zwar CODE-Tags, darin steht aber nicht, was man machen muß, um eine Box über TR-069 anzugreifen.
- Am Ende könnte es tatsächlich sein, daß ich mehr Fragen gestellt/aufgeworfen als beantwortet habe ... man muß also auch mit einem Cliffhanger (tatsächlich im Duden) leben können.
- Ich werde mich in der Folge ab und an mal auf einen Artikel bei AVM beziehen. Nun verbietet das Leistungsschutzrecht es ja, diesen in vollem Umfang zu zitieren, andererseits kam es ja auch schon vor, daß der Inhalt der AVM-Webseite plötzlich und überraschend ohne sichtbare Information über eine nachträgliche Änderung wechselte (niemand verpflichtet AVM zur Kennzeichnung solcher Änderungen, damit ich nicht mißverstanden werde) und auch das "Gedächtnis" des Internets ist ja nicht immer verläßlich, wenn Spider unerwünscht sind. Da ich aber mich nicht nachträglich dem Vorwurf eines falschen Zitats aussetzen will und auch das IPPF nicht mit einem kompletten Zitat der AVM-Seite in irgendwelche Schwierigkeiten bringen will, braucht es also eine Möglichkeit, den derzeitigen (relevanten) Inhalt irgendwie zu dokumentieren, ohne ihn in vollem Umfang zu zitieren. Dafür verwende ich das folgende Kommando:
Damit wird der entscheidende Textinhalt der Seite - von "Unmittelbarer Support seitens des Providers" bis "unabhängig von TR-069. " - aus der Seite extrahiert und über das Ergebnis ein Hash-Wert ermittelt, der sich ändert, wenn sich der Inhalt der Seite verändert. Am 28.04.2014 um 11:14 Uhr ergab dieses Kommando den Hash-Wert "ae22896d98da17092a5dc07e88d1abecbd9619345ca96ab88538c4aa6f8e3ffd" und meine Zitate stammen aus der Seite, die diesen Hash-Wert produzierte (privat darf ich die logischerweise weiterhin speichern, was ich auch getan habe). Wenn das also jemand überprüfen möchte, ist er herzlich dazu eingeladen. Sofern AVM diese Seite nicht ändert, darf sich auch das Ergebnis nicht ändern. Wenn ich zitiere und es irgendwelche Hervorhebungen dabei gibt, wurden diese immer durch mich angebracht, dann muß ich das auch nicht jedesmal im Einzelnen klarstellen.Code:wget -O - http://avm.de/aktuelles/kurz-notiert/2014/tr-069-ein-protokoll-mit-vielen-vorteilen/ | sed -e ':x;N;s/\n/ /;tx' | sed -e 's/\r//g' | sed -e 's/.*TYPO3SEARCH_begin-->\(.*\)<!--TYPO3SEARCH_end.*/\1/' | sed -e 's/<[^>]*>//g' | sha256sum - Der Artikel basiert auf meinem derzeitigen Wissensstand und wo ich entsprechende Internet-Quellen gefunden habe, führe ich diese an, um dem Leser die Möglichkeit einer eigenen Überprüfung zu bieten. Um nicht ständig mit Relativierungen wie "meines Wissens" o.ä. umgehen zu müssen, stelle ich hier nur einmalig fest, daß ich mich selbstverständlich auch - an nicht mit Quellen belegten Stellen - im Irrtum befinden kann. Wenn es also jemand besser/anders weiß (und bessere Belegstellen dafür vorweisen kann), steht ihm jederzeit die Korrektur meiner Aussagen frei. Zum Erkenntnisgewinn gehört immer auch der Irrtum und nur wer nichts tut, kann auch nichts falsch machen/schreiben.
- Am Anfang geht es mehr um Meinungen und die Analyse einer Veröffentlichung von AVM, das "Zerpflücken" der Firmware auf der Suche nach Erklärungen findet erst zum Ende hin statt.
Was ist eigentlich TR-069?
TR-069 ist erst einmal nicht anderes als ein Standard, um Geräte aus der Ferne zu konfigurieren. Die aktuelle Fassung des Standards ist hier zu finden, die grundlegenden Funktionen sind aber schon mehrere Jahre weitgehend unverändert festgeschrieben. Auf der "Providerseite" erfolgt die Kommunikation über den "Automatic Configuration Server" (ACS) und die Technik auf der Kundenseite wird als "Customer Premises Equipment" (CPE, in Deutsche übersetzt ungefähr als "Technik auf dem Grundstück bzw. in den Räumen des Kunden") bezeichnet. Diese Abkürzungen werde ich in der Folge nutzen, sie ersparen langwierige Umschreibungen. Es gibt zwar auch andere - ähnlich gelagerte - "Technical Reports", in denen dann auch die Konfiguration weiterer Geräte hinter dem CPE definiert wird, aber der eigentliche TR-069-Standard beschäftigt sich nur mit dem "CPE WAN Management Protocol" (CWMP) und damit mit der Kommunikation eines "Internet Gateway Device" (IGD) mit dem ACS (s. Abbildung 1 in der TR-069-Spezifikation). Wenn sich jemand schon einmal mit TR-069 (oder auch TR-064) befaßt hat, wird er hier einige Abkürzungen wiedererkennen, die ihm z.B. als "CWMP-Account" einer FRITZ!Box oder als "Typ" für eine im Netzwerk gefundene FRITZ!Box (IGD) wahrscheinlich schon einmal begegnet sind.
Im Wesentlichen definiert der Standard folgende Operationen:
- Verbindungsaufnahme eines CPE mit dem ACS
- eine Möglichkeit für den ACS, sich für die Benachrichtigung durch das CPE anzumelden, wenn sich auf der CPE-Seite irgendwelche Änderungen ergeben; dann informiert das CPE von sich aus den ACS über solche Änderungen
- eine Möglichkeit für den ACS, das CPE zu einer asynchronen Kontaktaufnahme zu bewegen; dabei baut das CPE nach dem "Anklopfen" des ACS dann die geforderte Verbindung zum ACS auf (nur dafür wird der eingehende Port beim TR-069 benötigt)
- eine Möglichkeit für den ACS, den Wert einer Einstellung abzufragen (GetParameterValues)
- eine Möglichkeit für den ACS, den Wert einer Einstellung zu setzen (SetParameterValues)
- eine Möglichkeit für den ACS, Dateien vom (Upload, das ist nach der Spezifikation aber optional) und zum (Download, das ist "mandatory") CPE zu übertragen (Abschnitt "2.3.2 File Transfers")
- eine Möglichkeit für den ACS, das CPE neu zu starten (Reboot), wahlweise mit Löschen aller Einstellungen (FactoryReset)
- diverse Hilfsfunktionen, um den tatsächlichen Umfang der Möglichkeiten zu ermitteln, da die konkrete Umsetzung eben nicht bis ins letzte Detail vorgeschrieben wird, es ist mehr ein "Framework" (also ein Rahmen(werk), der/das eine einheitliche Kommunikation ermöglichen soll)
Welche Einstellungen damit konkret gesetzt und/oder abgefragt werden können und welche Daten/Dateien woher und wohin übertragen werden können, läßt der Standard genauso offen (oder definiert es als "optional"), wie die Sicherung einer Verbindung zwischen ACS und CPE über TLS, was in der Folge ja unmittelbar auch Auswirkungen auf die sichere Feststellung der Identität der jeweiligen Gegenstelle hat. Der Standard definiert zwar im Abschnitt "2.2 Security Mechanisms" eine mögliche Absicherung der Kommunikation mit TLS ("[...] is designed to allow a high degree of security [...]), er fordert sie aber nicht (z.B. "[...] is designed to ensure a high [...]") und bietet im zweiten Spiegelstrich (HTTP-Layer) zwar eine Authentifizierung über "shared secrets" an, erzwingt diese aber auch nicht.
Damit zielt die Aussage von AVM (diese ist für mich "weiblich", einmal als "Firma" und einmal als "Gesellschaft mbH") in ihrem Artikel
ganz offensichtlich nicht auf die TR-069-Spezifikation und kann eigentlich nur noch die konkrete Umsetzung durch AVM adressieren, wenn AVM dort tatsächlich ihrerseits die notwendigen Vorkehrungen für diese "Garantie" trifft. Auch der folgende SatzAVM-Artikel oben verlinkt schrieb:
ist ganz offensichtlich nicht falsch, denn der Standard sieht es ja tatsächlich vor. Der dann noch anschließende SatzAVM-Artikel oben verlinkt schrieb:
ist inhaltlich ebenfalls nicht zu beanstanden, wenn man mal den grammatikalischen Aspekt ignoriert und von "die Echtheit" ausgeht. Wenn sich bei irgendeinem Leser in der Kombination dieser drei Sätze jetzt der Eindruck einstellen sollte, eine FRITZ!Box würde nun immer mit dem eingestellten ACS auch mit TLS-Verschlüsselung kommunizieren, dann ist das sicherlich nicht nur zufällig und - das ist allerdings pure Unterstellung meinerseits - sicherlich auch beabsichtigt. Auf den letzten Satz in diesem AbsatzAVM-Artikel oben verlinkt schrieb:
komme ich später noch einmal zurück, er soll hier nur nicht unerwähnt bleiben, denn der gesamte Absatz ist mitAVM-Artikel oben verlinkt schrieb:
überschrieben und soll sicherlich dem AVM-Kunden (oder auch dem Benutzer einer vom Provider bereitgestellten FRITZ!Box) ein Gefühl der Sicherheit und der Unbedenklichkeit der Nutzung von TR-069 vermitteln.AVM-Artikel oben verlinkt schrieb:
Hält denn AVM nun die oben gegebene Garantie auch tatsächlich ein?
Dazu genügt schon ein Blick in die Firmware, was bei einer "normalen" FRITZ!Box über den Telnet-Zugang ja jedem Kunden auch möglich ist. Es gibt dort eine Datei, die beim Einstellen eines Anbieters im HTTP-basierten Konfigurationsinterface einer FRITZ!Box (ab jetzt "Graphical User Interface" - GUI) zu Rate gezogen wird und für die angebotenen Provider u.a. auch die Angaben zur Verwendung von TR-069 und die dazu notwendigen Einstellungen (in erster Linie die URL des ACS) enthält. Ein Blick in diese Datei (bei einer FRITZ!Box 7490 mit Firmware-Version 06.23, diese Datei ist aber nahezu identisch bei fast jeder derzeit verfügbaren Firmware) offenbart dann dieses:
Code:
root@FB7490:~ $ tar xOf /etc/default.$CONFIG_PRODUKT/$OEM/providers-$Country.tar | grep "http:"
url = "http://80.228.251.206/live/CPEManager/CPEs/Auth_Basic/avm";
url = "http://acs.be-converged.com:9675";
url = "http://trixi.netcologne.de/initial";
url = "http://80.228.251.206/init/avm";
url = "http://trixi.netcologne.de/initial";
url = "http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm";
url = "http://acs.be-converged.com:9675";
url = "http://trixi.netcologne.de/initial";
url = "http://80.228.251.206/live/CPEManager/CPEs/Auth_Basic/avm";
url = "http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm";
url = "http://80.228.251.206/init/avm";
url = "http://80.228.251.206/init/avm";
url = "http://acs.be-converged.com:9675";
url = "http://trixi.netcologne.de/initial";
url = "http://cm.kielnet.net:7547/live/CPEManager/CPEs/avm";
Code:
root@FB7490:~ $ tar xOf /etc/default.$CONFIG_PRODUKT/$OEM/providers-$Country.tar | grep "https:"
url = "https://acs.htp-apv.de:7547";
url = "https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt";
url = "https://acs.o2online.de/nbbs/tr69";
url = "https://acs.htp-apv.de:7547";
url = "https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt";
url = "https://acs.htp-apv.de:7547";
url = "https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt";
url = "https://acs.o2online.de/nbbs/tr69";
url = "https://acs.o2online.de/nbbs/tr69";
url = "https://acs1.online.de/";
url = "https://acs.o2online.de/nbbs/tr69";
url = "https://acs.htp-apv.de:7547";
url = "https://acsaka.arcor-ip.de:22163/cwmpWeb/CPEMgt";
url = "https://acs.mnet-online.de";
url = "https://acs1.online.de/";
url = "https://acs1.online.de/";
url = "https://autoconf.wobline.de:7547/live/CPEManager/CPEs/genericTR69";
url = "https://acs.htp-apv.de:7547";Ob man das im Satz 1 nun als "Lüge" bezeichnen will oder als "gezielte Desinformation" oder als "unklare Ausdrucksweise", davon muß sich jeder selbst ein Bild machen. Ich verbuche das aber mal unter "Lüge 1", denn auch eine "versehentliche falsche Angabe" bleibt falsch und die sehr subtilen Formulierungen in den anderen Sätzen dieses Absatzes legen (wenn man mal den schweren Grammatikfehler nicht betrachtet) eigentlich eine entsprechend sorgfältige Planung dessen, was da gesagt/geschrieben werden sollte, nahe. Diese - jedenfalls für mein Empfinden - sorgfältigen Formulierungen, die immer haarscharf am technischen Sachverhalt vorbei gehen und doch nie als "komplett gelogen" entlarvt werden können, finden sich auch noch an diversen anderen Stellen:
AVM-Artikel oben verlinkt schrieb:
- "implementiert" ist schon mal etwas anderes als "spezifiziert" und damit dann doch wohl eher - es beschreibt ja die Tätigkeit von AVM, mithin die tatsächliche Umsetzung von TR-069 im FRITZ!OS - das von AVM geplante Ziel beim Einsatz von TR-069 beschrieben.
- "sicher" ist die Kommunikation auch nur bedingt, wie ich oben gezeigt habe.
- "zu ermöglichen" entschärft diesen Satz dann tatsächlich wieder, denn die sichere Kommunikation ist ja tatsächlich möglich ... wenn die Provider sie nicht anwenden, kann ja AVM nichts dafür, außer vielleicht genauere Aussagen ohne suggestiven Charakter zu tätigen und somit beim Kunden Unwissen und ein falsches Sicherheitsgefühl hervorzurufen.
Noch ein Beispiel?
Na wenn das keine gute Nachricht ist.AVM-Artikel oben verlinkt schrieb:
Es fehlt eigentlich nur das Wort "ausschließlich" zwischen "der Provider" und "die ursprünglichen" und ich würde tatsächlich (mit einigen Abstrichen, die ich noch erläutern werde) Applaus spenden, weil alle diese Punkte zweifellos eine (unter bestimmten Randbedingungen) sinnvolle Anwendung von TR-069 sind.
Wenn dann auch noch alles nur im Sinne des Anwenders ist (natürlich nimmt jeder Leser an, er selbst wäre auch tatsächlich der Kunde, was bei den über Provider vertriebenen FRITZ!Boxen wohl AVM auch etwas anders sieht, aber sie schreiben ja auch von Anwender, ich in der Regel von Benutzer), dann wäre man ja offensichtlich verrückt, wenn man diese Chancen nicht nutzen würde.
Wenn das "bei weniger technikaffinen Nutzern" auch noch erfolgt, ohne diese damit behelligen zu müssen, dann ist ja alles gut.
Oder vielleicht ist ja doch nicht alles so rosarot, besonders dann, wenn der Anwender davon gar nichts bemerkt (ggf. nicht einmal bemerken kann)?
Um das noch einmal aufzudröseln, hier werden folgende Funktionen der TR-069-Implementierung beschrieben:
- FactoryReset, oben als "die ursprünglichen Einstellungen [...] wiederherstellen" vorhanden
- Download (für Firmware-Updates), oben als "Firmware-Updates durchführen" aufgeführt
- "schnell auf Sicherheitslücken reagieren" soll wohl darauf hinauslaufen, daß der Provider anstelle des Anwenders mit neuer Firmware versorgt wird (hoffentlich nicht auch tatsächlich schon früher als der "gemeine Kunde") und diese dann einspielen kann.
Das ist für unbedarfte (von AVM etwas weniger drastisch als "weniger technikaffine Nutzer" bezeichnete) Anwender vielleicht wirklich erforderlich, nach meiner Einschätzung sollte sich das dann aber auch auf diese Aufgaben und auf diese Zielgruppe beschränken.
Gerade die Möglichkeit, aus der Ferne auch ein "FactoryReset" auszulösen, hat schon bei einigen Kunden von Kabel Deutschland für heftigen Ärger gesorgt und meiner Meinung nach auch bei vielen anderen Providern. Der einzige Provider, den ich kenne und der höflicherweise wenigstens den Kunden um seine Zustimmung zum Zugriff auf den Router des Kunden bittet (oder zumindest bat, als ich da noch mit zu tun hatte), ist 1&1.
Kabel Deutschland mißinterpretiert absichtlich jede Supportanfrage des Kunden mit Bezug auf die FRITZ!Box als implizite Zustimmung zur eigenständigen "Behebung" durch KDG-Techniker und dazu gehört offenbar immer ein "FactoryReset", unabhängig davon, ob es theoretisch überhaupt möglich wäre, daß ein solches Vorgehen tatsächlich hilft. Dort hilft dann nicht einmal der vorher ausdrücklich (schriftlich) geäußerte Widerspruch gegen ein "FactoryReset", die Einstellungen des Kunden werden einfach kommentarlos gelöscht und wie er sie wieder in die Box bekommt, soll er gefälligst selbst sehen.
Hier sehe ich AVM tatsächlich in der (zumindest moralischen) Pflicht, dem Kunden eine eigene Möglichkeit zu verschaffen, sich gegen solche Eingriffe zu verwahren (das wäre bei der erfolgreichen Abschaltung von TR-069 ja auch der Fall), aber da ist dann ein Satz wie
nur wenig hilfreich.AVM-Artikel oben verlinkt schrieb:
Auch wenn sich Mietgeräte im Eigentum des Anbieters befinden mögen, ist der tatsächliche Besitz (d.h. die "tatsächliche Herrschaft über die Sache") - zumindest für mich - der entscheidende Punkt in dieser Angelegenheit und AVM unterstützt hier die regelmäßige Mißachtung der Arbeit des Anwenders (die momentane Konfiguration der FRITZ!Box, die ja weit mehr enthalten kann, als der Provider seinerseits konfiguriert hat). Wenn man so etwas unbedingt machen will, dann muß man eben eine Trennung der Einstellungen des Anwenders von denen des Providers vornehmen und dem Provider nur noch die Möglichkeit einräumen, auch seine eigenen Einstellungen zu löschen.
Das wäre für mich tatsächliche "Anwenderorientierung", so ist es eher eine Art perverse "Kundenorientierung", denn offenbar ist AVM dabei der Kunde Provider wesentlich wichtiger als der Anwender und Besitzer.
Selbst wenn man TR-069 nicht abschaltbar macht, könnte man immer noch das tatsächliche "FactoryReset" von einer Handlung des Besitzers abhängig machen. Zum Beispiel könnte nach einem providerseitigen Request für das Zurücksetzen auf Werkseinstellungen eine FRITZ!Box erst einmal ihrerseits mit einer rot blinkenden Info-LED ein solches Ansinnen signalisieren und der Kunde muß das dann innerhalb einer bestimmten Zeit durch das Drücken eines Buttons an der FRITZ!Box auch genehmigen.
Damit wäre beiden Seiten (dem Provider und dessen Kunden) geholfen, denn die wenigsten Kunden werden sich bei einer Fehlermeldung an den Provider nicht vor Ort befinden und wenn der Provider seinerseits in seiner Technik eine "asynchrone Abarbeitung" durchführt, dann muß eben der Kunde vom Techniker angerufen werden. Das würde dann sicherlich auch das Rücksetzen "auf Verdacht" signifikant ausdünnen.
Wenn man es auf die Spitze treiben will, baut man eine - dann auch wirklich immer verfügbare und wirksame - Einstellung "Support-Zugriff nur mit Zustimmung des Kunden" ein, damit auch die Kunden "bedient" werden können, bei denen die Sicherheit des Routers und der "Gluteus maximus" keine Beziehung haben, die man im geometrischen Sinne als "tangential" bezeichnen würde.
Bei einem Mietgerät ist das jedenfalls regelmäßig auch ein Eingriff in die tatsächliche Beschaffenheit der Mietsache (und den Gebrauchswert für den Besitzer) und das ist zumindest bei Kabel Deutschland (bei "vermieteten" Geräten, d.h. wenn ein Aufpreis für das Gerät verlangt wird) in den mir vorliegenden neuen AGB/BGB (hier zu finden) inzwischen tatsächlich so geregelt, daß sich KDG dort das Recht einräumt (das war früher noch anders formuliert) "die Konfigurationsdaten und die Betriebssoftware herunterzuladen und zu verändern, um den Dienst für den Kunden wiederherzustellen".
Die Einschränkung "Dabei werden die Konfigurationsdaten des Kunden nur insofern erfasst, wie es zur Wiederherstellung der ursprünglichen Konfiguration notwendig ist." kann man nun wieder unterschiedlich interpretieren (was ist denn die "ursprüngliche Konfiguration", die des Kunden oder die des Providers - sprich FactoryReset + Provisionierung über den ACS - und warum muß man für das Wiederherstellen der Providerkonfiguration die Konfiguration des Kunden herunterladen, wenn doch der Provider alle notwendigen Angaben selbst haben sollte), ob man sie tatsächlich glaubhaft findet, muß wieder jeder selbst entscheiden. Ich komme gleich dazu, was da wohl tatsächlich passiert oder passieren könnte bei einer FRITZ!Box.
Die angesprochene Beschränkung auf die Zielgruppe soll jedenfalls offenbar über die im AVM-Artikel unter
aufgeführte Möglichkeit der Abschaltung realisiert werden, ob und wann das am Ende in vollem Umfang möglich ist (oder auch "Was ist denn nun der Unterschied zwischen "enabled" und "litemode" in den TR-069-Einstellungen?"), ändert(e) sich nach meinem Dafürhalten bis zur Version 06.20 ständig (manchmal von Labor- zu Labor-Version - und davon stand nichts in den "Changelogs") und ich habe es inzwischen aufgegeben, diese ständigen Änderungen nachzuverfolgen.AVM-Artikel oben verlinkt schrieb:
Mir würde es inzwischen schon reichen, wenn AVM in diesem Punkt eigentlich nicht meint, in FRITZ!OS 06.20 ließe sich TR-069 komplett abschalten (nebenbei gefragt, was ist eigentlich bei den anderen FRITZ!Boxen, für die es keine 06.20-Firmware gibt, wie zum Beispiel die "Homebox 1" von Kabel Deutschland?), sondern wenn da die Rede von ab oder seit wäre und man somit auch für künftige Versionen davon ausgehen könnte, daß sich TR-069 tatsächlich über die entsprechenden Einstellungen abschalten läßt und die Firmware nie wieder "nur so tut".
In diesen Kontext fällt dann auch das Starren auf den "offenen Port" für TR-069, das einige Anwender immer wieder befällt. Ob dieser Port nun offen ist oder nicht, spielt nur dann eine Rolle, wenn der ACS seinerseits das CPE zu einer Kontaktaufnahme auffordern will. Für sämtliche vom CPE selbst ausgehenden TR-069-Aktionen ist dieser Port vollkommen uninteressant, wenn ein Provider "etwas Geduld hat", kann er TR-069 auch ohne diesen offenen Port - mit genau denselben Gefährdungen wie mit offenem Port - betreiben. Der Port ist zwar ein ziemlich sicheres Anzeichen für aktiviertes TR-069, aber auch wenn er geschlossen ist, ist das noch lange kein Beweis für die tatsächliche Abschaltung von TR-069.
Da sogar die Adresse mindestens eines ACS (des von 1&1 - als "https://acs1.online.de" u.a. in 'ctlmgr' vorhanden, der auch das Auspacken der erwähnten Provider-Datenbank übernimmt) direkt in der Firmware hinterlegt ist, kann man eigentlich nicht einmal aus einer fehlenden URL für den ACS mit letzter Sicherheit darauf schließen, daß da tatsächlich "nichts läuft", das kann nur ein Packetdump (dann möglichst auch noch auf einem unabhängigen Gerät wie einem vorgeschalteten DSL-Modem) halbwegs verläßlich klären.
Wenn der Anwender etwas Pech hat, wurde nur der offensichtliche "litemode" in eine etwas weniger auffällige Form gebracht, die man von außen - eben ohne Packetdump, ich habe nur keinen 1&1-Anschluß, um das mal selbst zu verifizieren oder zu falsifizieren - nicht mehr ohne weiteres feststellen kann. Wobei das sicherlich in das Reich der Spekulation abdriftet, aber die Frage stelle ich mir schon, warum da der ACS direkt in der binären Firmware hinterlegt ist (das ist auch nicht vom Branding abhängig, der ctlmgr ist immer derselbe) und nicht wie bei anderen Providern entsprechend konfiguriert wird. Diese Sonderbehandlung erscheint mir schon etwas merkwürdig.
Zur Beschränkung auf die aufgeführten Aufgaben/Möglichkeiten von TR-069, wenn es der Anwender doch lieber eingeschaltet läßt, komme ich gleich, vorher fügt AVM den implementierten Möglichkeiten ja peu a peu weitere "Anwendungsfälle" hinzu:
Auch hier wird wohl wieder kein Kunde auf die im zweiten Satz gepriesene Verbesserung freiwillig verzichten wollen. Ob das auch noch der Fall ist, wenn man den ersten Satz hinterfragt, weiß ich nicht so genau:AVM-Artikel oben verlinkt schrieb:
- Status der Verbindung abfragen - gut, dagegen ist wenig zu sagen
- Logdateien auswerten - hier stellt sich mir dann schon die Frage, welche Logdateien das sein könnten (wir reden hier immer noch über die Möglichkeit, diese Daten auch ohne die Zustimmung (notfalls sogar gegen den Willen) des Anwenders abzufragen)
- Konfiguration anpassen - das kann ja nicht so schlimm sein, denn schließlich ist TR-069 ja genau dafür gedacht
Zu 3. stellt sich mir dann nur noch die Frage, warum AVM auch auf Nachfrage keine Informationen dazu (an Anwender, was bei einer im Einzelhandel erworbenen Box aber auch der Kunde sein sollte) herausgeben will, entsprechende E-Mails wurden (zumindest bei meiner Anfrage) nicht einmal einer Antwort gewürdigt. Vielleicht ist der genaue Umfang der Möglichkeiten über TR-069 AVM so peinlich, daß man lieber keine Diskussion darüber ermöglichen will und sich eher auf "Betriebsgeheimnisse" herausredet. Da bleibt also nur die eigene Recherche, die machen wir gleich gemeinsam.
Zu 2. und dem tatsächlichen Umfang der Logdateien kann man eigentlich nur Vermutungen anstellen, sollte es sich um die bekannten "Support-Daten" handeln, stehen auch da genug - ggf. auch private - Informationen drin, die ich persönlich meinem Provider nicht mitteilen will. Wenn es andere "Logdateien" sein sollten, stellt sich mir wieder die Frage, wo und wie die in der Firmware zusammengetragen werden. Das hinterfragen wir aber erst fast am Schluß noch einmal ...
Die oberflächliche Maskierung von Kennwörtern als "SECRET" in diesen Support-Daten kann auch nicht darüber hinwegtäuschen, daß dort z.B. auch die intern vorhandenen Clients mit zusätzlichen Informationen aufgelistet sind - von vielleicht eingerichteten "geheimen" Port-Forwardings auf solche Geräte ganz zu schweigen, auch wenn jeder selbst Schuld ist, wenn so etwas nicht zusätzlich gesichert wird und die Kenntnis des Ports schon ausreicht für einen Angriff oder sogar einen Mißbrauch.
Das ist auch nur ein Beispiel, über den Umfang der Support-Daten und die dort offengelegten Informationen (hat schon mal jemand erlebt, daß AVM einen Support-Fall mit technischem Hintergrund ohne - oder mit entsprechend manuell nachbearbeiteten - Support-Daten bearbeitet?) kann man problemlos noch einem weiteren Artikel verfassen.
In keinem Fall würde ich als Kunde jedenfalls wollen (auch nicht als Kunde "bei Anbietern, die FRITZ!Box als Mietgerät zur Verfügung stellen", wie AVM es formuliert), daß der Provider auch gegen meinen Willen Zugriff auf diese Informationen hat.
Aber dafür hat ja AVM schließlich auch Vorsorge getroffen und erklärt uns das auch:
Auch dieser Satz stimmt zu 100%, wenn man ihn tatsächlich wörtlich nimmt. Die schon zitierte Einschränkung folgt im Satz danach.AVM-Artikel oben verlinkt schrieb:
Nun ist es gar nicht so einfach, diese Einstellungen tatsächlich zu Gesicht zu bekommen, wenn man kein Kunde bei so einem Provider ist. Ich habe dazu eine FRITZ!Box 7490 (Branding AVM) mit FRITZ!OS 06.23 an einem Telekom-Business-Anschluß verwendet und da muß man erst einmal ein paar Vorbereitungen treffen. Dazu braucht es zwei "Patches", die mit folgenden "Diff-File" beschrieben sind:
Code:
--- /usr/www/avm/internet/providerservices.lua
+++ /var/providerservices.lua
@@ -10,13 +10,8 @@
require"tr069"
local gui_mode = tonumber(tr069.gui_mode)
local show, show_disabled
-if gui_mode then
-show = gui_mode > 0
-show_disabled = gui_mode == 2
-else
+show_disabled = false
show = true
-show_disabled = tr069.unprovisioned()
-end
function writehtml_enabled()
if show then
local addclass = show_disabled and " disable_onload" or ""
--- /usr/www/avm/menus/menu_show.lua
+++ /var/menu_show.lua
@@ -122,12 +122,7 @@
return config.TR069 and not config.LTE and not config.DOCSIS
end
menu.show_page["/internet/providerservices.lua"] = function()
-local gui_mode = tonumber(box.query("tr069:settings/gui_mode"))
-if gui_mode then
-return expert_mode and gui_mode > 0
-else
-return expert_mode and (oem ~= 'avm' or box.query("tr069:settings/url") ~= "")
-end
+return true
end
menu.exists_page["/internet/internet_settings.lua"] = function()
return not config.DOCSIS and not config.LTE- "gui_mode" darf nicht "0" sein, bei "2" werden die Einstellungen zwar angezeigt, lassen sich aber nicht ändern - das wird in der tr069.cfg auf Text-Werte abgebildet, wer die Zuordnung braucht, findet sie an anderer Stelle im IPPF
- fehlt in der tr069.cfg die Angabe zum "gui_mode" oder ist sie "0" (alles andere ist "true" im o.a. Lua-Code, wobei der Wert "0" eigentlich für "GUI nicht anzeigen" steht), wird noch geprüft, ob "oem" (das Branding)nicht "avm" ist oder die URL des ACS in der Konfiguration nicht fehlt
- Was man oben jetzt nicht sieht, ist: Bei DOCSIS-Boxen (selbst wenn man ein "AVM"-gebrandetes Gerät hätte), wird der Menüpunkt "Anbieterdienste" grundsätzlich nicht angezeigt, egal ob "gemietet", "überlassen" oder "gekauft":
Bei LTE- und DOCSIS-Boxen wird also die Existenz der betreffenden Seite im GUI-Menü in jedem Falle schamhaft verschwiegen, was bei LTE (da gibt es allerdings in der Firmware auch die notwendigen Dateien für TR-069, selbst wenn es vielleicht tatsächlich nicht genutzt werden sollte) ja noch durchgehen mag, bei DOCSIS-Boxen aber den Wahrheitsgehalt der AVM-Aussagen durchaus mindern würde, wenn es da nicht ausschließlich "Mietgeräte" (wenn man mal Überlassung dazu zählt) geben würde.Code:menu.exists_page["/internet/providerservices.lua"] = function() return config.TR069 and not config.LTE and not config.DOCSIS end
Egal, weiter im eigentlichen Thema ... will man nun die etwas störrischen TR-069-Einstellungen doch mal angezeigt bekommen, führt man die folgenden Kommandos aus:
Code:
# cp /usr/www/avm/menus/menu_show.lua /var/
# cp /usr/www/avm/internet/providerservices.lua /var/
# mount -o bind /var/menu_show.lua /usr/www/avm/menus/menu_show.lua
# mount -o bind /var/providerservices.lua /usr/www/avm/internet/providerservices.luaDas Ergebnis unterscheidet sich nur marginal von der Anzeige einer "originalen" Firmware mit aktiviertem (oder besser deaktiviertem) TR-069 und ist ausreichend genau, um es als Grundlage der weiteren Betrachtungen zu verwenden, auch wenn es nur durch Manipulation der Firmware zur Anzeige gelangte.
Somit erhält man dann immer die zusätzliche Anzeige der "Anbieterdienste", die bei mir dann so aussieht:
Anhang anzeigen 81691
Ich weiß ja nicht, wie es anderen geht, aber aus dem Text
würde ich nun auch wieder nicht schließen, daß damit auch eine "unsichere (unverschlüsselte) Übertragung" denkbar wäre (das habe ich oben ja schon gezeigt) oder daß da in Wirklichkeit viel mehr passiert und ermöglicht wird, als nur die "Übertragung der Internetzugangsdaten und Anmeldedaten für Internettelefonie auf diese FRITZ!Box".FRITZ!OS-GUI schrieb:
Von den weiteren Möglichkeiten (da geht es noch gar nicht um Firmware-Updates), die AVM auf der Webseite dann noch "eingesteht", steht da irgendwie nichts oder ich finde es nur nicht.
Die Aussage
finde ich auch etwas gewagt, was hat das "Dienstangebot" (das ja wohl vom "Dienstanbieter" stammt) mit dem Funktionsumfang der FRITZ!Box zu tun? Sollte tatsächlich mal ein Provider neue Dienste einführen wollen, die mit einer älteren Firmware nicht realisiert werden können, wäre das - für mich jedenfalls - schon eine Überraschung.FRITZ!OS-GUI schrieb:
Ansonsten sieht das für mich wieder wie das schamhafte Verschweigen der Tatsache aus, daß eine FRITZ!OS-Version auch mal Fehler enthalten kann (sogar richtig kritische, wie wir inzwischen wissen) und daß dann ein Update seitens des Providers wünschenswert ist, wenn der Kunde sich nicht selbst kümmert. Dieses als "Verbesserung des Dienstangebots" zu verbrämen, ist für mein Empfinden schon etwas kühn.
Die dritte Einstellung (DHCP-Option 43) dürfte nur den wenigsten überhaupt etwas sagen, sie dient eigentlich nur zur Deaktivierung einer Lücke, bei der der ACS des Providers über ein zusätzliches Datenfeld in einer DHCP-Antwort gesetzt werden kann und das ist spätestens dann riskant, wenn der Provider diesen DHCP-Server nicht selbst betreibt. Über diese Option kann selbstverständlich auch die unverschlüsselte Kommunikation mit einem falschen ACS konfiguriert werden, der Angreifer müßte nur das (unverschlüsselte) DHCP-Paket mit der Antwort abfangen und entsprechend modifizieren. Ob so ein Angriff tatsächlich einmal stattgefunden hat, kann man nur raten ... diese Option ist jedenfalls noch nicht allzu alt.
Damit bleiben für mich bei einem "normalen" Anwender eigentlich nur noch zwei TR-069-spezifische Einstellungen im GUI übrig, diese beschreibt AVM mit
wieder für mein Verständnis etwas zu euphorisch als "mehrere", aber das ist sicherlich Ansichtssache.AVM-Artikel oben verlinkt schrieb:
Viel bemerkenswerter finde ich es, daß es eben gerade keine Möglichkeit gibt, die möglichen Zugriffe (wenn man das abschaltbare Firmware-Update mal an dieser Stelle nicht allzu sehr in den Vordergrund rückt, es ist quasi nur ein Nebenkriegsschauplatz) durch den Provider in irgendeiner Form auf bestimmte Funktionen (meinetwegen "Fernkonfiguration" oder "Neustart" oder "Werkseinstellungen") zu beschränken. Wenn man TR-069 einschaltet (oder erst gar nicht vor diese Entscheidung gestellt wird, weil der Dienstanbieter sie für den Anwender trifft), dann nur alles oder nichts, eine Einstellung in mehreren Stufen ist das für mich eher nicht.
Aber auch das ist ja kein Problem, denn AVM hat uns ja ausdrücklich versichert:
Da taucht dann unmittelbar bei mir wieder die Frage auf, wie das zu den AGB von Kabel Deutschland paßt. Aber vermutlich gilt dieser Punkt bei Kabel Deutschland ja für FRITZ!Boxen gar nicht.AVM-Artikel oben verlinkt schrieb:
Was uns AVM mit der Formulierung "in FRITZ!Box ist" am Ende sagen will, frage ich lieber gar nicht erst.
Was ist denn da nun tatsächlich dran?
Wir wagen mal einen Blick in die Firmware (alles folgende ist aus der 113.06.23) und schauen uns als erstes das Kommando "tr069fwupdate" an, das sich in /usr/sbin befindet.
Code:
# tr069fwupdate
This is an 'internal' tool for TR-069 - don't run it from a shell
If you run from a shell, use parameters: packet <url> [<savefile>]Die erste Frage, die sich nun anschließt: Was könnte denn dieses Programm nun veranlassen, etwas mehr als nur diesen Text auszugeben? Dazu schauen wir einfach einmal in dieses Programm "hinein", am einfachsten funktioniert das mit einem Programm, das die dort enthaltenen Zeichenketten ausfiltert, dann müssen wir uns erst einmal nicht mit einem Hex-Viewer oder -Editor quälen.
Das Kommando dazu wäre "strings <dateiname>" und dessen Ausgabe sieht dann - auszugsweise, uninteressante Stellen habe ich ohne Kennzeichnung ausgelassen - so aus, ich habe einige Erklärungen (so wie ich sie mir vorstelle) hinzugefügt:
Code:
# strings /usr/bin/tr069fwupdate
configexport <- das sieht doch schon mal nach einem "echten" Anwendungsfall aus
check_configimport <- ich würde auf eine (syntaktische) Prüfung einer zu importierenden Konfiguration tippen, ggf. auch einer zuvor exportierten
configimport <- das wäre dann wohl der eigentliche Import
configimportbyusb <- na hoppla, geht das etwa auch über USB? Wenn ja, wie?
vpn_config <- VPN kann man über TR-069 auch konfigurieren? Beim "normalen" GUI-Import über firmwarecfg heißt das ähnlich, aber was hat der Provider mit VPN zu tun?Die Möglichkeit des Konfigurierens über USB hatten wir bereits an anderer Stelle (wofür ist ein USB-Stick an einer FRITZ!Box noch zu gebrauchen?) und die lasse ich hier mal außen vor.
Wenn ein Provider auch eine VPN-Verbindung importieren können sollte, ist das zwar etwas überraschend, aber ich kann mir tatsächlich Konfigurationen vorstellen, wo das Sinn machen würde. Die Frage bleibt, warum AVM das verschweigt, denn die Firmware identifiziert ja VPN-Verbindungen anhand des Namens und so könnte ein Import einer VPN-Verbindung ja eine vorhandene überschreiben, einerseits versehentlich, notfalls aber sogar gezielt.
Aber dazu müßte man über TR-069 ja erst einmal ermitteln, welche Verbindungen da überhaupt konfiguriert sind. Das wird ja nicht so einfach sein ... halt mal, steht nicht auch etwas dazu in den Support-Daten? Ein Glück, daß da der Provider niemals herankommen könnte, denn der hat ja nur Zugriff auf "Logdateien".
Vielleicht ist ein Import einer VPN-Verbindung ja auch gar nicht erst vorgesehen und ich sehe hier "rosa Elefanten", weil ich etwas Falsches geraucht habe? "vpn_config" muß ja noch lange nichts mit "vpn" und "config" zu tun haben, das kann ja auch etwas vollkommen anderes sein und wie sollte so eine Konfigurationsdatei überhaupt auf die FRITZ!Box kommen?
Ganz einfach, das steht auch in "tr069fwupdate":
Code:
wget %s -O - "ftp://%s" 2>/var/dl_err > /var/tmp/vpncfgimport.eff
wget %s -O - "ftp://%s:%s@%s" 2>/var/dl_err > /var/tmp/vpncfgimport.eff
wget %s -O - "ftp://%s" 2>/var/dl_err | /usr/www/cgi-bin/firmwarecfg stream |%s tar xvf -
wget %s -O - "ftp://%s:%s@%s" 2>/var/dl_err | /usr/www/cgi-bin/firmwarecfg stream | tar xvf -
wget %s -O - "ftp://%s" 2>/var/dl_err > /var/tmp/configimport.tmp
wget %s -O - "ftp://%s:%s@%s" 2>/var/dl_err > /var/tmp/configimport.tmp
httpsdl%s -O - "%s" 2>/var/dl_err > /var/tmp/vpncfgimport.eff
httpsdl%s -O - "%s" "%s" "%s" 2>/var/dl_err > /var/tmp/vpncfgimport.eff
httpsdl%s -O - "%s" 2>/var/dl_err | /usr/www/cgi-bin/firmwarecfg stream |%s tar xvf -
httpsdl%s -O - "%s" "%s" "%s" 2>/var/dl_err | /usr/www/cgi-bin/firmwarecfg stream | tar xvf -
httpsdl%s -O - "%s" 2>/var/dl_err > /var/tmp/configimport.tmp
httpsdl%s -O - "%s" "%s" "%s" 2>/var/dl_err > /var/tmp/configimport.tmpWenn bei einem Download über eine verschlüsselte Verbindung tatsächlich die Identität des Servers geprüft werden sollte, würde mich das schon sehr verblüffen. Das "httpsdl"-Kommando kennt jedenfalls diese Parameter:
Code:
# httpsdl
usage: httpsdl [options]
options:
-? - print this help
-O STRING - output file (- for stdout). (NULL)
-v - Verify certificate of SSL server. (NOTSET)
-c STRING - Own SSL certificate file (incl. private key). (NULL)
-t STRING - Trusted SSL server certificate. (NULL)
-T - Use TR-069 traffic class. (NOTSET)
-U STRING - Upload file to given URL (- for stdin). (NULL)
httpsdl [-v] [-c own_cert_file] [-t trusted_ca_file] [-T TR-069 traffic class] [-O output] url [user pass]
httpsdl -O - https://192.168.178.22/testfile aladdin sesame
httpsdl -v -c /etc/own_cert -t /etc/server_ca_cert -O /var/test https://192.168.178.22/testfile
httpsdl -U - https://192.168.178.22/testfileIch weiß auch nicht, wieviele Leute schon mal ihre eigenen Dateien über FTP oder HTTPS auf die Box übertragen haben, jedenfalls in der hier anzunehmenden Form der Angabe einer URL/Adresse für einen Download. Wir reden hier nicht über einen formularbasierten Upload mit einem Browser, die gezeigten Kommandos können verwendet werden, um solche Dateien von einer beliebigen Internet-Präsenz zu laden (wenn eine Internetverbindung besteht, aber das nehmen wir mal an, sonst kommt auch der Provider nicht rein).
Bei Firmware-Updates und Konfigurationen (dazu gleich) ist das vielleicht nur wenig überraschend, man könnte es tatsächlich aus den Texten im AVM-GUI schlußfolgern, auch wenn es da nicht steht und die Simplizität dieser Vorgänge (eigentlich reden wir ja über TR-069) schon etwas überrascht.
Aber daß so ein Download auch tatsächlich für eine VPN-Konfiguration vorgesehen ist, dürfte sicherlich einige überraschen, denn gemeinhin gilt nun mal eine VPN-Verbindung ja gerade als ein Mittel, den Verkehr durch das Netz des Providers zu verschlüsseln, damit dieser (und andere) nicht mitlesen können.
Wenn nun jemand den VPN-Verkehr auf einen Proxy umleitet (dafür braucht er nicht einmal zwingend einen Zugriff auf die Gegenseite, nur eine Kenntnis der VPN-Einstellungen), kriegt der Anwender davon am Ende gar nichts mit. Ob das tatsächlich jedem Anwender bei der "Freischaltung" von TR-069 für den Provider in der Konsequenz bewußt ist? Ich habe da so meine Zweifel.
Aber wir haben ja noch die Versicherung von AVM, daß es vollkommen unmöglich ist, über TR-069 an irgendwelche gespeicherten Zugangsdaten zu gelangen. Die Möglichkeit, daß der Provider tatsächlich Zugriff auf dieselben Support-Daten wie der Anwender hat und daß AVM das mit "Logdateien" meinen könnte, ist ja nur eine Annahme meinerseits und selbst dort sind die "geheimen" Daten ja als SECRET getarnt. Also alles halb so wild ... was soll die "Panikmache".
Wir waren ja bei den Möglichkeiten, die das Programm "tr069fwupdate" so zu bieten hat. Nun ist es ja eher unwahrscheinlich, daß vom Provider wirklich eine komplette Zeile mit einem Aufruf von "tr069fwupdate" übermittelt wird, wenn das zu irgendwelchen Aktionen benutzt werden soll.
Also ist es nur logisch, daß es wohl irgendwo in der Firmware eine oder mehrere andere Stellen geben muß, wo dieses Programm aufgerufen wird. Suchen wir doch einmal danach ... ich habe es der Einfachheit und der Geschwindigkeit halber nicht auf einer FRITZ!Box gemacht (ein "grep -r", das über "/proc" laufen soll, geht in der Box ohnehin schief), sondern mit einer ausgepackten Firmware, wie sie u.a. beim Erstellen eines Freetz-Images auf dem Build-Host vorliegt:
Code:
:~/original/filesystem$ grep -r tr069fwupdate
Binary file usr/bin/tr069fwupdate matches
Binary file usr/bin/ctlmgr matches
Binary file usr/share/ctlmgr/libtr069.so matches
Binary file usr/share/ctlmgr/libtr064.so matches
sbin/start_dect_update.sh:tr069fwupdate packet file://${mountpoint}/$filename 2>>/var/tmp/dect_update_error.log >>/var/tmp/dect_update_out.log
sbin/start_dect_update.sh:tr069fwupdate packet ${url} 2>>/var/tmp/dect_update_error.log >>/var/tmp/dect_update_out.log
Binary file bin/tr069starter matchesOffenbar kann man das Tool auch benutzen, um Dateien von irgendwelchen Adressen im Internet auf eine FRITZ!Box zu übertragen ... was es am Ende mehr kann als "wget" (vielleicht die automatische Auswahl von httpsdl, wenn die URL mit HTTPS beginnt?), ist für uns erst einmal egal.
Wie sehen denn solche Aufrufe an anderen Stellen nun tatsächlich aus, bisher wissen wir ja nur, daß sie überhaupt vorhanden sein könnten.
Code:
:~/original/filesystem$ strings usr/bin/ctlmgr | grep tr069fwupdate
/usr/bin/tr069fwupdate configexport "%s" > %s
tr069fwupdate
Code:
:~/original/filesystem$ strings bin/tr069starter | grep tr069fwupdate
tr069fwupdate configimportbyusb
Code:
:~/original/filesystem$ strings usr/share/ctlmgr/libtr064.so | grep tr069fwupdate
tr069fwupdate check_configimport "%s"
tr069fwupdate configimport "%s"
Code:
:~/original/filesystem$ strings usr/share/ctlmgr/libtr069.so | grep tr069fwupdate
tr069fwupdate configimport
/usr/bin/tr069fwupdate configexport > /var/tmp/configexport
/usr/bin/tr069fwupdate configexport '%s' > /var/tmp/configexport
tr069fwupdate check_configimport
tr069fwupdate
/usr/bin/tr069fwupdate configexport | httpsdl -U - "%s" "%s" "%s" 2>/var/dl_err
/usr/bin/tr069fwupdate configexport > %s; /usr/bin/ftpput%s "%s"%s "%s" -P %d "%s" "%s" %s 2>/var/dl_err"configimport" ist wenig überraschend, wir haben es in libtr069.so ohne Parameter (das ist das "%s" dahinter in libtr064.so, wobei die Anführungszeichen unsere Aufmerksamkeit verdienen) und in libtr064.so eben mit.
"configexport" finden wir nur in libtr069.so, einmal mit und einmal ohne Parameter, auch hier ist das Einschließen von '%s' in Hochkommata auffällig, die Ausgabe erfolgt offenbar auf stdout, daher die Umleitungen beim Aufruf.
Dann fangen wir doch erst einmal mit dem Test der Variante ohne Parameter an, dazu müssen wir zurück auf die FRITZ!Box (das "more" zeigt die Ausgabe seitenweise an, sie ist ansonsten recht lang, auch für einen Scrollback-Buffer eines Terminals):
Code:
root@FB7490:~ $ tr069fwupdate configexport | more
Content-type: application/octet-stream;
Content-Disposition: attachment; filename="FRITZ.Box 7490 113.06.23_28.04.15_1713.export"
**** FRITZ!Box 7490 CONFIGURATION EXPORT
Password=$$$$PMPNZFQVKFUPK4JXAPDCRAUEUCHXXLS3QY2OQEONV6UWC6CEIR3LPPB2PL1XZAYMWLWZW4X1ZQFKMEC663ZPJYSMU54WR1CVMUI5DWBO
FirmwareVersion=113.06.23
CONFIG_INSTALL_TYPE=mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
OEM=avm
Country=049
Language=de
**** CFGFILE:ar7.cfg
/*
* /var/tmp.cfg
* Tue Apr 28 17:13:43 2015
*/
meta { encoding = "utf-8"; }
ar7cfg {
[...]Eine über das GUI exportierte Einstellungssicherung sieht ja genauso aus. Nun könnte es auch sein, daß dieser Export über das GUI in Wirklichkeit genau durch den internen Aufruf dieses "tr069fwupdate" ausgeführt wird und ich mich da nur zu sehr auf den Namen versteife. Das läßt sich ja leicht ermitteln:
Code:
root@FB7490:~ $ echo -n >/var/tr069fwupdate
root@FB7490:~ $ mount -o bind /var/tr069fwupdate /usr/bin/tr069fwupdateDas macht er aber weiterhin, selbst wenn man "tr069fwupdate" in der Firmware von Beginn an durch einen Dummy ersetzt, klappt der Export weiterhin. Diese Funktion kann also eigentlich nichts mit der im GUI zu tun haben, außer daß sie beide am Ende dasselbe Format verwenden.
Wofür könnte aber dann dieser zusätzliche Parameter, der offenbar durch das %s in einigen Fällen noch entsteht, dienen? Es ist ganz simpel die Möglichkeit, auch hier eine Export-Datei mit einem eigenen Kennwort zu erzeugen.
Das erklärt auch die Anführungszeichen bzw. Hochkommata um diesen Parameter, denn ein solches Kennwort könnte ja seinerseits auch ein Leerzeichen enthalten und das würde die fertige Zeile durcheinander bringen.
Welche Konsequenzen die "Klammerung" in Anführungszeichen an der überwiegenden Anzahl der Fundstellen haben kann (das hängt stark vom verwendeten Aufrufmechanismus ab), kann sich jeder Shell-Anfänger schon vorstellen.
Wenn man einen solchen Aufruf dann tatsächlich mal ausführt und die entstandene Ausgabedatei (die drei obersten Zeilen natürlich nicht) wieder über das GUI importiert, merkt man auch, daß es exakt dasselbe Format ist (ein Vergleich zweier Dateien wird immer einen Unterschied ergeben, da die verschlüsselten Daten jedesmal anders dargestellt werden) und sich problemlos auch mit einem Kennwort importieren läßt.
Die Form ohne Parameter erzeugt dann wieder eine Datei, die (angeblich) nur auf derselben Box wieder entschlüsselt (ergo erfolgreich importiert) werden kann.
Ob es am Ende mit diesem Kommando und "check_configimport '%s'" tatsächlich möglich ist, ein Kennwort für eine fremde Konfiguration durch "brute force" - also eigentlich Ausprobieren - zu ermitteln, hängt sicherlich von der Stärke des Kennworts ab und von der Offenherzigkeit von "tr069fwupdate" in Bezug auf die konkrete Ursache eines Problems, ich habe es auch nie probiert. Aber "123456" ist wahrscheinlich ohnehin kein gutes Kennwort für so eine Export-Datei?
Wir wissen also jetzt definitiv, daß mit dem Kommando "tr069fwupdate configexport" eine exakte Kopie einer Export-Datei erstellt wird, wie wir sie auch über das GUI erhalten würden. Wenn ich mich nicht sehr irre, stehen da durchaus Zugangsdaten von mir drin und zwar für vollkommen verschiedene Dienste, die auch garantiert nicht das Geringste mit meinem Provider zu tun haben.
Kommt da die oben zitierte Aussage von AVM etwa ins Wanken? Aber die Möglichkeit der Erzeugung so einer Datei muß ja noch lange nicht heißen, daß sie auch in die Hände des Providers gelangt, auch wenn sich mir die Frage schon stellt, warum sie dann in einem "TR-069-Kontext" überhaupt erzeugt wird. Wir haben ja das "Versprechen" von AVM, daran sollten wir uns orientieren.
Haben wir eigentlich irgendwelche Aufrufe von "tr069fwupdate configexport" noch nicht genauer betrachtet?
Ja, haben wir und zwar diese in libtr069.so:
Code:
/usr/bin/tr069fwupdate configexport | httpsdl -U - "%s" "%s" "%s" 2>/var/dl_err
/usr/bin/tr069fwupdate configexport > %s; /usr/bin/ftpput%s "%s"%s "%s" -P %d "%s" "%s" %s 2>/var/dl_errWenn ich es nicht schwarz auf weiß von AVM hätte, würde ich glatt behaupten, daß da tatsächlich die exportierten Einstellungen (wie die aussehen, wissen wir ja inzwischen) entweder über HTTPS (damit dann wenigstens verschlüsselt) oder sogar über FTP (somit unverschlüsselt) an eine Internet-Adresse übertragen werden können.
Ich habe jedenfalls in meinem Netzwerk keinen Host, auf dem ein httpsdl-Kommando mit "-U"-Option die Einstellungen irgendeiner FRITZ!Box sichern müßte.
Selbstverständlich hat das auch überhaupt nichts mit TR-069 zu tun, es befindet sich nur zufällig in einer extra dafür benötigten Komponente. Bestimmt wissen auch die Provider gar nicht, wie man einen solchen Upload auslösen sollte ... außer Kabel Deutschland vielleicht?
Was die Verschlüsselung der Einstellungen mit den "Eigenschaften" der FRITZ!Box wert ist, habe ich schon mit der Camouflage-Möglichkeit in "decode_passwords" (in Freetz als "decrypt_fritzos_cfg" enthalten) gezeigt.
Wenn man bei einer DSL-Box den WLAN-Startkey kennt, braucht man noch die "maca"-Adresse. Der WLAN-Startkey steht hinten auf einer Box auf dem Aufkleber, der findet sich natürlich auch beim ersten Kontakt der Box mit dem Provider noch in den Einstellungen und ist sogar richtig über GetParameterValues per TR-069 abzufragen, später könnte er dann zwar vom Anwender auf einen eigenen Wert gesetzt werden, nach "FactoryReset" ist es aber wieder der ursprüngliche Key. Was für ein Glück, daß der Provider keine Möglichkeit hat, so ein "FactoryReset" auszuführen.
Die "maca"-Adresse steht entweder in den Support-Daten (ob der Provider die nun tatsächlich hat, wissen wir ja nicht genau), sie steht aber auch in direktem Zusammenhang zur auf der DSL-Schnittstelle verwendeten MAC-Adresse und läßt sich daraus ableiten.
Hat der Provider dann vor dem "FactoryReset" schon die Einstellungen gesichert und spielt diese Konfiguration hinterher wieder ein, hilft nur noch ein wirklich tiefer Blick in die Protokolle einer FRITZ!Box, um einen Restart in der Nacht überhaupt festzustellen. Ein richtig böswilliger Angreifer kann dann tatsächlich sogar das Ereignisprotokoll einer FRITZ!Box so manipulieren, daß am Ende der Restart verschleiert wird.
Kommen wir noch einmal kurz auf die Frage zurück, was denn nun "Logdateien" sein könnten. Im FRITZ!OS werden die Support-Daten durch den Aufruf von /bin/supportdata generiert und von diesem Kommando (ein Shell-Skript, das weitere aufruft, wo die Daten aus verschiedenen Quellen zusammengefügt werden) auf stdout ausgegeben. Wenn es also in einer TR-069-Komponente einen Aufruf dafür geben sollte, ist die Annahme, daß sich hinter den "Logdateien" eigentlich die Support-Daten (mit allen Konsequenzen, inkl. nicht abstellbarer und nicht protokollierter Abrufe durch den Provider) verbergen könnten, wohl nicht von der Hand zu weisen:
Code:
root@FB7490:~ $ strings /usr/share/ctlmgr/libtr069.so | grep supportdata
/bin/supportdataDamit bleibt mir als Fazit leider nur die Feststellung, daß an der Behauptung, über TR-069 wäre das Auslesen von Zugangsdaten nicht möglich, wohl etwas nicht so ganz stimmen dürfte.
Das ist nur die Formulierung im Konjunktiv ... ich halte sogar die Behauptung, daß AVM den Anwender hier nach Strich und Faden hintergeht, für vertretbar. Die offiziellen Aussagen passen offenbar nicht zum Inhalt der Firmware, soweit man das mit forensischen Mitteln ergründen kann. Da es sich bei diesen Komponenten um "Closed Source" handelt, ist eine unabhängige Untersuchung auch nicht möglich, damit ist es für mich auch legitim, beim Vorliegen so massiver Indizien einen solchen Verdacht zu formulieren.
Welche zusätzlichen Daten, die den Provider nun wirklich nichts angehen (VPN hatten wir schon, das ist bei aktiviertem TR-069 damit aus prinzipiellen Erwägungen schon Schrott), jeder in der eigenen FRITZ!Box gespeichert hat und ob er tatsächlich das (spurenlose) Kopieren der Daten vom USB-Stick der Box zum Provider in der Nacht bemerken würde, muß am Ende jeder selbst entscheiden. So eine Push-Mail ist schon praktisch, bestimmt ist mit dem in der FRITZ!Box hinterlegten Kennwort für den Versand der E-Mail aber gar kein Abruf von Mails möglich. Auch ein "Cloud"-Speicher, der ja auf dem eigenen Server (mit OwnCloud) sicher ist, denn es kommt ja keiner an die Zugangsdaten, ist schon schön, man sollte ihn aber wohl besser nicht in eine FRITZ!Box per WebDAV einbinden, wenn man nicht möchte, daß der Provider dort auch mitlesen kann.
Was ich mir denke, wenn wieder mal jemand (von AVM oder nicht) über die doch so praktischen Anwendungen von TR-069 und die hohen Sicherheitsanforderungen dort schwadroniert, muß ich sicherlich nicht extra ausführen.
Im nächsten Beitrag werden wir uns dann mal näher mit den DOCSIS-Boxen und der Frage, warum dort zwar der Provider einen Telnet-Zugang braucht, aber der Anwender keinen erhalten soll, beschäftigen. Dabei geht es dann aber auch nicht im Detail darum, wie man selbst einen Telnet-Zugang erhält. Ich will nur die Frage klären, ob in der Firmware irgendwelche Vorbereitungen für den Start eines Telnet-Daemons für und durch den Provider vorhanden sind und wofür man diese dann wieder nutzen könnte. Was man mit einzelnen Kommandos ansonsten noch so anfangen kann, habe ich hoffentlich hier gezeigt ... mit einem Telnet-Zugang hilft dann auch ein abschaltbares CWMP nicht mehr.
Zuletzt bearbeitet:
