@KunterBunter:
Das ist richtig, wobei es den "Zertifikatspeicher" der Box nicht wirklich gibt.
Es sind halt lediglich einige wenige vorkonfigurierte Dateien mit Zertifikaten von (öffentlichen und provider-eigenen) CAs im Filesystem, die man beim Modifizieren der Firmware auch jederzeit ändern kann/könnte.
Das ganze Thema TR-069 und SSL ist ohnehin mehr "Beruhigung" der Kunden als wirksame Sicherung ... hier sicherlich nicht der richtige Platz, ich wage es trotzdem mal wieder, es gerät i.m.A. zu leicht in Vergessenheit.
Falls doch mal wieder die Frage aufkommen sollte, welche Datei wozu (wahrscheinlich) dient und welche CAs dort hinterlegt sind (FB7390, 06.20, AVM):
1. /etc/jasonii_root_ca.pem
- self-signed Root-Zertifikat von AVM, wird für MyFRITZ!-Aktionen genutzt, um die Identität des AVM-Servers sicherzustellen - wird auch wirklich geprüft, deshalb muß zur Analyse der MyFRITZ!-Kommunikation auch diese Datei ersetzt werden
- einzige sichtbare Referenz erfolgt aus '/lib/libjasonclient.so'
Code:
Certificate 1
Subject : /C=DE/ST=Berlin/L=Berlin/O=AVM Computersysteme Vertriebs GmbH/OU=IT/CN=AVM Root CA Certification Authority
Issuer : self-signed
Valid from : Feb 1 13:37:24 2012 GMT
Valid until : Jan 29 13:37:24 2022 GMT
2. /etc/default/[provider]/common_root_ca.pem
- der Inhalt der Datei ist in allen drei Brandings identisch
- diese Datei wird nur aus voipd heraus angesprochen - wenn nicht irgendwo anders der Zugriff verschleiert werden sollte
- für '1und1'- und 'avm'-Branding stimmt der Inhalt dieser Datei auch noch mit dem der 'root_ca.pem' überein
Code:
Certificate 1
Subject : /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Issuer : self-signed
Valid from : Aug 22 16:41:51 1998 GMT
Valid until : Aug 22 16:41:51 2018 GMT
Certificate 2
Subject : /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
Issuer : self-signed
Valid from : Aug 1 00:00:00 1996 GMT
Valid until : Dec 31 23:59:59 2020 GMT
Certificate 3
Subject : /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Issuer : self-signed
Valid from : Jan 29 00:00:00 1996 GMT
Valid until : Aug 1 23:59:59 2028 GMT
Certificate 4
Subject : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Issuer : self-signed
Valid from : May 21 04:00:00 2002 GMT
Valid until : May 21 04:00:00 2022 GMT
Certificate 5
Subject : /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
Issuer : self-signed
Valid from : Nov 8 00:00:00 2006 GMT
Valid until : Jul 16 23:59:59 2036 GMT
Certificate 6
Subject : /O=Arcor AG Co. KG/CN=acs.arcor-ip.de
Issuer : self-signed
Valid from : Jul 19 10:03:34 2006 GMT
Valid until : Aug 30 10:03:34 2036 GMT
3. /etc/default/[provider]/root_ca.pem
- bei '1und1' und 'avm' identisch mit 'common_root_ca.pem', die u.a. Liste gilt also nur für 'otwo'-Branding
Code:
Certificate 1
Subject : /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Issuer : self-signed
Valid from : Aug 22 16:41:51 1998 GMT
Valid until : Aug 22 16:41:51 2018 GMT
Certificate 2
Subject : /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
Issuer : self-signed
Valid from : Aug 1 00:00:00 1996 GMT
Valid until : Dec 31 23:59:59 2020 GMT
Certificate 3
Subject : /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Issuer : self-signed
Valid from : Jan 29 00:00:00 1996 GMT
Valid until : Aug 1 23:59:59 2028 GMT
Man sieht, sie ist etwas kürzer und enthält das self-signed-Zertifikat für den Arcor-ACS
nicht, ebenso wenig das GeoTrust- und das VeriSign-G5-Zertifikat.
Nur bei 'avm'-Branding gibt es dann noch ein zusätzliches Root-Zertifikat mit dem Namen '/etc/default/avm/root_ca_mnet.pem':
Code:
Certificate 1
Subject : /C=DE/L=Muenchen/O=M-net Telekommunikations GmbH/OU=Internet Services/CN=CA/[email protected]
Issuer : self-signed
Valid from : May 26 10:18:01 2009 GMT
Valid until : May 24 10:18:01 2019 GMT
All diese Zertifikat-Listen
könnten auch über die tr069.cfg als 'trusted_ca_file' herangezogen werden, in toto werden aber nur bei 4 Provider-Einstellungen (1&1, GMX und zwei von den O2-Einstellungen) überhaupt andere
wirksame Einstellungen vorgenommen, ansonsten wird dort immer '/etc/default/avm/root_ca.pem' verwendet.
Bei 1&1/GMX wird dann auf /etc/default/1und1/root_ca.pem geändert, was angesichts des Dateiinhalts auch nur wie eine Änderung der Liste
aussieht, aber genau bei denselben CAs landet. Die 1&1-Einstellungen existieren auszugsweise (zumindest die ACS-Adresse und der Pfad zur CA-Liste) auch noch einmal direkt im ctlmgr, das dürfte vermutlich mit ein Grund sein, warum bei der Auswahl von 1&1 als Provider in der Box das TR-069 nie wirklich ganz ausgeschaltet wird/werden kann (das ist vom Branding vollkommen unabhängig, mithin auch davon, ob die Box über 1&1 beschafft wurde oder nicht).
Bei den beiden O2-Einstellungen kommt dann wirklich die Datei im 'otwo'-Verzeichnis zum Einsatz, die aber - wenn man es sich mal genau überlegt - nur Zertifikate ausschließt und keine neuen CAs hinzufügt. Damit dürfte diese Einstellung dann doch nicht ursächlich gewesen sein, wenn netsn00p keine Telefonie-Einstellungen erhalten hat und es dürfte eher das falsche Branding beim ersten Kontakt gewesen sein (das wird - wenn ich mich richtig erinnere - im INFORM-Request mitgesendet, genauso wie die Seriennummer - also bei FRITZ!Boxen die MAC-Adresse).
Die Identitäts-Sicherung des ACS (seitens der Box) bei der ganzen TR-069-Kommunikation beschränkt sich also darauf, daß der in der tr069.cfg angegebene Name des ACS (auch nicht immer, man kann die Zertifikatsprüfung in der tr069.cfg sogar noch explizit abschalten (verify_server = no), was bei einigen Providern auch passiert - auch bei Einsatz einer HTTPS-URL) mit dem im Zertifikat übereinstimmt. Da das so ziemlich jedes von einer der 5 großen CAs in der root_ca.pem signierte Zertifikat sein kann, ist die SSL-Absicherung der TR-069-Kommunikation im Endeffekt auch nur noch eine Abwehr von "Lauschern". Die Kontaktaufnahme zu einem falschen / gefaketen ACS würde sie nicht unterbinden, genauso wenig wie einen MITM mit einem gültigen Zertifikat, der als "Proxy" für den "richtigen ACS" fungiert.
Daß man genauso gut bei TR-069 auch vollkommen unverschlüsselt kommunizieren
darf (nicht muß oder soll), demonstrieren die Kabel-Anbieter in D (zumindest die zwei größeren, regionale sind nicht gemeint, da kann ich das nicht einschätzen) genauso eindrucksvoll wie leichtsinnig - mit dem Argument, ihre Netze wären ja privat und da könne überhaupt niemand die ACS-Kommunikation manipulieren. Das geht genau so lange gut, bis dort der erste mal wirklich etwas Energie investiert ...
Das zusätzliche File mit dem M-Net-Zertifikat ist insofern auch Humbug, als daß AVM bei M-Net als Provider in der providers-049.tar dort den falschen Pfad '/etc/default/avm
e' hinterlegt hat, das würde also nur auf einer internationalen Box klappen. Dafür ist dann auf einer internationalen 7390 (war jedenfalls vor ca. 3 Monaten noch so) in der Provider-Liste gar kein 'M-Net' enthalten. Da ist also einiges etwas durcheinander bzw. da werden Dateien und Einstellungen durch die Gegend geschleppt, die nur unter sehr selektiven Umständen überhaupt gültig sein mögen.
Dabei wäre genau die Vorgehensweise beim 'M-Net'-Eintrag eine halbwegs sichere gewesen. Wenn nur eine einzige CA das ACS-Zertifikat signieren darf, ist es für einen Angreifer automatisch schwerer, da er von dieser (privaten) CA ein Zertifikat benötigt, um sich - ordentliche Implementierung der anderen Faktoren vorausgesetzt - als MITM dort einzuschalten.
Auch wenn man nur spekulieren kann, für welche zusätzlichen Aufgaben diese Zertifikate-Listen ansonsten noch herangezogen werden, die Tatsache, daß dort ein self-signed-Zertifikat für den Arcor-ACS sicherheitstechnisch auf eine Stufe gestellt wird mit den CA-Certs einiger großer Anbieter, kann ja eigentlich nur bedeuten, daß bei Arcor dort dieselben Sicherheitsvorkehrungen für dieses ACS-Zertifikat gelten, wie bei den großen Anbietern für deren Root-Zertifikate und daß sich AVM davon selbst überzeugt hat. Sonst hätten sie sicherlich nicht die Sicherheit ihrer Geräte (mindestens potentiell) dadurch gefährdet, daß dort auch Zertifikate akzeptiert werden (egal für welchen Zweck das auch sein mag), die von einem privaten Anbieter signiert wurden - noch dazu mit einem nun wirklich keinesfalls sicheren CA-Zertifikat (MD5 und nur 2048-Bit).
Wenn das alles ausschließlich für die TR-069-Kommunikation verwendet wird, ist eine Lösung mit fünf Root-CAs, die für so ziemlich jeden Server ein Zertifikat gegen entsprechende Zahlung ausstellen (natürlich nicht auf fremde Namen) genauso sicher und unnötig, wie eine Zugangssicherung zum Bundestag auf der Basis eines gültigen U-Bahn-Tickets.
Das Argument, daß ein Angreifer den leichteren Weg über "gar keine Verschlüsselung" wählen würde/könnte, macht die SSL-Strecke dabei nicht einen Deut sicherer und wenn dann in Interviews und Stellungnahmen immer wieder darauf verwiesen wird, das wäre doch alles verschlüsselt (was eben bei Kabel-Providern und auch einigen anderen ohnehin glatt gelogen ist, die providers-049.tar der 7390 enthält alleine 15 "nur-HTTP"-URLs für ACS und ein wenig Differenzierung schadet da sicherlich nicht), kann man den dort Agierenden eigentlich nur noch wahlweise zu ihrem Optimismus (und der Unkenntnis der Zusammenhänge) oder einer - schon recht großen - Unverschämtheit gratulieren oder zu mangelnder Kenntnis der deutschen Sprache kondolieren, denn zwischen "das könnte alles verschlüsselt sein" und "das ist alles verschlüsselt" besteht eben ein himmelweiter Unterschied.
Beispiele für dieses Auftreten und diese falschen oder ungenauen Behauptungen gab es ja vor nicht allzu langer Zeit beim Bekanntwerden der Angriffsmöglichkeiten auf bestimmte ACS genug.
