Replies: 11 comments 4 replies
-
|
Sicherlich auch mehr als nur FragAttack und CA-Updates - und auch eine Änderung in WebDAV übernommen, die bei anderen Modellen erst ab 06.9x vorhanden war, womit (vermutlich!) eine RCE-Lücke geschlossen wurde. Ob das "vorauseilend" war oder generell beim Ersetzen von (anfälligen) Vorher sah das (nach dem Schließen einer Lücke, wo Dateinamen ... da wurden also die Zeichen, die in Shell-Syntax das Aber irgendwann hat man bei AVM dann wohl die Nase voll gehabt, weil eben Jedenfalls gibt es seitdem keine solchen Aufrufe mehr in der WebDAV-Implementierung (die im Rein theoretisch (ohne das jetzt als Exploit "auszuarbeiten" oder auch nur anzutesten) gäbe es m.E. in der alten Implementierung immer noch die Chance auf eine RCE-Lücke durch einen böswilligen WebDAV-Server. Schaut man sich das: genauer an und verfolgt den Weg zur Quelle der Zeichenkette, die aus Da wird also bei einem Fehler beim Zerlegen einer Statusnachricht (des WebDAV-Servers) in einer XML-Response (bei DAV-Status 207: https://datatracker.ietf.org/doc/html/rfc4918#section-13) ein Teil dieser fehlerhaften Daten in eine Fehlernachricht der Zu einem potentiellen Einfallstor (durch eine entsprechend gestaltete falsche Antwort des Servers) wird das am Ende erst dann, wenn man (wie AVM, solange da noch die o.g. Funktion auf ein Wie gesagt, ich habe das nicht bis zum Ende verfolgt, weil die Annahme, daß der Angreifer dazu den verwendeten WebDAV-Service unter seiner Kontrolle haben muß, mir als zu große Hürde erschien. Aber vielleicht hat ja jemand dieses Problem (oder ein anderes, ähnliches bzw. sogar gravierenderes und nicht "nebenbei" gefixtes) genauer angesehen und AVM sah sich dann doch genötigt, das Problem mit solchen Aber auch daran kann ich eigentlich nicht wirklich glauben (s. hier: https://www.ip-phone-forum.de/threads/fritz-box-7390-release-6-87-6-87i-vom-07-12-2021.311804/post-2453605) ... immerhin ist auch dieses Problem (zumindest in |
Beta Was this translation helpful? Give feedback.
-
Falls AVM Zertifikate wirklich nicht mit dem Hostnamen abgeglichen werden, und fall sogar Repeater irgendwas mit DNS machen evtl sogar updaten (hab kein Gerät zum testen)... Kann es sein dass JUIS auch durch das bald ablaufende AVM-RootCA wie MyFritz nicht mehr funktionieren könnte? In dem Zusammehang muss ich noch an den Monopolisten mit den lahmen Internetanschlüssen zu Premiumpreisen denken, die Telekom. |
Beta Was this translation helpful? Give feedback.
-
|
Und was ich auch noch vergessen hatte oben ... da die Repeater gar keinen WebDAV-Client haben (und per se schon deutlich weniger Dienste bieten), kann DORT eigentlich keine Ursache liegen für die Updates, denn die Repeater haben die ja ebenso erhalten. Damit sollte das auch irgendein(e) Service/Prozess/Datei sein, der/die sowohl auf den "richtigen" FRITZ!Boxen als auch auf den WLAN-Repeatern existent ist. |
Beta Was this translation helpful? Give feedback.
-
|
Guter Hinweise! Repeater haben kein USB -> kein mediaserv, ftp, webdav, samba, etc |
Beta Was this translation helpful? Give feedback.
-
|
lol, die Pappnasen: und 3272 |
Beta Was this translation helpful? Give feedback.
-
|
FRITZ.Repeater_3000 07.27 -> 07.29 Es gibt wohl Änderungen an
Bei der 3272 waren einige Fixes wohl Dinge die einfach die letzten Jare noch nicht geupdated wurden geänderte Dateien``` /bin/supportdata /etc/avm_root_ca.pem /etc/init.d/rc.conf /etc/.revision /etc/.version /lib/libar7cfg.so.1.0.0 /lib/libavmupnpbig.so.2.0.0 /lib/libboxlib.so.0.0.0 /lib/libcfgimpexp.so.0.0.0 /lib/libcmapi.so.1.0.0 /lib/libcrypto.so.1.1 /lib/libfwsign.so /lib/libfwupdate.so.0.0.0 /lib/libicm.so /lib/libjuisclient.so.0.0.0 /lib/libmailbuilder.so.0.0.0 /lib/libssl.so.1.1 /lib/modules/4.4.60/extra/hui.ko /lib/modules/4.4.60/extra/qca-ssdk.ko /lib/modules/4.4.60/kernel/drivers/rextd/krextdmod.ko /lib/modules/4.4.60/net/qca_ol.ko /lib/modules/4.4.60/net/umac.ko /sbin/deviceinfod /sbin/rextd /sbin/wland /sbin/wland_ctl /usr/bin/ctlmgr /usr/bin/tr069fwupdate /usr/sbin/ssdk_sh /usr/share/ctlmgr/libctlrext.so /usr/share/ctlmgr/libtr064.so /usr/share/ctlmgr/libtr069.so /usr/www/cgi-bin/firmwarecfg /var.tar ```ausgewähltes aus strings-diff |
Beta Was this translation helpful? Give feedback.
-
|
FRITZ.Box_7580 07.28 -> 07.29 alle geänderte Dateienausgewähltes aus strings-diff |
Beta Was this translation helpful? Give feedback.
-
|
Das ZigBee-Zeug (bisher hat AVM m.W. noch keine Box mit integriertem ZigBee angekündigt) hat m.W. (bei anderen Modellen) schon mit der 07.28 (vielleicht auch nur bei der Inhouse-Version?) Einzug gehalten (vorher gab es nur eine "Spur" im Skript für die Support-Daten) - und ansonsten sehe ich da (auf die Schnelle und nur oben gelesen) nichts Aufregendes. Ob ein |
Beta Was this translation helpful? Give feedback.
-
|
Nach docsis+1&1 hatte ich auch kurz gegoogelt, aber nichts gefunden. Dies gesehen? #424 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
Ja. Das Umbenennen von API-URLs bei AVM würde ebenfalls noch keine "Update-Welle" rechtfertigen, zumal die alten Adressen ja auch immer noch funktionieren (zumindest soweit ich das weiß) und beide Adressen auch dasselbe X.509-Zertifikat verwenden (was von der AVM-CA signiert ist). Ein simpler Wechsel dieses CA-Zertifikats (falls das kompromittiert worden sein sollte), wäre mit
ja auch deutlich "untertrieben" in der Beschreibung. Außerdem enthalten z.B. die 7390-Versionen gar keine JUIS benutzte bisher auch bei AVM kein TLS - vielleicht hat man das mittlerweile geändert, aber HTTP geht ja auch immer noch ... ansonsten wäre das vermutlich schon aufgefallen. Braucht man da auch nicht, die Antworten sind signiert, der Key steht in der Firmware: https://www.ip-phone-forum.de/threads/update-check-%C3%BCber-den-neuen-avm-service.287657/page-14#post-2332032 Was über die ganzen Modelle halt vorhanden wäre ... das wäre dann tatsächlich TR-069. Nur muß man auch da für einen Angriff einiges kontrollieren können - denn die Verbindung geht immer von CPE aus und man müßte den DNS-Namen innerhalb der Box kapern, damit man überhaupt etwas von einer unzureichenden Zertifikatprüfung bei TR-069-Kommunikation hätte - zumal das eben "abstellbar" ist in der Das ist mir aber alles zu spekulativ ... ich kann durchaus abwarten, bis die Katze irgendwann aus dem Sack gelassen wird (und das muß ja nicht mal zwangsläufig von AVM selbst kommen). Auf alle Fälle hebe ich noch genug ältere Versionen auf, um das irgendwann mal nachvollziehen zu können, falls es für mich von Interesse sein sollte. Wobei mir die 07.28 für die 7580 sogar "durchgerutscht" ist und das, obwohl ich selbst eine habe (mit bestücktem USB-RS323-Adapter) für Experimente mit GRX5 ... diese Version habe ich mir dann erst mal von 1&1 noch gesichert. Aber daran sieht man schon, wie wenig ich mich noch mit den Boxen befasse - von Anfang August bis heute gab es für mich keine Notwendigkeit, diese Firmware zu laden. 😎 |
Beta Was this translation helpful? Give feedback.
-
Es läuft einfach im nächsten Monat ab! -> #424 (reply in thread)
Richtig, die Datei heisst dort "jasonii_root_ca.pem", bei gleicher MD5
Falls AVM intern (bei neueren Boxen?) auf https umgestellt hätte wäre das durch ein abgelaufenes AVM-RootCA nicht mehr möglich
Das gibt es auch auf Repeatern, was damit dort angestellt wird erschliesst sich mir aber nicht |
Beta Was this translation helpful? Give feedback.
-
|
Ja, das könnte sicherlich ebenfalls ein Grund sein - wobei dann weniger JUIS als wohl eher MyFRITZ! das Problem wäre. Ich hatte irgendwann mal mit einem TLS-Proxy die Kommunikation mit dem MyFRITZ!-Service mitgeschnitten (das ersetzende Zertifikat hat es irgendwann sogar mal irrtümlich ins YourFritz-Repo geschafft und mittlerweile habe ich es absichtlich stehen gelassen, weil es mir eine ungefähre zeitliche Einordnung der damaligen Tests erlaubt) und dafür mußte ich das (CA-)Zertifikat auch ersetzen - und ja, damals hieß das tatsächlich noch was mit https://www.ip-phone-forum.de/threads/myfritz-ohne-fritz-box.271881/post-2024904 Vielleicht ist es also tatsächlich das AVM-Zertifikat, weil es Ende des nächsten Monats abläuft - da machen dann auch die Änderungen von API-URLs wieder einen Sinn, weil frühere Versionen bis zum Ablauf des CA-Zertifikats noch auf Endpunkte mit den alten Namen zugreifen und dort dann auch noch Zertifikate vorgelegt werden, die mit der alten CA signiert sind: Das oben ist das aktuelle Zertifikat von Wenn's tatsächlich nur das ablaufende CA-Zertifikat ist (der Rest wären dann "Nebelkerzen"?), macht ja auch eine weitere Suche nach anderen Ursachen weniger Sinn - denn das ist dann TATSÄCHLICH ein Problem, wobei ich auch staune, daß AVM da überhaupt noch aktiv wurde für die 7390 und die 7412 (der Rest der VR9-Modelle ist dann ein Aufwasch). Vielleicht ist man tatsächlich zu spät aufgewacht (das hätte man ja alles schon in der 07.28 mitmachen können) und dann hat 1&1 als "bester Kunde" (wo sicherlich auch irgendwo noch 7390 bei den Kunden herumgurken und natürlich auch neuere 7412, die man vermutlich nicht alle auf Provider-Kosten tauschen wollte) noch ein Machtwort gesprochen, daß man nicht möchte, daß nach dem 22.01.2022 die Kunden mit den alten Geräten massenhaft die Hotlines belagern - erst recht nicht im Angesicht der Neufassung des TKG seit 01.12.2021. Aber das ist immer noch alles Spekulation, wenn auch mal mit einem Ansatz einer plausiblen Erklärung - nur erklärt das für Repeater auch nicht alles. Die kontaktieren m.W. von sich aus keinen AVM-ACS (wobei ich das nicht sicher weiß, dafür habe ich zu wenige Repeater) und haben eigentlich auch keine eigenen MyFRITZ!-Accounts. Wenn die doch den ACS kontaktieren würden ... auch egal, dann ginge das eben erst wieder mit der nächsten Firmware-Version, dafür bräuchten die kein gesondertes Update. Updates kriegen sie (bisher) wieder per normalem Download (afaik erhalten sie die URL dafür vom Mesh-Master) bzw. könnten sie auch weiterhin über JUIS ohne TLS (und damit auch ohne Zertifikatprüfung) finden, wenn sie alleine arbeiten. Allerdings hat auch der ... da könnte das Datum im Zertifikat darauf hindeuten, daß man es tatsächlich erst Mitte Sept. 2021 bemerkt hat, daß da irgendwann mal etwas ablaufen könnte. Andererseits sucht auch eine 7590 mit 07.29 immer noch per unverschlüsselter HTTP-Verbindung nach Updates: ... für die Suche nach Updates und für den Download eines solchen braucht man also definitiv kein passendes CA-Zertifikat und eine neue Firmware-Version kann das dann auch noch später ersetzen. Bleiben ARGO und MyFRITZ! - ersteres nicht wirklich kritisch (dann fehlen halt mal Telemetrie-Daten) und letzteres auch nur dann (iirc), wenn man MyFRITZ!-Anmeldungen(!) ausführen will. Das reine Update für die Adressen erfolgt über HTTP bei Aber es bleibt zumindest eine logische Erklärung, wenn man die Repeater mal außen vor läßt - deren Firmware entpacke ich i.d.R. nicht mal, daher weiß ich über MyFRITZ! auf denen nichts und kann nicht mal sagen, ob in deren DNA ( |
Beta Was this translation helpful? Give feedback.
-
|
Hm, kann man die HTTPS-Seiten von AVM nicht mit beiden RootCA validieren? Danke fürs testen von JUIS, dass der noch HTTP verwendet finde ich komisch. Ich hätte auf Probleme damit getippt... Die ganzen Repeater sind eigentlich wie arg abgespeckte Router, ohne Voip, Pots, ISDN, DSL, WAN, Dect, USB (mit zugehörigen Daemons) und die ganzen Onlineservices. Der multid heisst rextd, macht aber scheinbar das selbe (müsste auch Port 53 belegen, hab nichts mehr zum testen: https://github.com/Freetz-NG/freetz-ng/tree/master/make/mod/files/root/usr/bin/wrapper). |
Beta Was this translation helpful? Give feedback.
-
Früher (als ich noch in die Repeater-Firmware gesehen habe) war das der Ersatz des Bei den Zertifikaten habe ich jetzt den Faden verloren - Du müßtest dazuschreiben, wo Du "alt" und "neu" verglichen hast. Denn so genau hatte ich mir die Zertifikate gar nicht angesehen - wenn AVM beim neuen keine anderen Daten verwendet (für Modulus/Exponent, weil der Key noch derselbe ist), dann ändert sich auch die "Authority Key ID" nicht und da die Signatur in einem Zertifikat dann weiterhin mit demselben Key verschlüsselt wird, kann sie auch mit demselben öffentlichen Schlüssel (Modulus + Exponent aus dem Zertifikat, welches zum "Unterschreiben" benutzt wurde) wieder entschlüsselt und mit dem selbst berechneten Hash über die Zertifikat-Properties verglichen werden (am Ende dasselbe, was auch bei den Firmware-Signaturen erfolgt). Da sich Seriennummer und "validity" geändert haben, MUSS der Hash über die Properties ein anderer sein - mithin auch die verschlüsselte Version. Die "Subject Key ID" bleibt dann auch dieselbe, denn üblicherweise (nicht zwingend per RFC, aber praktizierter Brauch) ist das der SHA1-Hash über den zu bestätigenden öffentlichen Schlüssel - nur über die Bits (bzw. die (ASN.1-)Bit-String) des Keys, nicht über die ASN.1-Header für die OID und die äußere "sequence", daher bei RSA-Keys (OID 1.2.840.113549.1.1.1) erst ab Offset 19 im binären (DER-)Format eines "public keys" zu finden. Das wäre dann z.B. an dieser Stelle: https://github.com/PeterPawn/YourFritz/blob/fb4bcf21af50b38e1afd326476bd03705cab9177/signimage/yf_mod2der#L662 im Ablauf der Fall, wenn man so einen öffentlichen Schlüssel aus Modulus und Exponent zusammenbasteln würde - wandelt man die Zeichenkette im Skript (die das alles als Hex-String macht, weil's in Shell nicht anders geht) in Binärdaten um und bildet darüber einen SHA1-Hash, hat man genau das, was üblicherweise als "Subject Key ID" verwendet wird. Solange man bei AVM also tatsächlich NUR das selbstsignierte CA-Zertifikat erneuert hat (dann ja schon lange vor dem Ablaufen des alten, welches dann obendrein noch für Jahre weiterhin in der Firmware "ausgeliefert" wurde - das macht es noch einmal peinlicher) und ansonsten am Inhalt (DN + Key) nicht geändert wurde (die "keyid" im "Authority Key Identifier" (OID 2.5.29.35) bleibt dann natürlich ebenfalls gleich - denn das ist beim "self-signed"-Zertifikat ja genau die "Subject Key ID" bzw. der öffentliche Schlüssel, aus dem sie generiert wurde), dann ist es beim Unterschreiben weiterer Zertifikate natürlich egal, denn in beiden Fällen wird ja mit demselben privaten Schlüssel signiert und nur dessen "Besitz" beim Unterzeichnenden wird ja mit der Signatur über den Zertifikat-Inhalt geprüft. Solange das Zertifikat beim "Authority Key Identifier" keine der optionalen Angaben enthält (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1), macht sich auch die geänderte Seriennummer des CA-Zertifikats nicht bemerkbar und Clients erkennen nicht mal (solange sie keine alten Zertifikate für Vergleiche gespeichert haben), wenn sich ein vorgelegtes Zertifikat ändert ... stimmt die Signatur, wird es akzeptiert. Was ich aber dennoch witzig finde ... das Zertifikat für die AVM-CA (auch das neue) ist nun wieder nur mit SHA1 signiert und wenn das irgendwo "öffentlich" benutzt würde und nicht nur innerhalb der Firmware (also an einer Stelle, wo ein Browser "Kontakt" aufnehmen würde), gäbe das gleich wieder dasselbe Geschrei (https://www.chromium.org/Home/chromium-security/education/tls/sha-1/) ... warum man es bei AVM dann nicht auch gleich besser macht und anstelle des SHA1-signierten CA-Zertifikats sofort eines mit SHA256-Signatur in die Firmware packt (auch das müßte zum Validieren zuvor ausgestellter Zertifikate weiterhin taugen), wird wohl ein Geheimnis bleiben. Zumal vermutlich die Laufzeit der CA bzw. ihres Zertifikats bis 2046 angesichts eines RSA-Keys mit 2048 Bit Länge auch etwas sehr optimistisch sein dürfte ... daß man nicht gleich auf EC gegangen ist, dürfte sicherlich auch damit zu tun haben, daß die Implementierung in älteren Versionen nicht immer zur Verfügung steht. |
Beta Was this translation helpful? Give feedback.
-
Ne, ctlmgr heisst immer so, bei Extendern (Repeater + Powerline) heisst der multid rextd. Das nutze ich so ab fos ~6.00
Die Datei /etc/avm_root_ca.pem (ab FOS ~6.9x), bzw in älterem FOS 05.2x-6.8x mit identischem Inhalt (=umbenannt) /etc/jasonii_root_ca.pem gibt es in 2 Versionen:
AVM hätte den "Neuen" also schon vor 5 Jahren einbauen können - falls diese Datumsangabe von AVM stimmt
neues root-caaltes root-ca
Also Firefox hat sich nicht über SHA1 beschwert. Da ich es in einer Test-VM ausgeführt hab glaube ich nicht dass ich etwas umkonfigurierte.
Das "neue" Zertifkat wurde 2016/05 erstellt, nicht lange nach der Ankündigung von Chromium 2015/12:
Auch weshlab man nicht wie jeder andere ein ganz normales HTTPS-Zertifkat nimmt, es geht ja um Hostnamen die im internet erreichbar sind. Noch ne witzige Theorie:ARGO nutzt auch das selbst erstellte root-ca auf https://argo.avm.de:7547/ . Zitat von dir:
AVM nutzt bekanntlich nicht unbedingt renomierte open-source Komponenten, sondern programmiert vieles gerne selbst und besserer... Aber wahrscheinlich seh ich das viel zu pessimistisch. Wir werden sehen. |
Beta Was this translation helpful? Give feedback.
-
Nachfolger: #846
2014:
Der kompletten Hack von FritzOS via webcm und dessen Kommunkation seitens AVM ist legendär.
Der Webserver/webcm hat die übergebenen Parameter nicht richtig geprüft und als root ausgeführt.
Den einen oder anderen hatte dies ein paar hundet oder tausend Euro an Voip-Gebühren gekostet:
2020:
Erst letztes Jahr gab es mit AVM Firmware das Problem dass der Fritzos DNS-Rebind Schutz mangelhaft umgesetzt ist
und (IPv4 mapped) IPv6-Adressen (zB ::FFFF:192.168.178.1) sowie Localhost (127.0.0.0/8) ignoriert wurden.
CVE: 2020-26887: FRITZ!Box 7.20 - DNS Rebinding Protection Bypass
2021:
Nun das Update der "Stammzertifizierungsstellen":
Changelog der Fritzbox 3272 06.88, kein Auszug:
Auswahl aus string-diff von FRITZ.Box_3272: Fritzos 06.87 > 06.88
Das string-diff wirft bei mir ein paar Fragen auf. Weshalb sollte etwas geändert werden was sicher ist? Sind MÖGLICHERWEISE noch andere Probleme behoben worden?
Schade dass es zu dieser älteren Fritzos Version vermutlich kein detailliertere, offizielle Mitteilung geben wird als der magere 2-Zeiler oben.
@PeterPawn: Du kennst dich doch mit den ganzen veröffentlichten Sicherheitslücken von AVM aus, sind Fixes für bereits bekanntes enthalten, abgesehen von den Libs?
Wie dem auch sein, ich bin jedenfalls froh dass FritzOS aus meinem internen Netzwerk verbannt ist und durch OpenWrt ersetzt wurde:
Es ist wesentlich flexibler und hat mehr Features (Vlan, Multi-SSID, konfigurierbarer Switch, iptables mit conntrack, ...) und ist dazu noch günstiger (AX Router für unter 100 Euro)
Da es AVM von aktuell für sehr viele Geräte neue Firmware-Updates gibt:
AVM veröffentlicht den Sourcecode zu jeder Firmware auf dem ftp-Server nur auf Anfage an fritzbox_info@avm.de.
Falls jemand diese (via GPL erlaubte) Regelung nich so dolle findet und AVM dies mitteilen möchte: Einfach eine eMail schreiben und nachfragen!
Beta Was this translation helpful? Give feedback.
All reactions