- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,278
- Punkte für Reaktionen
- 1,753
- Punkte
- 113
:doktor: ... das sollte zunächst mal erst gar nicht passieren (wozu gibt es Kennwort-Safes?) und eigentlich verbleibt ja auch dann noch die Möglichkeit, sich eine E-Mail mit einem (nur intern verwendbaren) Link zusenden zu lassen, mit dem man sich dann trotzdem an der Box anmelden kann - nur muß man das halt zu einem Zeitpunkt konfigurieren, wo man noch Zugriff auf das Gerät hat. Wer das versäumte, ist in gewisser Weise selbst schuld.
Wobei es natürlich auch Leute gibt, die Stein und Bein zu schwören bereit sind, daß genau dieses Kennwort gestern (oder auch vorgestern oder vor 10 Minuten) noch problemlos funktionierte ... und auch das sollte man nicht in Bausch und Bogen als Phantasie abtun, weil natürlich auch eine plötzliche Änderung eines Zugangskennworts ein Zeichen für einen (erfolgreich) durchgeführten Angriff sein kann (wo der Angreifer das Kennwort durch ein ihm bekanntes ersetzt hat und das nun nicht einfach rückgängig machen kann, weil er das ursprüngliche Kennwort gar nicht kennt) und gerade in einem solchen Fall ist es erst einmal schlauer, wenn man dem Problem nachzugehen versucht und nicht einfach die Box (unter Verlust aller Einstellungen, es sei denn, man hat eine aktuelle Sicherung und dann wollen wir mal die Daumen drücken, daß zumindest deren Kennwort das richtige ist) auf die Werkseinstellungen zurücksetzt und dabei dann noch alle vielleicht vorhandenen Spuren eines solchen Einbruchs selbst vernichtet. So kann man dann nicht einmal mehr mit einiger Wahrscheinlichkeit feststellen (Sicherheit gibt es an dieser Stelle ohnehin nicht, man muß dann zumindest vom "worst case" des Totalverlusts der Vertraulichkeit der in der Box gespeicherten Daten ausgehen), was so ein Angreifer nun eigentlich alles "erbeutet" hat.
Deshalb sollte man auch bei konfigurierten Einstellungen für den AVM-Weg mit der E-Mail immer mißtrauisch werden, wenn man sich diesen "Verlust" des richtigen Kennworts eigentlich nicht erklären kann ... das könnte auch jemand anderes gewesen sein, der dort (vorübergehend, bis man selbst das wieder behebt) ein neues Kennwort eingestellt hat und durch einen Neustart der FRITZ!Box lassen sich schon viele Spuren von einem Angreifer verwischen. Wer da nur mit den Schultern zuckt und automatisch von einer Fehlfunktion ausgeht, erlebt vielleicht in naher Zukunft dann andere unangenehme Überraschungen, wenn das ein Angreifer war und der andere Zugangsdaten (vom E-Mail-Postfach bis zum Online-Speicher) dabei erbeuten konnte.
Das wäre zwar schon genug "Zeigefinger", aber trotzdem geht es jetzt erst einmal ab auf die "stille Treppe" (in der überwiegenden Mehrheit ist es eben doch ein Layer8-Problem und kein Angriff) und eine Runde Schämen ist angesagt (auch Fremdschämen ist erlaubt), damit die Lektion verinnerlicht wird und als erste Aktion nach dem nächsten erfolgreichen Zugriff dann die notwendigen Einstellungen vorgenommen werden, um diesem Problem beim nächsten Mal über den von AVM implementierten Weg für "Kennwort-Recovery" zu Leibe rücken zu können - auch wenn das vielleicht gar nicht jeder mehr für die beste Lösung hält nach meinen einleitenden Bemerkungen. Zumindest sollte man als erste Aktion mit dem Link aus so einer E-Mail dann eine Sicherung der aktuellen Einstellungen vornehmen und diese gut weglegen, bevor man dem verwendeten Konto ein neues Kennwort verpaßt (denn damit ist das ggf. vom Angreifer gesetzte weg und damit auch die "Spur" bei einer nachträglichen Analyse des Geschehens).
Wobei zumindest meine 113.06.83 an dieser Stelle auch noch eine (kleine bis mittlere) Lücke hat, denn die Änderung der E-Mail-Adresse für diesen Vorgang ist nicht über die 2FA abgesichert und es wird zu allem Überfluß diese E-Mail auch noch an die Adresse verschickt, die bei den anderen Nachrichten als Absender und auch dort nur als sekundäre Information neben dem primären Absendernamen verwendet wird, den auch die meisten MUAs (Mail User Agents - das sind die Programme zum Empfangen und Senden bzw. zum Anzeigen von Mails) für die Anzeige bevorzugen. Ich kenne auch Leute, die dort als Absenderadresse irgendetwas verwenden, was gar nicht existiert - außer dieser E-Mail für den Link mit der SID gibt es keinen nachvollziehbaren Grund, warum man da eine "echte" E-Mail-Adresse verwenden sollte und auch die FRITZ!Box akzeptiert da über das GUI beliebigen Inhalt (ob der wenigstens einem Schema für E-Mail-Adressen folgen muß, weiß ich nicht - kann jeder selbst probieren), solange man den Mail-Versand beim Speichern der Einstellungen nicht testen läßt.
Wer für sein Administrator-Konto auch einen VPN-Zugang eingerichtet und irgendein anderes Gerät für diesen Zugang konfiguriert hat (und zwar so, daß auch die Daten für XAuth dabei auf dem Gerät gespeichert wurden), der kann auch versuchen, aus diesen gespeicherten Daten sein Kennwort irgendwie zu rekonstruieren. Das kann aber auch ein beliebiger Angreifer, der auf diesem Gerät Zugriff auf die (Klartext-)Daten erhält ... deshalb würde ich schon unter Sicherheitsaspekten jedem empfehlen, für solche VPN-Zugänge niemals ein Konto mit administrativem Zugriff auf die FRITZ!Box zu verwenden und sich lieber - egal wieviel zusätzlicher Aufwand das auch sein mag - für jedes Gerät einen gesonderten Zugang anzulegen, der nur die Berechtigung hat, eine VPN-Verbindung aufzubauen.
Die AVM-Apps machen das in den neueren Versionen m.W. auch so, allerdings benutzen diese dafür eine vom Hersteller vorgesehene Schnittstelle. Dann kann jedenfalls auch ein Angreifer auf diese gespeicherten Zugangsdaten für das VPN (und mal ehrlich, wer will die schon bei jedem Aktivieren der VPN-Verbindung von Hand eingeben) nichts weiter erreichen, als den Zugang zum LAN hinter der FRITZ!Box (das ist ggf. schon schlimm genug, aber den haben die ganzen IoT-Geräte heutzutage auch und da fragen ja auch die wenigsten, was das an Probemen geben könnte) und der Zugang zu irgendwelchen Diensten im LAN ist dann hoffentlich noch einmal gesondert abgesichert - und zwar mit anderen Credentials, als sie für den VPN-Zugang erforderlich sind.
Aber das war nur eine "Bemerkung am Rande" (und eine Möglichkeit, an das Kennwort zu gelangen) ... auch wenn das natürlich zum Thema "Zugangsdaten" gehört. Ob nun derjenige besser dran ist, der gar keine VPN-Zugänge verwendet oder derjenige, der dafür gesonderte Konten eingerichtet hat, will ich nicht entscheiden ... gegenüber dem Dritten, der dafür sein Administrator-Konto an der FRITZ!Box mit gespeicherten Daten auf einem Android-Gerät verwendet, befinden sich beide in einer besseren Situation. Das interessiert vermutlich niemanden, der bis hier gelesen hat, weil er selbst gerade sein Kennwort vergessen hat, aber wenn man schon mal die "Aufmerksamkeit" der Leute erlangt hat, kann/soll man sie auch nutzen für das "Missionieren".
Trotzdem ist auch für FRITZ!Box-Besitzer ohne VPN-Zugänge zu Administrator-Konten noch nicht alles verloren (auch mit einem solchen VPN-Zugang müßte man dort schon erst noch das Kennwort extrahieren aus den irgendwo auf einem Client gespeicherten Daten) ... gegenüber einem Zugriff über ein LAN-Kabel zum Zeitpunkt des Bootens der FRITZ!Box ist diese nämlich reichlich schutzlos (auch das kann ich nur immer wieder als Mantra wiederholen) - jedes Neugeborene ist da bereits besser aufgestellt, weil es i.d.R. zumindest über eine Möglichkeit der akustischen Signalisierung von Mißständen verfügt.
Einer FRITZ!Box kann man jedenfalls zum Zeitpunkt des Starts über den Bootloader alles Mögliche einreden, sie ist in diesem Zustand noch sehr leichtgläubig und so kann man über den eingebauten FTP-Server dort (der wird auch vom AVM-Recovery-Programm benutzt) problemlos sein eigenes Betriebssystem in das Gerät laden und dort starten lassen ... mit diesem System kann man dann auch auf die Einstellungen in der Box zugreifen und diese abändern. Im Falle des hier thematisierten Verlusts der Zugangsdaten für ein Adminstrator-Konto, wäre natürlich dabei das Ändern des Anmeldemodus oder das Hinzufügen eines weiteren Administrator-Kontos eine solche denkbare Änderung und genau diesem Thema bzw. dem dabei notwendigen Vorgehen wollen wir uns im Folgenden widmen.
-Entgegen meiner sonstigen Ambitionen wird das für diesen konkreten Einsatzfall (siehe Thread-Titel) sogar eine detaillierte Anleitung werden ... trotzdem erkläre ich zunächst mal die Grundlagen (auch wenn die ganz ungeduldigen Leser jetzt vielleicht schon mit den Füßen scharren), weil ich damit auch die Hoffnung verbinde, daß sich aus dem Verständnis der Funktion weitere Anwendungsmöglichkeiten ableiten lassen, die der Leser nach der Lektüre dann auch selbst in Angriff nehmen kann ... und zwar ohne zusätzliche Hilfen und Erklärungen (zumindest weitgehend).
Bei der konkreten Anleitung (und den von mir derzeit bereitgestellten Shell-Skripten dafür) geht es zunächst einmal generell nur um die FRITZ!Box-Modelle, die mit einem MIPS-34Kc-fähigen Prozessor ausgestattet sind (das sollte die überwiegende Mehrzahl der aktuell von AVM unterstützten Modelle sein - wer es genau wissen will, sieht in der Hardware-Liste von @qwertz.asdfgh nach), weil benötigte Binärdateien von mir (jedenfalls derzeit) nur für diese Architektur bereitgestellt werden. Aus dem Aufbau der jeweiligen Boxen ergibt sich dann eine weitere Beschränkung hinsichtlich der - schlüsselfertig - unterstützten Modelle ... hier kommen nur solche in Frage für die aktuellen Versionen der Skript-Dateien, die ihrerseits für das Speichern des realen Wurzeldateisystems (als SquashFS-Image) auf eine "Wrapper"-Partition im Flash-Speicher zurückgreifen (die dort dann mit einem yaffs2-Dateisystem arbeitet).
Nur deren Kernel sind (soweit ich das kenne) in der Lage, beim Laden eines Linux-Systems in den (Haupt-)Speicher der Box auch mit einem passend präparierten ext2-Dateisystem zu hantieren und die vorhandenen Skripte beschränken sich zunächst einmal auf den Weg mit einem ext2-Image, weil das bereits mit den Tools zu realisieren ist, die praktisch jeder Linux-Installation beiliegen und für die Variante mit einem SquashFS-Dateisystem dann wieder die richtigen Programme benötigt werden, um das von AVM verwendete SquashFS-Format zu (ent-)packen.
Was machen wir also im Folgenden? Wir nehmen uns eine originale AVM-Firmware-Datei und extrahieren uns aus dieser den dort enthaltenen Linux-Kernel. Das dürfen wir ohne weiteres machen, denn dieser Kernel steht in Gänze unter der GPLv2(-Lizenz) und nach deren Bestimmungen dürfen wir diesen (im Rahmen unserer Möglich- und Fähigkeiten) beliebig vervielfältigen, verbreiten und sogar bearbeiten (copy, distribute, modify) - jeder Versuch von AVM, uns das zu untersagen, stellt dann einen Verstoß gegen diese Lizenzbestimmungen dar und damit verlöre AVM auch automatisch das Recht, diesen Kernel in den eigenen Firmware-Versionen zu benutzen und zu verbreiten.
Warum brauchen wir nun überhaupt einen eigenen Kernel ... haben denn nicht die meisten (aktuellen) AVM-Modelle denselben Prozessor und ist nicht auch so ein Linux-Kernel mit den ganzen ladbaren Modulen (LKM - loadable kernel module) durchaus dazu geeignet, sich an unterschiedliche Umgebungen dynamisch anpassen zu lassen? Im Prinzip ist das soweit richtig ... aber AVM hat bei dem Modellen mit einem Kernel 3.10, die von sich aus über keinen Bootloader verfügen, der gemäß den "OpenFirmware"-Spezifikationen eine Beschreibung der verwendeten Hardware bereitstellen kann, einen anderen Weg beschritten und legt im Kernel einen speziellen Bereich an (namens "avm_kernel_config"), der diese Hardware-Beschreibungen für ein bestimmtes Modell enthält und bereits ganz am Beginn des Kernel-Setups die Daten dort erwartet und sie auch prüft.
Damit funktioniert dann so ein Kernel nur noch auf einem Modell (oder auf anderen, die dann aber baugleich sein sollten/müssen - schon eine abweichende Belegung von GPIO-Pins reicht für einen umgehenden Crash, wenn das System den falschen Pin erwischt) und man erstellt sich entweder tatsächlich seinen eigenen Kernel für die eigene Box (wobei man auch dort den AVM-Kernel als Vorlage für diesen "avm_kernel_config"-Bereich benötigt) oder man nimmt einfach den von AVM für das passende Modell her und arbeitet mit diesem weiter.
Anders sieht es dann wieder beim Dateisystem aus. Auch wenn man hier für das gesamte SquashFS-Image (auch wenn das noch einmal in einer ext2-Verpackung daherkommen sollte) wohl ebenfalls die Anwendbarkeit der Bestimmungen aus der GPLv2 annehmen darf, sieht es bei einzelnen Programmen von AVM in diesem Image vielleicht schon wieder etwas anders aus ... wobei es wirklich witzig wäre, wenn sich AVM darauf berufen würde, daß das eben keine "distribution as a whole" ist, was man da selbst betreibt und gleichzeitig unternimmt man keinerlei Anstalten, die eigenen Änderungen am SquashFS-Format irgendwie zu dokumentieren oder gar Tools bereitzustellen, mit denen andere aus diesem "Ganzen" ("as a whole") des Dateisystem-Images irgendwie "Einzelteile" extrahieren könnten.
Daher würde ich mir nicht einmal dann Gedanken über die AVM-Bestimmungen aus deren Lizenz-Datei machen, wenn ich tatsächlich eigene Images bereitstellen würde, die ihrerseits das komplette SquashFS-Image aus einer AVM-Firmware enthalten (auch wenn das nur die aus dem ext2-Image extrahierte "filesystem_core.squashfs" wäre). Solange dieses Image nur zur Laufzeit irgendwo gemountet wird und als Quelle für den (gezielten) Aufruf von AVM-Programmen dient, ist auch die AVM-Klausel mit dem "oder Teile herauszulösen" in meinen Augen nicht verletzt (ansonsten bin ich auf das Schreiben des AVM-Justitiars gespannt) und hinsichtlich des Kernels und der anderen im Dateisystem enthaltenen GPL-Komponenten (und unter dem "als Ganzes"-Aspekt, wie ich ihn versucht habe zu begründen) schlägt ohnehin die GPL die AVM-Lizenz ("Falls und soweit Open Source Software überlassen wird, gelten zusätzlich und vorrangig vor den vorliegenden Bestimmungen die Nutzungsbedingungen, denen die Open Source Software unterliegt.").
Dieser "Ausflug" zu den Lizenz-Bestimmungen sollte nur noch mal (er)klären, warum ich nicht einmal bei der Bereitstellung von konkreten Dateien, die ein bootfähiges Image für eine bestimmte Aufgabe bei einem bestimmten FRITZ!Box-Modell enthalten, irgendein "Unrechtsbewußtsein" haben würde ... auch wenn mir persönlich wieder die "Verwaltung" so eines Fundus für eine größere Anzahl von Modellen viel zu anstrengend ist und ich so etwas daher eher immer "on-the-fly" machen würde (wie das gehen kann, kommt gleich). Wenn sich jemand aber berufen fühlt, seinerseits fertige Images auf der Basis von mir bereitgestellter Shell-Skripte (bzw. auf der Weiterentwicklung dieser Dateien beruhende Lösungen) zu erstellen und anderen zur unkomplizierten Verwendung zur Verfügung zu stellen, darf/kann/soll er das in meinen Augen gerne tun. Wenn er sich dabei wohler fühlen sollte, daß ich als "Anstifter" das ebenfalls (ggf. auch zuvor) mache, stelle ich auch gerne selbst irgendein Image als exemplarisches Beispiel (und als Angriffspunkt für Einsprüche von AVM) bereit ... vermutlich am ehesten eines, das für die 7490 passend wäre.
Für den hier zu besprechenden Zweck ist es aber gar nicht notwendig, daß man auf ein Wurzeldateisystem von AVM zurückgreift ... weder auf das ext2-Dateisystem für die "wrapper"-Partition noch auf das dort enthaltene SquashFS-Image mit dem eigentlichen "rootfs". Da alle für den Zugriff auf die Daten in den TFFS-Partitionen notwendigen Komponenten (dort "lagern" die Einstellungen einer FRITZ!Box) bereits im Kernel fest eingebaut sind, braucht man nur noch irgendein Dateisystem mit einem passenden Format, welches dieser Kernel als Wurzeldateisystem mounten kann und aus dem er dann seinerseits die weiteren Dateien (in erster Linie auszuführende Kommandos und die dafür notwendigen Binärdateien, die sich bei einer FRITZ!Box alle in einer einzigen Datei - der BusyBox - versammeln) laden kann.
Da wir für unsere Aufgabenstellung hier am Ende nur eine einzige (statisch gelinkte) BusyBox-Datei brauchen, die ich parallel auch noch im Repository bereitstelle (es ist - nebenbei bemerkt - dieselbe, die auch beim "modfs"-Paket dabei ist und dank der Signatur daneben bürge ich mit meinem "guten Namen" (auch wenn ich nicht Hipp heiße) auch für diese Datei und deren (relative) Ungefährlichkeit), brauchen wir tatsächlich gar kein AVM-Dateisystem und bauen uns einfach (für diese simple Anwendung ist das tatsächlich "einfacher") unser eigenes ext2-Image, in dem wir die notwendigen Dateien erstellen und das wir dann zusammen mit dem Kernel in unser bootfähiges Image aufnehmen. Dafür verwenden wir eine 10 MByte große Image-Datei, diese begrenzt dann gleichzeitig auch die max. Größe der Dateien, die wir dort hineinkopieren können. Aber wir sind ohnehin genügsam und brauchen nicht viel ... es handelt sich in der Summe nur um einige wenige Dateien, von denen die BusyBox mit ihren knapp 1,2 MByte (die ist halt statisch gelinkt, dafür braucht es nur diese eine Datei und keine weiteren Bibliotheken) noch die größte ist:
Diese 5 "richtigen" Dateien braucht es nur (zusammen mit ein paar "device files" und einigen symbolischen Links - das sind Verweise an einer Stelle in einem Dateisystem auf eine andere), um ein bootfähiges Image zu erstellen, welches beim Laden und Ausführen dann in der "ar7.cfg" einer FRITZ!Box (wo u.a. auch die Informationen zu den Benutzerkonten liegen) die Änderungen vornimmt, die für das Aktivieren des "Keine Anmeldung (nicht empfohlen)"-Punktes bei den Einstellungen zur Anmeldung erforderlich sind.
Dieser Modus ist zwar definitiv nichts für den "täglichen Betrieb" einer FRITZ!Box (insofern ist auch das "nicht empfohlen" nur ein schwacher Trost, ich würde diesen Modus komplett verstecken und nur auf richtig komplizierten Umwegen zugänglich machen - z.B. über ein bootfähiges Image :mrgreen
, aber für das Wiedererlangen des Zugriffs auf die Box ist er u.a. auch deshalb ganz gut geeignet, weil seine Aktivierung nur dann irgendwelche Spuren verwischt, wenn die Box ansonsten im Modus "Anmeldung mit dem FRITZ!Box-Kennwort" (auch keine wirklich gute Idee) betrieben wird - das Verhalten einer Box, in der beide reservierten Benutzerkonten gleichzeitig aktiv sind, ist in meinen Augen nicht sauber vorherzusagen und so wird ggf. ein vorhandenes Konto für diesen Modus "ausschließlich mit dem Kennwort" in eines umgewandelt, das für "keine Anmeldung" verwendet wird.
Arbeitet die Box hingegen ursprünglich mit dem "Benutzername/Kennwort"-Modus bei der Anmeldung, werden bei dieser Änderung die vorhandenen Benutzerkonten gar nicht angefaßt und man kann tatsächlich anhand einer als erstes nach eines solchen Problem erstellten Sicherungsdatei irgendwann später in aller Ruhe noch rekonstruieren, welche Einstellungen für die vorhandenen Konten nun vorlagen und ob da ggf. ein Angreifer sein eigenes Kennwort gesetzt hatte und man deshalb keinen Zugriff mehr erhielt.
Was sind das überhaupt, diese "reservierten Benutzerkonten"? AVM verwendet für die beiden weniger sicheren Modi jeweils einen vordefinierten Benutzernamen mit einer festgelegten Benutzer-ID ... es gibt m.E. auch in der Firmware verschiedenen Stellen, wo dieser Modus mal auf der Basis von Benutzernamen und mal anhand der Benutzer-ID geprüft wird. Für den "keine Anmeldung"-Modus kommt dabei ein Benutzer mit dem Namen "@SkipAuthFromHomenetwork" und der UID 101 zum Einsatz und für den Modus "nur mit Kennwort" heißt der Benutzer dann "@CompatMode" und verwendet die UID 100. Bei "Benutzername/Kennwort" fehlen dann diese beiden Konten komplett.
Damit kann man einfach durch das Hinzufügen des Benutzerkontos für "@SkipAuthFromHomenetwork" die FRITZ!Box beim nächsten Start dazu bringen, daß sie den Zugriff auf das GUI ohne Anmeldung erlaubt und trotzdem die bisher definierten Konten immer noch erhalten bleiben ... mit allen ihren Einstellungen. Man kann also auch einfach für den Benutzer mit dem "vergessenen" Kennwort ein neues setzen und danach den Anmeldemodus wieder auf "Benutzername/Kennwort" ändern ... dann löscht die Box das Konto für UID 101 wieder und es sieht praktisch so aus, als wäre niemals etwas gewesen - nur daß man jetzt das (neue) Kennwort für den Benutzer wieder kennt und sich damit anmelden kann.
Diese ganzen Arbeiten mit dem Prüfen der aktuellen Einstellung und der richtigen Reaktion und Änderung, damit beim nächsten Start dann keine Anmeldung am GUI erforderlich ist, übernimmt das Skript "skip_auth_from_homenetwork" aus dem YourFritz-Repository, das wir auch mal kurz ansehen wollen:
Hier geht es mir um die Voraussetzungen, die das Skript bei seinem Aufruf erwartet - die stehen in den Zeilen 33 bis 36. Außer ein paar wenigen (Standard-)Kommandos (die auch die AVM-Version der BusyBox bereitstellen würde, aber diese ist für die Verwendung von DSOs (Dynamic Shared Object - das sind die Pendants zu DLLs unter Windows, also Bibliotheken, die von mehreren Anwendungen genutzt werden könn(t)en und damit nur einmal vorhanden sein müssen) gelinkt und braucht damit mehrere, zueinander passende Dateien - das fällt bei meiner statischen BusyBox weg) braucht es also nur noch ein passend gemountetes "procfs" unter "/proc" und irgendeinen beschreibbaren Platz in einem Dateisystem unter "/tmp".
Um den kompletten Rest (Suchen der "major"-Nummer des TFFS, Anlegen des "character device" für den Zugriff auf die "ar7.cfg" (das ist ja nur ein Name, uns geht es aber um deren Inhalt und so taucht dieser Name auch gar nicht wirklich auf im Skript, höchstens mal in den Kommentaren), Ermitteln des aktuellen Anmelde-Modus und die daraus abgeleiteten Änderungen an den Benutzerkonten) kümmert sich das Skript selbst ... man muß es halt nur in der richtigen Umgebung irgendwie aufrufen. Das kann einmal die sehr begrenzte Umgebung so eines bootfähigen Images für den FTP-Server in der EVA sein oder auch ein laufendes FRITZ!OS - deshalb der dritte Punkt mit dem Bezug auf die zentrale Instanz der AVM-Firmware, den "ctlmgr". Sucht man die verwendeten Kommandos zusammen, kommt dabei diese (eher kurze) Liste heraus (alphabetisch):
Der Aufruf dieses "skip_auth_from_homenetwork" (das ist schon die größte der vier hinzugefügten Textdateien - wir erinnern uns an die Liste der Dateien weiter oben) erfolgt dann aus der Datei "/sbin/rc.init" (der Name ist reine Phantasie, das kann auch irgendwo anders im Dateisystem liegen) und die sieht so aus:
Hier passiert also genau das, was das andere Skript als Voraussetzungen erwartet ... es werden das "procfs" und ein "tmpfs" (das ist ein Dateisystem im Hauptspeicher, was nur für "flüchtige" Daten (volatile) geeignet ist) gemountet, ein Suchpfad für andere Programme definiert (weil "skip_auth_from_homenetwork" beim Aufruf externer Kommandos ohne Pfadangaben (egal ob absolut oder relativ) arbeitet, braucht das eine Idee, wo Programme zu suchen sind - wobei das hier sogar noch entfallen könnte, denn diese Verzeichnisnamen sind "Standard" unter Linux, wenn es um die Suche nach ausführbaren Dateien geht) und dann wird auch schon das andere Skript aufgerufen, bevor nach dessen Beendigung dann die Box einfach neu gestartet wird.
Diese "rc.init" wird dann ihrerseits wieder aus einer Datei aufgerufen, die von "/sbin/init" (das ist das Programm, welches der Kernel nach seiner Initialisierung und nach dem Mounten des Wurzeldateisystems aufruft - diese Rolle übernimmt auch unsere BusyBox) automatisch verarbeitet wird, wenn dieses vom Kernel aufgerufen wurde. Diese Datei mit dem (festen) Namen "/etc/inittab" enthält dann in unserem Falle auch nur eine einzige Zeile:
, mit der dann diese "rc.init" gestartet wird beim Booten (dafür steht die Bedingung "sysinit" in der Zeile). Unser gesamtes Dateisystem besteht also im Hinblick auf "echte Dateien" nur aus diesen drei kleinen Text-Files und der BusyBox, dafür reichen auch die zuvor angesprochenen 10 MByte im ext2-Image locker aus.
Aber wie kommt man denn nun zu einem solchen ext2-Image und dem notwendigen Inhalt dort? Das automatisieren wir einfach auch und das ergibt dann (nur eine mögliche Umsetzung, die auch mehr Dateien und symbolische Links erzeugt, als für "skip_auth_from_homenetwork" eigentlich benötigt würden) das Skript "build_skip_auth_image" aus dem Repository. Dieses ist nun wieder dazu gedacht, daß man es auf einer eigenen Linux-Installation aufruft, in der man zuvor eine Kopie des YourFritz-Repositories angelegt hat.
Da ist zwar einiges mehr enthalten, als wir für diesen Einsatzfall benötigen, aber dann müssen wir uns keine Gedanken über eventuell fehlende Dateien machen und die Skripte können z.B. mit den richtigen relativen Pfaden auch die BusyBox-Datei für die MIPS-Architektur finden, ohne daß man etwas anpassen muß.
Als nächstes brauchen wir dann eine AVM-Firmware, aus der wir unseren Kernel extrahieren können. Deren URL sucht man sich am besten zuvor irgendwie heraus und dann läßt man sie (z.B. hier mit "wget") laden.
Nun haben wir bereits alle "Zutaten" und können uns ans Kochen machen ... ich verwende hier eine 7412 und damit auch eine zu dieser passende Firmware von AVM.
Die Ausgabe von "build_skip_auth_image" wird nach STDOUT geschrieben, wir leiten diesen Stream also in eine Datei um ... und die lassen wir gleich in das YourFritz-Verzeichnis "eva_tools" schreiben, weil wir sie dort dann mit anderen Skript-Dateien benutzen wollen, wenn es um das Booten der Box von diesem Image geht. Da beim Aufruf von "build_skip_auth_image" einige Kommandos ausgeführt werden, die Dateien in einer Weise erzeugen sollen, daß das FRITZ!OS (was nur mit dem Benutzer "root" arbeitet) korrekt darauf zugreifen kann, ist es jetzt notwendig, daß wir als "root" weiterarbeiten ... es gäbe zwar auch andere Möglichkeiten (z.B. "fakeroot", wie es die Freetz-Toolchain verwendet), diese sind aber deutlich komplizierter (auch in der Benutzung), als eine (eher kurzfristige) Umschaltung des Benutzers - der Weg dürfte auf allen Linux-Systemen ähnlich sein, bis hin zu den Canonical-Varianten (ich benutze hier ein openSUSE-System) ... einfach ein "sudo" vor den eigentlichen Aufruf setzen (und das Kennwort für einen berechtigten Benutzer kennen).
Was da nun im Einzelnen innerhalb von "build_skip_auth_image" passiert, erspare ich mir in diesem Beitrag ... zusammengefaßt liest sich das so:
Warum spielt hier Windows überhaupt eine Rolle, wenn wir doch fürs Erstellen des Images ohnehin eine Linux-Installation brauchten? Da komme ich dann wieder auf die oben geschriebenen Zeilen zur GPLv2 zurück und zu dem Gedanken/der Möglichkeit, daß jemand anderes mit einem Linux-System so ein Image für uns vorbereitet haben könnte und wir damit gar kein Linux-System mehr benötigen, um so eine Aktion wie das Umschalten auf "keine Anmeldung erforderlich" auszuführen ... das geht dann also auch mit einem Windows-PC.
Mit anderer Technik aus einem aktuellen Haushalt (Smartphone, Tablet), die auch nicht zum Erstellen eines solchen Images genutzt werden kann, wird es sicherlich auch schwerer, den notwendigen Zugriff über ein LAN-Kabel zu erlangen ... aber auch das wäre machbar, wenn man die FRITZ!Box und einen (autonomen) WLAN-AP (Access Point, also eine WLAN-"Basisstation") miteinander per Kabel verbindet und sich mit seinem WLAN-Gerät am AP anmeldet. Zumindest mit einem (ggf. gerooteten) Android-Gerät sollte das auch funktionieren - das wäre dann aber wieder mehr die Richtung "Linux-System" und bei iOS-Geräten mit Jailbreak läuft es auf dasselbe hinaus (ohne Jailbreak aber dort auch keine eigenen Kommandos in der Shell).
Wenden wir uns also zuerst dem Thema "Linux-System für EVA-Zugriff" zu ... das ist gleichzeitig die erste (und voraussichtlich einzige) Beschreibung meinerseits (jedenfalls in diesem Umfang), wie man die Shell-Skripte aus "eva_tools" benutzen kann.
Beim Zugriff auf den Bootloader einer FRITZ!Box gibt es zwei - eigentlich getrennte - Aufgaben ... einerseits geht es erst einmal darum, eine startende FRITZ!Box im LAN zu finden, sie dann in diesem Modus "festzuhalten" (weil sie nur für 5-10 Sekunden auf eingehende FTP-Verbindungen beim Start wartet) und als zweites geht es dann um die Kommunikation mit dem FTP-Server. Egal ob man auf EVA mit einem Windows-PC oder einem Linux-System zugreifen will ... da eine startende FRITZ!Box ihre Ethernet-Schnittstellen erst einmal aktivieren muß und das System am anderen Ende des Kabels erst dann darüber informiert wird, daß da jetzt "jemand ist", kann jede automatische Netzwerk-Konfiguration, die auf dieses (angenommene) "Einstecken" eines LAN-Kabel reagiert und dann erst einmal per DHCP irgendwelche IP-Adressen für das Interface erfragen möchte, bereits dazu führen, daß die erwähnten 5 bis 10 Sekunden lange um sind, wenn die Netzwerkschnittstelle dann endlich bereit ist, um mit der Box kommunizieren zu können.
Schon aus diesem Grund sollte man - sofern man ein passendes Gerät besitzt, dafür reichen auch alte Gurken für Fast-Ethernet (100 MBit/s) oder sogar solche für 10 MBit/s - irgendeinen Ethernet-Switch (notfalls tut es auch ein Hub und bei der Variante mit dem WLAN-AP wäre auch dieser bereits ausreichend) zwischen FRITZ!Box und PC schalten und auf dem PC dafür sorgen, daß das verwendete Ethernet-Interface bereits eine IPv4-Adresse hat - das kann bei einem Windows-System auch gerne eine APIPA-Adresse aus dem Bereich 169.254.0.0/16 sein (oder das "zeroconf"-Pendant beim Linux).
Wichtig ist nur, daß diese Adresse bereits aktiv ist (also kein bis dahin unkonfiguriertes Interface erst beim "media sensing" auf die Suche nach einer DHCP-Adresse geht) - arbeitet man ohne zusätzliche Hardware zwischen FRITZ!Box und PC, muß man ggf. das "media sensing" im verwendeten PC-Betriebssystem auch abschalten - das Internet hilft bei der Suche, wie das beim eigenen System geht und auch Windows-Benutzer müssen heutzutage dafür nicht mehr in die Tiefen der Registry hinabsteigen; also Vorsicht vor allzu alten "Anleitungen", wie man das über die Registry machen kann - zumal das dann erst nach einem Neustart wirksam wird.
Für den ersten Schritt (das Suchen der FRITZ!Box, bei dieser Suche kann man dann einer FRITZ!Box mit einer bis dahin unbekannten Adresse, die diese im Bootloader benutzt, auch gleich noch eine definierte Adresse zuweisen, die zu Konfiguration des eigenen Ethernet-Interfaces paßt) gibt es Unterstützung von mehreren Seiten ... ich zähle mal ein paar auf, bevor ich mich den Skript-Dateien im YourFritz-Repository für diesen Zweck widme:
(*) Ich bin zugegebenermaßen kein allzu großer Fan des "ruKernelTools", weil das in meinen Augen eher "closed source" ist, auch wenn der Autor den Einblick in den Source-Code anbietet (zumindest für die Version ohne das "X" im Namen). Dort wird m.W. "AutoIt" verwendet, eine BASIC-artige Programmiersprache für die Automatisierung von Windows-Aktionen und die war sicherlich zum Zeitpunkt der Entstehung des Tools noch ein gangbarer und notwendiger Weg, aber heutzutage kommt eben jede noch von MS unterstützte Windows-Version auch in den Genuß einer weitaus mächtigeren Script-Engine - der PowerShell.
Da hat man dann wieder beide Vorteile vereint ... einerseits sind solche PowerShell-Skripte auch ohne Hilfsmittel "lesbar", was ein Review wahnsinnig erleichtert und das notwendige Vertrauen in den Autoren überhaupt erst entstehen lassen kann (in meinen Augen) und andererseits ist das auch eine Art und Weise der "Programmierung", wo sich irgendwelche Virenwächter nicht dran stören (oder zumindest extrem selten), während es bei AutoIt schon mal deutlich öfter zu Alarm kommt, auch wenn das vielleicht alles "false positives" sein sollten ... eine Heuristik oder Verhaltensanalyse kann eben bei solchen "Skriptsprachen", die in Form einer einzelnen ausführbaren Datei (exe) daherkommen, wesentlich leichter auf falsche Ideen kommen als bei "normalen" Programmen.
Es ist ja nicht ganz einfach (und logisch zu vermitteln), wenn man jemandem auf der einen Seite einen Virenwächter empfiehlt (und sei es nur der Windows-Defender als "eingebaute" Variante - mal unabhängig von jeder Diskussion darum, wie notwendig, wichtig und richtig solche Software nun ist) und auf der anderen Seite soll man dann sagen: "Wenn es aber das Programm ist oder jenes, dann sind das alles Fehlalarme." - das macht es für den "normalen Anwender" ja nicht leichter, eine Entscheidung "von Fall zu Fall" zu treffen und i.d.R. wird er auch dann am ehesten auf solche Probleme mit AutoIt-Programmen treffen, wenn er diese eigentlich ganz dringend bräuchte und gar keine Zeit/Lust hat, da erst großartigen Aufwand in eine gründlichere Untersuchung zu stecken.
Also wird gerade dann am ehesten auf "mach mal" gedrückt und das ist eine erhebliche Gefahr. Durch die regelmäßig "ablaufenden" Programmversionen (auch wenn ich die Idee dahinter nachvollziehen kann) wird das auch nicht erleichtert ... man kann eben nicht nur ein einziges Mal hingehen und eine bestimmte Version gründlich untersuchen und als "ungefährlich" einstufen, denn wenn man die dann wirklich mal verwenden will, ist ihre "Haltbarkeitsdauer" i.d.R. bereits abgelaufen. Dabei wäre gerade dieses Tool mit der Integration aller Schritte in einem einzigen Aufruf auch gut dazu geeignet, solche Images wie hier direkt in eine FRITZ!Box zu laden und dort zu starten ... ich finde den Ansatz also gar nicht so schlecht, aber kann eben "AutoIt" als Grundlage nicht wirklich "empfehlen".
Das gilt aber auch für Java oder etwas anderes, was "plattformübergreifend" zur Verfügung stünde (und einer lokalen Installation bedarf) - jede zusätzlich zu installierende Software vergrößert die Angriffsfläche auf ein System und zieht - schon mit regelmäßig notwendigen Updates u.ä. - weiteren Aufwand nach sich. Leider bei vielen Systemen mit dem Ergebnis (das sagt jedenfalls meine Erfahrung), daß dann immer eine gammelige alte Java-Installation noch irgendwo "herumliegt" (aka dahinvegetiert), weil die mal von irgendeiner getesteten Software benötigt und nicht zusammen mit dieser deinstalliert wurde - es gibt aber gar keine andere Software, die dieses Java benötigen würde oder auch nur von ihm wüßte - bis dann doch mal eine Malware auf der Suche nach Schwachstellen genau auf eine solche alte Version trifft und deren Lücken ausnutzt.
Wenn eine Lösung mir also "gefallen" soll, dann braucht sie nur ein Minimum an zusätzlicher Software (auch kein PHP, Perl, Python, keine LAMP-Installation, keine weiteren Datenbanken, usw. usf.) und erzeugt nicht für eine eher selten benötigte Funktion einen zusätzlichen "Wartungsaufwand", der in keinem Verhältnis zum "Ertrag" aus der Nutzung der Software steht.
Es ist also gar nicht notwendig, daß man die beiden Schritte (Suchen der Box und "Festhalten" im Bootloader einerseits und die Kommunikation mit dem FTP-Server andererseits) mit demselben Programm erledigt oder auch nur auf derselben Plattform. Wer z.B. kein Linux-System mit einer "socat"-Variante hat (die wird für die UDP-Broadcasts benötigt und ich kenne keine Alternative, die ohne C-Compiler auskommt - womit ich dann wieder beim Thema "zusätzliche Software" bin), kann auch die Box mit einem Windows-System und dem AVM-Recovery-Programm (wie geschrieben, für ein falsches Modell - die Idee dahinter hatte ich hier schon früher beschrieben) bis zu diesem Punkt treiben und dann mit einem anderen System (z.B. einem RasPi mittels einer SSH-Session) mit dem FTP-Server weiter arbeiten.
Will man dann unter Linux (oder OS X, wobei ich das noch nicht getestet habe) mit meinem "eva_discover" arbeiten, braucht man zunächst mal Informationen zu seinen eigenen Netzwerk-Einstellungen. Das Skript an sich ist weit, weit von einer Fertigstellung entfernt ist, das war auch mal in der Vergangenheit nur eine "Prinzipskizze" (vorab für jemanden als Beispiel eingecheckt) mit jeder Menge offener Baustellen bei den Parametern, bis mir dann die Notwendigkeit der wiederholten Betonung dieser Tatsache auf den Geist ging und ich jeden Code zur Erkennung von Einstellungen deaktiviert habe. Damit braucht man jetzt folgende Informationen, wenn man das Skript erfolgreich aufrufen will:
Optional verkraftet das Skript zum Suchen der FRITZ!Box (das heißt - nebenbei bemerkt - dann "eva_discover") auch noch weitere Angaben:
Wie man jetzt Interface-Namen und IP-Adressen findet, beschreibe ich hier nicht ... das ist u.a. auch von der Distribution abhängig und definitiv "nicht mein Tisch". Bei mir nehme ich einfach das Interface "vlan1" und die eigene IP-Adresse 192.168.178.2 (mit einer 24er-Maske, die hier aber nicht angegeben wird) - das ergibt dann für die 7412 die Möglichkeit, mit der Adresse 192.168.178.1 (auch hier wieder eine implizierte /24, die aber auch nicht angegeben wird) zu arbeiten. Man kann hier aber wirklich mit jeder beliebigen eigenen Adresse arbeiten und muß sich nur eine dazu passende Adresse der FRITZ!Box "ausdenken", damit die Pakete auch auf dem richtigen Netzwerk-Interface (vorausgesetzt, die Linux-Maschine hat mehr als eines) gesendet werden. Dann sind die anderen Einstellungen auch egal, weil das alles innerhalb derselben L2-Domain arbeiten muß und da spielen dann auch Netzwerk-Masken nur noch eine sehr untergeordnete Rolle. Wir passen hier also die FRITZ!Box an unsere Vorstellungen an und nicht umgekehrt unsere Vorstellungen an die FRITZ!Box.
Wenn das "eva_discover"-Skript die FRITZ!Box nicht finden kann innerhalb der vorgegebenen Zeit, wird "EVA_FOUND=0" auf STDOUT ausgegeben, ansonsten "EVA_FOUND=1" und als "EVA_IP=<ip>" auch die Angabe, welche Adresse die FRITZ!Box jetzt hat. Man kann nämlich mit "TO=0.0.0.0" ihr auch gestatten, die bisher eingestellte Adresse weiterhin zu verwenden - ggf. muß man mit Problemen rechnen, wenn diese bei der eigenen Linux-Maschine auf einem anderen Interface läge, wie es häufig bei "99.88.77.xx" der Fall sein dürfte, da wird wohl in der überwiegenden Zahl der Fälle die "default"-Route zuständig sein. Diese Art der Ausgabe auf STDOUT (alle anderen Ausgaben gehen nach STDERR und sind damit leicht von diesen Angaben zu trennen) macht es auch möglich, den Aufruf einfach in eine Form
zu kleiden ... da erkennt man dann auch, warum es gar nicht erforderlich ist, die Box mittels "HOLD=1" irgendwie aus dem Tritt zu bringen. Wenn man weiß, was man machen will, packt man einfach diese 7 Zeilen in eine Textdatei (mit den richtigen Angaben beim Aufruf von "eva_discover" und "eva_to_memory") und ruft die dann mittels "bash <dateiname>" auf (oder auch mit der "dash" oder "ash", wenn man eine BusyBox verwendet). Da die Parameter eben von der eigenen Installation abhängig sind, macht es auch wenig bis keinen Sinn, so etwas als "template" bereitzustellen.
Wir haben also unsere Box "vorbereitet" mit der Verkabelung und sind jetzt zurück in der oben unterbrochenen Linux-Shell-Session:
Während die FRITZ!Box gesucht wird, erfolgt durch das "BLIP=1" beim Aufruf eine Anzeige mit einer wachsenden Anzahl von Punkten (für jedes UDP-Paket einer) auf STDERR, die am Ende über ANSI-Terminal-Sequenzen wieder gelöscht wird, daher taucht sie oben bei mir nicht auf in der CODE-Box. Während diese Punkte nun einer nach dem anderen angezeigt werden, muß man irgendwie die FRITZ!Box neu starten ... das geht vom "Strom aus/ein" (das man auch an beiden Ende der Stromversorgung praktizieren kann oder über eine fernsteuerbare Steckdose) bis zum "reboot"-Kommando (auch über das GUI), was hier aber vermutlich nicht in Frage kommt, solange man sich auf der Box nicht einloggen kann.
Bisher hat noch jede FRITZ!Box, die ich dabei bewußt beobachtet habe, beim Initialisieren der GPIO-Ports für die Ansteuerung der LEDs alle gleichzeitig kurz aufblinken lassen und danach beginnt die Karenzzeit (wie gesagt, irgendwas zwischen 5 und 10 Sekunden nach meiner Erfahrung), in der man mit der Box Verbindung aufgenommen haben muß. Wenn sich also innerhalb von - sagen wir mal - 15 Sekunden nach dem Herstellen der Stromversorgung noch nichts getan hat (die GRX500-Boxen brauchen wohl länger, was ich auf die angenommene Virtualisierung zurückführen würde), dann ist irgendetwas anderes faul im Staate Dänemark ("Something is rotten in the state of Denmark.") und wenn das auch bei einem zweiten oder dritten Versuch nicht funktionieren will, ist da der Wurm drin und es wird auch beim 20. Versuch (ohne Änderungen) eher nicht funktionieren. Dann gibt es i.d.R. irgendwo einen Fehler, z.B. hängt die Box (oder der dazwischengeschaltete Switch) am falschen Ethernet-Port des Rechners oder es wird doch irgendeine langwierige Autokonfiguration verwendet und die frißt dann schon die verfügbare Karenzzeit. Das ist allerdings bei Windows-PC deutlich häufiger der Fall, weil diese Autokonfiguration unter Linux eher (und gründlicher) abgeschaltet werden kann.
Hier habe ich jedenfalls im oben stehenden Beispiel auch gleich noch den Aufruf für den Zugriff auf den FTP-Server angehangen ... auch dieser ist auf vielen anderen Wegen realisierbar - es muß nur eine passive Datenübertragung möglich sein und damit fällt der Kommandozeilen-FTP-Client von Windows bereits aus. Allerdings sind eben ein paar Berechnungen auf der Basis der Hauptspeichergröße der FRITZ!Box und der Größe des Images notwendig und diese Berechnungen übernimmt i.d.R. kein anderer "FTP-Client" ... genau für diesen Upload eines bootfähigen Images ist das Skript "eva_to_memory" ja mal entstanden. Das erwartet als ersten Parameter den Namen der zu übertragenden Image-Datei (deshalb haben wir das weiter oben ja direkt in diesem Verzeichnis gespeichert, das erspart uns jetzt die Angabe von Pfaden) und als optionalen zweiten Parameter die IP-Adresse der FRITZ!Box, wobei da "192.168.178.1" verwendet würde, wenn die Angabe fehlt.
Anders als "eva_discover" braucht nun "eva_to_memory" anstelle von "socat" auch nur noch eine Version von "netcat" (unter dem Namen "nc"), wobei hier die "Geschmacksrichtung" aus dem "netcat-openbsd"-Paket die erste Wahl ist. Das "netcat-traditional" (das ist m.W. die GNU-Version) kennt einige der verwendeten Parameter nicht und ich habe bisher keine Lust gehabt, das Skript so abzuändern, daß es auf diese Parameter verzichten könnte. Jedenfalls ist nun "netcat" auch auf durchschnittlichen Linux-Installationen deutlich öfter bereits vorhanden, als das beim "socat" der Fall ist, auch wenn wohl die meisten Distributionen die Installation von "socat" aus einem (Binär-)Repository unterstützen werden.
Jedenfalls wurde dann im o.a. Beispiel das zuvor erzeugte bootfähige Image in die FRITZ!Box 7412 geladen und dort gestartet ... das brauchte ja nun nicht sehr lange für die Abarbeitung von "skip_auth_from_homenetwork" und startete dann die 7412 gleich noch einmal. Nach diesem Start konnte man/ich dann problemlos auf das GUI der 7412 zugreifen - auch ohne jede Anmeldung, wobei mich in der Übersichtsseite die Information/Warnung "Kennwortschutz nicht aktiv, Kennwort setzen" darauf hinwies, daß da etwas zu tun wäre.
Für die Verwender einer Linux-Maschine war es das dann auch schon (nur noch das "Aufräumen" bzw. Löschen der Dateien aus dem geklonten Repository stünde ggf. an) ... mit sieben Kommandos (die "ls -l" zur Verdeutlichung dessen, was da an Dateien existiert, habe ich mal nicht mitgezählt) haben wir auf einer (angenommen unbekannten und unzugänglichen) FRITZ!Box 7412 einen Zugriff auf das GUI erhalten. Es klingt (angesichts der Länge dieses Beitrags bis hier, aber Strafe muß eben auch sein, wenn man seine Kennwörter vergißt oder Fremde an der eigenen FRITZ!Box spielen läßt) vielleicht etwas komisch, aber wenn man erst einmal weiß, wie es geht und wo man die notwendigen Dateien findet, dann braucht das keine fünf Minuten ... da ist natürlich die Zeit zum Lesen und Verstehen keinesfalls eingepreist. Das geht aber (zumindest für Linux-Benutzer, die nichts groß installieren müssen und direkt mit dem "git clone" loslegen können) deutlich schneller, als sich erst irgendwelche anderen Pakete/Programme (von Freetz - wo teilweise schon das "svn checkout" so lange braucht - bis zum "ruKernelTool", was man i.d.R. auch erst neu laden muß, weil es mal wieder abgelaufen ist) zu installieren und es ist auch deutlich schneller wieder von der eigenen Platte geputzt, wenn man es nicht länger benötigt.
Als Alternative gibt es in "toolbox" auch noch eine Variante (add_user_to_fritzos), mit der man anstelle der Umschaltung des Anmeldemodus einen neuen Benutzer-Account mit einem anzugebenden Namen und Kennwort (wobei beides auf "superuser" gesetzt wird, wenn man die Angabe ausläßt) hinzufügen kann, den man dann nach dem nächsten Start zur Anmeldung verwendet (der hat auch die Rechte "aus dem Internet" - und das ist durchaus Absicht). Auch dafür gibt es mit "build_add_user_image" ein Shell-Skript, was genauso arbeitet wie "build_skip_auth_image" und halt nur das andere Shell-Skript auf der Box startet. Das ist als zweites Beispiel zwar etwas schwach (weil die Unterschiede sehr gering sind), aber mit diesem Skript kann man auch noch anderen Unsinn treiben ... darauf komme ich später noch einmal zurück.
Trotzdem sollte man bis hier dann das Prinzip verstanden haben und wer möchte, kann sich nun eigene Skripte bauen, die er auf der Box ausführen läßt. Das geht z.B. mit einem "Auslesen" des TFFS-Inhalts los (für Forensiker immer ein Thema, wie man ein Gerät untersuchen kann, ohne es zu verändern oder aufzuschrauben und auseinanderzunehmen), wobei man dabei dann noch einen Weg finden muß, die ausgelesenen Daten aus der Box zu schaffen (wenn man sie nicht im NAND für das NAS ablegen kann/will, wobei auch für den Zugriff auf diesen Speicher noch ein paar mehr Dateien benötigt würden, als sie meine beiden Beispiele im Image anlegen) - dafür bietet sich dann z.B. TFTP an, wie es auch AVM verwendet, wenn die Ergebnisse einer Installation von Firmware protokolliert werden sollen (dafür braucht es dann noch ein paar Environment-Variablen im Bootloader, damit diese Installationsdateien die Netzwerk-Funktionen aktivieren).
Solange man nicht auf das WAN-Interface (und irgendein Modem) will, ist so eine simple Netzwerk-Konfiguration aller vorhandenen Ethernet-Ports als Bridge (auch bei der 7412 muß man nicht unbedingt vor eth1-eth3 zurückschrecken, dann gibt das eben einen (zu ignorierenden) Fehler, wenn die fehlen) schnell erledigt, wenn die passenden Kommandos in der BusyBox und ein paar benötigte Geräte-Dateien in "/dev" vorhanden sind. Dann kann man auch mit so simplen Protokollen wie TFTP (oder auch mit einem "nc") mit der Außenwelt aus so einem bootfähigen Image heraus kommunizieren ... wobei ich das jetzt nicht soweit treiben würde, daß ich da auch noch einen USB-Speicher einbeziehe. Das ist dann mit dem AVM-Dateisystem (und dort gemounteten oder überlagerten Dateien, wie es z.B. "modfs-Starter" gemacht hat) wieder einfacher zu realisieren ... die Möglichkeiten für Tests und Fehlersuchen sind ohne bestückte serielle Schnittstelle in der FRITZ!Box auch eher beschränkt und es macht nicht wirklich Spaß, da Fehler in den eigenen Dateien zu suchen.
Was aber noch relativ einfach umzusetzen ist ... die Installation von ShellInABox auf demselben Weg, wie ich es im "modfs-Starter"-Thread mal beschrieben habe, erfordert nur noch eine passende Gerätedatei für das MTD-Device mit der yaffs2-Partition und das passende "mount"-Kommando; dann kann man auch in diese Partition schreiben, die später im laufenden System nach dem "pivot_root" als "wrapper" verbleibt und wo es noch einiges an Platz gibt, den man benutzen kann. Wie das aussehen kann/würde, kann man in "update_yaffs2" nachlesen - auch wenn man hier bei der Installation natürlich etwas anders vorgehen müßte, wären die "inline"-Skripte dort in etwa das, was man in die Wrapper-Partition schreiben lassen müßte. Auch das sollte sich mit wenig Aufwand in ein Skript packen lassen und auch ein "build_..._image"-Skript dafür sollte nur ein paar kleine Zusätze benötigen im Vergleich zu den beiden anderen.
Vielleicht werde ich im Laufe der Zeit noch ein paar weitere praktische Skripte in das "toolbox"-Verzeichnis einfließen lassen ... das sind nur zwei (zuvor nicht richtig parametrierbare und nicht dokumentierte) Beispiele von Dateien, die ich ansonsten bisher eher auf einem RasPi hatte, den man per SSH-Session steuern und mit dem LAN-Interface an eine FRITZ!Box stecken kann. Meine Ambitionen, das auch mit einem "GUI" zu versehen und dann direkt über einen Touchscreen zu steuern, sind bisher immer an mangelnder Zeit gescheitert ... aber es wäre schon "cool", wenn man nur noch eine FRITZ!Box anstecken müßte und dann automatisch das Modell ermittelt, die richtige Firmware geladen (wenn sie nicht schon vorhanden ist) und damit ein bootfähiges Image mit "skip_auth_from_homenetwork" erzeugt und gestartet wird. Das illustriert dann als "schlüsselfertige Lösung" vielleicht auch meine Kritik hinsichtlich der Angreifbarkeit der FRITZ!Boxen über das LAN-Kabel besser, als es Worte je könnten ... bei einer ausreichend großen "Bibliothek" mit AVM-Images und Zugriff auf das Stromversorgungs- und LAN-Kabel einer FRITZ!Box dauert das im "Automatik-Modus" vielleicht noch 2-3 Minuten, so eine FRITZ!Box "zu übernehmen" und ob das deren Besitzer dann tatsächlich bemerkt, hängt auch eher davon ab, wie ungeschickt sich so ein Angreifer dann anstellen mag. Aber darauf komme ich nachher noch einmal zurück ... jetzt wäre es (vom Aufbau her) eher an der Zeit, sich dem EVA-Zugriff von einem Windows-System unter Benutzung der PowerShell-Skripte aus dem "eva_tools"-Verzeichnis zu widmen.
-Auch hier beim Windows will ich mich nicht mit Fragen aufhalten, die mit dem Zugriff auf den Bootloader nur am Rande zu tun haben ... z.B. dem Thema, wie man das erzeugte bootfähige Image nun von der Linux-Maschine, auf der es erstellt wurde, auf irgendein Windows-System mit einer PowerShell bekommt. Was vermutlich nicht funktionieren wird (ich habe es aber auch nicht wirklich probiert), ist die Verwendung der Skripte in der von Canonical mit Microsoft entwickelten "bash"-Shell unter Windows (x64 unter "developer tools"). Das liegt m.E. daran (auch wenn ich es nicht getestet habe), daß dort gar keine echten Treiber für Dateisysteme existieren dürften und das Mounten unseres eigenen Images damit schon fehlschlagen sollte. Wenn es doch funktioniert, bin ich zumindest mal überrascht ... aber zu dem, was unter dieser Shell aus dem YourFritz-Repository benutzbar ist und was nicht, habe ich irgendwo an anderer Stelle schon etwas geschrieben - auch wenn ich selbst nicht mehr weiß, wo das genau war und das will ich jetzt auch nicht suchen und hier verlinken. Zunächst mal reicht es mir, wenn ich meinerseits einfach feststelle, daß diese Skripte nicht für die "bash" unter Windows x64 gedacht sind und jede erfolgreiche Anwendung rein zufällig und von mir nicht beabsichtigt wäre.
Wer die PowerShell-Skripte verwenden möchte, sollte als erstes mal seine PowerShell-Installation (gerade auch dann, wenn er - wie ich - immer noch gerne auf einem Windows 7 arbeitet) auf den aktuellen Stand bringen ... die Minimal-Anforderungen für die PowerShell-Version stehen in "EVA-FTP-Client.ps1" (ab Zeile 360 im Moment) und können jederzeit auf dem eigenen System durch die Eingabe von "$PSVersionTable" in einer PowerShell-Session abgefragt werden.
Da es ein paar Sicherheitbeschränkungen bei der Benutzung der PowerShell gibt und man als "Hobby-Anwender" sicherlich eher nicht auf die Idee kommen wird, die Skripte irgendwie zu signieren, muß man - nach dem Download der Skripte als Textdatei mit Speichern an irgendeiner Stelle, wo man sie auch wiederfindet - zunächst mal diese Sicherheitseinstellungen korrekt vornehmen (das gilt für jedes PowerShell-Skript und ist nicht spezifisch für die EVA-Skripte) ... auch das ist wieder ein Thema, was mehrfach im Internet beschrieben ist (Stichwort "Set-ExecutionPolicy") und was ich hier nicht noch einmal auswalzen will.
Für die erste Aufgabe beim Kontakt zum Bootloader einer FRITZ!Box (das war das Suchen und Finden der Box) gibt es das Skript "EVA-Discover.ps1", welches - neben den ansonsten noch möglichen Parametern für praktisch jedes Skript - als Parameter "-maxWait" die Anzahl der Sekunden erwartet, die es auf die FRITZ!Box warten soll, wobei hier der Standardwert nur 30 Sekunden sind. Mit "-requested_address" kann man die IP-Adresse für die FRITZ!Box "ansagen" (der Standardwert ist die AVM-übliche 192.168.178.1) und mit "-nohold 1" könnte man auch hier den TCP-Verbindungsversuch zur FRITZ!Box unterbinden ... anders als bei der Linux-Variante nutzt aber das PowerShell-Skript inzwischen eine korrekte FTP-Anmeldung bei dieser Verbindung und das funktioniert dann - nach meiner bisherigen Erfahrung - auch wesentlich besser, weshalb hier auch die Bedeutung des Parameters (und dessen Standardwert) so geändert ist, daß man den Wunsch nach "nicht anhalten" gesondert äußern muß. Mit den Parametern "-Debug" und "-Verbose" kann man ein paar zusätzliche Nachrichten generieren, damit man auch hier die "Warterei" des Skripts sehen kann.
Anschließend steht hier die FRITZ!Box wie eine Eins und man hat alle Zeit der Welt, sich dem FTP-Zugriff zu widmen.
Dazu brauchen wir dann das andere Skript (oben schon mal verlinkt), welches sich auf zwei verschiedenen Wegen benutzen läßt, wie im Skript (derzeit um Zeile 610 herum, das kann sich auch mal etwas verschieben) beschrieben ist. Man kann entweder vor der Benutzung hingehen und die auszuführenden Aktionen (die Liste der bereits implementierten Funktionen steht in der erwähnten Beschreibung) der Reihe nach in die geschweiften Klammer um diesen Kommentarblock herum einfügen, dann braucht man beim Aufruf nur den Parameter "-Address" angeben mit der IP-Adresse der FRITZ!Box und auch das ist nur erforderlich, wenn es nicht die als Standard vorgegebene 192.168.178.1 wäre. Auch hier kann man wieder mit "-Debug" und "-Verbose" etwas mehr an Informationen aus dem Skript herauskitzeln, während es mit der Box kommuniziert.
Da dieses Editieren der Datei etwas unpraktisch sein kann (es sei denn, man hat eine Kopie für einen ganz gezielten Anwendungsfall, die man desöfteren verwenden will), bevorzugt das Skript die Angabe eines "ScriptBlock"-Parameters beim Aufruf. Das ist im Prinzip nichts anderes als die Angabe der aufzurufenden Funktion(en) in geschweiften Klammern ... das aber nicht mit irgendwelchen Anführungszeichen oder ähnlichem, weil das keine Zeichenketten sein sollen. Will man mehrere Aktionen ausführen lassen (z.B. ein TFFS-Image in beide TFFS-Partitionen schreiben lassen, wobei die 7412 auch dort nur eine Partition (mtdnand) hat), trennt man diese mit einem Semikolon innerhalb des Blocks (also innerhalb der geschweiften Klammern). Zusammengesetzt sieht das dann so aus (alle Dateien auf dem Desktop gespeichert, mit "Save as" für die "raw"-Versionen aus GitHub und bitte auch das "unblock" in den Eigenschaften nicht vergessen), wenn man wieder dieselbe Image-Datei in die 7412 laden läßt:
Das war es dann aber auch schon, wenn man die PowerShell-Skripte unter Windows verwenden will - mehr wüßte ich dazu jetzt nicht zu schreiben.
-Kommen wir noch einmal kurz auf das "add_user_to_fritzos" zurück. Eines fällt ja an den von AVM für die reservierten Benutzerkonten verwendeten Namen auf ... beide beginnen mit dem eigentlich unnötigen Zeichen "@". Was mag da wohl der Hintergrund sein? Das ist ganz einfach ... AVM zeigt einfach alle Benutzer, deren Name mit diesem Zeichen beginnt, im GUI nicht an und zwar weder in der Select-Box für die Anmeldung aus dem LAN, noch in der Benutzerliste unter "System" oder gar in der Seite für die Analyse der Sicherheitseinstellungen. Das verhindert aber nicht, daß man ein solches Konto für die Anmeldung verwendet ... z.B. für einen TR-064-Zugriff. Zwar wird dieser Zugriff dann tatsächlich auch im Ereignisprotokoll als "Anmeldung einer App des Benutzers @irgendwas von IP-Adresse x.y.z" aufgeführt, aber es ist eben auch möglich, das Event-Log zu manipulieren, wenn man erst einmal über irgendeine Lücke Shell-Zugriff erlangt hat.
Sind dann keine E-Mails für diese Anmeldungen aktiviert (wobei die TR-064-Anmeldungen iirc ohnehin keine solchen E-Mails erzeugen), kriegt der FRITZ!Box-Besitzer davon am Ende nicht einmal in jedem Falle etwas mit, daß es da jetzt einen zusätzlichen Benutzer-Account in seiner FRITZ!Box gibt (er sieht den Namen ja auch nicht wirklich in einer Sicherungsdatei und kann höchstens durch Abzählen der Einträge dort erkennen, daß es einer zuviel ist) - wenn der Angreifer jetzt noch die Energie aufbringt, das Event-Log auch noch zu manipulieren, dann ist der schon fast "unsichtbar". Für eine solche Manipulation des Event-Logs reicht es ggf. schon, den Zeiger für den nächsten Eintrag zurückzusetzen und irgendeine andere Nachricht mittels "eventadd" zu erzeugen (das müßte ich für die neue 06.83 glatt mal wieder probieren) ... die AVM-Komponenten greifen m.W. über "memory mapped file"-Operationen auf die Datei zu, in der dieses Event-Log am Ende gespeichert wird (/var/.ar7events).
Daher finde ich jedenfalls, daß es sich AVM hier auch mit diesem Sonderzeichen für das Verstecken von Benutzernamen zu einfach macht (man findet das z.B. auch in den (OpenSource-)Quellen für den "ftpd", daß dort gar nichts in das Event-Log geschrieben wird, wenn ein Benutzer mit dem "@" am Beginn für eine solche Nachricht in Frage käme) ... für @SkipAuthFromHomenetwork und @CompatMode könnte man das auch anhand der Benutzer-ID entscheiden und sollte es für die Dateifreigaben über HTTP-URLs tatsächlich zusätzliche Accounts geben müssen (ich habe irgendwo im Hinterkopf die Idee, daß ich mal etwas in dieser Richtung irgendwo gesehen hätte, finde aber im GUI einer 06.83 gerade keine Möglichkeit, solche Links zusätzlich zu schützen), dann kann man das bestimmt auch anders regeln. Diese sehr einfache Variante, ein komplettes Konto vor den Augen des Besitzers und/oder berechtigten Administrators zu verstecken, ist jedenfalls irgendetwas zwischen einer Schwachstelle und einer echten Backdoor, wenn z.B. die FTP-Zugriffe so eines Nutzers gar nicht protokolliert werden (in den "ftpd" (Datei "ftpd.c" aus den "inetutils" in den AVM-Quellen) kann jeder selbst hineinschauen).
-Ich bin - nur um das auch noch einmal festzuhalten - auch nicht der Ansicht, daß ich mit diesem Beitrag nun irgendwie dabei helfen würde, die Sicherheit von FRITZ!Boxen "aufzuweichen". Für die Benutzung des Bootloaders braucht es immer noch den LAN-Zugriff zum Zeitpunkt des Starts und auch wenn ich es unmöglich finde, wie einfach ein Angreifer an dieser Stelle in eine FRITZ!Box gelangen kann (da käme jetzt wieder der Vorschlag, den FTP-Server im Bootloader nur "auf Knopfdruck" beim Power-On zu aktivieren), so ist das schon länger bekannt und wird - mehr oder weniger schulterzuckend - hingenommen. Das ist hier jetzt nur eine konkrete (für so manchen vielleicht auch sinnvolle) Anwendung, mit der man aber eben auch das Schadenspotential dieser "Schwachstelle Bootloader" demonstrieren kann - in meinen Augen auch recht eindrucksvoll in der "Schlichtheit" dessen, was es dafür nur braucht.
Angesichts der weiter oben angetexteten Möglichkeit, daß so ein falsches Kennwort auch das Ergebnis eines erfolgreichen Angriffs durch einen Dritten sein könnte und daß man mit dem Zurücksetzen des Kennworts über den AVM-Weg erst einmal selbst die Spuren verwischen würde, wenn man nicht zuvor noch eine Sicherungsdatei zieht, müßte man eigentlich sogar darüber nachdenken, ob man nicht auch Software veröffentlichen sollte, die dem FRITZ!Box-Besitzer anhand der Dekodierung der verschlüsselten Daten in so einer Sicherungsdatei (der Weg der "FRITZ!Box Tools" ist zwar auch nicht uninteressant, aber doch schon sehr umständlich zu nutzen) eine Einschätzung ermöglicht, ob es wirklich nur die eigene Vergesslichkeit oder ein Tippfehler bei der Änderung war (auch unterschiedliche Tastatursprachen (DE vs. EN) sind immer wieder gerne genommen als Fehlerquellen in so einem Fall), was da zum Zugangsproblem führte oder ob das doch jemand anderes war, der das originale Kennwort nicht kannte und daher dieses auch nicht wieder aktivieren konnte, um seine Spuren richtig zu verwischen.
Wer tatsächlich bis hier gekommen ist beim Lesen und nun rechtschaffen malade ist, der mache mir keinen Vorwurf und denke eher darüber nach, daß ich beim Schreiben noch viel länger brauchte, als ein durchschnittlich schneller Leser für seinen "Konsum" benötigt.
Wobei es natürlich auch Leute gibt, die Stein und Bein zu schwören bereit sind, daß genau dieses Kennwort gestern (oder auch vorgestern oder vor 10 Minuten) noch problemlos funktionierte ... und auch das sollte man nicht in Bausch und Bogen als Phantasie abtun, weil natürlich auch eine plötzliche Änderung eines Zugangskennworts ein Zeichen für einen (erfolgreich) durchgeführten Angriff sein kann (wo der Angreifer das Kennwort durch ein ihm bekanntes ersetzt hat und das nun nicht einfach rückgängig machen kann, weil er das ursprüngliche Kennwort gar nicht kennt) und gerade in einem solchen Fall ist es erst einmal schlauer, wenn man dem Problem nachzugehen versucht und nicht einfach die Box (unter Verlust aller Einstellungen, es sei denn, man hat eine aktuelle Sicherung und dann wollen wir mal die Daumen drücken, daß zumindest deren Kennwort das richtige ist) auf die Werkseinstellungen zurücksetzt und dabei dann noch alle vielleicht vorhandenen Spuren eines solchen Einbruchs selbst vernichtet. So kann man dann nicht einmal mehr mit einiger Wahrscheinlichkeit feststellen (Sicherheit gibt es an dieser Stelle ohnehin nicht, man muß dann zumindest vom "worst case" des Totalverlusts der Vertraulichkeit der in der Box gespeicherten Daten ausgehen), was so ein Angreifer nun eigentlich alles "erbeutet" hat.
Deshalb sollte man auch bei konfigurierten Einstellungen für den AVM-Weg mit der E-Mail immer mißtrauisch werden, wenn man sich diesen "Verlust" des richtigen Kennworts eigentlich nicht erklären kann ... das könnte auch jemand anderes gewesen sein, der dort (vorübergehend, bis man selbst das wieder behebt) ein neues Kennwort eingestellt hat und durch einen Neustart der FRITZ!Box lassen sich schon viele Spuren von einem Angreifer verwischen. Wer da nur mit den Schultern zuckt und automatisch von einer Fehlfunktion ausgeht, erlebt vielleicht in naher Zukunft dann andere unangenehme Überraschungen, wenn das ein Angreifer war und der andere Zugangsdaten (vom E-Mail-Postfach bis zum Online-Speicher) dabei erbeuten konnte.
Das wäre zwar schon genug "Zeigefinger", aber trotzdem geht es jetzt erst einmal ab auf die "stille Treppe" (in der überwiegenden Mehrheit ist es eben doch ein Layer8-Problem und kein Angriff) und eine Runde Schämen ist angesagt (auch Fremdschämen ist erlaubt), damit die Lektion verinnerlicht wird und als erste Aktion nach dem nächsten erfolgreichen Zugriff dann die notwendigen Einstellungen vorgenommen werden, um diesem Problem beim nächsten Mal über den von AVM implementierten Weg für "Kennwort-Recovery" zu Leibe rücken zu können - auch wenn das vielleicht gar nicht jeder mehr für die beste Lösung hält nach meinen einleitenden Bemerkungen. Zumindest sollte man als erste Aktion mit dem Link aus so einer E-Mail dann eine Sicherung der aktuellen Einstellungen vornehmen und diese gut weglegen, bevor man dem verwendeten Konto ein neues Kennwort verpaßt (denn damit ist das ggf. vom Angreifer gesetzte weg und damit auch die "Spur" bei einer nachträglichen Analyse des Geschehens).
Wobei zumindest meine 113.06.83 an dieser Stelle auch noch eine (kleine bis mittlere) Lücke hat, denn die Änderung der E-Mail-Adresse für diesen Vorgang ist nicht über die 2FA abgesichert und es wird zu allem Überfluß diese E-Mail auch noch an die Adresse verschickt, die bei den anderen Nachrichten als Absender und auch dort nur als sekundäre Information neben dem primären Absendernamen verwendet wird, den auch die meisten MUAs (Mail User Agents - das sind die Programme zum Empfangen und Senden bzw. zum Anzeigen von Mails) für die Anzeige bevorzugen. Ich kenne auch Leute, die dort als Absenderadresse irgendetwas verwenden, was gar nicht existiert - außer dieser E-Mail für den Link mit der SID gibt es keinen nachvollziehbaren Grund, warum man da eine "echte" E-Mail-Adresse verwenden sollte und auch die FRITZ!Box akzeptiert da über das GUI beliebigen Inhalt (ob der wenigstens einem Schema für E-Mail-Adressen folgen muß, weiß ich nicht - kann jeder selbst probieren), solange man den Mail-Versand beim Speichern der Einstellungen nicht testen läßt.
Wer für sein Administrator-Konto auch einen VPN-Zugang eingerichtet und irgendein anderes Gerät für diesen Zugang konfiguriert hat (und zwar so, daß auch die Daten für XAuth dabei auf dem Gerät gespeichert wurden), der kann auch versuchen, aus diesen gespeicherten Daten sein Kennwort irgendwie zu rekonstruieren. Das kann aber auch ein beliebiger Angreifer, der auf diesem Gerät Zugriff auf die (Klartext-)Daten erhält ... deshalb würde ich schon unter Sicherheitsaspekten jedem empfehlen, für solche VPN-Zugänge niemals ein Konto mit administrativem Zugriff auf die FRITZ!Box zu verwenden und sich lieber - egal wieviel zusätzlicher Aufwand das auch sein mag - für jedes Gerät einen gesonderten Zugang anzulegen, der nur die Berechtigung hat, eine VPN-Verbindung aufzubauen.
Die AVM-Apps machen das in den neueren Versionen m.W. auch so, allerdings benutzen diese dafür eine vom Hersteller vorgesehene Schnittstelle. Dann kann jedenfalls auch ein Angreifer auf diese gespeicherten Zugangsdaten für das VPN (und mal ehrlich, wer will die schon bei jedem Aktivieren der VPN-Verbindung von Hand eingeben) nichts weiter erreichen, als den Zugang zum LAN hinter der FRITZ!Box (das ist ggf. schon schlimm genug, aber den haben die ganzen IoT-Geräte heutzutage auch und da fragen ja auch die wenigsten, was das an Probemen geben könnte) und der Zugang zu irgendwelchen Diensten im LAN ist dann hoffentlich noch einmal gesondert abgesichert - und zwar mit anderen Credentials, als sie für den VPN-Zugang erforderlich sind.
Aber das war nur eine "Bemerkung am Rande" (und eine Möglichkeit, an das Kennwort zu gelangen) ... auch wenn das natürlich zum Thema "Zugangsdaten" gehört. Ob nun derjenige besser dran ist, der gar keine VPN-Zugänge verwendet oder derjenige, der dafür gesonderte Konten eingerichtet hat, will ich nicht entscheiden ... gegenüber dem Dritten, der dafür sein Administrator-Konto an der FRITZ!Box mit gespeicherten Daten auf einem Android-Gerät verwendet, befinden sich beide in einer besseren Situation. Das interessiert vermutlich niemanden, der bis hier gelesen hat, weil er selbst gerade sein Kennwort vergessen hat, aber wenn man schon mal die "Aufmerksamkeit" der Leute erlangt hat, kann/soll man sie auch nutzen für das "Missionieren".
Trotzdem ist auch für FRITZ!Box-Besitzer ohne VPN-Zugänge zu Administrator-Konten noch nicht alles verloren (auch mit einem solchen VPN-Zugang müßte man dort schon erst noch das Kennwort extrahieren aus den irgendwo auf einem Client gespeicherten Daten) ... gegenüber einem Zugriff über ein LAN-Kabel zum Zeitpunkt des Bootens der FRITZ!Box ist diese nämlich reichlich schutzlos (auch das kann ich nur immer wieder als Mantra wiederholen) - jedes Neugeborene ist da bereits besser aufgestellt, weil es i.d.R. zumindest über eine Möglichkeit der akustischen Signalisierung von Mißständen verfügt.
Einer FRITZ!Box kann man jedenfalls zum Zeitpunkt des Starts über den Bootloader alles Mögliche einreden, sie ist in diesem Zustand noch sehr leichtgläubig und so kann man über den eingebauten FTP-Server dort (der wird auch vom AVM-Recovery-Programm benutzt) problemlos sein eigenes Betriebssystem in das Gerät laden und dort starten lassen ... mit diesem System kann man dann auch auf die Einstellungen in der Box zugreifen und diese abändern. Im Falle des hier thematisierten Verlusts der Zugangsdaten für ein Adminstrator-Konto, wäre natürlich dabei das Ändern des Anmeldemodus oder das Hinzufügen eines weiteren Administrator-Kontos eine solche denkbare Änderung und genau diesem Thema bzw. dem dabei notwendigen Vorgehen wollen wir uns im Folgenden widmen.
-Entgegen meiner sonstigen Ambitionen wird das für diesen konkreten Einsatzfall (siehe Thread-Titel) sogar eine detaillierte Anleitung werden ... trotzdem erkläre ich zunächst mal die Grundlagen (auch wenn die ganz ungeduldigen Leser jetzt vielleicht schon mit den Füßen scharren), weil ich damit auch die Hoffnung verbinde, daß sich aus dem Verständnis der Funktion weitere Anwendungsmöglichkeiten ableiten lassen, die der Leser nach der Lektüre dann auch selbst in Angriff nehmen kann ... und zwar ohne zusätzliche Hilfen und Erklärungen (zumindest weitgehend).
Bei der konkreten Anleitung (und den von mir derzeit bereitgestellten Shell-Skripten dafür) geht es zunächst einmal generell nur um die FRITZ!Box-Modelle, die mit einem MIPS-34Kc-fähigen Prozessor ausgestattet sind (das sollte die überwiegende Mehrzahl der aktuell von AVM unterstützten Modelle sein - wer es genau wissen will, sieht in der Hardware-Liste von @qwertz.asdfgh nach), weil benötigte Binärdateien von mir (jedenfalls derzeit) nur für diese Architektur bereitgestellt werden. Aus dem Aufbau der jeweiligen Boxen ergibt sich dann eine weitere Beschränkung hinsichtlich der - schlüsselfertig - unterstützten Modelle ... hier kommen nur solche in Frage für die aktuellen Versionen der Skript-Dateien, die ihrerseits für das Speichern des realen Wurzeldateisystems (als SquashFS-Image) auf eine "Wrapper"-Partition im Flash-Speicher zurückgreifen (die dort dann mit einem yaffs2-Dateisystem arbeitet).
Nur deren Kernel sind (soweit ich das kenne) in der Lage, beim Laden eines Linux-Systems in den (Haupt-)Speicher der Box auch mit einem passend präparierten ext2-Dateisystem zu hantieren und die vorhandenen Skripte beschränken sich zunächst einmal auf den Weg mit einem ext2-Image, weil das bereits mit den Tools zu realisieren ist, die praktisch jeder Linux-Installation beiliegen und für die Variante mit einem SquashFS-Dateisystem dann wieder die richtigen Programme benötigt werden, um das von AVM verwendete SquashFS-Format zu (ent-)packen.
Was machen wir also im Folgenden? Wir nehmen uns eine originale AVM-Firmware-Datei und extrahieren uns aus dieser den dort enthaltenen Linux-Kernel. Das dürfen wir ohne weiteres machen, denn dieser Kernel steht in Gänze unter der GPLv2(-Lizenz) und nach deren Bestimmungen dürfen wir diesen (im Rahmen unserer Möglich- und Fähigkeiten) beliebig vervielfältigen, verbreiten und sogar bearbeiten (copy, distribute, modify) - jeder Versuch von AVM, uns das zu untersagen, stellt dann einen Verstoß gegen diese Lizenzbestimmungen dar und damit verlöre AVM auch automatisch das Recht, diesen Kernel in den eigenen Firmware-Versionen zu benutzen und zu verbreiten.
Warum brauchen wir nun überhaupt einen eigenen Kernel ... haben denn nicht die meisten (aktuellen) AVM-Modelle denselben Prozessor und ist nicht auch so ein Linux-Kernel mit den ganzen ladbaren Modulen (LKM - loadable kernel module) durchaus dazu geeignet, sich an unterschiedliche Umgebungen dynamisch anpassen zu lassen? Im Prinzip ist das soweit richtig ... aber AVM hat bei dem Modellen mit einem Kernel 3.10, die von sich aus über keinen Bootloader verfügen, der gemäß den "OpenFirmware"-Spezifikationen eine Beschreibung der verwendeten Hardware bereitstellen kann, einen anderen Weg beschritten und legt im Kernel einen speziellen Bereich an (namens "avm_kernel_config"), der diese Hardware-Beschreibungen für ein bestimmtes Modell enthält und bereits ganz am Beginn des Kernel-Setups die Daten dort erwartet und sie auch prüft.
Damit funktioniert dann so ein Kernel nur noch auf einem Modell (oder auf anderen, die dann aber baugleich sein sollten/müssen - schon eine abweichende Belegung von GPIO-Pins reicht für einen umgehenden Crash, wenn das System den falschen Pin erwischt) und man erstellt sich entweder tatsächlich seinen eigenen Kernel für die eigene Box (wobei man auch dort den AVM-Kernel als Vorlage für diesen "avm_kernel_config"-Bereich benötigt) oder man nimmt einfach den von AVM für das passende Modell her und arbeitet mit diesem weiter.
Anders sieht es dann wieder beim Dateisystem aus. Auch wenn man hier für das gesamte SquashFS-Image (auch wenn das noch einmal in einer ext2-Verpackung daherkommen sollte) wohl ebenfalls die Anwendbarkeit der Bestimmungen aus der GPLv2 annehmen darf, sieht es bei einzelnen Programmen von AVM in diesem Image vielleicht schon wieder etwas anders aus ... wobei es wirklich witzig wäre, wenn sich AVM darauf berufen würde, daß das eben keine "distribution as a whole" ist, was man da selbst betreibt und gleichzeitig unternimmt man keinerlei Anstalten, die eigenen Änderungen am SquashFS-Format irgendwie zu dokumentieren oder gar Tools bereitzustellen, mit denen andere aus diesem "Ganzen" ("as a whole") des Dateisystem-Images irgendwie "Einzelteile" extrahieren könnten.
Daher würde ich mir nicht einmal dann Gedanken über die AVM-Bestimmungen aus deren Lizenz-Datei machen, wenn ich tatsächlich eigene Images bereitstellen würde, die ihrerseits das komplette SquashFS-Image aus einer AVM-Firmware enthalten (auch wenn das nur die aus dem ext2-Image extrahierte "filesystem_core.squashfs" wäre). Solange dieses Image nur zur Laufzeit irgendwo gemountet wird und als Quelle für den (gezielten) Aufruf von AVM-Programmen dient, ist auch die AVM-Klausel mit dem "oder Teile herauszulösen" in meinen Augen nicht verletzt (ansonsten bin ich auf das Schreiben des AVM-Justitiars gespannt) und hinsichtlich des Kernels und der anderen im Dateisystem enthaltenen GPL-Komponenten (und unter dem "als Ganzes"-Aspekt, wie ich ihn versucht habe zu begründen) schlägt ohnehin die GPL die AVM-Lizenz ("Falls und soweit Open Source Software überlassen wird, gelten zusätzlich und vorrangig vor den vorliegenden Bestimmungen die Nutzungsbedingungen, denen die Open Source Software unterliegt.").
Dieser "Ausflug" zu den Lizenz-Bestimmungen sollte nur noch mal (er)klären, warum ich nicht einmal bei der Bereitstellung von konkreten Dateien, die ein bootfähiges Image für eine bestimmte Aufgabe bei einem bestimmten FRITZ!Box-Modell enthalten, irgendein "Unrechtsbewußtsein" haben würde ... auch wenn mir persönlich wieder die "Verwaltung" so eines Fundus für eine größere Anzahl von Modellen viel zu anstrengend ist und ich so etwas daher eher immer "on-the-fly" machen würde (wie das gehen kann, kommt gleich). Wenn sich jemand aber berufen fühlt, seinerseits fertige Images auf der Basis von mir bereitgestellter Shell-Skripte (bzw. auf der Weiterentwicklung dieser Dateien beruhende Lösungen) zu erstellen und anderen zur unkomplizierten Verwendung zur Verfügung zu stellen, darf/kann/soll er das in meinen Augen gerne tun. Wenn er sich dabei wohler fühlen sollte, daß ich als "Anstifter" das ebenfalls (ggf. auch zuvor) mache, stelle ich auch gerne selbst irgendein Image als exemplarisches Beispiel (und als Angriffspunkt für Einsprüche von AVM) bereit ... vermutlich am ehesten eines, das für die 7490 passend wäre.
Für den hier zu besprechenden Zweck ist es aber gar nicht notwendig, daß man auf ein Wurzeldateisystem von AVM zurückgreift ... weder auf das ext2-Dateisystem für die "wrapper"-Partition noch auf das dort enthaltene SquashFS-Image mit dem eigentlichen "rootfs". Da alle für den Zugriff auf die Daten in den TFFS-Partitionen notwendigen Komponenten (dort "lagern" die Einstellungen einer FRITZ!Box) bereits im Kernel fest eingebaut sind, braucht man nur noch irgendein Dateisystem mit einem passenden Format, welches dieser Kernel als Wurzeldateisystem mounten kann und aus dem er dann seinerseits die weiteren Dateien (in erster Linie auszuführende Kommandos und die dafür notwendigen Binärdateien, die sich bei einer FRITZ!Box alle in einer einzigen Datei - der BusyBox - versammeln) laden kann.
Da wir für unsere Aufgabenstellung hier am Ende nur eine einzige (statisch gelinkte) BusyBox-Datei brauchen, die ich parallel auch noch im Repository bereitstelle (es ist - nebenbei bemerkt - dieselbe, die auch beim "modfs"-Paket dabei ist und dank der Signatur daneben bürge ich mit meinem "guten Namen" (auch wenn ich nicht Hipp heiße) auch für diese Datei und deren (relative) Ungefährlichkeit), brauchen wir tatsächlich gar kein AVM-Dateisystem und bauen uns einfach (für diese simple Anwendung ist das tatsächlich "einfacher") unser eigenes ext2-Image, in dem wir die notwendigen Dateien erstellen und das wir dann zusammen mit dem Kernel in unser bootfähiges Image aufnehmen. Dafür verwenden wir eine 10 MByte große Image-Datei, diese begrenzt dann gleichzeitig auch die max. Größe der Dateien, die wir dort hineinkopieren können. Aber wir sind ohnehin genügsam und brauchen nicht viel ... es handelt sich in der Summe nur um einige wenige Dateien, von denen die BusyBox mit ihren knapp 1,2 MByte (die ist halt statisch gelinkt, dafür braucht es nur diese eine Datei und keine weiteren Bibliotheken) noch die größte ist:
Code:
# [COLOR="#0000FF"][B]find -type f -ls[/B][/COLOR]
1301 1163 -r-xr-xr-x 1 root root 1184184 May 8 02:07 ./bin/busybox
1289 1 -rw-rw-rw- 1 root root 42 May 8 23:19 ./etc/inittab
1288 0 -rwx------ 1 root root 0 May 8 23:19 ./tmp/mtab
1361 15 -rwxrwxrwx 1 root root 14013 May 8 23:19 ./sbin/skip_auth_from_homenetwork
1362 1 -rwxrwxrwx 1 root root 149 May 8 23:19 ./sbin/rc.initDieser Modus ist zwar definitiv nichts für den "täglichen Betrieb" einer FRITZ!Box (insofern ist auch das "nicht empfohlen" nur ein schwacher Trost, ich würde diesen Modus komplett verstecken und nur auf richtig komplizierten Umwegen zugänglich machen - z.B. über ein bootfähiges Image :mrgreen
, aber für das Wiedererlangen des Zugriffs auf die Box ist er u.a. auch deshalb ganz gut geeignet, weil seine Aktivierung nur dann irgendwelche Spuren verwischt, wenn die Box ansonsten im Modus "Anmeldung mit dem FRITZ!Box-Kennwort" (auch keine wirklich gute Idee) betrieben wird - das Verhalten einer Box, in der beide reservierten Benutzerkonten gleichzeitig aktiv sind, ist in meinen Augen nicht sauber vorherzusagen und so wird ggf. ein vorhandenes Konto für diesen Modus "ausschließlich mit dem Kennwort" in eines umgewandelt, das für "keine Anmeldung" verwendet wird. Arbeitet die Box hingegen ursprünglich mit dem "Benutzername/Kennwort"-Modus bei der Anmeldung, werden bei dieser Änderung die vorhandenen Benutzerkonten gar nicht angefaßt und man kann tatsächlich anhand einer als erstes nach eines solchen Problem erstellten Sicherungsdatei irgendwann später in aller Ruhe noch rekonstruieren, welche Einstellungen für die vorhandenen Konten nun vorlagen und ob da ggf. ein Angreifer sein eigenes Kennwort gesetzt hatte und man deshalb keinen Zugriff mehr erhielt.
Was sind das überhaupt, diese "reservierten Benutzerkonten"? AVM verwendet für die beiden weniger sicheren Modi jeweils einen vordefinierten Benutzernamen mit einer festgelegten Benutzer-ID ... es gibt m.E. auch in der Firmware verschiedenen Stellen, wo dieser Modus mal auf der Basis von Benutzernamen und mal anhand der Benutzer-ID geprüft wird. Für den "keine Anmeldung"-Modus kommt dabei ein Benutzer mit dem Namen "@SkipAuthFromHomenetwork" und der UID 101 zum Einsatz und für den Modus "nur mit Kennwort" heißt der Benutzer dann "@CompatMode" und verwendet die UID 100. Bei "Benutzername/Kennwort" fehlen dann diese beiden Konten komplett.
Damit kann man einfach durch das Hinzufügen des Benutzerkontos für "@SkipAuthFromHomenetwork" die FRITZ!Box beim nächsten Start dazu bringen, daß sie den Zugriff auf das GUI ohne Anmeldung erlaubt und trotzdem die bisher definierten Konten immer noch erhalten bleiben ... mit allen ihren Einstellungen. Man kann also auch einfach für den Benutzer mit dem "vergessenen" Kennwort ein neues setzen und danach den Anmeldemodus wieder auf "Benutzername/Kennwort" ändern ... dann löscht die Box das Konto für UID 101 wieder und es sieht praktisch so aus, als wäre niemals etwas gewesen - nur daß man jetzt das (neue) Kennwort für den Benutzer wieder kennt und sich damit anmelden kann.
Diese ganzen Arbeiten mit dem Prüfen der aktuellen Einstellung und der richtigen Reaktion und Änderung, damit beim nächsten Start dann keine Anmeldung am GUI erforderlich ist, übernimmt das Skript "skip_auth_from_homenetwork" aus dem YourFritz-Repository, das wir auch mal kurz ansehen wollen:
Code:
1 #! /bin/sh
2 #######################################################################################################
3 # #
4 # switch a FRITZ!OS device with a lost password to @SkipAuthFromHomenetwork mode #
5 # #
6 #######################################################################################################
7 # #
8 # Copyright (C) 2016-2017 P.Hämmerlein ([email protected]) #
9 # #
10 # This program is free software; you can redistribute it and/or modify it under the terms of the GNU #
11 # General Public License as published by the Free Software Foundation; either version 2 of the #
12 # License, or (at your option) any later version. #
13 # #
14 # This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without #
15 # even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU #
16 # General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details. #
17 # #
18 #######################################################################################################
19 # #
20 # The script checks the current login mode (based on user IDs in the boxusers.users section of the #
21 # 'ar7.cfg' file) and adds a complete new entry for the pseudo user '@SkipAuthFromHomenetwork' (with #
22 # user ID 101), if the box uses the 'username and password' mode at this time. If the compatibility #
23 # mode is active, its pseudo user (@CompatMode with user ID 100) will be changed to the correct data #
24 # for the 'skip authentication from home-network' mode. If this mode is already active, nothing will #
25 # be changed. #
26 # #
27 # It will create its own character device to access the TFFS node 113 and will setup an user account #
28 # with ID 101 and the name "@SkipAuthFromHomenetwort" - either with a modification of an existing #
29 # "@CompatMode" account (it changes UID/name and removes an existing password) or it creates a #
30 # brand-new user account with the needed settings. #
31 # #
32 # The major device number of the TFFS driver will be read from "/proc/devices" and the script needs #
33 # a writable filesystem mounted on "/tmp" - this means, the caller is responsible to ensure, that #
34 # #
35 # - procfs is mounted on /proc #
36 # - a writable filesystem (usually tmpfs) is mounted on /tmp #
37 # - no ctlmgr instance is running, which may use its own copy of the edited file and overwrite the #
38 # changes to "ar7.cfg" #
39 # #
40 #######################################################################################################
41 # #
42 # constants #
43 # #
44 #######################################################################################################
45 tmpdir="/tmp"
46 proc="/proc"
47 ar7_minor=113
48 user_template="\t\tenabled = yes;\n"
49 user_template="${user_template}\t\tid = 101;\n"
50 user_template="${user_template}\t\tname = \"@SkipAuthFromHomenetwork\";\n"
51 user_template="${user_template}\t\temail = \"\";\n"
52 user_template="${user_template}\t\tpassword = \"\";\n"
53 user_template="${user_template}\t\tvpn_access = no;\n"
54 user_template="${user_template}\t\tbox_admin_rights = secobj_access_rights_readwrite_from_homenetwork_only;\n"
55 user_template="${user_template}\t\tnas_rights = secobj_access_rights_readwrite_from_homenetwork_only;\n"
56 user_template="${user_template}\t\tphone_rights = secobj_access_rights_readwrite_from_homenetwork_only;\n"
57 user_template="${user_template}\t\thomeauto_rights = secobj_access_rights_readwrite_from_homenetwork_only;\n"
58 user_template="${user_template}\t} {\n"
59 #######################################################################################################
60 # #
61 # subfunctions #
62 # #
63 #######################################################################################################
64 # #
65 # read and sort user IDs #
66 # #
67 #######################################################################################################
68 read_users()
69 {
70 i=0
71 while read id; do
72 i=$(( i + 1 ))
73 eval id_$i=$id
74 done
75 [ $i -eq 0 ] && return 1 # no users found, usually the source file is empty
76 j=$i
77 while [ $j -gt 1 ]; do
78 n=1
79 k=0
80 while [ $k -lt $(( j - 1 )) ]; do
81 k=$(( k + 1 ))
82 eval l=\$id_$k
83 eval r=\$id_$(( k + 1 ))
84 [ $l -lt $r ] || continue
85 eval id_$k=$r
86 eval id_$(( k + 1 ))=$l
87 n=$k
88 done
89 j=$n
90 done
91 j=0
92 while [ $j -lt $i ]; do
93 j=$(( j + 1 ))
94 eval printf "%u:" \$id_$j
95 done
96 }
97 #######################################################################################################
98 # #
99 # search a user ID in the list #
100 # #
101 #######################################################################################################
102 find_userid()
103 {
104 i="$2"
105 IFS=:
106 set -- $1
107 while [ $# -gt 0 ]; do
108 [ $1 -eq $i ] && return 0
109 shift
110 done
111 return 1
112 }
113 #######################################################################################################
114 # #
115 # check debug option #
116 # #
117 #######################################################################################################
118 if [ "$1" = "-d" -o "$1" = "--debug" ]; then
119 debug=1
120 shift
121 else
122 debug=0
123 fi
124 #######################################################################################################
125 # #
126 # determine the major device number for TFFS nodes #
127 # #
128 #######################################################################################################
129 if ! [ -e "$proc/devices" ]; then
130 [ $debug -eq 1 ] && printf "The file '%s/devices' does not exist, please mount procfs first.\n" "$proc" 1>&2
131 exit 1
132 fi
133 major=$(sed -n -e "s|^\([0-9]\{1,3\}\)[ \t]tffs\$|\1|p" "$proc/devices")
134 if [ ${#major} -eq 0 ]; then
135 [ $debug -eq 1 ] && printf "No TFFS device was found in '%s/devices'.\n" "$proc" 1>&2
136 exit 1
137 fi
138 #######################################################################################################
139 # #
140 # create a character device for our TFFS node #
141 # #
142 #######################################################################################################
143 if ! [ -d "$tmpdir" ]; then
144 [ $debug -eq 1 ] && printf "The directory '%s' does not exist.\n" "$tmpdir" 1>&2
145 exit 1
146 fi
147 node_name="$tmpdir/$$_add_user_cdev"
148 rm "$node_name" 2>/dev/null
149 touch "$node_name" 2>/dev/null
150 if ! [ -e "$node_name" ]; then
151 [ $debug -eq 1 ] && printf "The directory '%s' is not writable.\n" "$tmpdir" 1>&2
152 exit 1
153 fi
154 rm "$node_name" 2>/dev/null
155 mknod -m 666 "$node_name" c $major $ar7_minor
156 if ! [ -c "$node_name" ]; then
157 [ $debug -eq 1 ] && printf "Error creating character device for the TFFS stream.\n" 1>&2
158 exit 1
159 fi
160 #######################################################################################################
161 # #
162 # copy the existing content and collect the present user IDs #
163 # #
164 #######################################################################################################
165 copy="$tmpdir/$$_add_user_org"
166 cat "$node_name" >"$copy" 2>/dev/null
167 new_users="$tmpdir/$$_add_user_boxusers"
168 new_user="$tmpdir/$$_add_user_adduser"
169 sed -n -e "/^boxusers/,/^}/p" "$copy" >"$new_users"
170 userids="$(sed -n -e "/^[ \t]*id =/s|.* = \([0-9]*\);|\1|p" $new_users | read_users)"
171 #######################################################################################################
172 # #
173 # check login mode #
174 # #
175 #######################################################################################################
176 if find_userid "$userids" 101; then # @NoAuthFromHomenetwork - no reason to set a new user
177 [ $debug -eq 1 ] && printf "Login mode is already set to @SkipAuthFromHomenetwork, nothing was changed.\n" 1>&2
178 action=0
179 elif find_userid "$userids" 100; then # @CompatMode - change user ID and name and remove any password
180 sed -n -e "/^[ \t]*users {\$/,/[ \t]*}\$/p" "$new_users" | \
181 sed -e "/id = 100/,/name =/s|name = \"[^\"]*\";|name = \"@SkipAuthFromHomenetwork\";|" | \
182 sed -e "/id = 100/,/password =/s|password = \"[^\"]*\";|password = \"###REMOVETHISLINE###\";|" | \
183 sed -e "/###REMOVETHISLINE###/d" | \
184 sed -e "/id = 100/s|100|101|" >"$new_user"
185 sed -e "/[ \t]*}\$/,\$d" "$new_user" >"$new_users"
186 printf "\t}\n" >>"$new_users"
187 [ $debug -eq 1 ] && printf "Login mode was set to '@CompatMode', changed it to '@SkipAuthFromHomenetwork'.\n" 1>&2
188 action=1
189 else # add a complete new account for @SkipAuthFromHomenetwork
190 printf "$user_template" >"$new_user"
191 sed -n -e "/^boxusers/,/^}/p" "$copy" | sed -e "/^[ \t]*users {\$/r $new_user" | sed -e "1d" -e "/[ \t]*}\$/,\$d" >"$new_users"
192 [ $debug -eq 1 ] && printf "Added a new user entry for '@SkipAuthFromHomenetwork'.\n" 1>&2
193 printf "\t}\n" >>"$new_users"
194 action=1
195 fi
196 #######################################################################################################
197 # #
198 # edit the original file and replace the boxusers.users section with our new file #
199 # #
200 #######################################################################################################
201 [ $action -eq 1 ] && sed -e "/^[ \t]*users {\$/,/^[ \t]*}\$/d" "$copy" | sed -e "/^boxusers/r $new_users" >"$node_name"
202 #######################################################################################################
203 # #
204 # remove temporary files #
205 # #
206 #######################################################################################################
207 rm "$copy" "$new_users" "$new_user" "$node_name" 2>/dev/null
208 #######################################################################################################
209 # #
210 # end of script #
211 # #
212 #######################################################################################################
213 exit 0Um den kompletten Rest (Suchen der "major"-Nummer des TFFS, Anlegen des "character device" für den Zugriff auf die "ar7.cfg" (das ist ja nur ein Name, uns geht es aber um deren Inhalt und so taucht dieser Name auch gar nicht wirklich auf im Skript, höchstens mal in den Kommentaren), Ermitteln des aktuellen Anmelde-Modus und die daraus abgeleiteten Änderungen an den Benutzerkonten) kümmert sich das Skript selbst ... man muß es halt nur in der richtigen Umgebung irgendwie aufrufen. Das kann einmal die sehr begrenzte Umgebung so eines bootfähigen Images für den FTP-Server in der EVA sein oder auch ein laufendes FRITZ!OS - deshalb der dritte Punkt mit dem Bezug auf die zentrale Instanz der AVM-Firmware, den "ctlmgr". Sucht man die verwendeten Kommandos zusammen, kommt dabei diese (eher kurze) Liste heraus (alphabetisch):
- cat
- mknod
- printf
- rm
- sed
- touch
Der Aufruf dieses "skip_auth_from_homenetwork" (das ist schon die größte der vier hinzugefügten Textdateien - wir erinnern uns an die Liste der Dateien weiter oben) erfolgt dann aus der Datei "/sbin/rc.init" (der Name ist reine Phantasie, das kann auch irgendwo anders im Dateisystem liegen) und die sieht so aus:
Code:
1 #! /bin/sh
2 /bin/mount -t proc proc /proc
3 /bin/mount -t tmpfs tmpfs /tmp
4 export PATH=/sbin:/bin
5 /bin/sh /sbin/skip_auth_from_homenetwork
6 /sbin/rebootDiese "rc.init" wird dann ihrerseits wieder aus einer Datei aufgerufen, die von "/sbin/init" (das ist das Programm, welches der Kernel nach seiner Initialisierung und nach dem Mounten des Wurzeldateisystems aufruft - diese Rolle übernimmt auch unsere BusyBox) automatisch verarbeitet wird, wenn dieses vom Kernel aufgerufen wurde. Diese Datei mit dem (festen) Namen "/etc/inittab" enthält dann in unserem Falle auch nur eine einzige Zeile:
Code:
1 /dev/ttyS0::sysinit:/bin/sh /sbin/rc.initAber wie kommt man denn nun zu einem solchen ext2-Image und dem notwendigen Inhalt dort? Das automatisieren wir einfach auch und das ergibt dann (nur eine mögliche Umsetzung, die auch mehr Dateien und symbolische Links erzeugt, als für "skip_auth_from_homenetwork" eigentlich benötigt würden) das Skript "build_skip_auth_image" aus dem Repository. Dieses ist nun wieder dazu gedacht, daß man es auf einer eigenen Linux-Installation aufruft, in der man zuvor eine Kopie des YourFritz-Repositories angelegt hat.
Code:
[COLOR="#FF0000"]linux:~ $[/COLOR] [COLOR="#0000FF"][B]cd /tmp[/B][/COLOR]
[COLOR="#FF0000"]linux:/tmp $[/COLOR] [COLOR="#0000FF"][B]git clone https://github.com/PeterPawn/YourFritz.git[/B][/COLOR]
Cloning into 'YourFritz'...
remote: Counting objects: 1721, done.
remote: Compressing objects: 100% (43/43), done.
remote: Total 1721 (delta 23), reused 0 (delta 0), pack-reused 1676
Receiving objects: 100% (1721/1721), 2.27 MiB | 1.77 MiB/s, done.
Resolving deltas: 100% (1064/1064), done.
Checking connectivity... done.
[COLOR="#FF0000"]linux:/tmp $[/COLOR] [COLOR="#0000FF"][B]ls -l YourFritz/[/B][/COLOR]
total 96
drwxr-xr-x 2 peh users 4096 May 9 00:35 autoupdate
drwxr-xr-x 3 peh users 4096 May 9 00:35 avm_kernel_config
drwxr-xr-x 4 peh users 4096 May 9 00:35 bin
drwxr-xr-x 2 peh users 4096 May 9 00:35 bootmanager
drwxr-xr-x 4 peh users 4096 May 9 00:35 customconfig
drwxr-xr-x 2 peh users 4096 May 9 00:35 encryption
drwxr-xr-x 2 peh users 4096 May 9 00:35 eva_tools
drwxr-xr-x 2 peh users 4096 May 9 00:35 export
drwxr-xr-x 8 peh users 4096 May 9 00:35 .git
-rw-r--r-- 1 peh users 448 May 9 00:35 .gitattributes
drwxr-xr-x 2 peh users 4096 May 9 00:35 helpers
drwxr-xr-x 2 peh users 4096 May 9 00:35 luavar
-rw-r--r-- 1 peh users 969 May 9 00:35 mitmproxy-ca.pem
-rw-r--r-- 1 peh users 7373 May 9 00:35 PeterPawn.asc
-rw-r--r-- 1 peh users 3628 May 9 00:35 README.md
drwxr-xr-x 15 peh users 4096 May 9 00:35 reported_threats
drwxr-xr-x 3 peh users 4096 May 9 00:35 scriptlib
drwxr-xr-x 2 peh users 4096 May 9 00:35 signimage
drwxr-xr-x 2 peh users 4096 May 9 00:35 switch
drwxr-xr-x 2 peh users 4096 May 9 00:35 tffs
drwxr-xr-x 2 peh users 4096 May 9 00:35 toolbox
drwxr-xr-x 2 peh users 4096 May 9 00:35 tools
drwxr-xr-x 2 peh users 4096 May 9 00:35 update_yaffs2Als nächstes brauchen wir dann eine AVM-Firmware, aus der wir unseren Kernel extrahieren können. Deren URL sucht man sich am besten zuvor irgendwie heraus und dann läßt man sie (z.B. hier mit "wget") laden.
Code:
[COLOR="#FF0000"]linux:/tmp $[/COLOR] [COLOR="#0000FF"][B]cd YourFritz/toolbox/[/B][/COLOR]
[COLOR="#FF0000"]linux:/tmp/YourFritz/toolbox $[/COLOR] [COLOR="#0000FF"][B]wget http://ftp.avm.de/fritz.box/fritzbox.7412/firmware/deutsch/FRITZ.Box_7412.137.06.83.image[/B][/COLOR]
--2017-05-09 00:52:37-- http://ftp.avm.de/fritz.box/fritzbox.7412/firmware/deutsch/FRITZ.Box_7412.137.06.83.image
Resolving ftp.avm.de (ftp.avm.de)... 213.61.47.146, 212.42.244.7, 212.42.244.98, ...
Connecting to ftp.avm.de (ftp.avm.de)|213.61.47.146|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20899840 (20M) [application/octet-stream]
Saving to: ‘FRITZ.Box_7412.137.06.83.image’
FRITZ.Box_7412.137.06.83.image 100%[============================>] 19.93M 9.06MB/s in 2.2s
2017-05-09 00:52:39 (9.06 MB/s) - ‘FRITZ.Box_7412.137.06.83.image’ saved [20899840/20899840]
[COLOR="#FF0000"]linux:/tmp/YourFritz/toolbox $[/COLOR] [COLOR="#0000FF"][B]ls -l[/B][/COLOR]
total 26524
-rwxr-xr-x 1 peh users 13835 May 9 00:45 add_user_to_fritzos
-rwxr-xr-x 1 peh users 21396 May 9 00:45 build_add_user_image
-rwxr-xr-x 1 peh users 20871 May 9 00:45 build_skip_auth_image
-rw-r--r-- 1 peh users 20899840 Mar 9 19:01 FRITZ.Box_7412.137.06.83.image
-rwxr-xr-x 1 peh users 11078 May 9 00:45 get_file_from_image
-rwxr-xr-x 1 peh users 14013 May 9 00:45 skip_auth_from_homenetworkDie Ausgabe von "build_skip_auth_image" wird nach STDOUT geschrieben, wir leiten diesen Stream also in eine Datei um ... und die lassen wir gleich in das YourFritz-Verzeichnis "eva_tools" schreiben, weil wir sie dort dann mit anderen Skript-Dateien benutzen wollen, wenn es um das Booten der Box von diesem Image geht. Da beim Aufruf von "build_skip_auth_image" einige Kommandos ausgeführt werden, die Dateien in einer Weise erzeugen sollen, daß das FRITZ!OS (was nur mit dem Benutzer "root" arbeitet) korrekt darauf zugreifen kann, ist es jetzt notwendig, daß wir als "root" weiterarbeiten ... es gäbe zwar auch andere Möglichkeiten (z.B. "fakeroot", wie es die Freetz-Toolchain verwendet), diese sind aber deutlich komplizierter (auch in der Benutzung), als eine (eher kurzfristige) Umschaltung des Benutzers - der Weg dürfte auf allen Linux-Systemen ähnlich sein, bis hin zu den Canonical-Varianten (ich benutze hier ein openSUSE-System) ... einfach ein "sudo" vor den eigentlichen Aufruf setzen (und das Kennwort für einen berechtigten Benutzer kennen).
Code:
[COLOR="#FF0000"]linux:/tmp/YourFritz/toolbox $[/COLOR] [COLOR="#0000FF"][B]sudo ./build_skip_auth_image FRITZ.Box_7412.137.06.83.image >../eva_tools/7412_skip_auth.image[/B][/COLOR]
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
root's password:
[COLOR="#FF0000"]linux:/tmp/YourFritz/toolbox $[/COLOR] [COLOR="#0000FF"][B]ls -l ../eva_tools/7412*[/B][/COLOR]
-rw-r--r-- 1 peh users 12992000 May 9 01:07 ../eva_tools/7412_skip_auth.image- Prüfen der Verfügbarkeit der anderen benötigten Skript-Dateien
- Prüfen des angegebenen Firmware-Images von AVM
- Extrahieren des Kernels und ggf. das Auffüllen auf eine Größe, die ein Vielfaches von 256 ist (das hängt damit zusammen, wie der Kernel nach dem Dateisystem sucht)
- Prüfen des AVM-Dateisystems, daß da wirklich "ext2" verwendet wird, dabei fällt gleich noch eine Datei ab (der Dummy-Header, um das ext2-Image als SquashFS-Datei (zumindest in Teilen) auszugeben), die wir später noch brauchen
- Erstellen unseres eigenen 10 MByte großen Images, Formatieren als "ext2", Mounten
- Anlegen von Verzeichnissen, Dateien und Geräten im neuen Dateisystem
- Kopieren der MIPS-BusyBox in das Dateisystem und Anlegen der symbolischen Links für die benötigten BusyBox-Applets
- Kopieren von "skip_auth_from_homenetwork" ins neue Dateisystem
- Anlegen der anderen beiden Dateien (s.o.)
- Aushängen des Images
- Kopieren von Kernel, Dummy-Header und ext2-Image nach STDOUT
Warum spielt hier Windows überhaupt eine Rolle, wenn wir doch fürs Erstellen des Images ohnehin eine Linux-Installation brauchten? Da komme ich dann wieder auf die oben geschriebenen Zeilen zur GPLv2 zurück und zu dem Gedanken/der Möglichkeit, daß jemand anderes mit einem Linux-System so ein Image für uns vorbereitet haben könnte und wir damit gar kein Linux-System mehr benötigen, um so eine Aktion wie das Umschalten auf "keine Anmeldung erforderlich" auszuführen ... das geht dann also auch mit einem Windows-PC.
Mit anderer Technik aus einem aktuellen Haushalt (Smartphone, Tablet), die auch nicht zum Erstellen eines solchen Images genutzt werden kann, wird es sicherlich auch schwerer, den notwendigen Zugriff über ein LAN-Kabel zu erlangen ... aber auch das wäre machbar, wenn man die FRITZ!Box und einen (autonomen) WLAN-AP (Access Point, also eine WLAN-"Basisstation") miteinander per Kabel verbindet und sich mit seinem WLAN-Gerät am AP anmeldet. Zumindest mit einem (ggf. gerooteten) Android-Gerät sollte das auch funktionieren - das wäre dann aber wieder mehr die Richtung "Linux-System" und bei iOS-Geräten mit Jailbreak läuft es auf dasselbe hinaus (ohne Jailbreak aber dort auch keine eigenen Kommandos in der Shell).
Wenden wir uns also zuerst dem Thema "Linux-System für EVA-Zugriff" zu ... das ist gleichzeitig die erste (und voraussichtlich einzige) Beschreibung meinerseits (jedenfalls in diesem Umfang), wie man die Shell-Skripte aus "eva_tools" benutzen kann.
Beim Zugriff auf den Bootloader einer FRITZ!Box gibt es zwei - eigentlich getrennte - Aufgaben ... einerseits geht es erst einmal darum, eine startende FRITZ!Box im LAN zu finden, sie dann in diesem Modus "festzuhalten" (weil sie nur für 5-10 Sekunden auf eingehende FTP-Verbindungen beim Start wartet) und als zweites geht es dann um die Kommunikation mit dem FTP-Server. Egal ob man auf EVA mit einem Windows-PC oder einem Linux-System zugreifen will ... da eine startende FRITZ!Box ihre Ethernet-Schnittstellen erst einmal aktivieren muß und das System am anderen Ende des Kabels erst dann darüber informiert wird, daß da jetzt "jemand ist", kann jede automatische Netzwerk-Konfiguration, die auf dieses (angenommene) "Einstecken" eines LAN-Kabel reagiert und dann erst einmal per DHCP irgendwelche IP-Adressen für das Interface erfragen möchte, bereits dazu führen, daß die erwähnten 5 bis 10 Sekunden lange um sind, wenn die Netzwerkschnittstelle dann endlich bereit ist, um mit der Box kommunizieren zu können.
Schon aus diesem Grund sollte man - sofern man ein passendes Gerät besitzt, dafür reichen auch alte Gurken für Fast-Ethernet (100 MBit/s) oder sogar solche für 10 MBit/s - irgendeinen Ethernet-Switch (notfalls tut es auch ein Hub und bei der Variante mit dem WLAN-AP wäre auch dieser bereits ausreichend) zwischen FRITZ!Box und PC schalten und auf dem PC dafür sorgen, daß das verwendete Ethernet-Interface bereits eine IPv4-Adresse hat - das kann bei einem Windows-System auch gerne eine APIPA-Adresse aus dem Bereich 169.254.0.0/16 sein (oder das "zeroconf"-Pendant beim Linux).
Wichtig ist nur, daß diese Adresse bereits aktiv ist (also kein bis dahin unkonfiguriertes Interface erst beim "media sensing" auf die Suche nach einer DHCP-Adresse geht) - arbeitet man ohne zusätzliche Hardware zwischen FRITZ!Box und PC, muß man ggf. das "media sensing" im verwendeten PC-Betriebssystem auch abschalten - das Internet hilft bei der Suche, wie das beim eigenen System geht und auch Windows-Benutzer müssen heutzutage dafür nicht mehr in die Tiefen der Registry hinabsteigen; also Vorsicht vor allzu alten "Anleitungen", wie man das über die Registry machen kann - zumal das dann erst nach einem Neustart wirksam wird.
Für den ersten Schritt (das Suchen der FRITZ!Box, bei dieser Suche kann man dann einer FRITZ!Box mit einer bis dahin unbekannten Adresse, die diese im Bootloader benutzt, auch gleich noch eine definierte Adresse zuweisen, die zu Konfiguration des eigenen Ethernet-Interfaces paßt) gibt es Unterstützung von mehreren Seiten ... ich zähle mal ein paar auf, bevor ich mich den Skript-Dateien im YourFritz-Repository für diesen Zweck widme:
- ein "falsches" Recovery-Programm von AVM (gibt es nur für Windows) ... dieses setzt seinerseits eine zum Netzwerk-Interface des Windows-Systems passende IP-Adresse für die Box und hält sie zugleich im richtigen Modus fest, wenn es bei der Kommunikation mit der Box feststellt, daß diese das falsche Modell ist - das ist gerade für "Anfänger" eine nahezu narrensichere Variante, solange da keine "Security-Suite" (aka "Schlangenöl") auf dem Windows-System wieder für zusätzliche Probleme sorgt
- das "ruKernelTool" (näheres hier irgendwo im Forum - i.d.R. schon älter, weil es da mal Streit gab - oder beim Autoren; auch hier hilft die Suche im Internet), welches auch dafür genutzt werden kann, die FRITZ!Box zu suchen, ihre Adresse zu setzen (das macht das Tool etwas eigenwillig und setzt irgendwas mit 99.88.77.xx) und eine FTP-Sitzung zur Box zu starten (die kann man dann einfach beenden und die Box wartet weiter im richtigen Modus, wo man ihr dann mit dem PowerShell-Skript zuleibe rücken kann (*)
- irgendein Perl-Skript (der Name ist mir gerade nicht geläufig) aus der Freetz-Toolchain enthält auch noch den Code, um eine FRITZ!Box per UDP-Broadcast zu suchen ... ob da auch die Adresse gesetzt werden kann, weiß ich nicht mehr
- und "last but not least" habe ich im YourFritz-Repository sowohl für *nix-Systeme (unter Verwendung des Programmes "socat" i.V.m. einer "bash"-Shell) als auch für Windows-Systeme (hier mit PowerShell-Skript) eine Variante "im Angebot", mit der man das auch machen kann (natürlich beschreibe ich unten dann diese Variante - die anderen haben deren Autoren ja schon dokumentiert)
(*) Ich bin zugegebenermaßen kein allzu großer Fan des "ruKernelTools", weil das in meinen Augen eher "closed source" ist, auch wenn der Autor den Einblick in den Source-Code anbietet (zumindest für die Version ohne das "X" im Namen). Dort wird m.W. "AutoIt" verwendet, eine BASIC-artige Programmiersprache für die Automatisierung von Windows-Aktionen und die war sicherlich zum Zeitpunkt der Entstehung des Tools noch ein gangbarer und notwendiger Weg, aber heutzutage kommt eben jede noch von MS unterstützte Windows-Version auch in den Genuß einer weitaus mächtigeren Script-Engine - der PowerShell.
Da hat man dann wieder beide Vorteile vereint ... einerseits sind solche PowerShell-Skripte auch ohne Hilfsmittel "lesbar", was ein Review wahnsinnig erleichtert und das notwendige Vertrauen in den Autoren überhaupt erst entstehen lassen kann (in meinen Augen) und andererseits ist das auch eine Art und Weise der "Programmierung", wo sich irgendwelche Virenwächter nicht dran stören (oder zumindest extrem selten), während es bei AutoIt schon mal deutlich öfter zu Alarm kommt, auch wenn das vielleicht alles "false positives" sein sollten ... eine Heuristik oder Verhaltensanalyse kann eben bei solchen "Skriptsprachen", die in Form einer einzelnen ausführbaren Datei (exe) daherkommen, wesentlich leichter auf falsche Ideen kommen als bei "normalen" Programmen.
Es ist ja nicht ganz einfach (und logisch zu vermitteln), wenn man jemandem auf der einen Seite einen Virenwächter empfiehlt (und sei es nur der Windows-Defender als "eingebaute" Variante - mal unabhängig von jeder Diskussion darum, wie notwendig, wichtig und richtig solche Software nun ist) und auf der anderen Seite soll man dann sagen: "Wenn es aber das Programm ist oder jenes, dann sind das alles Fehlalarme." - das macht es für den "normalen Anwender" ja nicht leichter, eine Entscheidung "von Fall zu Fall" zu treffen und i.d.R. wird er auch dann am ehesten auf solche Probleme mit AutoIt-Programmen treffen, wenn er diese eigentlich ganz dringend bräuchte und gar keine Zeit/Lust hat, da erst großartigen Aufwand in eine gründlichere Untersuchung zu stecken.
Also wird gerade dann am ehesten auf "mach mal" gedrückt und das ist eine erhebliche Gefahr. Durch die regelmäßig "ablaufenden" Programmversionen (auch wenn ich die Idee dahinter nachvollziehen kann) wird das auch nicht erleichtert ... man kann eben nicht nur ein einziges Mal hingehen und eine bestimmte Version gründlich untersuchen und als "ungefährlich" einstufen, denn wenn man die dann wirklich mal verwenden will, ist ihre "Haltbarkeitsdauer" i.d.R. bereits abgelaufen. Dabei wäre gerade dieses Tool mit der Integration aller Schritte in einem einzigen Aufruf auch gut dazu geeignet, solche Images wie hier direkt in eine FRITZ!Box zu laden und dort zu starten ... ich finde den Ansatz also gar nicht so schlecht, aber kann eben "AutoIt" als Grundlage nicht wirklich "empfehlen".
Das gilt aber auch für Java oder etwas anderes, was "plattformübergreifend" zur Verfügung stünde (und einer lokalen Installation bedarf) - jede zusätzlich zu installierende Software vergrößert die Angriffsfläche auf ein System und zieht - schon mit regelmäßig notwendigen Updates u.ä. - weiteren Aufwand nach sich. Leider bei vielen Systemen mit dem Ergebnis (das sagt jedenfalls meine Erfahrung), daß dann immer eine gammelige alte Java-Installation noch irgendwo "herumliegt" (aka dahinvegetiert), weil die mal von irgendeiner getesteten Software benötigt und nicht zusammen mit dieser deinstalliert wurde - es gibt aber gar keine andere Software, die dieses Java benötigen würde oder auch nur von ihm wüßte - bis dann doch mal eine Malware auf der Suche nach Schwachstellen genau auf eine solche alte Version trifft und deren Lücken ausnutzt.
Wenn eine Lösung mir also "gefallen" soll, dann braucht sie nur ein Minimum an zusätzlicher Software (auch kein PHP, Perl, Python, keine LAMP-Installation, keine weiteren Datenbanken, usw. usf.) und erzeugt nicht für eine eher selten benötigte Funktion einen zusätzlichen "Wartungsaufwand", der in keinem Verhältnis zum "Ertrag" aus der Nutzung der Software steht.
Es ist also gar nicht notwendig, daß man die beiden Schritte (Suchen der Box und "Festhalten" im Bootloader einerseits und die Kommunikation mit dem FTP-Server andererseits) mit demselben Programm erledigt oder auch nur auf derselben Plattform. Wer z.B. kein Linux-System mit einer "socat"-Variante hat (die wird für die UDP-Broadcasts benötigt und ich kenne keine Alternative, die ohne C-Compiler auskommt - womit ich dann wieder beim Thema "zusätzliche Software" bin), kann auch die Box mit einem Windows-System und dem AVM-Recovery-Programm (wie geschrieben, für ein falsches Modell - die Idee dahinter hatte ich hier schon früher beschrieben) bis zu diesem Punkt treiben und dann mit einem anderen System (z.B. einem RasPi mittels einer SSH-Session) mit dem FTP-Server weiter arbeiten.
Will man dann unter Linux (oder OS X, wobei ich das noch nicht getestet habe) mit meinem "eva_discover" arbeiten, braucht man zunächst mal Informationen zu seinen eigenen Netzwerk-Einstellungen. Das Skript an sich ist weit, weit von einer Fertigstellung entfernt ist, das war auch mal in der Vergangenheit nur eine "Prinzipskizze" (vorab für jemanden als Beispiel eingecheckt) mit jeder Menge offener Baustellen bei den Parametern, bis mir dann die Notwendigkeit der wiederholten Betonung dieser Tatsache auf den Geist ging und ich jeden Code zur Erkennung von Einstellungen deaktiviert habe. Damit braucht man jetzt folgende Informationen, wenn man das Skript erfolgreich aufrufen will:
- den Namen irgendeines Netzwerk-Interfaces (als Angabe "INTERFACE=<name>" beim Aufruf) in der verwendeten Maschine ... das muß gar nicht das richtige Interface sein, an dem auch die FRITZ!Box hängt; es ist ein Relikt aus der Zeit, wo einige Parameter noch (bzw. "schon") teilweise "erraten" wurden auf der Basis von anderen und davon ist immerhin noch die Prüfung übrig geblieben, ob der Parameter angegeben wurde (was jetzt "Pflicht ist") und daß es sich um ein vorhandenes Netzwerk-Interface handelt
- die eigene IP-Adresse des Interfaces, über das man auf die FRITZ!Box zugreifen will (als "FROM=<ip>")
- eine zur eigenen Adresse passende Angabe für die FRITZ!Box (als "TO=<ip>"), diese wird dann in der FRITZ!Box "eingestellt"
Optional verkraftet das Skript zum Suchen der FRITZ!Box (das heißt - nebenbei bemerkt - dann "eva_discover") auch noch weitere Angaben:
- eine Angabe, wie lange nach der FRITZ!Box gesucht werden soll (als "WAIT=<n>", wobei "n" die Anzahl der Sekunden ist und hier sind zwei Minuten der Standard) - dabei wird jede Sekunde ein UDP-Broadcast-Paket gesendet, damit eine gerade startende FRITZ!Box so früh wie möglich erkannt wird
- die Angabe, ob schon "eva_discover" eine TCP-Verbindung zum FTP-Port der Box aufbauen soll oder nicht (als "HOLD=<0|1>", wobei "1" für die TCP-Verbindung steht, die sofort wieder beendet wird und nur dazu dient, daß die Box nicht weitermacht im Bootvorgang) - das würde ich in dieser Form nur selten empfehlen ("HOLD=0" ist auch der Standard), weil "eva_discover" selbst kein FTP-Login enthält und die verschiedenen Bootloader (teils auf demselben Modell nach meiner Meinung) durchaus unterschiedlich auf den plötzlichen Abbruch der TCP-Verbindung, wie ihn "eva_discover" praktiziert, reagieren; besser ist es, die Skripte "aneinanderzureihen", so daß der nachfolgende FTP-Zugriff (dort dann inkl. der Anmeldung) innerhalb der Wartezeit erfolgt
- über die Angabe von "BLIP=1" kann man eine Anzeige für jedes als Broadcast gesendete UDP-Paket erhalten ... das ermöglicht die Verfolgung der Aktivitäten von "eva_discover", was ansonsten etwas dröge daherkommt und sich bis zum Auffinden der FRITZ!Box oder bis zum Ablauf der Wartezeit nicht weiter bemerkbar machen würde
Wie man jetzt Interface-Namen und IP-Adressen findet, beschreibe ich hier nicht ... das ist u.a. auch von der Distribution abhängig und definitiv "nicht mein Tisch". Bei mir nehme ich einfach das Interface "vlan1" und die eigene IP-Adresse 192.168.178.2 (mit einer 24er-Maske, die hier aber nicht angegeben wird) - das ergibt dann für die 7412 die Möglichkeit, mit der Adresse 192.168.178.1 (auch hier wieder eine implizierte /24, die aber auch nicht angegeben wird) zu arbeiten. Man kann hier aber wirklich mit jeder beliebigen eigenen Adresse arbeiten und muß sich nur eine dazu passende Adresse der FRITZ!Box "ausdenken", damit die Pakete auch auf dem richtigen Netzwerk-Interface (vorausgesetzt, die Linux-Maschine hat mehr als eines) gesendet werden. Dann sind die anderen Einstellungen auch egal, weil das alles innerhalb derselben L2-Domain arbeiten muß und da spielen dann auch Netzwerk-Masken nur noch eine sehr untergeordnete Rolle. Wir passen hier also die FRITZ!Box an unsere Vorstellungen an und nicht umgekehrt unsere Vorstellungen an die FRITZ!Box.
Wenn das "eva_discover"-Skript die FRITZ!Box nicht finden kann innerhalb der vorgegebenen Zeit, wird "EVA_FOUND=0" auf STDOUT ausgegeben, ansonsten "EVA_FOUND=1" und als "EVA_IP=<ip>" auch die Angabe, welche Adresse die FRITZ!Box jetzt hat. Man kann nämlich mit "TO=0.0.0.0" ihr auch gestatten, die bisher eingestellte Adresse weiterhin zu verwenden - ggf. muß man mit Problemen rechnen, wenn diese bei der eigenen Linux-Maschine auf einem anderen Interface läge, wie es häufig bei "99.88.77.xx" der Fall sein dürfte, da wird wohl in der überwiegenden Zahl der Fälle die "default"-Route zuständig sein. Diese Art der Ausgabe auf STDOUT (alle anderen Ausgaben gehen nach STDERR und sind damit leicht von diesen Angaben zu trennen) macht es auch möglich, den Aufruf einfach in eine Form
Code:
eval $(./eva_discover ...)
if [ "$EVA_FOUND" = "1" ]; then
printf "FRITZ!Box gefunden unter der IP-Adresse %s" "$EVA_IP" 1>&2
./eva_to_memory 7412_skip_auth.image $EVA_IP
else
printf "FRITZ!Box nicht gefunden" 1>&2
fiWir haben also unsere Box "vorbereitet" mit der Verkabelung und sind jetzt zurück in der oben unterbrochenen Linux-Shell-Session:
Code:
[COLOR="#FF0000"]linux:/tmp/YourFritz/toolbox $[/COLOR] [COLOR="#0000FF"][B]cd ../eva_tools/[/B][/COLOR]
[COLOR="#FF0000"]linux:/tmp/YourFritz/eva_tools $[/COLOR] [COLOR="#0000FF"][B]eval $(./eva_discover INTERFACE=vlan1 TO=192.168.178.1 FROM=192.168.178.2 BLIP=1);[ "$EVA_FOUND" = "1" ] && ./eva_to_memory 7412_skip_auth.image $EVA_IP[/B][/COLOR]
Found AVM bootloader: AVM EVA Version 1.2605 0x0 0x47409
Found hardware revision: 209
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0xc63e00 (12 MB)
Setting temporary memory size to: 0x0739c200
Setting temporary kernel args to: mtdram1=0x8739c200,0x88000000
Image uploaded to device.Bisher hat noch jede FRITZ!Box, die ich dabei bewußt beobachtet habe, beim Initialisieren der GPIO-Ports für die Ansteuerung der LEDs alle gleichzeitig kurz aufblinken lassen und danach beginnt die Karenzzeit (wie gesagt, irgendwas zwischen 5 und 10 Sekunden nach meiner Erfahrung), in der man mit der Box Verbindung aufgenommen haben muß. Wenn sich also innerhalb von - sagen wir mal - 15 Sekunden nach dem Herstellen der Stromversorgung noch nichts getan hat (die GRX500-Boxen brauchen wohl länger, was ich auf die angenommene Virtualisierung zurückführen würde), dann ist irgendetwas anderes faul im Staate Dänemark ("Something is rotten in the state of Denmark.") und wenn das auch bei einem zweiten oder dritten Versuch nicht funktionieren will, ist da der Wurm drin und es wird auch beim 20. Versuch (ohne Änderungen) eher nicht funktionieren. Dann gibt es i.d.R. irgendwo einen Fehler, z.B. hängt die Box (oder der dazwischengeschaltete Switch) am falschen Ethernet-Port des Rechners oder es wird doch irgendeine langwierige Autokonfiguration verwendet und die frißt dann schon die verfügbare Karenzzeit. Das ist allerdings bei Windows-PC deutlich häufiger der Fall, weil diese Autokonfiguration unter Linux eher (und gründlicher) abgeschaltet werden kann.
Hier habe ich jedenfalls im oben stehenden Beispiel auch gleich noch den Aufruf für den Zugriff auf den FTP-Server angehangen ... auch dieser ist auf vielen anderen Wegen realisierbar - es muß nur eine passive Datenübertragung möglich sein und damit fällt der Kommandozeilen-FTP-Client von Windows bereits aus. Allerdings sind eben ein paar Berechnungen auf der Basis der Hauptspeichergröße der FRITZ!Box und der Größe des Images notwendig und diese Berechnungen übernimmt i.d.R. kein anderer "FTP-Client" ... genau für diesen Upload eines bootfähigen Images ist das Skript "eva_to_memory" ja mal entstanden. Das erwartet als ersten Parameter den Namen der zu übertragenden Image-Datei (deshalb haben wir das weiter oben ja direkt in diesem Verzeichnis gespeichert, das erspart uns jetzt die Angabe von Pfaden) und als optionalen zweiten Parameter die IP-Adresse der FRITZ!Box, wobei da "192.168.178.1" verwendet würde, wenn die Angabe fehlt.
Anders als "eva_discover" braucht nun "eva_to_memory" anstelle von "socat" auch nur noch eine Version von "netcat" (unter dem Namen "nc"), wobei hier die "Geschmacksrichtung" aus dem "netcat-openbsd"-Paket die erste Wahl ist. Das "netcat-traditional" (das ist m.W. die GNU-Version) kennt einige der verwendeten Parameter nicht und ich habe bisher keine Lust gehabt, das Skript so abzuändern, daß es auf diese Parameter verzichten könnte. Jedenfalls ist nun "netcat" auch auf durchschnittlichen Linux-Installationen deutlich öfter bereits vorhanden, als das beim "socat" der Fall ist, auch wenn wohl die meisten Distributionen die Installation von "socat" aus einem (Binär-)Repository unterstützen werden.
Jedenfalls wurde dann im o.a. Beispiel das zuvor erzeugte bootfähige Image in die FRITZ!Box 7412 geladen und dort gestartet ... das brauchte ja nun nicht sehr lange für die Abarbeitung von "skip_auth_from_homenetwork" und startete dann die 7412 gleich noch einmal. Nach diesem Start konnte man/ich dann problemlos auf das GUI der 7412 zugreifen - auch ohne jede Anmeldung, wobei mich in der Übersichtsseite die Information/Warnung "Kennwortschutz nicht aktiv, Kennwort setzen" darauf hinwies, daß da etwas zu tun wäre.
Für die Verwender einer Linux-Maschine war es das dann auch schon (nur noch das "Aufräumen" bzw. Löschen der Dateien aus dem geklonten Repository stünde ggf. an) ... mit sieben Kommandos (die "ls -l" zur Verdeutlichung dessen, was da an Dateien existiert, habe ich mal nicht mitgezählt) haben wir auf einer (angenommen unbekannten und unzugänglichen) FRITZ!Box 7412 einen Zugriff auf das GUI erhalten. Es klingt (angesichts der Länge dieses Beitrags bis hier, aber Strafe muß eben auch sein, wenn man seine Kennwörter vergißt oder Fremde an der eigenen FRITZ!Box spielen läßt) vielleicht etwas komisch, aber wenn man erst einmal weiß, wie es geht und wo man die notwendigen Dateien findet, dann braucht das keine fünf Minuten ... da ist natürlich die Zeit zum Lesen und Verstehen keinesfalls eingepreist. Das geht aber (zumindest für Linux-Benutzer, die nichts groß installieren müssen und direkt mit dem "git clone" loslegen können) deutlich schneller, als sich erst irgendwelche anderen Pakete/Programme (von Freetz - wo teilweise schon das "svn checkout" so lange braucht - bis zum "ruKernelTool", was man i.d.R. auch erst neu laden muß, weil es mal wieder abgelaufen ist) zu installieren und es ist auch deutlich schneller wieder von der eigenen Platte geputzt, wenn man es nicht länger benötigt.
Als Alternative gibt es in "toolbox" auch noch eine Variante (add_user_to_fritzos), mit der man anstelle der Umschaltung des Anmeldemodus einen neuen Benutzer-Account mit einem anzugebenden Namen und Kennwort (wobei beides auf "superuser" gesetzt wird, wenn man die Angabe ausläßt) hinzufügen kann, den man dann nach dem nächsten Start zur Anmeldung verwendet (der hat auch die Rechte "aus dem Internet" - und das ist durchaus Absicht). Auch dafür gibt es mit "build_add_user_image" ein Shell-Skript, was genauso arbeitet wie "build_skip_auth_image" und halt nur das andere Shell-Skript auf der Box startet. Das ist als zweites Beispiel zwar etwas schwach (weil die Unterschiede sehr gering sind), aber mit diesem Skript kann man auch noch anderen Unsinn treiben ... darauf komme ich später noch einmal zurück.
Trotzdem sollte man bis hier dann das Prinzip verstanden haben und wer möchte, kann sich nun eigene Skripte bauen, die er auf der Box ausführen läßt. Das geht z.B. mit einem "Auslesen" des TFFS-Inhalts los (für Forensiker immer ein Thema, wie man ein Gerät untersuchen kann, ohne es zu verändern oder aufzuschrauben und auseinanderzunehmen), wobei man dabei dann noch einen Weg finden muß, die ausgelesenen Daten aus der Box zu schaffen (wenn man sie nicht im NAND für das NAS ablegen kann/will, wobei auch für den Zugriff auf diesen Speicher noch ein paar mehr Dateien benötigt würden, als sie meine beiden Beispiele im Image anlegen) - dafür bietet sich dann z.B. TFTP an, wie es auch AVM verwendet, wenn die Ergebnisse einer Installation von Firmware protokolliert werden sollen (dafür braucht es dann noch ein paar Environment-Variablen im Bootloader, damit diese Installationsdateien die Netzwerk-Funktionen aktivieren).
Solange man nicht auf das WAN-Interface (und irgendein Modem) will, ist so eine simple Netzwerk-Konfiguration aller vorhandenen Ethernet-Ports als Bridge (auch bei der 7412 muß man nicht unbedingt vor eth1-eth3 zurückschrecken, dann gibt das eben einen (zu ignorierenden) Fehler, wenn die fehlen) schnell erledigt, wenn die passenden Kommandos in der BusyBox und ein paar benötigte Geräte-Dateien in "/dev" vorhanden sind. Dann kann man auch mit so simplen Protokollen wie TFTP (oder auch mit einem "nc") mit der Außenwelt aus so einem bootfähigen Image heraus kommunizieren ... wobei ich das jetzt nicht soweit treiben würde, daß ich da auch noch einen USB-Speicher einbeziehe. Das ist dann mit dem AVM-Dateisystem (und dort gemounteten oder überlagerten Dateien, wie es z.B. "modfs-Starter" gemacht hat) wieder einfacher zu realisieren ... die Möglichkeiten für Tests und Fehlersuchen sind ohne bestückte serielle Schnittstelle in der FRITZ!Box auch eher beschränkt und es macht nicht wirklich Spaß, da Fehler in den eigenen Dateien zu suchen.
Was aber noch relativ einfach umzusetzen ist ... die Installation von ShellInABox auf demselben Weg, wie ich es im "modfs-Starter"-Thread mal beschrieben habe, erfordert nur noch eine passende Gerätedatei für das MTD-Device mit der yaffs2-Partition und das passende "mount"-Kommando; dann kann man auch in diese Partition schreiben, die später im laufenden System nach dem "pivot_root" als "wrapper" verbleibt und wo es noch einiges an Platz gibt, den man benutzen kann. Wie das aussehen kann/würde, kann man in "update_yaffs2" nachlesen - auch wenn man hier bei der Installation natürlich etwas anders vorgehen müßte, wären die "inline"-Skripte dort in etwa das, was man in die Wrapper-Partition schreiben lassen müßte. Auch das sollte sich mit wenig Aufwand in ein Skript packen lassen und auch ein "build_..._image"-Skript dafür sollte nur ein paar kleine Zusätze benötigen im Vergleich zu den beiden anderen.
Vielleicht werde ich im Laufe der Zeit noch ein paar weitere praktische Skripte in das "toolbox"-Verzeichnis einfließen lassen ... das sind nur zwei (zuvor nicht richtig parametrierbare und nicht dokumentierte) Beispiele von Dateien, die ich ansonsten bisher eher auf einem RasPi hatte, den man per SSH-Session steuern und mit dem LAN-Interface an eine FRITZ!Box stecken kann. Meine Ambitionen, das auch mit einem "GUI" zu versehen und dann direkt über einen Touchscreen zu steuern, sind bisher immer an mangelnder Zeit gescheitert ... aber es wäre schon "cool", wenn man nur noch eine FRITZ!Box anstecken müßte und dann automatisch das Modell ermittelt, die richtige Firmware geladen (wenn sie nicht schon vorhanden ist) und damit ein bootfähiges Image mit "skip_auth_from_homenetwork" erzeugt und gestartet wird. Das illustriert dann als "schlüsselfertige Lösung" vielleicht auch meine Kritik hinsichtlich der Angreifbarkeit der FRITZ!Boxen über das LAN-Kabel besser, als es Worte je könnten ... bei einer ausreichend großen "Bibliothek" mit AVM-Images und Zugriff auf das Stromversorgungs- und LAN-Kabel einer FRITZ!Box dauert das im "Automatik-Modus" vielleicht noch 2-3 Minuten, so eine FRITZ!Box "zu übernehmen" und ob das deren Besitzer dann tatsächlich bemerkt, hängt auch eher davon ab, wie ungeschickt sich so ein Angreifer dann anstellen mag. Aber darauf komme ich nachher noch einmal zurück ... jetzt wäre es (vom Aufbau her) eher an der Zeit, sich dem EVA-Zugriff von einem Windows-System unter Benutzung der PowerShell-Skripte aus dem "eva_tools"-Verzeichnis zu widmen.
-Auch hier beim Windows will ich mich nicht mit Fragen aufhalten, die mit dem Zugriff auf den Bootloader nur am Rande zu tun haben ... z.B. dem Thema, wie man das erzeugte bootfähige Image nun von der Linux-Maschine, auf der es erstellt wurde, auf irgendein Windows-System mit einer PowerShell bekommt. Was vermutlich nicht funktionieren wird (ich habe es aber auch nicht wirklich probiert), ist die Verwendung der Skripte in der von Canonical mit Microsoft entwickelten "bash"-Shell unter Windows (x64 unter "developer tools"). Das liegt m.E. daran (auch wenn ich es nicht getestet habe), daß dort gar keine echten Treiber für Dateisysteme existieren dürften und das Mounten unseres eigenen Images damit schon fehlschlagen sollte. Wenn es doch funktioniert, bin ich zumindest mal überrascht ... aber zu dem, was unter dieser Shell aus dem YourFritz-Repository benutzbar ist und was nicht, habe ich irgendwo an anderer Stelle schon etwas geschrieben - auch wenn ich selbst nicht mehr weiß, wo das genau war und das will ich jetzt auch nicht suchen und hier verlinken. Zunächst mal reicht es mir, wenn ich meinerseits einfach feststelle, daß diese Skripte nicht für die "bash" unter Windows x64 gedacht sind und jede erfolgreiche Anwendung rein zufällig und von mir nicht beabsichtigt wäre.
Wer die PowerShell-Skripte verwenden möchte, sollte als erstes mal seine PowerShell-Installation (gerade auch dann, wenn er - wie ich - immer noch gerne auf einem Windows 7 arbeitet) auf den aktuellen Stand bringen ... die Minimal-Anforderungen für die PowerShell-Version stehen in "EVA-FTP-Client.ps1" (ab Zeile 360 im Moment) und können jederzeit auf dem eigenen System durch die Eingabe von "$PSVersionTable" in einer PowerShell-Session abgefragt werden.
Da es ein paar Sicherheitbeschränkungen bei der Benutzung der PowerShell gibt und man als "Hobby-Anwender" sicherlich eher nicht auf die Idee kommen wird, die Skripte irgendwie zu signieren, muß man - nach dem Download der Skripte als Textdatei mit Speichern an irgendeiner Stelle, wo man sie auch wiederfindet - zunächst mal diese Sicherheitseinstellungen korrekt vornehmen (das gilt für jedes PowerShell-Skript und ist nicht spezifisch für die EVA-Skripte) ... auch das ist wieder ein Thema, was mehrfach im Internet beschrieben ist (Stichwort "Set-ExecutionPolicy") und was ich hier nicht noch einmal auswalzen will.
Für die erste Aufgabe beim Kontakt zum Bootloader einer FRITZ!Box (das war das Suchen und Finden der Box) gibt es das Skript "EVA-Discover.ps1", welches - neben den ansonsten noch möglichen Parametern für praktisch jedes Skript - als Parameter "-maxWait" die Anzahl der Sekunden erwartet, die es auf die FRITZ!Box warten soll, wobei hier der Standardwert nur 30 Sekunden sind. Mit "-requested_address" kann man die IP-Adresse für die FRITZ!Box "ansagen" (der Standardwert ist die AVM-übliche 192.168.178.1) und mit "-nohold 1" könnte man auch hier den TCP-Verbindungsversuch zur FRITZ!Box unterbinden ... anders als bei der Linux-Variante nutzt aber das PowerShell-Skript inzwischen eine korrekte FTP-Anmeldung bei dieser Verbindung und das funktioniert dann - nach meiner bisherigen Erfahrung - auch wesentlich besser, weshalb hier auch die Bedeutung des Parameters (und dessen Standardwert) so geändert ist, daß man den Wunsch nach "nicht anhalten" gesondert äußern muß. Mit den Parametern "-Debug" und "-Verbose" kann man ein paar zusätzliche Nachrichten generieren, damit man auch hier die "Warterei" des Skripts sehen kann.
Code:
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose[/B][/COLOR]
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
TrueDazu brauchen wir dann das andere Skript (oben schon mal verlinkt), welches sich auf zwei verschiedenen Wegen benutzen läßt, wie im Skript (derzeit um Zeile 610 herum, das kann sich auch mal etwas verschieben) beschrieben ist. Man kann entweder vor der Benutzung hingehen und die auszuführenden Aktionen (die Liste der bereits implementierten Funktionen steht in der erwähnten Beschreibung) der Reihe nach in die geschweiften Klammer um diesen Kommentarblock herum einfügen, dann braucht man beim Aufruf nur den Parameter "-Address" angeben mit der IP-Adresse der FRITZ!Box und auch das ist nur erforderlich, wenn es nicht die als Standard vorgegebene 192.168.178.1 wäre. Auch hier kann man wieder mit "-Debug" und "-Verbose" etwas mehr an Informationen aus dem Skript herauskitzeln, während es mit der Box kommuniziert.
Da dieses Editieren der Datei etwas unpraktisch sein kann (es sei denn, man hat eine Kopie für einen ganz gezielten Anwendungsfall, die man desöfteren verwenden will), bevorzugt das Skript die Angabe eines "ScriptBlock"-Parameters beim Aufruf. Das ist im Prinzip nichts anderes als die Angabe der aufzurufenden Funktion(en) in geschweiften Klammern ... das aber nicht mit irgendwelchen Anführungszeichen oder ähnlichem, weil das keine Zeichenketten sein sollen. Will man mehrere Aktionen ausführen lassen (z.B. ein TFFS-Image in beide TFFS-Partitionen schreiben lassen, wobei die 7412 auch dort nur eine Partition (mtdnand) hat), trennt man diese mit einem Semikolon innerhalb des Blocks (also innerhalb der geschweiften Klammern). Zusammengesetzt sieht das dann so aus (alle Dateien auf dem Desktop gespeichert, mit "Save as" für die "raw"-Versionen aus GitHub und bitte auch das "unblock" in den Eigenschaften nicht vergessen), wenn man wieder dieselbe Image-Datei in die 7412 laden läßt:
Code:
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\Desktop\7412_skip_auth.image }[/B][/COLOR]
DEBUG: Response:
220 ADAM2 FTP Server ready
================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2
================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in
================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.2605 0x0 0x47409
================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize 0x08000000
200 GETENV command successful
================
DEBUG: Memory size found : 08000000
DEBUG: Image size found : 0x00c63e00
DEBUG: Set memory size to : 0x0739c200
DEBUG: Set MTD ram device to: 0x8739c200,0x88000000
DEBUG: Sent
SETENV memsize 0x0739c200
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8739c200,0x88000000
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY
================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM
================
DEBUG: Uploading file '.\Desktop\7412_skip_auth.image' to '0x8739c200 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,2)
================
DEBUG: Sent
STOR 0x8739c200 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection
================
DEBUG: Response:
226 Transfer complete
================
True-Kommen wir noch einmal kurz auf das "add_user_to_fritzos" zurück. Eines fällt ja an den von AVM für die reservierten Benutzerkonten verwendeten Namen auf ... beide beginnen mit dem eigentlich unnötigen Zeichen "@". Was mag da wohl der Hintergrund sein? Das ist ganz einfach ... AVM zeigt einfach alle Benutzer, deren Name mit diesem Zeichen beginnt, im GUI nicht an und zwar weder in der Select-Box für die Anmeldung aus dem LAN, noch in der Benutzerliste unter "System" oder gar in der Seite für die Analyse der Sicherheitseinstellungen. Das verhindert aber nicht, daß man ein solches Konto für die Anmeldung verwendet ... z.B. für einen TR-064-Zugriff. Zwar wird dieser Zugriff dann tatsächlich auch im Ereignisprotokoll als "Anmeldung einer App des Benutzers @irgendwas von IP-Adresse x.y.z" aufgeführt, aber es ist eben auch möglich, das Event-Log zu manipulieren, wenn man erst einmal über irgendeine Lücke Shell-Zugriff erlangt hat.
Sind dann keine E-Mails für diese Anmeldungen aktiviert (wobei die TR-064-Anmeldungen iirc ohnehin keine solchen E-Mails erzeugen), kriegt der FRITZ!Box-Besitzer davon am Ende nicht einmal in jedem Falle etwas mit, daß es da jetzt einen zusätzlichen Benutzer-Account in seiner FRITZ!Box gibt (er sieht den Namen ja auch nicht wirklich in einer Sicherungsdatei und kann höchstens durch Abzählen der Einträge dort erkennen, daß es einer zuviel ist) - wenn der Angreifer jetzt noch die Energie aufbringt, das Event-Log auch noch zu manipulieren, dann ist der schon fast "unsichtbar". Für eine solche Manipulation des Event-Logs reicht es ggf. schon, den Zeiger für den nächsten Eintrag zurückzusetzen und irgendeine andere Nachricht mittels "eventadd" zu erzeugen (das müßte ich für die neue 06.83 glatt mal wieder probieren) ... die AVM-Komponenten greifen m.W. über "memory mapped file"-Operationen auf die Datei zu, in der dieses Event-Log am Ende gespeichert wird (/var/.ar7events).
Daher finde ich jedenfalls, daß es sich AVM hier auch mit diesem Sonderzeichen für das Verstecken von Benutzernamen zu einfach macht (man findet das z.B. auch in den (OpenSource-)Quellen für den "ftpd", daß dort gar nichts in das Event-Log geschrieben wird, wenn ein Benutzer mit dem "@" am Beginn für eine solche Nachricht in Frage käme) ... für @SkipAuthFromHomenetwork und @CompatMode könnte man das auch anhand der Benutzer-ID entscheiden und sollte es für die Dateifreigaben über HTTP-URLs tatsächlich zusätzliche Accounts geben müssen (ich habe irgendwo im Hinterkopf die Idee, daß ich mal etwas in dieser Richtung irgendwo gesehen hätte, finde aber im GUI einer 06.83 gerade keine Möglichkeit, solche Links zusätzlich zu schützen), dann kann man das bestimmt auch anders regeln. Diese sehr einfache Variante, ein komplettes Konto vor den Augen des Besitzers und/oder berechtigten Administrators zu verstecken, ist jedenfalls irgendetwas zwischen einer Schwachstelle und einer echten Backdoor, wenn z.B. die FTP-Zugriffe so eines Nutzers gar nicht protokolliert werden (in den "ftpd" (Datei "ftpd.c" aus den "inetutils" in den AVM-Quellen) kann jeder selbst hineinschauen).
-Ich bin - nur um das auch noch einmal festzuhalten - auch nicht der Ansicht, daß ich mit diesem Beitrag nun irgendwie dabei helfen würde, die Sicherheit von FRITZ!Boxen "aufzuweichen". Für die Benutzung des Bootloaders braucht es immer noch den LAN-Zugriff zum Zeitpunkt des Starts und auch wenn ich es unmöglich finde, wie einfach ein Angreifer an dieser Stelle in eine FRITZ!Box gelangen kann (da käme jetzt wieder der Vorschlag, den FTP-Server im Bootloader nur "auf Knopfdruck" beim Power-On zu aktivieren), so ist das schon länger bekannt und wird - mehr oder weniger schulterzuckend - hingenommen. Das ist hier jetzt nur eine konkrete (für so manchen vielleicht auch sinnvolle) Anwendung, mit der man aber eben auch das Schadenspotential dieser "Schwachstelle Bootloader" demonstrieren kann - in meinen Augen auch recht eindrucksvoll in der "Schlichtheit" dessen, was es dafür nur braucht.
Angesichts der weiter oben angetexteten Möglichkeit, daß so ein falsches Kennwort auch das Ergebnis eines erfolgreichen Angriffs durch einen Dritten sein könnte und daß man mit dem Zurücksetzen des Kennworts über den AVM-Weg erst einmal selbst die Spuren verwischen würde, wenn man nicht zuvor noch eine Sicherungsdatei zieht, müßte man eigentlich sogar darüber nachdenken, ob man nicht auch Software veröffentlichen sollte, die dem FRITZ!Box-Besitzer anhand der Dekodierung der verschlüsselten Daten in so einer Sicherungsdatei (der Weg der "FRITZ!Box Tools" ist zwar auch nicht uninteressant, aber doch schon sehr umständlich zu nutzen) eine Einschätzung ermöglicht, ob es wirklich nur die eigene Vergesslichkeit oder ein Tippfehler bei der Änderung war (auch unterschiedliche Tastatursprachen (DE vs. EN) sind immer wieder gerne genommen als Fehlerquellen in so einem Fall), was da zum Zugangsproblem führte oder ob das doch jemand anderes war, der das originale Kennwort nicht kannte und daher dieses auch nicht wieder aktivieren konnte, um seine Spuren richtig zu verwischen.
Wer tatsächlich bis hier gekommen ist beim Lesen und nun rechtschaffen malade ist, der mache mir keinen Vorwurf und denke eher darüber nach, daß ich beim Schreiben noch viel länger brauchte, als ein durchschnittlich schneller Leser für seinen "Konsum" benötigt.
Zuletzt bearbeitet:
