1&1 manipuliert automatisiert Fritz!Box VOIP Konfiguration

[Peter_Lehmann]

@PeterPawn:
Weil mich das "GEFÄLLT MIR" zu sehr an die ungeliebten Fazebuck-Patschhändchen erinnert, in freundlichen deutschen Worten:
DANKE für deinen (wie immer) sehr guten Beitrag!


Hallo allerseits!

Wie viele andere User, welche in der Lage sind einen (und nicht nicht nur einen privaten Plastik-) Router sachgerecht zu konfigurieren, habe ich alle meine bisherigen Fritz-Boxen (7170, 7270 v1 und v3, 7390 und die 7490) immer selbst konfiguriert und TR-069 vorher abgeschaltet. Im Falle einer Störung hatte ich für den Provider immer einen per Startcode eingerichteten Router zum "Vorzeigen".
Bei meiner aktuellen (gekauften, weißen) 7590 ist es mir allerdings nicht gelungen, vor der Konfiguration TR-096 abzuschalten. Ich habe "alles mögliche" versucht, sicherlich nicht das, was dazu erforderlich war. => Wenn mir ein Wissensträger dazu auf die Sprünge helfen wurde, wäre ich sehr dankbar.

Nun kenne ich das, was das Protokoll TR-096 (CPE WAN Management Protocol) an offiziell beschriebenen Funktionen beinhaltet recht gut. Es steht aber in offiziellen und veröffentlichten Dokumenten nichts darüber, was dieses Protokoll sonst alles noch kann. Damit meine ich Funktionen, welche ohne mein Wissen und ohne dass sie in den Logs der Box erkennbar sind hinter meinem Rücken ablaufen. Entsprechende höfliche Anfragen beim Provider, bei AVM und als Leserbrief bei heise nach einem entsprechenden Artikel wurden entweder nicht beantwortet oder mit einer dummen Antwort "abgebügelt". Ja, ich weiß noch nicht einmal, ob das Deaktivieren von TR-096 in der Box dieses wirklich deaktiviert oder nur (mehr oder weniger) ein Dummie ist. => Gibt es zu diesem Thema gesicherte Erkenntnisse?


MfG Peter

 

[malski]

Hallo PeterPawn,

vielen Dank für Deine umfangreichen Erläuterungen! Wie oben beschrieben verhält es sich so:

Die Liste ist zunächst:

1. VOIP1
2. VOIP2
3. VOIP3
4. Betamax1
5. Betamax2

Bei der ersten Neukonfiguration wird die Nummer VOIP3 gelöscht und die Nummer Betamax1 auf die SIP-Konfiguration von VOIP3 gesetzt. Eine Wahlregel für Auslandstelefonie über Betamax1 greift danach weiter, nur steht dahinter fortan die 1&1 Nummer VOIP3. In den Wahlregeln und dem Anruf-Protokoll ist dies nicht zu erkennen, da dort weiter die Nummer Betamax1 als Ausgangs-Nummer angezeigt wird.

Leider kenne ich die konkreten Funktionsaufrufe in TR-069 dazu nicht. Es scheint aber, also ob zunächst der Index 3 gelöscht wird wodurch Index 4 zu Index 3 wird. Dann wird die Konfiguration von VOIP3 in Index 3 geschrieben wobei der Name bzw. die Verdrahtung in Bezug auf Wahlregeln erhalten bleibt. Somit läuft z.b. die Auslands-Telefonie fortan über VOIP3 bzw. 1&1 zu sehr teuren Konditionen.

Unter der Annahme das die These oben stimmt wäre die Situation zu umgehen wenn bei Index-Änderungen auch die Wahlregeln ungültig gemacht würden bzw. gelöscht würden. Dann wären derartige Situationen nicht mehr möglich. Die Sache hat mich ca. 1.000 EUR gekostet ohne jegliche Kulanz von 1&1.

Lässt sich das auf Deinen Erfahrungsschatz zum Thema abbilden?

@H'Sishi: Leider habe ich keine schriftlichen Aussagen zum technischen Sachverhalt - eMails schreiben können die Tech-Support Mitarbeiter angeblich nicht. Nur die Support-Mailbox bzw. Rechnungsabteilung hat sich mit Zurückweisungen bei mir gemeldet. Da das Thema sehr technisch und für nicht Experten komplex ist habe ich bis jetzt davon abgesehen den Sachverhalt einem Anwalt bzw. Richter zu verdeutlichen.

Grüße

 

[MockiDi]

Hallo zusammen,
@malski Genau so ist es bei mir gelaufen. VoIP 3 wurde auf Position 4 geschrieben, wo ich voip2gsm registriert hatte. Die Rufbehandlung der Fritz!Box hat weiter auf Position 4 die Gespräche geroutet und bei uns ist das nach einer 100-Euro-Rechnung gerade noch rechtzeitig aufgefallen.

Obwohl "nur" 100 Euro, möchte ich die Sache gerne juristisch klären. Daher ist m.E. der Umstand, dass 1&1 von dem Verhalten der eignenen "HomeServer" bei TR069-Zugriff bereits wusste und in der Information zu den Netzarbeiten ausdrücklich sagte, die Endeinrichtung könne normal weitergenutzt werden, ggf. b e w u s s t irreführend.

Klingt das nicht auch nach strafrechtlich relevanter Datenmanipulation?

Hat jemand mit dem Sachverhalt mal eine Staatsanwaltschaft oder die Bundesnetzagentur befasst?

Grüße

 

[PeterPawn]

Die beiden Fälle klingen ja eher nach einem Programmierfehler bei 1&1 - wenn da bei der dritten Nummer ein Index verwendet wird, der um 1 zu hoch ist (also 3 anstelle von 2).

Was steht denn nach so einer "Neukonfiguration" dann auf dem Platz des Eintrags mit dem Index 2 (nullbasiert zählen)? Rein theoretisch müßte da ja dann (wenn das nur am falschen Index liegt) weiterhin der alte Account konfiguriert sein - wenn die nicht vorher noch gelöscht werden. IIRC überschreibt ein weiteres "X_AVM-DE_AddVoIPAccount" einen bereits vorhandenen Eintrag mit demselben Index - man müßte also (wenn das noch stimmt) die alten Einträge nicht zuerst löschen. Wobei AVM m.W. wieder die Nummer auch als Kriterium für die anderen Telefoniefunktionen verwendet und ich nicht weiß, was da geschieht, wenn dort doppelte Einträge auftauchen.

Wer die Daten nicht über TR-064 auslesen will (da kriegt man die ja nur anhand des Index), kann auch die "Vorauswahl" anschauen, die der jeweiligen Nummer zugewiesen wurden.

Bei der Konfiguration über das GUI werden doppelte Nummern auch nicht direkt abgefangen (man kann also auch zwei Einträge mit identischer Rufnummer in der Box anlegen) - das GUI zeigt einem dann eben treudoof zweimal dieselbe Nummer an und wenn man das in der Rufbehandlung irgendwie "zuordnen" will, muß man sich ggf. sogar selbst im HTML-Code ansehen, welcher Eintrag sich hinter der angezeigten Nummer verbirgt:

<select size="1" id="uiViewTo" name="call_to_sel" onchange="OnChangeTo(this.value)" class="">
<option value="tochoose">Bitte wählen ...</option><option value="SIP0">620</option><option value="SIP1">620</option>
</select>

Nun fallen solche Änderungen durch den Provider ja offenbar immer erst spät(er) auf ... andererseits sollte in aktueller Firmware bei jeder Änderung über TR-069 durch den Provider auch eine Nachricht im Event-Log auftauchen - O-Ton: "Der Anbieter hat erfolgreich Einstellungen in diese Box übertragen".

Das sollte dann wohl Anlaß sein, die Konfiguration der eigenen Nummern zu überprüfen ... und wer es schafft, sollte bei der Gelegenheit auch einfach mal die Support-Daten sichern. In neuerer Firmware (spätestens ab 06.90, wenn ich mich richtig erinnere, aber vermutlich auch noch früher) wird nämlich auch die TR-069-Kommunikation in einem Ringbuffer protokolliert (einmal "tr069" und einmal "tr069_avm", letzterer wohl für "argo") und dessen Inhalt sollte auch in der Support-Datei landen.

Wer hier tatsächlich feststellen sollte, daß 1&1 die falsche Konfiguration "ausspielt" und es sich damit deutlich nicht um einen Firmware-Fehler handelt, der dürfte auch bei der Frage des Schadenersatzes deutlich bessere Karten haben, als wenn man das einfach nur so als Behauptung in den Raum stellen muß (bzw. kann). Ob AVM bei einem Software-Fehler haftbar wäre, mag ich nicht beurteilen ... meine Tendenz wäre aber "nein", denn der Provider wäre wohl auch dafür verantwortlich, das Ergebnis seiner Änderungen noch einmal zu kontrollieren und bereits dabei müßte es dann auffallen, wenn ein falscher Index für einen VoIP-Account eingerichtet wurde. Ob das aber auch eine Haftung für 1&1 nach sich zieht?

Ich bin da skeptisch (wenn der Schaden wegen der fehlenden Kontrolle und eines Fehlers in der Firmware eintrat - weil man dann 1&1 die vorherige Kenntnis dieses Problems immer noch nachweisen müßte) ... aber wenn es wirklich jemandem gelingen sollte, eine falsche Konfiguration von 1&1-Seite nachzuweisen, dann dürfte 1&1 in so einem Falle (überhöhtes Telefonie-Aufkommen nach Neukonfiguration über TR-069) auch relativ leicht zu einer Kulanzregelung zu bewegen sein, ehe man sich in die Gefahr begibt, vor Gericht zu unterliegen und damit ein Urteil zu erhalten, auf das sich weitere Kunden stützen könnten.

Da helfen dann aber auch die Support-Daten wieder deutlich (die dann auch die Meldung über die Konfiguration durch den Anbieter belegen, denn auch das Event-Log sollte dort enthalten sein) ... es lohnt sich also durchaus, ab und an mal einen Blick in die Protokolle (zumindest das Event-Log) zu werfen und sich dieses vielleicht auch täglich zuschicken zu lassen und zu prüfen. Wer das nur wöchentlich oder gar monatlich macht, riskiert dann eben auch, daß die "alten Daten" im Ringbuffer für die TR-069-Logs lange schon wieder überschrieben wurden.

 

[Micha0815]

Beim eher gelegentlichen Blick ins Kunden Control-Center prangten mir zwei Infos ins Gesicht.

Kostenlimit und Rufsperre "aufgehoben bzw. nichtmehr konfigurierbar"
Ich hatte vor Urzeiten iirc für Telefonie (VOIP+Mobil ging nur gemeinsam) 50 Euro eingegeben und als Rufsperre sämtliche 900er Nummern.
Fatal eigentlich, dass solche Limits auf ISP-Ebene nun rausfliegen und nur noch in der FB z.T. gepflegt werden können.
LG

 

[ciesla]

Es gibt gute Anbieter, die das von sich aus für alle Nutzer/Kunden tun. Also auch solche, die das Thema überhaupt nicht verstehen. Bzw. frühestens dann, wenn sie mal reingefallen sind.
https://www.easybell.de/unsere-betrugsschutz-garantie.html

 

[Zentronix]

Kostenlimit und Rufsperre "aufgehoben bzw. nichtmehr konfigurierbar". [...]
Fatal eigentlich, dass solche Limits auf ISP-Ebene nun rausfliegen und nur noch in der FB z.T. gepflegt werden können.

Immerhin existiert die Sperre anscheinend noch. Warum aber wird der Einstellungsdialog entfernt? Sind die Kunden damit überfordert? Hat man einfach die am wenigsten verwendeten Funktionen entfernt?

Ist wohl ein genereller Trend. Bei Sipgate Basic ist auch einiges rausgeflogen.

Grüße.

 

[Micha0815]

@ciesla Diese Kostenlimit-Sperre konnte frei gewählt werden und hat mit Betrug in "Deinem Sinne" rein garnix zu tun. Auch der TE hat ja unbestritten ins Ausland telefoniert!

Einschub: Ich hatte seinerzeit der 1und1 Anschlussinhaberin das 50€-Limit eingerichtet, da sie erstens NIE über sämtliche VOIP-Accounts trotz gelegentlich notwendiger 018x-Service-Rufnummern/Ausland/Mobilnetze-DE über gefühlt max. 5-10€ zusätzlich/Monat an Telefonkosten kam (über viele Jahre hinweg bei einer Doppelflat). Eine bittere Pille vor 2-3Jahren war die Urlaubserfahrung mit ihrem Sanmsung S3 im span. Mobilfunknetz und Whats-App und dem "intelligenten Netzwechsel"
Im lahmen Hotel-WLAN/Kneipen-WLAN switche das S3 eher unerkannt via Roaming ins schnellere UMTS-Roaiming-Netz und produzierte stolze MB-Traffic-Preise. Es gab ja die 50€-Bremse? ... Dumm gelaufen, da der Abrechnungszyklus bei 1und1 in den angegliederten Mobilfunktarifen vom 21ten des Monates bis zum 21ten des nächtsten Monats läuft, aber die Sperre vom 1ten bis Monatsultimo! Die seinerzeitige Roaming-Rechnung über rd. 88€ trotz 50€-Sperre lief halt dumm über die Abrechnungs-/Datumsgrenze im Mobilfunksektor und griff nicht!

LG und einige andere imo sinnvolle Features wie Parallel-Ruf wurden im 1und1-KCC entsorgt, weshalb ich überhaupt dies hier eher OT/Am Rande erwähnen wollte.

 

[oldmen]

... immer selbst konfiguriert und TR-069 vorher abgeschaltet. ...
... ist es mir allerdings nicht gelungen, vor der Konfiguration TR-096 abzuschalten.

Nach meinen bescheidenen Erfahrungen ist die Einstellmöglichkeit für TR-069 ("Anbieter Dienste") nur bei bestimmten Providern verfügbar (z.B. 1&1).
Bei der Telekom als Provider z.B. gibt es diese Einstellmöglichkeit nicht.

 

[Peter_Lehmann]

Hallo oldman,

und Danke für den Versuch einer Antwort auf meine Fragen.
Wie aus meiner Signatur ersichtlich ist, ist mein Provider 1&1 und habe ich auch viele Jahre lang alle meine Fritz!Boxen selbst manuell eingerichtet. Es ist mir also bislang immer gelungen, diesen von mir ungewollten TR-069-Zugriff zumindest im GUI sichtbar zu deaktivieren, bevor der Router das erste mal Kontakt ins Internet hatte. (Alles andere steht ja in meinem o.g. Beitrag.)

Ich frage deshalb noch einmal die Wissensträger nach dem mir bislang trotz Suche entgangenen Trick, eine neue (meinetwegen per Recovery auf "neu gemachte") 7590 so einzurichten, dass ich TR-096 vor der Eingabe der Zugangsdaten abschalten kann.

Und wenn mir noch jemand (derjenige weiß schon, wen ich meine ;-)) mitteilen würde, ob mit der Deaktivierung von TR-096 dieses auch wirklich abgeschaltet ist, oder die Deaktivierung nur im GUI als Dummie angezeigt wird, wäre ich sehr dankbar. Gleiches trifft auch zu, für die Frage nach den in den offiziellen Dokumenten NICHT erwähnten "neuen Features" von TR-096, bis hin zur evtl. vorhandenen Möglichkeit (auf höherem Level als dem GUI des 1st-Level-Support) zum Erlangen eines root-Zuganges auf dem Router incl. im GUI des Routers nicht sichtbaren Änderungen, Auslesen von Passwörtern und ähnlichen Schweinereien. (Ich schreibe hier von Möglichkeiten und bin mir natürlich gaaaaanz sicher, dass das mein Provider niemals machen würde ... .)


MfG Peter

 

[PeterPawn]

Meines Wissens (für die Labor-Reihen habe ich da nichts getestet, das kommt frühestens mit dem Erscheinen einer finalen Version von FRITZ!OS 7) gibt es vor der Festlegung des Anbieters dazu keine Möglichkeit - denn es erfolgt genau bei dessen Auswahl, daß die TR-069-Funktionen aktiviert werden oder eben auch nicht.

==============================================================

Auch für die Telekom stimmt die Aussage "kein TR-069" nicht mehr so ganz ... es gibt ein Provider-Profil (telekom_tr069):

#Keywords: '#' 'NAME=' 'ID=' 'BOX=' 'OEM=' 'MEDIUM=' 'AUTOSTART=' 'LISTLEVEL=' 'SIMID='

NAME=Telekom$EMPFOHLEN: Automatische Einrichtung des Internetzugangs, der Telefonie und weiterer EasySupport Dienste der Telekom Deutschland GmbH (weitere Infos unter www.telekom.de/easysupport)
{
ID=telekom_tr069;BOX=7490;
ID=telekom_tr069;BOX=7590;
}

NAME=Telekom$Einrichtung mit manueller Eingabe von Zugangsdaten
{
ID=tonline_ata;MEDIUM=ATA_EXCL;LISTLEVEL=1;
ID=tonline;
}

NAME=Telekom$Einrichtung für Zuhause Start Tarife
{
ID=telekom_zs;
}

NAME=1&1 Internet
{
ID=1und1;
ID=1und1_lte;BOX=6810;MEDIUM=LTE;SIMID=26202_1&1;
ID=1und1_lte;BOX=6840;MEDIUM=LTE;SIMID=26202_1&1;
ID=1und1_lte;BOX=6842;MEDIUM=LTE;SIMID=26202_1&1;
}

NAME=1&1 D-Netz
{
ID=1und1_dlte;BOX=6820;MEDIUM=LTE;SIMID=26202_1&1;
}

NAME=1&1 E-Netz
{
ID=1und1_elte;BOX=6820;MEDIUM=LTE;SIMID=26203_1&1;
}

NAME=Vodafone$Automatische Einrichtung mit Modem-Installations-Code
{
ID=vodafone_bytr069_adsl;BOX=7490;MEDIUM=ADSL;
ID=vodafone_bytr069_adsl;BOX=3490;MEDIUM=ADSL;
ID=vodafone_bytr069_adsl;BOX=7430;MEDIUM=ADSL;
ID=vodafone_bytr069_adsl;BOX=7590;MEDIUM=ADSL;
ID=vodafone_bytr069_vdsl;BOX=7490;MEDIUM=VDSL;
ID=vodafone_bytr069_vdsl;BOX=3490;MEDIUM=VDSL;
ID=vodafone_bytr069_vdsl;BOX=7430;MEDIUM=VDSL;
ID=vodafone_bytr069_vdsl;BOX=7590;MEDIUM=VDSL;
}

(das oben ist der Anfang der "providermaps.txt" aus einer 113.06.93), welches zumindest bei der 7490 (und dem Inhalt der Datei nach auch bei der 7590) verwendet werden kann und die Teilnahme der Box am "EasySupport" der Telekom ermöglicht. Das geht dort allerdings nur für "zertifizierte" Geräte und so hat die Firmware für diese Modelle zusätzlich ein "client-side certificate" (samt privatem Schlüssel) von der Telekom spendiert bekommen, das AVM dann in diese Firmware packt:

vidar:/home/FritzBox/FB7490/firmware/113.06.93 # cat etc/default.Fritz_Box_HW185/avm/tr069-default-iad-fritzchen.telekom.de.pem
-----BEGIN CERTIFICATE-----
MIIGITCCBAmgAwIBAgICEAQwDQYJKoZIhvcNAQELBQAwfjELMAkGA1UEBhMCREUx
DzANBgNVBAgMBkhlc3NlbjEcMBoGA1UECgwTRGV1dHNjaGUgVGVsZWtvbSBBRzEg
MB4GA1UECwwXUHJvZHVjdHMgYW5kIElubm92YXRpb24xHjAcBgNVBAMMFVRlbGVr
b20gUk1ELUNQRSBDQSBJMTAeFw0xNjA2MjExMjA0MThaFw0yNjA5MjcxMjA0MTha
MIHKMQswCQYDVQQGEwJERTEPMA0GA1UECAwGSGVzc2VuMRIwEAYDVQQHDAlEYXJt
c3RhZHQxHDAaBgNVBAoME0RldXRzY2hlIFRlbGVrb20gQUcxIDAeBgNVBAsMF1By
b2R1Y3RzIGFuZCBJbm5vdmF0aW9uMSEwHwYDVQQDDBhpYWQtYXZtZmI3NDkwLnRl
bGVrb20uZGUxMzAxBgkqhkiG9w0BCQEWJGtvbnN0YW50aW5vcy5wYXBhc3Rlcmdp
b3VAdGVsZWtvbS5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKg2
ijGWb/IdI5g089dkVlvr9PEOc/QzM124luqrkOt024H8FkLpUevXfxu4xqbN3bP1
0Odbx/RslHXw4JhCwj2QMexY3xrQkANtvjvy9m8q6ks6eD9+BIuvPyAWw/iqs9yv
X/Bp3MgC+3k3ImqiQiB9F6ay9zjvGpyx3NnrkoDqE/udgrJA6uEs5ud5nmok9ff4
jMIJ2zMyPHdzyevbjbHP3MpCfS8WDKlj/UfWMaKQEivyXMTT2nbr//CecrNXph1e
hUHwsxydSGayp3oeZJW9kh0W3XjnWg/eKlj+8pllEZmQHERIefmx3Xm2BjIYtMwx
Iu/P4xYTKKqGVrzpTo8CAwEAAaOCAVowggFWMAkGA1UdEwQCMAAwEQYJYIZIAYb4
QgEBBAQDAgZAMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBTZXJ2
ZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFPG4CnIKbqjpg7oBjducKbsSqpkTMIG8
BgNVHSMEgbQwgbGhgaqkgacwgaQxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZIZXNz
ZW4xEjAQBgNVBAcMCURhcm1zdGFkdDEcMBoGA1UECgwTRGV1dHNjaGUgVGVsZWtv
bSBBRzEgMB4GA1UECwwXUHJvZHVjdHMgYW5kIElubm92YXRpb24xMDAuBgNVBAMM
J1RlbGVrb20gUk1ELUNQRSBLTFVLIEF1dGhvcml0eSBSb290Q0EgMYICEAAwDgYD
VR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUA
A4ICAQAB9mHycXOHoJrgOrhRWPJa18BEd6DmIu/ED/HEFOfi8BAiVGUwQ2dlXiw5
N3ygYq7aqAWhmJu7CP9PJVmHwc0ZgdXutCQ239X5aaviA8UXcUXNSPj+Ib6qKyJ3
urwX+hoaELYE2NseF+B7EwFnqo/OaKC/bLXlpUwZlsf7dVnQe9g/Fjieuw5dh24i
nzA//Ij4sQZiugMhn6ZqK1hmq7QhSm4L8MKdbc3gyA7DXNYcp5qNWo8D1ITgXafK
fmE98SMATaV9pa2U/cxJt/a5w/7RB4LJvfQ2rrPFKYmMDtN5oaUbUnYg8DoCVu4s
FdTf1h7iQKXPjfIvFNDKK4UUNvywx+HSh15BJDl91JZZs5PiAxWqJf/nata7YsTp
5Hg8DOF8kBIDhWRv5f1oSJ56QPLe/+TxtYxTMYLLXkmo7enZnNNWhHfDXSVvoGxQ
ctqjE6Nlo/vx/MHq9wsqbRkv+tAsk7sN4Pm/B+xtkf3YSlAphM7ckUZLfduhO7Dr
JFA99hpO/wEtOC3em4HG9kDeBaTHfP/Z2hzM6uSu7XsHfUL/t140Pet/E7V9TQFO
v0jYf4ovNf6y2G0N5XVMLYhibpxLGTiGjfBt1sVHqbRpNhXVZ6C0mHGpVkXVo1Gc
76i1CUIe7hzOoQxW7oqaHYZyvP3WL4El4JsPGr8dHAHdteFoLg==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,B3941C87F8E7E7C04568C6967A4078FC

I5NUF9FtNYTf1OHebJtHNsSxeSqA4oI2TRzjDUddCl6vjhSiEXKDk5I/B5h2X5EZ
rfbaX81qgA5KsBzUJuX9y0/HDnKZearYxGJesOec9k2mj07oZ4UfzWpnpXsKNHHV
DpzvtBgW+2pTN3tOM4nV6vVawxHCBK7HUglhjqKBkH2mhQ92lWNdYDYlDnXTCThM
MN6ZFv4Gffk8GHio2gXHJuN5bXomV+HBw1bZdiZlm2xVbre67pNJ/SeGHMkVQUfQ
FEjBVaAJtgjuf9F7ueMuAMpxlGyLergzfzRvcG1DCaCBnEOHKTW4zf5Bjojvo1du
/Yw6wxhSS6IvXBZcX6ZQgqfp0UlZL+izNhlLFDdEjkWn/+jzLo1OKIXpjOzoPslZ
fAx8DaBcPQIFwU9umZV73HaTpzg2Wk7kJmzFvFwyF6dV7q+L/RDcFlnrrbWbj7Q0
mCZbExRbTb760R9iCqCAVxSL+NEZL0kaFsRzGMqg5gBcReeUvFJDxTmj+ZbdBGz2
haM8XwgR24c3CTdoCaengqKePQ7IV6p1rsBgnu/p3FKHs12rxsv/yEEg92BsiNAr
PXwr692EKkzE4hla3zLYv9742vjc8BPsKRWWRJuILoUNUk8CgyiJzjB+y4qC3ps4
GCvnhTfKQGDxZ3WiDU/we9eT1064ialLV/QBgn+iF/vWLnsXVSsdMPL/31HZhx0+
EfhFRp8mqH0BjYxw9Q43aEZlk5p2o+/9jladuQYnKtNL8shi7ialdifnBcb0j8LB
2GV+DC6x63T8t1KnFADTGwFLXxLEAzt6A/1nDJx1ZPnO2ZR5b66G3Ows7W5u5K2n
2ecq9exJaIdyqbhI8MdNmUpg2TkdDKcn1AJTmYa90mOhV8GHaqHjLNARvJHWAqjb
TudlFom+HSPLumi+ukoYVXxQjiL+dtWEqatMZCV6Psl/PA9kc5ccvkp313ywRCu/
Am020B+/2YOvj1QEiN/PXZKfbsY4X0JD/VbL1+tRCJqxKos4OeoFvC36b+WgqZ4f
aJUMFNjKn60E4tUI+kY120Ks5So1/E5ch9ZpYkG7d36h3dut5U8/3Z5hTdD2HQR4
wZjSD9whznyAC3/FMrkWchrVensLYohB2ZtWm9zb0bUlzLIgMfaZprhfFPPtXGDv
HFJ6Gu49nsRVEpkc8LbqLdKZhOhxpW0liblXp4ui0A3S0PTRqFk+bLwnPvXejrgA
uw5rrNZOhr3G0z6fEIv8U3CcfMFjyVbCzgQft+x2WA5rda9cdZHvpq1L5cve2Pu6
lr1UKCLfD8/Wvp6yyK48nyUe+s3adClEGXrmNJhIOB/CSFCy0GmpVSodtpTI3lZo
mcEg8AALHoOXs8u68bTe8EUIgK+0hrclznnQIs4tiQ9D66TCBWOwMBdY88CEdmv4
q1Sc7ZH/VUlQQ8efJdTYk/2W+raajItTRn+NujeZX1z01NQkwykH1K063tyPxulO
fv6HlB5S4mbVQjx6ih9JhVNG0L1N8m/UMMYp9gs1eN8r/oQOf56CNHutZOnq9mcP
fauIIe/ayE9rqBCD8E7AI1AsWfhjzQphY3heUdC5ldVz/rxryK/ugimNLO2WTq/F
-----END RSA PRIVATE KEY-----
vidar:/home/FritzBox/FB7490/firmware/113.06.93 # openssl x509 -text -noout -in etc/default.Fritz_Box_HW185/avm/tr069-default-iad-fritzchen.telekom.de.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4100 (0x1004)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, ST = Hessen, O = Deutsche Telekom AG, OU = Products and Innovation, CN = Telekom RMD-CPE CA I1
        Validity
            Not Before: Jun 21 12:04:18 2016 GMT
            Not After : Sep 27 12:04:18 2026 GMT
        Subject: C = DE, ST = Hessen, L = Darmstadt, O = Deutsche Telekom AG, OU = Products and Innovation, CN = iad-avmfb7490.telekom.de, emailAddress = [email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a8:36:8a:31:96:6f:f2:1d:23:98:34:f3:d7:64:
                    56:5b:eb:f4:f1:0e:73:f4:33:33:5d:b8:96:ea:ab:
                    90:eb:74:db:81:fc:16:42:e9:51:eb:d7:7f:1b:b8:
                    c6:a6:cd:dd:b3:f5:d0:e7:5b:c7:f4:6c:94:75:f0:
                    e0:98:42:c2:3d:90:31:ec:58:df:1a:d0:90:03:6d:
                    be:3b:f2:f6:6f:2a:ea:4b:3a:78:3f:7e:04:8b:af:
                    3f:20:16:c3:f8:aa:b3:dc:af:5f:f0:69:dc:c8:02:
                    fb:79:37:22:6a:a2:42:20:7d:17:a6:b2:f7:38:ef:
                    1a:9c:b1:dc:d9:eb:92:80:ea:13:fb:9d:82:b2:40:
                    ea:e1:2c:e6:e7:79:9e:6a:24:f5:f7:f8:8c:c2:09:
                    db:33:32:3c:77:73:c9:eb:db:8d:b1:cf:dc:ca:42:
                    7d:2f:16:0c:a9:63:fd:47:d6:31:a2:90:12:2b:f2:
                    5c:c4:d3:da:76:eb:ff:f0:9e:72:b3:57:a6:1d:5e:
                    85:41:f0:b3:1c:9d:48:66:b2:a7:7a:1e:64:95:bd:
                    92:1d:16:dd:78:e7:5a:0f:de:2a:58:fe:f2:99:65:
                    11:99:90:1c:44:48:79:f9:b1:dd:79:b6:06:32:18:
                    b4:cc:31:22:ef:cf:e3:16:13:28:aa:86:56:bc:e9:
                    4e:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
            Netscape Comment:
                OpenSSL Generated Server Certificate
            X509v3 Subject Key Identifier:
                F1:B8:0A:72:0A:6E:A8:E9:83:BA:01:8D:DB:9C:29:BB:12:AA:99:13
            X509v3 Authority Key Identifier:
                DirName:/C=DE/ST=Hessen/L=Darmstadt/O=Deutsche Telekom AG/OU=Products and Innovation/CN=Telekom RMD-CPE KLUK Authority RootCA 1
                serial:10:00

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha256WithRSAEncryption
         01:f6:61:f2:71:73:87:a0:9a:e0:3a:b8:51:58:f2:5a:d7:c0:
         44:77:a0:e6:22:ef:c4:0f:f1:c4:14:e7:e2:f0:10:22:54:65:
         30:43:67:65:5e:2c:39:37:7c:a0:62:ae:da:a8:05:a1:98:9b:
         bb:08:ff:4f:25:59:87:c1:cd:19:81:d5:ee:b4:24:36:df:d5:
         f9:69:ab:e2:03:c5:17:71:45:cd:48:f8:fe:21:be:aa:2b:22:
         77:ba:bc:17:fa:1a:1a:10:b6:04:d8:db:1e:17:e0:7b:13:01:
         67:aa:8f:ce:68:a0:bf:6c:b5:e5:a5:4c:19:96:c7:fb:75:59:
         d0:7b:d8:3f:16:38:9e:bb:0e:5d:87:6e:22:9f:30:3f:fc:88:
         f8:b1:06:62:ba:03:21:9f:a6:6a:2b:58:66:ab:b4:21:4a:6e:
         0b:f0:c2:9d:6d:cd:e0:c8:0e:c3:5c:d6:1c:a7:9a:8d:5a:8f:
         03:d4:84:e0:5d:a7:ca:7e:61:3d:f1:23:00:4d:a5:7d:a5:ad:
         94:fd:cc:49:b7:f6:b9:c3:fe:d1:07:82:c9:bd:f4:36:ae:b3:
         c5:29:89:8c:0e:d3:79:a1:a5:1b:52:76:20:f0:3a:02:56:ee:
         2c:15:d4:df:d6:1e:e2:40:a5:cf:8d:f2:2f:14:d0:ca:2b:85:
         14:36:fc:b0:c7:e1:d2:87:5e:41:24:39:7d:d4:96:59:b3:93:
         e2:03:15:aa:25:ff:e7:6a:d6:bb:62:c4:e9:e4:78:3c:0c:e1:
         7c:90:12:03:85:64:6f:e5:fd:68:48:9e:7a:40:f2:de:ff:e4:
         f1:b5:8c:53:31:82:cb:5e:49:a8:ed:e9:d9:9c:d3:56:84:77:
         c3:5d:25:6f:a0:6c:50:72:da:a3:13:a3:65:a3:fb:f1:fc:c1:
         ea:f7:0b:2a:6d:19:2f:fa:d0:2c:93:bb:0d:e0:f9:bf:07:ec:
         6d:91:fd:d8:4a:50:29:84:ce:dc:91:46:4b:7d:db:a1:3b:b0:
         eb:24:50:3d:f6:1a:4e:ff:01:2d:38:2d:de:9b:81:c6:f6:40:
         de:05:a4:c7:7c:ff:d9:da:1c:cc:ea:e4:ae:ed:7b:07:7d:42:
         ff:b7:5e:34:3d:eb:7f:13:b5:7d:4d:01:4e:bf:48:d8:7f:8a:
         2f:35:fe:b2:d8:6d:0d:e5:75:4c:2d:88:62:6e:9c:4b:19:38:
         86:8d:f0:6d:d6:c5:47:a9:b4:69:36:15:d5:67:a0:b4:98:71:
         a9:56:45:d5:a3:51:9c:ef:a8:b5:09:42:1e:ee:1c:ce:a1:0c:
         56:ee:8a:9a:1d:86:72:bc:fd:d6:2f:81:25:e0:9b:0f:1a:bf:
         1d:1c:01:dd:b5:e1:68:2e
vidar:/home/FritzBox/FB7490/firmware/113.06.93 #

Der Key dazu ist zwar (per se) erst mal verschlüsselt, aber wie das nun mal so ist, wenn man solche Kennwörter irgendwo fix einbauen muß: Es läßt sich (leicht) ermitteln.

==============================================================

Hinsichtlich des "richtigen Abschaltens" muß man mit seinen Aussagen halt etwas vorsichtig sein, wenn man sich nicht (ohne Not) zu weit aus dem Fenster lehnen will und am Ende Fake-News verbreitet. Ich habe leider keinen 1&1-Anschluß (mehr) - und der einzige Anschluß bei 1&1, auf den ich noch Zugriff habe, läuft mit einer 7390 mit Firmware 06.83. Daher kann ich für alles ab 06.98 dafür auch nur spekulieren, bei der erwähnten 06.83 ist es jedenfalls immer noch das folgende Bild in der "tr069.cfg", auch wenn im GUI alle Zugriffe durch den Provider deaktiviert wurden:

tr069cfg {
        enabled = yes;
        litemode = yes;
        tr181_support = no;
        dhcp43_support = yes;
        igd {
                DeviceInfo {
                        ProvisioningCode = "005.000.000.000";
                        FirstUseDate = "2014-03-07 14:xx:xx";
                }
                managementserver {
                        url = "https://acs2.online.de";
                        username = "SECRET";
                        password = "SECRET";
                        URLAlreadyContacted = yes;
                        LastInformReq = "2018-05-10 15:02:xx";
                        LastSuccessfulContact = "2018-05-10 15:02:xx";
                        URLbyDHCPIface = "";
                        PeriodicInformEnable = no;
                        PeriodicInformInterval = 0;
                        PeriodicInformTime = "1970-01-01 01:00:00";
                        UpgradesManaged = no;
                        ACSInitiationEnable = no;
                        ACSInitiationPorts = "46000+1000";
                        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;
        lab {
                Enable = no;
                URLAlreadyContacted = no;
                PeriodicInformInterval = 0;
                Features = 65535;
        }
}

Es ist also nicht mehr ganz das alte Bild (iirc), weil inzwischen nicht mehr mit "enabled = no;" die Abschaltung "vorgespielt" wird in der "tr069.cfg" ... stattdessen ist es jetzt "yes", während parallel der "litemode" aktiviert ist. Wenn die "tr069.cfg" bei den anderen Informationen nicht lügt, überträgt die Box aber auch mit diesen Einstellungen weiterhin Informationen per TR-069 an den Provider (LastInformReq, LastSuccessfulContact) und ob bzw. wie gut die "Sperre" gegen Zugriffe von der Providerseite hier arbeitet (beim TR-069 baut ja das CPE die Verbindung auf und der Server hat seinerseits mit entsprechenden Antworten die Möglichkeit, zusätzliche Funktionen aufzurufen), kann man nur schwer selbst testen und so muß man sich hier erst einmal voll und ganz auf AVM verlassen.

Die Tatsache, daß im GUI aber nach wie vor von "sichere (verschlüsselte) Übertragung" die Rede ist, während in der originalen Firmware von AVM (113.06.92) sich immer noch 12 Fundstellen (allerdings nur für drei verschiedene Server in verschiedenen Profilen) für HTTP-URLs (von ACS) - also TR-069 ohne TLS - befinden:

vidar:/home/FritzBox/FB7490/firmware/113.06.93 # tar -x -f etc/default.Fritz_Box_HW185/avm/providers-049.tar -O | grep "http://" | wc -l
12
vidar:/home/FritzBox/FB7490/firmware/113.06.93 # tar -x -f etc/default.Fritz_Box_HW185/avm/providers-049.tar -O | grep "http://"
                        url = "http://trixi.netcologne.de/initial";
                        url = "http://trixi.netcologne.de/initial";
                        url = "http://80.228.251.206/init/avm";
                        url = "http://acs.be-converged.com:9675";
                        url = "http://acs.be-converged.com:9675";
                        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://80.228.251.206/live/CPEManager/CPEs/Auth_Basic/avm";
                        url = "http://80.228.251.206/init/avm";
                        url = "http://trixi.netcologne.de/initial";
vidar:/home/FritzBox/FB7490/firmware/113.06.93 #

, stimmt mich da genauso wenig fröhlich wie die fehlende Information durch AVM (s. Screenshot und m.W. hat sich das auch in der Labor-Reihe noch nicht geändert, was bei mir wieder die Frage der DSGVO und des Endes der Übergangszeit am 25.05.2018 aufkommen läßt, wenn es um die Übermittlung von Daten an Dritte durch das FRITZ!OS geht), daß auch bei angeblich ausgeschaltetem TR-069 da wohl immer noch eine Kommunikation stattfindet und was dabei nun genau an den Provider übermittelt wird.

Normalerweise kann man beim TR-069 ja seine Wünsche "anmelden", welche Werte des Gerätes man gerne in so einem Inform-Request sehen würde - daher verstehe ich schon, daß AVM hier keine genaue Auskunft geben kann, was tatsächlich abgefragt wird. Aber die Information, was abgefragt werden könnte, die sollte AVM geben können ... als ich das Thema "TR-069-Dokumentation" mal in einem Telefonat mit einem AVM-Verantwortlichen (also nicht "nur" mit dem Support und das Gespräch fand auch schon vor mehr als drei Jahren statt) angesprochen habe, hieß es dazu nur, daß darin auch "Geheimnisse" anderer Firmen enthalten wären (damals ging es wohl in erster Linie um die WLAN-Hotspots bei den DOCSIS-Boxen, wobei das auch in den EuroPacketCable-Standards spezifiziert ist) und man das deshalb nicht veröffentlichen würde.

Keine Ahnung, wie man heute und im Angesicht des Endes der Übergangszeit für die DSGVO zu diesem Thema steht ... aber - da ich es hier schreibe - für mich auch ein Anlaß, da einfach noch einmal bei AVM zu diesem Thema nachzufragen (in zwei Wochen). Anders als bei irgendwelcher anderen Software, die man auf einem Gerät selbst installiert, gibt es bei AVM ja eben keine EULA (mal vollkommen abgesehen von deren (Un-)Wirksamkeit im Einzelfall) oder irgendetwas anderes, mit dem man pauschal schon durch den Einsatz des Routers einer Datenübermittlung irgendwohin zustimmen würde/könnte (die über den Rahmen des technisch Erforderlichen hinausgeht, denn das Übermitteln der Login-Daten an den Provider dürfte klar "notwendig" sein).

==============================================================

Die zuvor vorhandenen, offenkundigen Lücken in der TR-069-Implementierung, wo über passend formulierte Parameter (z.B. beim Kennwort für den Export) zusätzliche Shell-Kommandos in die Box eingeschmuggelt werden konnten, hat AVM m.W. inzwischen (im zweiten Anlauf) dann komplett geschlossen. Wie weit es da aber zusätzliche Änderungen gab, damit ein Provider auch über TR-069 nicht länger an die Daten der Kunden gelangen kann, weiß ich nicht. Es gab/gibt ja in der TR-069-Implementierung die Möglichkeit, sich die Konfiguration der Box (das, was man als "Export-Datei" auch erhält) zu verschaffen:

vidar:/home/FritzBox/FB7490/firmware/113.06.93 # strings usr/share/ctlmgr/libtr069.so | grep -A 11 "Firmware Upgrade Image"
1 Firmware Upgrade Image
3 Vendor Configuration File
X 00040E VPN.CFG
%s(): filetype (%d) not allowed - deny
X 00040E Hotspot-StationList
X 00040E WLAN-Supportdata
X 00040E DSL-Supportdata
CONFIG_DSL
Vendor Configuration File
X 00040E Supportdata
X 00040E Webstat
X_AVM_DE_GetBasicInfo
vidar:/home/FritzBox/FB7490/firmware/113.06.93 #

Das sind die "Dateitypen", die vom TR-069 für den Up- und Download verstanden werden, zumindest stehen sie so in der "libtr069.so" und mit etwas Variation kriegt man auch heraus, was AVM ansonsten noch so für TR-069 an "vendor extensions" bei den Dateitypen vorgesehen hat:

vidar:/home/FritzBox/FB7490/firmware/113.06.98-55294 # strings usr/share/ctlmgr/libtr069.so | grep -i 00040E
00040E-000000000000
X 00040E VPN.CFG
X 00040E Hotspot-StationList
X 00040E WLAN-Supportdata
X 00040E DSL-Supportdata
X 00040E Supportdata
X 00040E Webstat
X 00040E DSL Diagnose
X 00040E LTE DumpFile
X 00040E Mesh Topology
X 00040E DOCSIS Diagnose
vidar:/home/FritzBox/FB7490/firmware/113.06.98-55294 #

Auch die Kommandos, um über "tr069fwupdate" die Konfiguration auszulesen (und zu versenden) bzw. zu importieren, sind nach wie vor zu finden:

vidar:/home/FritzBox/FB7490/firmware/113.06.93 # strings usr/share/ctlmgr/libtr069.so | grep tr069fwupdate
tr069fwupdate configimport
/usr/bin/tr069fwupdate configexport '%s' > /var/tmp/configexport
/usr/bin/tr069fwupdate configexport > /var/tmp/configexport
tr069fwupdate check_configimport
tr069fwupdate
%s(): failed to initialize 'tr069fwupdate', error code %d
%s(): 'tr069fwupdate' initialized successfully.
/usr/bin/tr069fwupdate configexport | %s
/usr/bin/tr069fwupdate configexport > %s; /usr/bin/ftpput%s '%s'%s '%s' -P %d '%s' '%s' %s 2>/var/dl_err
vidar:/home/FritzBox/FB7490/firmware/113.06.93 #

Es ist also sicherlich nicht ganz abwegig zu mutmaßen, daß da über das "Vendor Configuration File" nach wie vor der komplette Zugriff auf die Konfigurationsdatei möglich ist und auch wenn das beim "ftpput" nicht direkt eine Pipe ist, wo die Ausgabe landet (in der Zeile darüber dann schon, das wollen wir auch nicht aus dem Auge verlieren), so ist der direkte Aufruf von "ftpput" nach einem "configexport" schon recht eindeutig. Worum es sich bei der Ausgabe von "tr069fwupdate configexport" am Ende handelt, ist einerseits bekannt und andererseits kann das jeder selbst (mit einer Shell auf der Box) probieren. Ich habe schon an anderen Stellen gezeigt, daß das 1:1 die Export-Datei ist, hier mit ein paar "Ausschmückungen" in Form von zusätzlichen MIME-Headern vor den Daten.

==============================================================

Zumindest bei den "erweiterten Support-Daten" hat AVM schon vor einiger Zeit dann nachgebessert und inzwischen wird die Einstellung dafür nicht mehr so gespeichert, daß damit auch automatisch der Provider die Support-Daten inkl. TFFS-Dump erhält, denn auch über TR-069 ist das Abrufen der Support-Datei wohl möglich (oben als "X 00040E Supportdata"), die notwendigen Aufrufe finden sich jedenfalls auch in der "libtr069.so":

vidar:/home/FritzBox/FB7490/firmware/113.06.98-55294 # strings usr/share/ctlmgr/libtr069.so | grep supportdata
/bin/supportdata
/bin/supportdata.argo
vidar:/home/FritzBox/FB7490/firmware/113.06.98-55294 #

Spannenderweise ist das aber nichts, woran AVM den Kunden selbst teilhaben lassen möchte, denn über TR-064 gibt es diese Datei (jedenfalls soweit es mir bekannt ist) dann wieder nicht.

Jedenfalls ist das Ermitteln der "Box-Identität" für das Entschlüsseln des "rohen TFFS-Inhalts" (und auch der Daten aus einer Export-Datei ohne Kennwort, wie das bei einigen der oben gezeigten "tr069fwupdate"-Aufrufe ja der Fall wäre, wenn da nach dem "configexport" kein Kennwort angegeben ist) dann auch nur noch eine Fingerübung:

[Info] Wie funktioniert eigentlich die AVM-Verschlüsselung für die Einstellungen?

Die "maca" steht in jeder Support-Datei und läßt sich notfalls auch aus anderen MAC-Adressen einer FRITZ!Box ableiten, da dort bekanntlich immer mehrere MAC-Adressen (u.a. auch für das WLAN) in sequentieller (wenn auch abweichender) Folge verwendet werden. Den zusätzlich notwendigen "wlan_key" kriegt man im TFFS-Dump auch "frei Haus" und kann ihn sich ansonsten relativ leicht besorgen. Notfalls setzt man die Box auf Werkseinstellungen (ich unterstelle mal, daß darunter die TR-069-Kommunikation nicht direkt leidet, was z.B. bei einer Box mit "provider_additive"-Konfiguration gegeben wäre) und liest dann deren WLAN-Konfiguration noch einmal aus (in der ist die aktuelle Passphrase dann auch unverschlüsselt enthalten) - zum Spurenverwischen kann man hinterher ja die erste Konfiguration wiederherstellen.

==============================================================

Mit dem LabACS ist dann beim TR-069 noch einmal eine neue Qualität eingezogen, das verwendet AVM selbst für die "Telemetrie" der FRITZ!Boxen. Dabei werden u.a. auch Daten gesammelt (als "key performance indicators" - KPI), die dem Provider (vermutlich!) nicht zur Verfügung stehen. Da diese gesamte Kommunikation mit AVM aber nur noch verschlüsselt erfolgt (Applaus), braucht es gehörigen Aufwand, da in die tatsächlich übermittelten Daten zu schauen und man ist ansonsten auf Schlußfolgerungen angewiesen ... denn die Frage, warum AVM zusätzliche Daten erzeugt auf der Box (z.B. in "/sbin/kpi" in den Labor-Versionen), diese über das Mesh sammelt (es gibt jetzt sogar zusätzliche "log_server"-Prozesse, die Daten per UDP entgegennehmen und sie in Protokolldateien schreiben - siehe u.a. "sbin/wifi_offload_link.sh" in der Labor-Reihe) und sie (die KPI) dem Kunden selbst dann (m.W.) doch nicht anzeigt, ist sicherlich erlaubt und die naheliegendste Vermutung wäre es da nun mal, daß diese Daten dafür gedacht sind, an AVM gesendet zu werden.

==============================================================

Ich habe mal "über Eck" von einer Studie (an einer Uni) gehört, bei der untersucht werden sollte, wie Provider die TR-069-Funktionen nun tatsächlich nutzen ... ob da auch eine Untersuchung dabei war, was bei einzelnen Geräten an Funktionen nun implementiert ist und was nicht, weiß ich genauso wenig, wie mir der Stand/Fortschritt da bekannt ist und die Frage, ob das den Machern recht wäre, wenn man sie "benennt" (daher so vage in den Worten).

Wenn die Studie nicht veröffentlicht werden sollte, bis das FRITZ!OS 7 dann großflächig auf dem Markt ist bzw. wenn die Frage, was eigentlich "geht" da keine wirkliche Rolle spielt, habe ich mir eigentlich fest vorgenommen, da mal einen etwas größeren Versuchsaufbau zu machen und die Boxen selbst zu belauschen bzw. mit einem eigenen ACS erneut zu testen - schon die Änderungen von FRITZ!OS 7 (die bei der Studie naturgemäß keine Priorität haben dürften) wären wohl ein ausreichender Grund.

Solange man für TR-069 kein gesondertes (WAN-)Interface aufmacht, funktioniert das nämlich auch ganz gut, wenn man der FRITZ!Box einen ACS auf ihrer LAN-Seite "verordnet" ... man muß also nicht zwangsläufig auf der WAN-Seite testen und kann so eine kleine, vorbereitete Test-Suite auch auf einem kleinen Einplatinen-Computer per LAN-Kabel laufen lassen - wenn man nur die Fähigkeiten testen will und nicht die Frage klären möchte, was davon tatsächlich genutzt wird.

Erst wenn man das dann wieder beisammen hat, kann man sich die vorhandenen Funktionen noch einmal ansehen und sich überlegen, welche davon nun welche Lücken aufweisen könnte und ob/wie man die ggf. ausnutzen könnte (auch als "Provider"), um die Box des Kunden ohne seine Kenntnis zu "übernehmen". Die meisten "leichten" Wege zur Shell (bzw. zu Shell-Kommandos) für den Provider sind jedenfalls (m.W.) dicht - andererseits ist es ja das Primärziel eines Angreifers, überhaupt erst einmal Zugriff auf das Gerät zu erlangen und den kriegt ein Provider (zumindest nach meiner Überzeugung, auch wenn es für aktuelle Versionen nur Theorien und Schlußfolgerungen aus sichtbaren Fundstellen im Code sind) ja per TR-069 schon auf dem Silbertablett.

==============================================================

Was aber nach meiner Ansicht durchaus positiv zu bewerten ist: Die Zugriffe von AVM und/oder des Providers werden jetzt wohl sauber im Event-Log protokolliert (ich unterstelle mal, daß es da keine "backdoor" mit "pssst" gibt) und können damit (ohne zusätzlichen Aufwand beim Spurenverwischen, was wohl wieder Shell-Kommandos erfordern würde) nicht mehr klamm und heimlich erfolgen. Andererseits setzt das eben auch einen Besitzer der Box voraus, der sich tatsächlich für Protokolle so weit interessiert, daß er sie sich (a) zuschicken läßt und sie (b) dann auch auswertet bzw. auswerten läßt (das kann man ja automatisieren).

Hier sollte AVM auch schleunigst die optionale, lokale Protokollierung über einen Syslog-Server nachrüsten ... den gibt es heute in immer mehr Haushalten, in Gestalt von NAS oder zusätzlichen Einplatinen-Computern oder Android-Sticks, usw. und der ist nicht so leicht zu übertölpeln wie ein E-Mail-Versand, dem ich nur als erstes die Credentials wegnehmen muß, damit der (verzögerte) Versand nicht mehr funktioniert und von den - vor meinem Einbruch protokollierten - Spuren nichts mehr den Besitzer erreicht. Das ist zwar auch noch nicht wasserdicht - aber ein Fortschritt im Kampf gegen unbemerkte bzw. leicht zu verschleiernde Angriffe.

 

[AndreasR]

Hallo,

ich hatte gestern einen seltsamen Effekt und würde gerne wissen, ob das durch TR-069 ausgelöst werden konnte:

Nach dem Update die Firmware der 7390 auf die aktuelle Wartungs-Version (zwecks DSL-Kompatibilität) hat es die VoIP-Konfiguration durcheinandergehauen: Die ersten Einträge in der Übersicht "Eigene Nummer" der Fritzbox standen auf dus.net und waren aktiv, aber mit VoIP-Kennungen, die ich gar nicht bei dus.net habe. Ein Anruf dort bestätigte, dass die Kennungen definitiv nicht von dus.net stammen. Tatsächlich waren sie aber von 1 &1. Das sind zwei Nummern, die wahrscheinlich vorher gar nicht in der Fritzbox eingetragen waren, da ich sie nicht nutze. Sicher bin ich aber nicht. Offenbar sind jedenfalls 1 & 1-Zugangskennungen in die Felder gerutscht, aber die Überschrift stand weiter auf "dus.net".

Zwei von vier dus.net-Nummern fehlten in der Box, die musste ich neu eintragen. Die dritte 1 & 1-Nummer, die ich vorher schon verwendet habe, war weiterhin aktiv.

Kann das TR-069 gewesen sein?

Die beiden ungenutzten 1 & 1 -Nummern habe ich jetzt in der Box angelegt, aber als inaktiv gekennzeichnet.

Über die Oberfläche kann ich TR-069 nicht abschalten. Wenn ich das Häkchen rausnehme und über übernehmen drücke, ist das Häkchen sofort wieder da.

Grüße
Andreas

 

[PeterPawn]

Zur Frage des "Auslesens" und der "Reihenfolge" bei der VoIP-Konfiguration über TR-069/TR-064 gibt es einen anderen Thread (EDIT) Beitrag weiter vorne... den dortigen Bemerkungen zur Verwaltung von Rufnummern über "Indizes" ist (m.W.) nichts Neues hinzuzufügen - der andere Thread drehte sich irgendwie um zu hohe Kosten bei der Telefonie, weil nach der Aktualisierung durch den Provider die "Vorauswahl" nicht mehr zum VoIP-Account paßte. (EDIT) es hätte jemandem, der den Thread gerade erst gelesen hat, eigentlich auffallen können, daß es sich tatsächlich um diesen Thread hier handelte ... aber eben auch, daß ich in #20 bereits den Versuch unternommen habe, die "Probleme" für den Provider zu beschreiben, wenn der Kunde sich nicht entscheiden kann, wer denn nun eigentlich für die VoIP-Konfiguration zuständig sein soll.

Wer parallel zu einer automatischen Konfiguration auch noch "von Hand" weitere Nummern eintragen will oder muß, der muß halt auch irgendwie dafür sorgen (notfalls mit "dummy entries"), daß diese nicht auf den ersten Positionen landen, weil der Provider (zumindest über die Interfaces für VoIP-Accounts) gar keine Möglichkeit hat, die bestehenden Accounts so auszulesen (d.h. inkl. Kennwort), daß er sie ohne weiteres auf anderen Positionen wieder einrichten könnte (das heißt aber noch nicht, daß er das bei TR-069 jetzt gar nicht auslesen könnte, nur halt nicht über die VoIP-Konfigurationsinterfaces).

 

[AndreasR]

Hallo Peter,

Zur Frage des "Auslesens" und der "Reihenfolge" bei der VoIP-Konfiguration über TR-069/TR-064 gibt es einen anderen Thread ...

Magst Du den bitte verlinken? Über die Suchfunktion finde ich zuviel und weiß nicht, welche Diskussion Du meinst.

Danke
Andreas

 

[PeterPawn]

Ich habe den Link auch nicht ... müßte also genauso über die Suchfunktionen gehen. Mehr als das oben im ersten Absatz Geschriebene zum "Thema" des Threads weiß ich auch nicht ... dafür gibt es hier einfach zuviele. Die einzige Zusatzinformation, die mir da noch einfiele, wäre die Beschränkung auf dieses Kalenderjahr, denn iirc es ist noch nicht sooo lange her.

EDIT: OK, daß es nun mal genau dieser Thread hier ist, auf den ich mich dabei bezogen habe (konkret auf #20), hätte Dir ja auch auffallen müssen/können, wenn Du den Thread vor Deinem eigenen Beitrag komplett gelesen hast ... da müßte das bei Dir eigentlich noch deutlich "frischer" in der Erinnerung sein, als bei mir - es sind immerhin schon wieder sieben Wochen vergangen, seit ich versucht habe, das zu erklären.

 

[AndreasR]

Hallo,

danke! Ich muss zugeben, bei der Länge der Beiträge nicht alles gelesen zu haben, schon weil ich Deine Ausführungen nur teilweise verstehe.

Jedenfalls habe ich jetzt *121# bis *123# mit den drei 1 & 1-VoIP-Nummern versehen, wobei das nicht die drei obersten Positionen der Liste in der Fritzbox sind. Damit sollte das Risiko des Überschreibens seitens des Providers minimal sein, richtig?

Grüße
Andreas

 

[PeterPawn]

Wenn meine Einschätzungen richtig sind und AVM da nichts großartig mehr ändert bzw. geändert hat, würde ich das so sehen ... ja.

Wobei ich selbst (schon aus Gründen der "Erweiterbarkeit") noch eine größere "Lücke" zu den automatisch konfigurierten Nummern lasse, wenn ich irgendwo auf eine solche Konstellation treffe.

Angesichts des "Löschens" der alten Einträge in den DOCSIS-Boxen (bei PACM für die SIP-Konfiguration), wo die Indizes von 1 bis 20 gehen, kann man m.E. davon ausgehen, daß die AVM-Firmware bis zu 20 Einträgen in jedem Falle arbeitet ... damit baue ich das i.d.R. dann "von hinten" auf, auch bei den DSL-Boxen (wo es dieses Löschen von 1 bis 20 nicht gibt).

 

[Hans Juergen]

Jedenfalls habe ich jetzt *121# bis *123# mit den drei 1 & 1-VoIP-Nummern versehen, wobei das nicht die drei obersten Positionen der Liste in der Fritzbox sind. Damit sollte das Risiko des Überschreibens seitens des Providers minimal sein, richtig?

Ja, so war es in der Praxis bei mir. Ich hatte nach der Konfiguration von Delmont-Nummern später noch eine 1&1 hinzugefügt, die wurde dann bei einem tr-069-Test nach vorn gezogen...

 

[GregorNord]

Ein guter Bekannter von mir hatte jetzt im April 2019 das gleiche Problem.

Ich hatte ihm einen Rufnummereintrag von Dellmont eingetragen.

Einige Zeit später bat ich ihn, das mit der Anwahl von 0310 oder 0311 noch mal zu prüfen. Und es meldete sich 1&1 für diese Rufnummer!

Im Logfile der privaten Fritz.Box war ein Eintrag weniger und der Eintrag unter der neuen Nummer hatte 1&1 als SIP-Adresse. Die Änderung hat in der ersten Nacht zwischen 3 und 4 Uhr stattgefunden.

Frage an alle 1&1 Kunden, da mein Bekannter sich nicht daran erinnern kann, so etwas zugelassen zu haben:
weiß einer von Euch, ob sich 1&1 das Einverständnis für ein solches Handeln hat geben lassen? Ist das überhaup rechtmäßig? Wie geschrieben, die Fritz.Box ist kein Eigentum von 1&1, ebensowenig die Daten des Bekannten.

Nun warten wir die Rechnung ab. Sollte 1&1 nicht aufzeigen können, dass sie dazu das Einverständnis haben, so werden wir wohl klagen, erst strafrechtlich und dann zivil.
Wir sehen §§303a (Datenmanipulation) und 263a (Computerbetrug) StGB als erfüllt an. Der Versuch ist bei Computerbetrug bereits strafbar.

2017 habe ich gegen ein anderes Unternehmen Strafanzeige nach §240 (Nötigung) gestellt, weil die sich quer stellten. Die Staatsanwaltschaft hat wunderbar geholfen, als die Kontakt aufnahmen. Und alles ist kostenfrei.

 

[ciesla]

Ist normal und "schon immer" üblich bei 1&1!
In den Einstellungen müssen die Anbieterdienste abgeschaltet werden, damit das Spionageprotokoll von 1&1 abgeschaltet wird.
Hilft aber auch nicht 100%. Der Anbieter kann die Box aus der Ferne auch dann noch neu starten.