PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Leider zuviele und daher ist das mehr "so könnte es sein" als handfeste Untersuchungen.
Ich hatte mich noch einmal etwas in die CVC-Datei von AVM vertieft - die ist ja definitiv in dieser Form von AVM signiert mit deren CVC-Key. Das ist immer etwas merkwürdig beim Formulieren, weil "CVC" m.W. für "code verification certificate" steht und gleichzeitig wohl als "Erweiterung" für diese Dateien verwendet wird - egal, es gibt ja neben dem Herstellerzertifikat noch ein weiteres, mit dem solche Updates dann signiert werden ... daher ist das (hoffentlich) von AVM, dieser Key wird ja nicht auch bei einem Provider liegen, damit der im Namen von AVM signieren kann.
Ich weiß ja nicht, wie lange das schon so geht - normalerweise sollte der "operator" ja nach der DOCSIS-Spezifikation nur die Möglichkeit des "co-signings" habe, um damit seinerseits das "OK" zur Benutzung im eigenen Netz zu erteilen (optional). Dann kann er aber nichts am Inhalt der Firmware ändern - wollen wir einfach mal annehmen, daß da auch in den frühen Jahren (das CVC-Zertifikat, mit dem das File von AVM signiert ist, stammt ja auch schon aus 2009, wie das alte auf der Box) von AVM kein Schlüssel an die KNB verteilt wurde - ich war da immer sehr skeptisch, ob die KNB nun ändern und selbst signieren können oder nicht und das freiwillige Verteilen des alten Keys für die CM-Zertifikate mit der Firmware war einer der Gründe dafür, daß da etwas nicht "nach Standard" laufen könnte.
Egal ... jedenfalls enthält das CVC-File für die 06.50 (mit lgi- und avm-Branding im Inneren) gar kein Programm zum Update des Zertifikats ... das paßt dann auch wieder dazu, daß eigentlich das CM während eines solchen Updates die einzige aktive Komponente des eDOCSIS-Gerätes sein sollte. Wenn das so ist, braucht es da ja auch kein Update-Programm und keine /var/docsiscertdefaults - letztlich auch kein ewnw_check_install. Und siehe da, es gibt sie tatsächlich nicht im enthaltenen Tarball - und auch keinen Aufruf von ewnw_check_install innerhalb der /var/install.
Damit dürften die Boxen bei den Providern auch nur dann ein Online-Update des Zertifikats versuchen, wenn das Update vom Provider auf einem anderen Weg angeschoben wurde und da bleibt ja eigentlich nur TR-069 übrig. In dem dort verteilten Image (auch das ist ja von AVM signiert, wenn auch auf die "herkömmliche" Art ohne die DOCSIS-PKI) sollte dann wieder das Update-Programm enthalten sein.
Da ich selbst noch kein Update beobachten oder mitschneiden konnte, bleibt mir ja nur das Ansehen des von AVM so großzügig verteilten Programms "cm_dl_cert", das sich ja merkwürdigerweise sogar in den Retail-Updates findet, obwohl mir die Phantasie fehlt, was es dort bringen soll. Die sollten ja alle neue Zertifikate schon ab Werk haben.
Eine Weile war ich der Ansicht, AVM würde tatsächlich die neuen Zertifikate ähnlich sichern, wie es vermutlich beim Finalisieren der Firmware erfolgt. Wer sich schon einmal den "ptestd" angesehen hat (der stammte wohl mal aus dieser Finalisierung und wurde dann für die interne Kommunikation zwischen ARM und x86 "mißbraucht", jedenfalls ist er ja in der Retail-Firmware nach dem Auspacken zu finden:
Code:
/proc/mtd
Finalize: error in call to fopen()
test_finalize.c
Finalize: error in call to malloc()
Finalize: error in reading /proc/mtd
urlader
Finalize: error: mtd_buffer too small
Finalize: error: mtd entry for 'urlader' not found
/var/ptestd/finalize.cfg
MAIN
HWRevision overwrite
ProductID overwrite
SerialNumber overwrite
annex overwrite
usb_device_id overwrite
usb_revision_id overwrite
usb_manufacturer_name overwrite
MAC
maca overwrite
macb overwrite
macwlan overwrite
macdsl overwrite
usb_board_mac overwrite
usb_rndis_mac overwrite
WLAN
wlan_cal once
TR069
tr069_serial overwrite
tr069_passphrase overwrite
GUIPASS
webgui_pass overwrite
HWSUB
HWSubRevision overwrite
MACWLAN2
macwlan2 overwrite
Finalize: WARNING: unknown group flags: %08x
Finalize: groups: %s
Finalize started
/usr/bin/set_config -e /proc/sys/urlader/environment -i
-u /dev/
mtd1
mtd2
mtd3
mtd4
mtd5
mtd6
mtd7
mtd8
mtd9
Finalize: error: invalid mtd
Finalize: calling '%s'
Finalize: error in call to system() (executing set_config command)
Finalize: set_config return value: %d
Finalize finishedDa stellt sich dann die Frage, wofür wohl das Programm "burnimage" bei den Dateien ist, die nur für die Dauer des Updates auf der Box liegen - und das sowohl im CVC-Image als auch in den Retail-Versionen. Aber das wird wohl wirklich nirgendwo aufgerufen und damit habe ich die Idee, daß da tatsächlich der Bootloader permanent geändert wird, eigentlich wieder aufgegeben.
Dann stellt sich aber eine entscheidende Frage ... in der Firmware 06.50 (lgi+avm) sieht die Initialisierung so aus:
Code:
[...]
if [ -n "${mtd_nvram}" ] && [COLOR="#FF0000"][ -n "${Recover_was_here}" ][/COLOR] ; then
del_mtd_nvram=${mtd_nvram#mtd}
del_mtd_nvram=${del_mtd_nvram%:*}
## erase nvram (formatting) due to preceding recover
nvram_erasestring="mtd ${del_mtd_nvram} erase all"
echo "[config-space/Recover] nvram erasing start ... (${nvram_erasestring})" > /dev/console
echo "${nvram_erasestring}" > /proc/mtd
echo "[config-space/Recover] nvram erasing ... done." > /dev/console
fi
Code:
# [COLOR="#0000FF"]grep recovered setfactorydefaults[/COLOR]
## firmware_info setzen (damit wir nach dem reboot das nachholen k�nnen) [factorydef: recovered=3]
## take care on preventing multiple entrys ',recovered=*'
fw_info=`echo ${fw_info} | sed -e "s/,recovered=[0-9]\+//g"`
[COLOR="#FF0000"]echo "$fw_info,recovered=3" >$CONFIG_ENVIRONMENT_PATH/environment[/COLOR]Das sollten gerade diejenigen im Auge behalten, die eine 06.50 (die kdg-Version muß allerdings nicht genauso aussehen) und eine Retail-Version auf der Box und die neuen Zertifikate nicht ab Werk installiert haben. Wenn so jemand auf der Box ein Zurücksetzen auf Werkseinstellungen in Auftrag gibt und im Anschluß startet die 06.50, dann müßten - immer noch in der Theorie - die Zertifikate hinterher weg sein. Vielleicht hat ja jemand eine solche Box (eine ältere vom Provider (s.o.), die aber auf 06.50 aktualisiert wurde, als sie noch im Vertrag war und nun im Besitz des Kunden ist, wenn er die 160 EUR an seinen Provider gezahlt hat) und traut sich dieses Experiment mal zu? Die Zertifikate kann man ja vorher einfach sichern lassen, auch das kann ein Skript auf /var/media/ftp übernehmen, wenn es von /var/post_install aufgerufen wird. Es sollte natürlich jemand sein, der sich dann auch zu helfen weiß ...
Wenn diese Theorie aber stimmen sollte, dann könnte so eine Box eigentlich hinterher gar nicht anders, als über "docsis_init_once" (da wird dann auch die NvramDb wieder initialisiert) ein neues Zertifikat zu generieren und das mit dem alten Schlüssel zu signieren - das "cmcertgen" ist ja vorhanden, wenn auch in einer moderneren Version mit verschlüsselter Datei für den privaten Herstellerschlüssel (der natürlich auch vorhanden ist). Dann meldet sich diese Box aber wieder mit einem alten Zertifikat (hier geht es ja um das AVM-Zertifikat in der Kette und nicht darum, daß das CM-Zertifikat "frisch" ist) und wenn der alte Key am CMTS gesperrt ist, würde so eine Box (auch wenn sie sich im Bestand des Providers befindet) ja nicht mehr "reinkommen" und das nach jedem Zurücksetzen auf Werkseinstellungen.
Da das auch der Benutzer auslösen kann (und ein Angreifer im LAN erst recht), sehe ich gerade nicht so richtig, wie der Provider das alte Zertifikat überhaupt dauerhaft sperren kann, solange er Boxen an diesem CMTS hat, die ihrerseits die Daten nur im Nvram haben und gleichzeitig noch die 06.50 (zumindest eben die lgi+avm, kdg könnte anders aussehen, vielleicht findet sich ja jemand mit einer 06.50 von KDG) als Firmware-Version verwenden. Wenn solche Geräte dann gar nicht erst soweit kämen, daß der Provider sie über den ACS erneut aktualisieren kann (notfalls mit der schon einmal installierten Version) und das geht eben erst nach der Provisionierung, dann müssen die wohl erst noch auf die nächste Provider-Firmware aktualisiert werden (und zwar alle), bevor das alte Zertifikat (und damit der Schlüssel) jemals gesperrt werden kann.
Wenn das tatsächlich stimmen sollte, kann ich mir auch die zurückhaltende Reaktion von AVM ggü. heise.de erklären ... ansonsten wäre das ja irgendwo (Ruf-)Selbstmord, wenn man genau weiß, daß da etwas die Runde machen wird (weil heise.de anfragt) und man steckt trotzdem den Kopf in den Sand.
Soweit ich weiß, ist bei den beiden großen Providern immer noch die 06.50 in Benutzung ... und dann gilt das natürlich nur für die Boxen, die keine Zertifikate (weder alt noch neu) ab Werk haben. Aber das dürfte auch eine erkleckliche Anzahl sein - vermutlich alle diejenigen, deren MAC-Adresse mit 34 beginnt und noch einige aus der C8:0E:14-Reihe ... und von einer Nachfolge-Version für die 06.50 bei den Providern hat man m.E. bisher auch noch nichts gesehen. Da werden die wohl schwer am Testen sein - dann noch den Rollout dazugerechnet und dann wird der AVM-Service wohl doch noch eine Weile laufen müssen. Was aber viel schlimmer ist an dieser Stelle ... wenn AVM nicht zulassen will, daß eine solche Box nach dem Factory-Reset gar nicht mehr funktioniert und dem Provider die Möglichkeit geben will, über den ACS Firmware und Zertifikate zu erneuern, dann muß man an der Stelle auch ein zweites Zertifikat für eine Box ausstellen, die bereits ein anderes erhalten hatte.
Da es für AVM eigentlich keine Möglichkeit gibt (ich kann mir jedenfalls keine vorstellen), ein tatsächlich ausgeführtes Werksreset der alten Box festzustellen, könnte wohl ein Angreifer auch hingehen und an einem geeigneten CMTS mit einer Box desselben Modells und derselben Firmware die Box des Nachbarn klonen (hinsichtlich der CM-MAC, jedoch nicht so, daß er damit den Nachbarn "abhören" könnte, weil das zwei getrennte private Schlüssel sind oder zumindest sein sollten) ... und auch wenn ich das nicht für eine wirkliche Gefahr für den Kunden halte, ist das schon ein erhebliches Problem.
Solange CM-MAC und WLAN-MAC einer FRITZ!Box in einem berechenbaren Verhältnis zueinander stehen (ich kenne nur zwei Zählweisen, hatten wir glaube ich auch schon als Thema - ich hoffe, es gibt mehr), kann der Nachbar nämlich auch die CM-MAC (die er sonst nicht unbedingt kennt - wobei das auf dem RF-Interface auch irgendwo zu finden sein müßte, die CM-MAC ist ja nicht geheim - aber es geht ja auch per Berechnung) zumindest erraten (m.E. mit 50:50-Chance).
Ich halte trotzdem die akute(!) Gefahr des unbemerkten(!) Identitätsmißbrauchs (was Kosten und Ärger bei Gesetzesverstößen nach sich ziehen könnte) für etwas übertrieben ... an demselben CMTS dürfte es (ich müßte auch erst in MULPI nachlesen, also rate ich) gar nicht funktionieren mit zwei identischen MAC-Adressen, wenn die auch zur Adressierung verwendet werden und nicht nur zur Authentifizierung und auch das CMTS sollte eigentlich bemerken, wenn da zweimal dieselbe CM-MAC existiert.
Die Telefonie ist ohnehin nicht so ganz einfach ebenfalls zu klonen, dafür bräuchte man schon die SIP-Credentials aus der Box des Angegriffenen und die wird der wohl kaum freiwillig abliefern. Soweit ich das aus meiner Zeit als KDG-Kunde kenne, wird bei der automatischen Konfiguration der Telefonie über SNMP (PACM) aber auch beim Provider ein neuer Datensatz mit neuen Credentials erzeugt, damit sollte der Angegriffene recht schnell mit der Telefonie offline sein (seine Credentials stimmen ja nicht mehr) und sich beim Provider beschweren. Wenn der dann den Klon nicht findet, ist er selbst schuld - zumindest sollte meines Erachtens feststellbar sein, daß/ob der Klon über ein anderes CMTS arbeitet und damit ist es dann eben nicht der Kunde mit seinem (ja doch an einen Ort gebundenen) Anschluß. Das mit dem Generieren neuer Credentials wäre jedenfalls "best practice", denn auf diesem Wege wären auch irgendwie ausgespähte Credential ja durch ein Werksreset (wenn es der Support macht, dann aber bitte nur mit Zustimmung des Kunden) und die sich anschließende automatische Konfiguration problemlos zu invalidieren.
Auch bei der Suche eines Anschlußinhabers wegen irgendwelcher Ermittlungen sollte es nicht wirklich problematisch sein ... solange der Angegriffene sein Modem nicht immer beim Verlassen des Hauses ausschaltet, sollte es zu jedem Zeitpunkt zwei IP-Adressen für den angeblichen Kunden geben (an unterschiedlichen CMTS, das sollte man schon an der IP-Adresse erkennen) und da das eigentlich nicht sein kann, dürfte eine "blindwütige Ermittlung" auch nicht stattfinden bzw. müßte schnell aufzuklären sein. Immer unter der Voraussetzung natürlich, daß der Provider die Daten in der VDS auch doppelt hat (und seinerseits sorgfältig prüft bei einer Abfrage) - aber da er ja gar nicht weiß, welches der richtige Kunde ist (sonst würde er den anderen nicht reinlassen), wüßte ich gerne, wieso das nicht so sein sollte.
Es gibt also (wieder vermutlich, das sind ja nur theoretische Überlegungen, die gerne jemand widerlegen kann und ich werde es nicht ausprobieren) eine Gefahr des Klonens einer CM-MAC und eines passenden Zertifikats - was schon besch***en genug ist. Aber auch heise.de schrieb ja zurecht von "schlimmstenfalls" und dieser "worst case" braucht schon einige Faktoren, die da zusammenkommen müssen, damit ein Schaden eintreten kann - und am Ende braucht es auch noch einen Provider, der m.E. seine Hausaufgaben nicht richtig macht, wie die Prüfung auf doppelte aktive CM mit derselben MAC, ein Münchener Kunde an einem CMTS in Berlin, usw. - man denke sich selbst eine Plausibilitätskontrolle aus. Aber dafür haben die Provider ja hoffentlich eine "fraud detection"-Abteilung, die sich mit solchen Sachen befaßt und dann geht es nun eben nicht mehr nur um die Telefonie.
Wenn das vorstehend Geschriebene in dem Punkt mit der Notwendigkeit des Fortbestehens des AVM-Services noch für eine ganze Weile stimmen sollte, dann dürfte es auch noch eine Weile möglich sein, seine eigene alte Box mit neuen Zertifikaten zu versehen, so man denn nur an einem passenden CMTS hängt. Meine These wäre es, daß das bei @Kirandia der Fall ist und vielleicht auch noch bei den ganzen Bekannten in der Nachbarschaft (sollte dasselbe CMTS sein). Bei anderen gab und gibt es vielleicht keine alten Boxen im Kabelsegment und dann könnte tatsächlich auch die Absenderadresse so eines Update-Requests wieder eine Rolle spielen, denn eine Adresse sollte sich meines Wissens eindeutig einem CMTS zuordnen lassen (sonst bräuchten die KNB wohl sehr große Routingtabellen, denn der letzte Hop vorm Kunden müßte das CMTS sein) und der Provider könnte die Adresse bei AVM selektiv sperren, wenn der Request von einem CMTS ohne alte Clients stammt. Oder sogar AVM könnte mit einer passenden Firewall (schon iptables mit ipset macht das richtig gut, selbst bei langen Black- oder White-Listen) dafür sorgen, wenn sie denn die Adressen vom Provider kriegen.
Wenn dann aber an so einem "freigegebenen" Anschluß die eine Box neue Zertifikate kriegt und die andere nicht, dann würde ich wieder auf die "Anmeldung" der Boxen im Bestand des KNB bei AVM für das Update zurückkommen wollen. Ich kann die Quelle, von der ich das gehört habe, nicht zitieren und nicht meinerseits überprüfen - vorstellen kann ich es mir ohne weiteres und plausibel wäre es (als ergänzende Maßnahme) auch noch. Allerdings habe ich noch nicht so viele Lösungen von AVM gesehen, wo es mehr als die unbedingt erforderlichen "lines of defense" gab. So eine Liste würde auch erst beim Request greifen, da wäre der 3way-Handshake für die TLS-Session dann schon erfolgt.
Mir ist es jedoch über einen Telekom-Anschluß nicht einmal gelungen, ein erstes SYN/ACK vom AVM-Server zu erhalten und auch kein ICMP-Paket zur Ablehnung, erst recht keinen TCP-Handshake oder gar eine TLS-Connection ... und erst dann käme der Request, der wegen falscher CM-MAC abgelehnt wird. Da ich noch kein (erfolgreiches) Update erlebt habe und selbst nur an einem Telekom-Anschluß mit dem Ergebnis "timeout" nach Senden des ersten SYN leben muß, weiß ich nicht, wie es "richtig" läuft und vielleicht ist es ja wirklich eine Kombination mehrerer Maßnahmen ... nötig wäre es jedenfalls.
Solange also niemand mit einem Anschluß, an dem schon früher das Update funktioniert hat, einen solchen Fehlversuch mal zum besten gibt oder gar mitschneidet (geht nur um die Pakete an sich, der Inhalt kann ruhig verschlüsselt bleiben, wir wollen das ja nur verstehen und nicht nachbauen - jedenfalls ist das nicht mein erklärtes Ziel), solange bleibt das alles vage und ein wenig Stochern im Nebel. Aber bei der Notwendigkeit mehrfacher Zertifizierungen für dieselbe CM-MAC nach Werksreset bin ich mir ziemlich sicher (und habe es mehrfach hin und her geprüft, was da passieren müßte) - ich glaube nicht, daß das Online-Update die Finalisierung ändert.
Zuletzt bearbeitet:
