Bei 1&1-Kunden würde ich immer noch auf "anderer Anbieter" bei den Internet-Zugangsdaten umstellen. Ich finde weiterhin die direkte Angabe des ACS von 1&1 in den Zeichenketten des ctlmgr merkwürdig genug (unabhängig vom Branding sind die im ctlmgr identisch), um da lieber zu den Aluhut-Trägern zu wechseln ... von den diversen anderen Stellen, wo der acs1.online.de noch einmal explizit in Lua-Code auftaucht, mal vollkommen abgesehen. Normal wäre die Angabe in den Provider-Einstellungen in der providers-049.tar - wenn da zusätzliche Vorkehrungen für einige ACS in einer Closed-Source-Komponente getroffen werden, darf man ruhig spekulieren, warum sich jemand diese Arbeit machen sollte, wenn es gar keine "Spezialbehandlung" dafür geben sollte.
Die Adresse des Management-Servers in der tr069.cfg kann man offensichtlich ebenfalls über TR-069 ändern ... ob als einzelne Einstellung per passendem SetParameterValues-Aufruf oder durch komplettes Ersetzen der tr069.cfg, spielt hier keine wirkliche Rolle, auch die Änderung des Protokolls auf "http" anstelle von "https" und mithin der Verzicht auf eine Transportverschlüsselung sollte problemlos auf diesem Weg möglich sein (schließlich wird die komplette URL gesetzt und nicht nur der Teil mit dem Servernamen). Das läßt sich jedenfalls daraus folgern, daß in der AVM-Firmware eigentlich der Server acs1.online.de hinterlegt ist, während in der tr069.cfg einer 7390 (mit 06.20, weil das eine Rolle spielen könnte - ich weiß, daß es neuere Firmware gibt, das ist aber auch nicht das Thema) folgendes eingetragen ist:
Code:
# cat /var/flash/tr069.cfg
/*
* /var/flash/tr069.cfg
* Fri Dec 4 10:53:13 2015
*/
meta { encoding = "utf-8"; }
tr069cfg {
[COLOR="#FF0000"] enabled = yes;
litemode = yes;
[/COLOR] tr181_support = no;
dhcp43_support = yes;
igd {
DeviceInfo {
ProvisioningCode = "005.000.000.000";
FirstUseDate = "2014-03-07 14:11:27";
}
managementserver {
url = "[COLOR="#00FF00"]https://acs2.online.de[/COLOR]";
username = "$$$$HTGGX4DRVKFHWZDYFSDPDSTJQAZOVPA4TCLGHENBGYKTE512OZ2UOSYYWE3RYD43D2TXY6CJBSJXSAAA";
password = "$$$$1J1AW2BURYSBSOKMNDQVMJHQVCTJ4LRKKMODWIFCH5I2POZ12YC6E1PP5AYTLMZMYXODRSEWOPPFQAAA";
URLAlreadyContacted = yes;
LastInformReq = "2015-12-04 10:53:13";
LastSuccessfulContact = "2015-12-04 10:53:13";
URLbyDHCPIface = "";
PeriodicInformEnable = no;
PeriodicInformInterval = 0;
PeriodicInformTime = "1970-01-01 01:00:00";
UpgradesManaged = no;
ACSInitiationEnable = yes;
SessionTerminationWithEmptyPost = no;
ConnectionRequestUsername = "";
ConnectionRequestPassword = "";
dnsprefer = tr069dnsprefer_ipv6;
}
}
FirmwareDownload {
enabled = no;
enabled_converted = yes;
upload_enabled = no;
valid = no;
suppress_notify = no;
status = 0;
StartTime = "1970-01-01 01:00:00";
CompleteTime = "1970-01-01 01:00:00";
method = Download_Method_DL;
}
RebootRequest = no;
RebootRequest_CommandKey = "";
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";
}
guimode = guimode_visible;
}
Man sieht also eine andere URL des Management-Servers, als sie in der Ausgangskonfiguration jemals vorgelegen haben kann - also muß der Server nachträglich geändert worden sein.
Die Angaben bei "username" und "password" sind nebenbei bemerkt tatsächlich der 1&1-Login-Name (nur der Teil nach dem Schrägstrich und vor dem @) und auch noch einmal dasselbe Kennwort, wie es für die PPPoE-Anmeldung verwendet wird. Die Konfiguration erfolgte m.W. nicht über einen Start-Code von 1&1.
Und da wird es dann auch wieder "spannend" bzw. da findet sich dann der Grund, warum die Einstellung im GUI eben den Kunden m.E. komplett verarscht, wenn sie den Eindruck erweckt (das tut sie doch, oder?):
Anhang anzeigen 84774
, das TR-069 wäre ausgeschaltet ... das muß man notfalls zur Klarstellung im Zusammenhang mit der
Seite bei AVM lesen, wo ja explizit beschrieben wird, man könne es ab 06.20 auch abschalten:
AVM-Seite schrieb:
In FRITZ!OS 6.20 optional abschaltbar
Sofern Ihr Internetanbieter TR-069 nutzt, können sie in FRITZ!OS unter dem Punkt Internet/Zugangsdaten/Anbieter-Dienste in mehreren Stufen festlegen, wie Ihr Gerät TR-069 nutzen soll. Bitte beachten Sie, dass diese Option möglicherweise bei Anbietern, die FRITZ!Box als Mietgerät zur Verfügung stellen, nicht ausgewählt werden kann.
Es handelt sich hier um eine originale AVM-Box in rot-silber mit "avm"-Branding und kein Mietgerät - um auch das noch einmal festzuhalten.
Allerdings ist als Anbieter eben "1&1 Internet" ausgewählt:
Anhang anzeigen 84775
Die aus der Kombination von eingestelltem Provider und den gezeigten Einstellungen bei "Anbieter-Dienste" resultierenden TR-069-Settings in der /var/flash/tr069.cfg haben wir schon gesehen, die nach wie vor bemerkenswerte Stelle habe ich rot markiert.
Es wird also immer noch bei 1&1 lediglich ein "litemode" aktiviert, wenn man die Anbieterdienste abschaltet ... mit einem MITM-Proxy und der Änderung der URL in eine eigene Adresse kann man dann leicht nachweisen (wenn man den anderen Angaben in der tr069.cfg nicht trauen mag - da steht ja auch, wann der Anbieter das letzte Mal kontaktiert wurde), daß nach wie vor die FRITZ!Box sich regelmäßig beim Provider meldet.
Die sonstigen aus der Einstellung "litemode" hervorgehenden Beschränkungen der TR-069-Möglichkeiten sind am Ende sogar vollkommen uninteressant (die hervorstechendste Änderung ist m.W. das Schließen des Ports für asynchrone Verbindungswünsche von der ACS-Seite), die könnte AVM auch jederzeit mit einer neuen Firmware wieder ändern - es ist halt alles Closed-Source und man kommt selbst als interessierter Beobachter ja mit dem kompletten Testen nicht bei jeder Version hinterher - auch sind die Namen von Einstellungen eben nicht
öffentlich dokumentiert und man muß sich die richtigen Angaben mühsam aus den Zeichenketten in der /usr/share/ctlmgr/libtr069.so zusammensuchen, wobei weder Vollständigkeit garantiert ist (das wäre bei einer Dokumentation aber auch nicht der Fall) noch ist es bei jeder dieser Einstellungen 100%ig festzustellen, was nun genau geändert wird, solange es sich nicht in einer der Konfigurationsdateien niederschlägt (die teilweise ja auch in binärer Form vorliegen, wo man dann nur noch raten und schlußfolgern kann).
Ich würde also als Kunde, der die TR-069-Kommunikation wirklich sicher unterbinden will, als erstes mal den url-Eintrag in der tr069.cfg
ändern - von einem kompletten Löschen des Inhalts würde ich sogar wieder abraten, da dann wohl eher davon auszugehen ist, daß irgendwelche "fallback"-Varianten genutzt würden, als wenn da eben ein falscher - nicht existenter - Server hinterlegt ist. Das Ändern von "enabled" und "litemode" könnte man zwar ebenfalls von Hand versuchen, niemand garantiert einem, daß nicht in der vorhandenen oder einer künftigen Firmware einfach wieder die Einstellungen aus den Provider-Einstellungen (bei 1und1 sehen die so aus in der 31976 der 7490):
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";
}
}
) mit den vorhandenen Einstellungen "gemischt" werden, wobei dann natürlich das "enabled = yes" aus der o.a. Datei wieder siegen würde. Ob und wann dieses Mischen tatsächlich stattfindet, ändert sich m.W. auch ab und an mal ... bei einem früheren Test (war glaube ich noch die 06.10-Labor) konnte man das bei jedem Start des ctlmgr beobachten (die Kommandos zum Auspacken der providers-$Country.tar finden sich auch heute noch in den Zeichenketten des ctlmgr), das beschränkt sich heutzutage m.W. auf weniger Fälle, findet aber wohl immer noch ab und an statt ... spätestens bei einer "Bestätigung" des Internet-Anbieters im GUI.
Daher bleibt als (zumindest vermeintlich) sicherer Weg in meinen Augen tatsächlich nur die Auswahl von "anderer Anbieter", da dort auch in den Voreinstellungen keine tr069.cfg-Inhalte vorhanden sind (wohin sollte z.B. die URL auch zeigen in so einem Fall).
Das mit dem "vermeintlich sicher" formuliere ich deshalb so, weil es natürlich auch weitere Möglichkeiten gäbe, die Zugangsdaten eines 1&1-Kunden zu erkennen (geht schon beim @online.de los und wird in anderem Kontext auch gemacht, z.B. bei den Voreinstellungen für Push-Mail-Adressen) und wenn dann noch eine ACS-Adresse in irgendwelchen Closed-Source-Komponenten hinterlegt ist (für deren Betreiber es an anderen Stellen eben erwiesenermaßen schon eine Sonderbehandlung gibt, der "litemode" ist - ich lasse mich gerne korrigieren - 1&1-spezifisch), dann kann eigentlich nur ein Packetdump auf der WAN-Seite (und auch der wäre theoretisch noch manipulierbar, wenn man da den eingebauten Mechanismus im FRITZ!OS beim Capture verwendet) weitere Klärung bringen. Der müßte aber eben sehr sehr lange laufen und ist auch entsprechend bescheiden zu speichern.
Einen Inhalt der TR-069-Kommunikation sieht man damit aber immer noch nicht, solange man nicht mit einem MITM-Proxy für verschlüsselte HTTP-Verbindungen (das braucht dann ggf. noch den Austausch von Zertifikaten in der Box, damit der Proxy akzeptiert wird oder die passende Einstellung in der tr069.cfg, daß entsprechende SSL-Fehler zu ignorieren sind) dazwischen geht ... das muß dann aber in aller Regel auch schon wieder ein eigener Server im Internet (also hinter dem DSLAM aus FRITZ!Box-Sicht) sein, denn in die Verbindung zwischen DSLAM und Modem kommt man ja nicht rein mit Hausmitteln (LAN1 könnte schon wieder als "Abbruchkriterium" gelten bei einer Sonderbehandlung).
Die Idee, an die Stelle einer TLS-basierten ACS-Verbindung erst einmal eine ohne Verschlüsselung zu setzen und dann von diesem Proxy mit HTTPS weiter zu kommunizieren mit dem Anbieter, hatte ich zwar auch mal in Angriff genommen, aber am Ende ist ein MITM-Proxy die einfachere Lösung, weil der alles Notwendige, wie z.B. auch das Rewriting von HTTP-Headern, von selbst macht. Man muß halt die Zertifikat-Prüfung abschalten ... glücklicherweise gibt es dafür ja auch passende Optionen in der tr069.cfg (als Abschnitt ACS_SSL), wo man einerseits das "trusted_ca_file" sogar auf ein eigenes im NAND-Flash oder auf einem USB-Stick verbiegen konnte (ob das heute noch so ist, weiß ich nicht) und andererseits mit "verify_server=no" die Überprüfung des Zertifikats auch gleich komplett abschalten kann, dann kann man einen beliebigen Servernamen für sein eigenes Zertifikat verwenden.
Mag sein, daß ich da bei 1&1 das Gras wachsen höre (ich habe nur zwei 1&1-Boxen selbst im Zugriff und beide sind nicht meine), aber wenn schon bei der vorgeblichen Abschaltung des TR-069 solche Spielchen getrieben werden, halte ich das auch an anderen Stellen für denkbar und nicht nur für Auswüchse einer paranoiden Phantasie. Wenn es keine Sonderbehandlungen gäbe (und die Extrawurst muß in mehr als der direkten Hinterlegung eines möglichen ACS in binären Dateien bestehen, sonst würde bei acs2.online.de als ACS ja gar nicht mehr erkannt, daß es sich ebenfalls um 1&1 handelt), bräuchte es außer den Einstellungen in der providers-049.tar keine weiteren Fundstellen für diesen Servernamen. Bei der neuen Labor-Version ist diese Fundstelle nebenbei bemerkt aus dem ctlmgr in die neue libcmapi.so (cmapi = control manager api? zumindest naheliegend dem Inhalt nach und nicht nur anhand des Namens) gewandert.
