- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,278
- Punkte für Reaktionen
- 1,753
- Punkte
- 113
Ich habe zwar sogar über ein neues Skript für "toolbox" (in meinem Repo) und ein damit vorbereitetes, fertiges Image für die 7490 zum "Implantieren" dieses Keys nachgedacht (so, wie SIAB auch eingebaut werden kann, was ja bei der 7590 nicht auf diesem Wege funktioniert - deshalb nur für die 7490), aber eigentlich ist ja zur Verwendung eines solchen "Erste Hilfe"-Images genau dieselbe Vorbereitung notwendig, wie für das bootbare Image, was man mit "image2ram" oder dem oben beschriebenen PS-Aufruf erzeugen kann.
Insofern erscheint das (zumindest für mich) wenig sinnvoll ... es wäre nur für diejenigen eine Hilfe, die diesen Teilschritt mit dem Erzeugen des bootbaren Images nicht hinkriegen - das sind hoffentlich nicht wirklich viele und denen kann sicherlich auch "verbal" geholfen werden.
Daher denke ich da jetzt nicht weiter drüber nach ... für eine "echte Automatisierung" des ganzen Ablaufs fehlen mir noch ein paar Bausteine - in erster Linie der FTP-Client, der sich mit den EVA.-Besonderheiten auskennt (der kann zwar schon Downloads und GETENV/SETENV, aber noch nichts in die Box laden).
Ob man eine komplette Automatisierung in diesem konkreten Fall überhaupt möchte, muß man auch gut überlegen ... denn so ganz von der Hand ist das ja nicht zu weisen, daß mit der notwendigen Installation des Keys oder der ersten Version jetzt eine "Grundqualifikation" beim potentiellen Tester vorhanden sein muß. Wobei auch das lange nicht so "hart" ist, wie es sich im ersten Moment anhören mag, wenn man eine Anleitung/Erklärung lesen, verstehen und befolgen kann - ansonsten kann man ja auch nachfragen.
---------------------------------------------------------------------------------------------------------------
Denn eines erreicht AVM damit natürlich auch (und das ist bisher vielleicht bei meinen Ausführungen zu kurz gekommen) ... es kann jetzt auch kein Fremder mehr so ohne weiteres ein Inhouse-Image auf einer Box installieren, wenn er irgendwie aus der Ferne (oder über ein Relay im LAN - z.B. eine IP-Cam) Zugriff zum GUI kriegt. Bis hin zum Provider, der so ein Update auch über TR-069 anschieben könnte - auch wenn der vermutlich immer noch Downgrades machen könnte, was weiterhin ein Problem wäre (komme ich später noch mal drauf).
Denn das enthält immerhin viele, potentiell auch gefährliche, zusätzliche Werkzeuge - angefangen bei SIAB, was inzwischen ja auch noch zusätzlich "gestartet" werden mußte und nicht mehr permanent aktiv war, wie in früheren Versionen (auch wenn es da als CGI lief und nur bei einem Request gestartet wurde) - auch das war natürlich ein Sicherheitsgewinn bei der Benutzung einer solchen Version.
Eine "normale" Box würde eine Installation jetzt auch über TR-069 verweigern, wenn das Image mit dem zusätzlichen Key signiert ist - bisher hätte ein Provider über TR-069 einfach ein solches Image einspielen und damit (ein Konto kann er sich ohnehin anlegen) auch wieder "Vollzugriff" auf die Box erlangen können - das galt natürlich für die Installation einer neuen Firmware über TR-064 ebenso (da muß man schon für das Update die Credentials eines Admins irgendwie ergattern).
---------------------------------------------------------------------------------------------------------------
Auch eine weitere Schwachstelle ist in letzter Konsequenz damit etwas entschärft - ich hatte zwischendrin auch schon mal darauf hingewiesen (https://www.ip-phone-forum.de/threa...das-lange-leben-der-var-flash-calllog.299002/), daß ein "böser Bube" mit mehreren, aufeinander abgestimmten Manipulationen über die "calllog" und den "developer mode" des "telefon"-Daemons (der in den Inhouse-Images automatisch aktiv ist) durchaus auch eine fremde Box manipulieren könnte, wenn er an wichtigen Stellen (u.a. auf gespeicherte Sicherungsdateien aus Push-Mails in einem E-Mail-Postfach) einen Zugriff erlangt (und die "calllog" manipulieren kann, was auch über die Sicherungsdatei funktioniert, wenn er den Besitzer dazu kriegt, die manipulierte Datei wieder einzuspielen), während er gleichzeitig den Benutzer "überredet" (z.B. mit Mimikry als "Support"), die per E-Mail zugesandte "Spezial-Version" (die könnte sogar noch über eine echte AVM-URL in der E-Mail geladen werden und damit "seriös" erscheinen) zu installieren, um sein Problem genauer untersuchen zu können.
In der Kombination aus Inhouse-Firmware und manipulierter "calllog"-Datei kann so ein Angreifer dann (bei einem Anruf) wieder beliebige Kommandos ausführen (den Inhalt der "calllog" halt) ... eines der neuen Images kann der angegriffene Benutzer aber nicht mehr ohne weiteres selbst installieren, ohne dabei ein Programm benutzen zu müssen, was erkennbar nicht von AVM selbst stammt (und dem aufmerksamen Kunden/Benutzer damit auffallen sollte).
Daher will auch gut überlegt sein, wie und wie leicht man das Einspielen des zusätzlichen Keys für die Inhouse-Versionen macht - es muß sich bei dieser Aktion von AVM also auch nicht nur um "Schikane" für die ganzen freiwilligen Tester handeln und um eine Selektion.
---------------------------------------------------------------------------------------------------------------
Allerdings bringt das eben auch erst mit höheren Versionsnummern wirklich etwas ... wenn sich so ein "bad guy" eine ältere Inhouse-Version hingelegt hat und damit einen Benutzer einer FRITZ!Box mit einer Versionsnummer < 07.0x beglückt, kann diese ältere Inhouse noch installiert werden (hier schließt sich der Kreis zur (angenommenen) Downgrade-Möglichkeit für den Provider, wobei die nicht geprüft/verbürgt ist für aktuelle FRITZ!OS-Versionen) ... ist auf der Box des Kunden aber schon eine 07.01 installiert, verweigert das FRITZ!OS (eben wg. Downgrades) das ohnehin.
Nun kann man nur noch hoffen, daß AVM dann mit der neuen Möglichkeit des Downgrades (die hatte ich hier mal angerissen: https://www.ip-phone-forum.de/threa...se-vom-12-09-2018.300814/page-10#post-2300254 und ich habe noch gar keine Zeit gehabt zu schauen, ob die in der 07.08 auch tatsächlich vorhanden und nutzbar ist) nicht doch wieder ein neues Schlupfloch aufreißt ... aber zumindest wird diese Downgrade-Möglichkeit dann ja wohl auch über JUIS gesteuert und ist (wenn die Signatur dort ernstgemeint ist und auch funktioniert - das wollte ich auch schon lange mal prüfen, weil es mir beim "juis_check" ja nicht gelungen war, die irgendwie mal erfolgreich zu verifizieren) damit nicht so ohne weiteres zu manipulieren.
Was hier aber immer noch fehlt (zumindest habe ich nichts in dieser Richtung gesehen), ist ein Sicherheitsmerkmal in der JUIS-Antwort von AVM ... zwar wird die Antwort insgesamt signiert (ich gehe jetzt mal davon aus, daß das auch klappt), aber der Download erfolgt wohl immer noch über "offene Protokolle" und wenn ein Angreifer sich als "ftp.avm.de" ausgeben kann (durch simple DNS-Manipulation) und anstelle der korrekten Datei eine alte Inhouse-Version unter dem richtigen Namen zum Download bereithält (die ist ja trotzdem korrekt signiert und der dafür genutzte Key ist auch in neuen Versionen weiterhin vorhanden), dann würde das FRITZ!OS diese wohl auch noch (zumindest über den neuen Downgrade-Mechanismus, wie ich ihn beim o.a. Link gesehen hatte) installieren.
Hier hilft es schon, in die Antwort des JUIS noch den Hash für die richtige Datei einzubauen, den die Box nach deren Empfang auch noch kontrolliert (dann muß "tr069fwupdate" eben auch noch den Hash über die gesamte Datei berechnen und mit dem erwarteten Wert vergleichen und nicht nur die Signaturprüfung machen) und man kann auch weiterhin FTP und "offenes" HTTP für den Download einsetzen.
Insofern erscheint das (zumindest für mich) wenig sinnvoll ... es wäre nur für diejenigen eine Hilfe, die diesen Teilschritt mit dem Erzeugen des bootbaren Images nicht hinkriegen - das sind hoffentlich nicht wirklich viele und denen kann sicherlich auch "verbal" geholfen werden.
Daher denke ich da jetzt nicht weiter drüber nach ... für eine "echte Automatisierung" des ganzen Ablaufs fehlen mir noch ein paar Bausteine - in erster Linie der FTP-Client, der sich mit den EVA.-Besonderheiten auskennt (der kann zwar schon Downloads und GETENV/SETENV, aber noch nichts in die Box laden).
Ob man eine komplette Automatisierung in diesem konkreten Fall überhaupt möchte, muß man auch gut überlegen ... denn so ganz von der Hand ist das ja nicht zu weisen, daß mit der notwendigen Installation des Keys oder der ersten Version jetzt eine "Grundqualifikation" beim potentiellen Tester vorhanden sein muß. Wobei auch das lange nicht so "hart" ist, wie es sich im ersten Moment anhören mag, wenn man eine Anleitung/Erklärung lesen, verstehen und befolgen kann - ansonsten kann man ja auch nachfragen.
---------------------------------------------------------------------------------------------------------------
Denn eines erreicht AVM damit natürlich auch (und das ist bisher vielleicht bei meinen Ausführungen zu kurz gekommen) ... es kann jetzt auch kein Fremder mehr so ohne weiteres ein Inhouse-Image auf einer Box installieren, wenn er irgendwie aus der Ferne (oder über ein Relay im LAN - z.B. eine IP-Cam) Zugriff zum GUI kriegt. Bis hin zum Provider, der so ein Update auch über TR-069 anschieben könnte - auch wenn der vermutlich immer noch Downgrades machen könnte, was weiterhin ein Problem wäre (komme ich später noch mal drauf).
Denn das enthält immerhin viele, potentiell auch gefährliche, zusätzliche Werkzeuge - angefangen bei SIAB, was inzwischen ja auch noch zusätzlich "gestartet" werden mußte und nicht mehr permanent aktiv war, wie in früheren Versionen (auch wenn es da als CGI lief und nur bei einem Request gestartet wurde) - auch das war natürlich ein Sicherheitsgewinn bei der Benutzung einer solchen Version.
Eine "normale" Box würde eine Installation jetzt auch über TR-069 verweigern, wenn das Image mit dem zusätzlichen Key signiert ist - bisher hätte ein Provider über TR-069 einfach ein solches Image einspielen und damit (ein Konto kann er sich ohnehin anlegen) auch wieder "Vollzugriff" auf die Box erlangen können - das galt natürlich für die Installation einer neuen Firmware über TR-064 ebenso (da muß man schon für das Update die Credentials eines Admins irgendwie ergattern).
---------------------------------------------------------------------------------------------------------------
Auch eine weitere Schwachstelle ist in letzter Konsequenz damit etwas entschärft - ich hatte zwischendrin auch schon mal darauf hingewiesen (https://www.ip-phone-forum.de/threa...das-lange-leben-der-var-flash-calllog.299002/), daß ein "böser Bube" mit mehreren, aufeinander abgestimmten Manipulationen über die "calllog" und den "developer mode" des "telefon"-Daemons (der in den Inhouse-Images automatisch aktiv ist) durchaus auch eine fremde Box manipulieren könnte, wenn er an wichtigen Stellen (u.a. auf gespeicherte Sicherungsdateien aus Push-Mails in einem E-Mail-Postfach) einen Zugriff erlangt (und die "calllog" manipulieren kann, was auch über die Sicherungsdatei funktioniert, wenn er den Besitzer dazu kriegt, die manipulierte Datei wieder einzuspielen), während er gleichzeitig den Benutzer "überredet" (z.B. mit Mimikry als "Support"), die per E-Mail zugesandte "Spezial-Version" (die könnte sogar noch über eine echte AVM-URL in der E-Mail geladen werden und damit "seriös" erscheinen) zu installieren, um sein Problem genauer untersuchen zu können.
In der Kombination aus Inhouse-Firmware und manipulierter "calllog"-Datei kann so ein Angreifer dann (bei einem Anruf) wieder beliebige Kommandos ausführen (den Inhalt der "calllog" halt) ... eines der neuen Images kann der angegriffene Benutzer aber nicht mehr ohne weiteres selbst installieren, ohne dabei ein Programm benutzen zu müssen, was erkennbar nicht von AVM selbst stammt (und dem aufmerksamen Kunden/Benutzer damit auffallen sollte).
Daher will auch gut überlegt sein, wie und wie leicht man das Einspielen des zusätzlichen Keys für die Inhouse-Versionen macht - es muß sich bei dieser Aktion von AVM also auch nicht nur um "Schikane" für die ganzen freiwilligen Tester handeln und um eine Selektion.
---------------------------------------------------------------------------------------------------------------
Allerdings bringt das eben auch erst mit höheren Versionsnummern wirklich etwas ... wenn sich so ein "bad guy" eine ältere Inhouse-Version hingelegt hat und damit einen Benutzer einer FRITZ!Box mit einer Versionsnummer < 07.0x beglückt, kann diese ältere Inhouse noch installiert werden (hier schließt sich der Kreis zur (angenommenen) Downgrade-Möglichkeit für den Provider, wobei die nicht geprüft/verbürgt ist für aktuelle FRITZ!OS-Versionen) ... ist auf der Box des Kunden aber schon eine 07.01 installiert, verweigert das FRITZ!OS (eben wg. Downgrades) das ohnehin.
Nun kann man nur noch hoffen, daß AVM dann mit der neuen Möglichkeit des Downgrades (die hatte ich hier mal angerissen: https://www.ip-phone-forum.de/threa...se-vom-12-09-2018.300814/page-10#post-2300254 und ich habe noch gar keine Zeit gehabt zu schauen, ob die in der 07.08 auch tatsächlich vorhanden und nutzbar ist) nicht doch wieder ein neues Schlupfloch aufreißt ... aber zumindest wird diese Downgrade-Möglichkeit dann ja wohl auch über JUIS gesteuert und ist (wenn die Signatur dort ernstgemeint ist und auch funktioniert - das wollte ich auch schon lange mal prüfen, weil es mir beim "juis_check" ja nicht gelungen war, die irgendwie mal erfolgreich zu verifizieren) damit nicht so ohne weiteres zu manipulieren.
Was hier aber immer noch fehlt (zumindest habe ich nichts in dieser Richtung gesehen), ist ein Sicherheitsmerkmal in der JUIS-Antwort von AVM ... zwar wird die Antwort insgesamt signiert (ich gehe jetzt mal davon aus, daß das auch klappt), aber der Download erfolgt wohl immer noch über "offene Protokolle" und wenn ein Angreifer sich als "ftp.avm.de" ausgeben kann (durch simple DNS-Manipulation) und anstelle der korrekten Datei eine alte Inhouse-Version unter dem richtigen Namen zum Download bereithält (die ist ja trotzdem korrekt signiert und der dafür genutzte Key ist auch in neuen Versionen weiterhin vorhanden), dann würde das FRITZ!OS diese wohl auch noch (zumindest über den neuen Downgrade-Mechanismus, wie ich ihn beim o.a. Link gesehen hatte) installieren.
Hier hilft es schon, in die Antwort des JUIS noch den Hash für die richtige Datei einzubauen, den die Box nach deren Empfang auch noch kontrolliert (dann muß "tr069fwupdate" eben auch noch den Hash über die gesamte Datei berechnen und mit dem erwarteten Wert vergleichen und nicht nur die Signaturprüfung machen) und man kann auch weiterhin FTP und "offenes" HTTP für den Download einsetzen.
Zuletzt bearbeitet:
