Wünsche für neue Firmware-Features

Sicherung der Anrufliste als CSV-Datei ohne Excel-Formatprobleme:

Eine voll Excel-kompatible CSV-Datei muss wie folgt erzeugt werden:
- statt im Format UTF-8 ohne BOM im Format UTF-8 mit korrekter BOM 0xEF 0xBB 0xBF am Dateianfang
- ohne die unnötige Zeile mit "sep=;"
- Felder/Werte mit möglichen führenden Nullen im Format ="0049123456789"

Wenn ich das richtig auf dem Schirm habe, kann man die Anrufliste wohl auch noch nicht importieren. Das ist relevant, wenn man von z.B. einer FB 7490 auf eine FB 7590 um steigt und die Sicherung der 7490, sich nicht in die 7590 importieren lässt.
 
Livebild (am Dect Mobilteil):
# Zumindest bei der Fritzbox 68xx LTE, Firmware 7.08x, , lassen sich keine jpg und .png bei https Adressen wieder geben. Bei entsprechenden http Adressen geht es allerdings.
# Das Live Bild, gibt keine mp4 Filmchen wieder.
# Auch werden nicht gerade alle Aufrufe, die das von der Fritzbox unterstützte (.mpeg oder jpeg ??? Name klären) Format zurück geben, wieder gegeben, wenn es das (Name klären) Format nicht als Bezeichnung in der Aufruf Extension trägt.
 
Zuletzt bearbeitet:
Fritzbox Firmware, Zeitschaltung für AVM Schaltsteckdosen:
# Bei der Einstellung von Schaltzeiten für Steckdosen, nicht nur feste glatte (viertel, halbe, dreivirtel, volle Stunden) Stunden ein stellen können, sondern entweder belibige Minutenzeiten, oder noch besser, wie bisher, virtel Stuinden weise, jedoch bei Auswahl eines entsprechenden Buttons, mit täglicher, z.B. im Bereich von 5 oder 10 Minuten, erneut gewürfelter Varianz.
 
Zuletzt bearbeitet:
Das ist natürlich Bockmist. Man lehnt es mit einer Meldung ab und schneidet nicht ab.

Ich habe das derzeitige Passworthandling am WE bei einem Bekannten an einer Fritzbox 6890, mit der FW 07.03 testen können.

Das Ergebnis: Das Passworthandling ist nicht sauber und mit struktureller Schwäche.

* Testweise für die Fritzbox ein Kennwort von 35 Zeichen neu vergeben. Bei der Eingabe gab es keine Fehlermeldung.
* Man konnte sich nach Abmeldung, dann mit dem 35 Zeichen langen Kennwort an melden (ohne irgend welche Fehlermeldungen)
* Allerdings kann man sich bei dieser Variante, sowohl mit dem 35 Zeichen langen Kennwort ein loggen, als auch, wenn man das vergebene 35 Zeichen Kennwort auf 32 Zeichen ein kürzt.
* Wie wir aus dem Beispiel erkennen, Scheidet die beschriebene Firmware, sowohl bei Passwortvergabe, als auch bei Passwortverwendung, (zumindest bei einer Passwortlänge von 35 Zeichen), kommentarlos die Zeichen, die länger als 32 Zeichen sind ab und ignoriert diese.
* Vermutlich ist es derzeit generell egal, was man nach den ersten 32 Zeichen ein gibt, ob nun 33 oder 32 +x Zeichen. Daraus folgt vermutlich, das man derzeit nur die ersten 32 Zeichen eines Kennwortes kennen muß. Das scheint zwar zugegeben immer noch recht sicher. Allerdings, kann man es auch anders herum sehen, der Nutzer denkt vlt. ein deutlich längeres Kennwort zu verwenden, verwendet aber nur ein vlt. deutlich kürzeres. Und zumindest wenn der Nutzer ein deutlich längeres Kennwort al 32 verwenden sollte (z.B. 64 Zeichen), besteht das Kuriosum, das tausende und abertausende nicht vergebene Kennwörter in der Lage sind das Webinterface der Fritzbox zu öffnen, d.h. weniger als welche die den Zugriff verwehren.
 
Zuletzt bearbeitet:
Und zumindest wenn der Nutzer ein deutlich längeres Kennwort al 32 verwenden sollte (z.B. 64 Zeichen), besteht das Kuriosum, das tausende und abertausende nicht vergebene Kennwörter in der Lage sind das Webinterface der Fritzbox zu öffnen, d.h. weniger als welche die den Zugriff verwehren.
Du kennst die Möglichkeit, bei einer F!B diese Millionen Kennwörter auszuprobieren?

# es fehlt als ein und ausgehende Teleonsperre, die Vorlage für den technisch nicht zulässigen Nummernbereich "000"
# für eingehende Gespräche, die selben als Vorlage angebotenen Sperrtelefonnummern an bieten, wie sie für ausgehende Gespräche an geboten werden

# und 00800 Nummernbereich in
die Auswahlliste der zu sperrenden Nummernbereiche, ein und ausgehend, auf nehmen
Warum soll ein Rufnummernbereich (000) gesperrt werden, wenn er technisch 'dahinter' nicht möglich ist?

Warum sollte die 00800 gesperrt werden?
Weil sie so viel kostet?

# Es lassen sich keine ausgehenden Gespräche mit unterdrückter Rufnummernübermittlung sperren
Du möchtest verhindern, dass jemand mit unterdrückter Rufnummer rauswählt?
Warum?
 
Zuletzt bearbeitet:
Nein, die wären? ;)

Vor allem, wie lange dauert das von 0-..... incl der "Wartezeit" nach (mehrmaliger) Falscheingabe,... ?
 
Du kennst die Möglichkeit, bei einer F!B diese Millionen Kennwörter auszuprobieren?
Und BTW: Bei physischem Zugang zur Box ist das noch nicht einmal notwendig. Sobald dieser Zugang zur Box möglich ist, spielt es überhaupt keine Rolle mehr, ob das Passwort 4, 16, 64 oder auch 128 Zeichen besitzt (die letzten beiden Varianten natürlich nur theoretisch, wenn das FRITZ!OS unterstützen würde), es wäre sowieso ruckzuck ausgelesen/entschlüsselt...

Des Weiteren fehlt weiterhin eine optional komplett verschlüsselte Export-Datei (alternativ sollte auf expliziten Wunsch auch weiterhin die Teilverschlüsselung in derzeitiger Form möglich sein, zumindest wenn nicht über eine Push-Mail gesichert wird). Das würde ich übrigens für sehr viel wichtiger halten, als Benutzer-Passwörter mit mehr als 32 Zeichen zu unterstützen. Zumindest beim (automatischen) Sichern per Push-Mail, ein durchaus sehr wichtiges Feature. Und da würde ich ebenfalls noch nicht einmal auf mehr als 32 mögliche Zeichen für das Passwort bestehen sondern (zusätzlich) auf eine PGP-Verschlüsselung der versendeten Push-Mail. Das wäre imo besser als ein Passwort mit bspw. 128 Zeichen einzusetzen. @MegaV0lt hatte sich das bspw. auch schon in Beitrag #2875 gewünscht.
 
Kann ich absolut nicht nachvollziehen.
Bei mir (FB 6890 LTE 7.03) kann ich nach der Eingabe von z.B. 123456789a123456789b123456789c12 als neues Kennwort mit 32 Zeichen nichts mehr hinzufügen, wobei das Feld dort breit genug ist, dies sofort zu erkennen. Beim Login reicht das Feld leider nur für 27 ½ "Zeichen" (Mozilla 100%), aber man kann sich die Mühe machen und die "Kullern" auszählen, aber auch da stoppt nach dem 32. Zeichen die Eingabe.
Das länger als 32 Zeichen Kennwort jeweils in das Kennworteld rein KOPIREN, per Copy and Past, nicht per Tastatur in den beiden Kennworteldern ein tragen.

Du kennst die Möglichkeit, bei einer F!B diese Millionen Kennwörter auszuprobieren?


Warum soll ein Rufnummernbereich (000) gesperrt werden, wenn er technisch 'dahinter' nicht möglich ist?

Warum sollte die 00800 gesperrt werden?
Weil sie so viel kostet?


Du möchtest verhindern, dass jemand mit unterdrückter Rufnummer rauswählt?
Warum?
Weil der Tel Nummern Bereich der mit 000 an fängt, keinen positiven Nutzwert zum Leben eines Telefonanschlußrechnungsempängers leisten kann und dem zu Folge nur Risiken birgt, irgend wo auf der Welt alsch interpretiert zu werden und Unsinn zu erzeugen.

Nein, die wären? ;)

Vor allem, wie lange dauert das von 0-..... incl der "Wartezeit" nach (mehrmaliger) Falscheingabe,... ?
Die notwendige Zeit verdoppelt sich nach ein paar Falscheingaben recht schnell. Zumindest ist es so, wenn nicht noch irgend wo andere Bugs bestehen, die in Kombination auch diese Absicherung kippen. Schlägst du vor, bekannte strukturelle Schwächen zu ignorieren oder siehst du gar Vorteile für den Nutzer in fest eingebauten Schwächen ?

Und BTW: Bei physischem Zugang zur Box ist das noch nicht einmal notwendig. Sobald dieser Zugang zur Box möglich ist, spielt es überhaupt keine Rolle mehr, ob das Passwort 4, 16, 64 oder auch 128 Zeichen besitzt (die letzten beiden Varianten natürlich nur theoretisch, wenn das FRITZ!OS unterstützen würde), es wäre sowieso ruckzuck ausgelesen/entschlüsselt...

Des Weiteren fehlt weiterhin eine optional komplett verschlüsselte Export-Datei.
Wenn ich mich recht entsinne, konnte ich in besagter Datei, auch bereits alle möglichen Daten der FB lesen, bis auf die in der FB verwendeten Kennwörter, ohne das FB Kennwort zu kennen.

Warum sollte die 00800 gesperrt werden?
Weil sie so viel kostet?
Warum?

Ich sperre bei Nutzern die Fritzboxen verwenden, Nummern, wie z.B. 0800 eingehend, die bei ihnen keinen Sinn machen und demzufolge, keinen Nutzen für sie haben. Auf der Gegenseite, trägt aber eine keinen Sinn machende Variante immer ein Mißbrauchspotential und sei es auch nur in Verbindung mit einem anderen fiktiven Bug. Der z.B. bei einer erlaubten Einwahl per 0800, zu einem Rückruf bei Besetzt, auf einer z.B. 0900 Nummer führt.

So ist das nun mal in der IT. Erlaube keine Dinge die der entsprechende Nutzer für nichts benötigt.

Du möchtest verhindern, dass jemand mit unterdrückter Rufnummer rauswählt?
Warum?

Manch einer hält so etwas für unseriös und möchte das deshalb bei seiner Fritzbox sperren. In manchen rechtlichen Kontexten, ist das in Deutschland gar mit durchaus beachtlichen Strafen belegt, mit unterdrückter Nummer andere Leute an zu rufen.

//edit by stoney: Mehrere Doppelposts zusammengeführt - Vollzitate bitte selbst passend kürzen
 
Zuletzt bearbeitet von einem Moderator:
... bis auf die in der FB verwendeten Kennwörter, ohne das FB Kennwort zu kennen.
Dann weißt du vermutlich nur nicht, wie das Auslesen der unverschlüsselten Kennwörter geht. Das ändert aber nichts an der Tatsache, dass es geht. Denn Unwissenheit schützt bekanntlich nicht vor Kompromittierung/Angriff... :D
 
Dann weißt du vermutlich nur nicht, wie das Auslesen der unverschlüsselten Kennwörter geht....

Das mag sein das es da mehrere Wege gibt. Auch habe ich nicht den Ehrgeiz jegliche Eigenschaft zu ergründen. Das sollte sicherlich ein wenig intensiver bei AVM ergründet werden, bevor eine Firmware zum Endtest auf den Kunden los gelassen wird.

Als ich mal per einem js rein geschaut hatte, konnte ich meiner Erinnerung nach alles bis auf Zugangskennwörter lesen, ohne das Exportkennwort der Datei an zu geben. unter Angabe des Exportkennwortes, konnte ich dann auch die vorher nicht sinnvoll lesbaren Kennwörter lesen.

Wie auch immer. Ich reporte das Verbesserungspotential, der FB hier und an anderen Stellen, auf das die FB möglichst weniger Bugs als Features hat.
 
Unnötiges Vollzitat entfernt - HabNeFritzbox

Nchträglich eingefügtes gekürztes Zitat:
"Dann KOPIERE mal bitte 123456789a123456789b123456789c123456789d123456789e123456789f1234 per copyPasta da rein und schreibe uns, welche/wieviele Zeichen davon dann in dem Feld zum Stehen kommen."

Ich habe jetzt keine Fritzbox verfügbar, mit der ich deine Test gegen checken könnte. Wenn das jetzt bei dir anders sein sollte, dann scheint es an irgend welchen Unterschieden in der verwendeten Firmware, des Kennwortes oder der Testdurchführung zu liegen.

Nachtrag:
Es geht nicht darum wie viele Zeichen die Fritzbox im Eingabefeld an zeigen kann, sondern darum wie viele Zeichen die Fritzbox intern tatsächlich von dem eingegebenen Passwort verwendet.
 
Zuletzt bearbeitet:
# Es ist eine vermeidbare Sicherheitsschwäche, das per WLAN ein Zugang zum Webinterface der Fritzbox besteht. Zumindest sollte diese Variante deaktivierbar sein. Aus Sicherheitssicht, ist es besser, den Zugriff auf das Webinterface auf die Lan Ports beschränken zu können.
 
In manchen rechtlichen Kontexten, ist das in Deutschland gar mit durchaus beachtlichen Strafen belegt, mit unterdrückter Nummer andere Leute an zu rufen.
Interessant, und welche? Das kannst du doch sicher gerne erläutern.

Denn ich kenne einige, die eine Rufnummernübertragung nie freigeschaltet haben.
Ich sperre bei Nutzern die Fritzboxen verwenden, Nummern, wie z.B. 0800 eingehend, die bei ihnen keinen Sinn machen und demzufolge, keinen Nutzen für sie haben. Auf der Gegenseite, trägt aber eine keinen Sinn machende Variante immer ein Mißbrauchspotential und sei es auch nur in Verbindung mit einem anderen fiktiven Bug. Der z.B. bei einer erlaubten Einwahl per 0800, zu einem Rückruf bei Besetzt, auf einer z.B. 0900 Nummer führt.
Hä?

Wie soll, wenn du die Nummer X wählst, ein RbB auf eine Nummer Y gehen, besonders, ohne dann dieses von deiner Telefonanlage gewählt wird?

Wenn du meinst, dass jemand es schaffte, eine 0800er-Nummer auf eine 0900er weiterzuleiten, und dass der Anrufer diese Kosten zahlen musst, dann kannst du sicher auch erklären, wie das funktionieren soll.

Und selbst wenn, warum sperrst du dann die 00800, nicht aber die 0800?
 
dann scheint es an irgend welchen Unterschieden in der verwendeten Firmware, des Kennwortes oder der Testdurchführung zu liegen.
Hast Du auch mal in Erwägung gezogen, daß schlicht Dein Testaufbau falsch gewesen sein könnte und daher bei Dir das falsche Ergebnis dabei herauskam?

Ist zwar schwer "off-topic", aber ich wage mal die Behauptung (und versuche auch, den Beweis anzutreten), daß Du hier schweren Unsinn getestet hast. Wenn das hier nichts zu suchen hat, werden die Moderatoren es hoffentlich in einen anderen Thread auslagern und nicht nur entsorgen (Danke vorab).

--------------------------------------------------------------------------------------------------------------------------------------------

Sowohl beim Setzen eines Kennworts als auch in der Login-Maske ist das Kennwortfeld mit einem "maxlength"-Attribut definiert, das einen Wert von 32 hat. Für die Aktionen beim Erreichen der max. Länge der Eingabe ist - afaik - der Browser zuständig (z.B. für ein kurzes akustisches oder optisches Signal) - eine generelle Festlegung (aka Spezifikation) gibt es da m.W. nicht.

Was passiert z.B., wenn man (unter F(ire)F(ox) 67.0.1, Windows 7 x64) jetzt auf die Idee kommt, etwas in ein solchermaßen beschränktes Eingabefeld zu kopieren, was diese Länge überschreitet?

Das ist ganz einfach festzustellen ... man öffne die Anmeldeseite (s)einer FRITZ!Box und drücke dort einfach mal die F12 - dieses ruft dann die Developer-Tools auf.

Dazu gehört auch die JS-Console und so kann man da nette Spielereien mit dem Inhalt der angezeigten Login-Seite machen, u.a. das Feld für die Kennworteingabe näher untersuchen, dieses hat die ID "uiPass":
Code:
>> document.getElementById("uiPass").value.length
<- 0
>> document.getElementById("uiPass").getAttribute("maxlength")
<- "32"
>> // jetzt einfach mal 31 Zeichen in das Feld kopieren (Vorlage: 1234567890123456789012345678901234567890 - einfach soviel markieren und kopieren, wie man braucht), danach abfragen
>> document.getElementById("uiPass").value.length
<- 31
>> document.getElementById("uiPass").value
<- "1234567890123456789012345678901"
>> // jetzt mit 32 Zeichen
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
>> // und nun - drumroll - mit 33 Zeichen
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
Die Ausgabe nach dem versuchten Kopieren von 33 Zeichen ist auch kein Unfall ... man kann das gleich noch einmal mit anderen Werten im Eingabefeld testen, bevor man versucht, die Zeichen hineinzukopieren (hier habe ich gleich die 40 Zeichen von oben genommen beim zweiten Versuch):
Code:
>> document.getElementById("uiPass").value.length
<- 8
>> document.getElementById("uiPass").value
<- "ABCDEFGH"
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
Wir können also schon einmal festhalten, daß es - beim von mir verwendeten Browser, bei Dir fehlt die Angabe dazu - keinen Unterschied macht, wie man versucht, die Daten in das Feld zu kriegen, ob mit der Tastatur oder per Copy&Paste ... ab "maxlength" wird abgeschnitten. Das KÖNNTE zwar bei einem anderen Browser anders sein, aber um das zu prüfen, müßte man halt mehr über den Testaufbau wissen.

Nun heißt das aber tatsächlich noch nicht, daß man die Länge der Daten in diesem Feld NIEMALS über diese festgelegten 32 Zeichen hinaustreiben könnte. Bei einer Zuweisung greift dieses Attribut nämlich tatsächlich nicht:
Code:
>> document.getElementById("uiPass").value
<- ""
>> document.getElementById("uiPass").value.length
<- 0
>> document.getElementById("uiPass").getAttribute("maxlength")
<- "32"
>> document.getElementById("uiPass").value = "1234567890123456789012345678901234567890"
<- "1234567890123456789012345678901234567890"
>> document.getElementById("uiPass").value.length
<- 40
>> document.getElementById("uiPass").value
<- "1234567890123456789012345678901234567890"
Wenn man es also drauf anlegt, kann man auch mehr als 32 Zeichen in so ein Eingabefeld prügeln und außerdem könnte man ja auch noch direkt den POST-Request an die Box, der den Inhalt dieses Feldes enthält, manipulieren ... nirgendwo steht, daß der aus einem Browser mit JS-Support kommen muß.

Aber das weiß AVM eben auch ... schaut man sich jetzt die Lua-Dateien für das GUI an (ich nehme hier mal die "boxuser_edit.lua"), werden die Variablen am Ende (tatsächlich ohne weitere Längenprüfung) über die Funktion "box.set_config(<table>)" an den "ctlmgr" übergeben.

Das läßt sich bekanntlich mit der "set.lua" auch machen und notfalls auch über "ctlmgr_ctl". Aber testen wir es doch zunächst mal mit der erwähnten "set.lua" - als erstes die Anzeige für den Benutzer "test_upnp", dessen Kennwort ich einfach mal gelöscht habe:
Code:
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
        users {
                enabled = yes;
                id = 10;
                name = "test_upnp";
                email = "";
                password = "";
                vpn_access = no;
root@FB7490:~ $
Die Verwaltung von Variablen/Objekten, die als Array vorliegen, erfolgt ja über Indizes, daher brauchen wir erst einmal die Benutzer-ID oder den Index dieses Account, denn die ID ist leider nicht die angezeigte "10", zumindest nicht zwingend:
Code:
root@FB7490:~ $ echo "L=boxusers:settings/user/list(UID,id,name)" | queries.lua | grep test_upnp
L_4_name="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user/list(UID,id,name)" | queries.lua | grep L_4
L_4_index="user3"
L_4_UID="boxuser10"
L_4_id="10"
L_4_name="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user3/name" | queries.lua
L="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user3/password" | queries.lua
L=""
root@FB7490:~ $ echo "L=boxusers:settings/user2/password" | queries.lua
L="****"
root@FB7490:~ $
Unser Benutzer "test_upnp" ist also "user3" (das ist leichter als die Array-Schreibweise, die auch funktionieren würde) und hat kein Kennwort. Im Gegensatz zum Benutzer 2 (letzte Zeile oben) wird das tatsächlich auch "angezeigt" vom "ctlmgr", ein vorhandenes Kennwort wird aber immer nur mit den gezeigten vier Sternen ausgegeben.

Was passiert jetzt, wenn wir erst mal überhaupt ein Kennwort für "user3" setzen?
Code:
root@FB7490:~ $ echo "boxusers:settings/user3/password=ABCDEFGH" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
        users {
                enabled = yes;
                id = 10;
                name = "test_upnp";
                email = "";
                password = "ABCDEFGH";
                vpn_access = no;
root@FB7490:~ $ echo "L=boxusers:settings/user3/password" | queries.lua
L="****"
root@FB7490:~ $
Kennwort auf "ABCDEFGH" gesetzt, Anzeige aber "****", der Weg funktioniert aber - das sei hiermit bewiesen.

Also testen wir das jetzt wieder mit den 31, 32 und danach mit mehr als 32 Zeichen, das Auslesen machen wir über die "ar7.cfg", da können wir das gesetzte Kennwort dann auch sehen:
Code:
root@FB7490:~ $ echo "boxusers:settings/user3/password=1234567890123456789012345678901" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
        users {
                enabled = yes;
                id = 10;
                name = "test_upnp";
                email = "";
                password = "1234567890123456789012345678901";
                vpn_access = no;
root@FB7490:~ $ echo "boxusers:settings/user3/password=12345678901234567890123456789012" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
        users {
                enabled = yes;
                id = 10;
                name = "test_upnp";
                email = "";
                password = "12345678901234567890123456789012";
                vpn_access = no;
root@FB7490:~ $ echo "boxusers:settings/user3/password=123456789012345678901234567890123" | set.lua
Das Kennwort ist ungültig.
root@FB7490:~ $
... und siehe da, ab dem Überschreiten der max. Länge von 32 Zeichen für das Passwort, läßt es sich gar nicht mehr speichern - das System liefert sogar die passende Fehlermeldung.

Nun erfolgte dieser Test aber tatsächlich an einer 113.07.11 ... diese Angabe zum Testaufbau fehlte auch noch von meiner Seite - absichtlich. Denn auf die Frage der FRITZ!OS-Version komme ich jetzt noch einmal zurück. Die 07.03, mit der Du bei der 6890 getestet hast (was ja @Olaf Ligor schon nicht nachvollziehen konnte und der hatte die absolut identische Firmware-Version), gehört ja in dieselbe Linie, wie z.B. die ältere 07.01 für die 7490 - also versuchen wir das doch einfach mit dieser Version auch noch einmal:
Code:
root@FB7490:~ $ /etc/version
113.07.01
root@FB7490:~ $ echo "boxusers:settings/user3/password=123456789012345678901234567890123" | set.lua
Das Kennwort ist ungültig.
root@FB7490:~ $
oder auch mit einer anderen Box (6490) und einer noch älteren FRITZ!OS-Version:
Code:
/var/media/ftp/pentest/bin # /etc/version
141.06.83
/var/media/ftp/pentest/bin # echo "boxusers:settings/user1/password=123456789012345678901234567890123" | ./set.lua
Das Kennwort ist ungültig.
/var/media/ftp/pentest/bin #
Die Ergebnisse sind also dieselben - von der 06.83 bis zur 07.11 ... spätestens beim Versuch des Speicherns eines Kennwortes mit mehr als 32 Zeichen, gibt es im FRITZ!OS einen Fehler.

Ich kann hier auch absolut nichts sehen, wo AVM irgendeine Security-Sünde begehen würde, die man auch tatsächlich AVM zurechnen müßte oder könnte. Den HTML-Standard hat AVM nicht verbrochen, Java-/ECMA-Script auch nicht und m.W. stellt AVM auch keinen Browser her, wenn man Programmierung so nennen will. Die Länge der Eingabe wird begrenzt und zu lange Daten werden auch beim Speichern im Backend abgewiesen.

Ob und wieviele Tasten der Benutzer noch drückt, wenn die 32 Zeichen voll sind, interessiert hier gar nicht ... erst dann, wenn jemand für ein Login per API auf die Idee käme, mit einem längeren Kennwort den MD5-Hash zu berechnen, spielt das u.U. wieder eine Rolle - nur wird dieser Hash-Wert dann nicht zum Ergebnis aus den 32 gespeicherten Zeichen passen.

Da hier aber eben gar kein Kennwort mehr "über die Leitung geht" (das ist ja schon bei der Login-Maske nicht wirklich der Fall, weil der Hash ja lokal berechnet wird), interessiert es auch nicht, über wieviele Zeichen irgendein Benutzer-Programm diesen Hash nun bilden will - sind es mehr als die 32 gespeicherten Zeichen oder gar andere, paßt eben der Hash nicht ... fertig. Punkt. Ob so ein Programm dann seinerseits "smart" ist, die Vorgaben von AVM kennt und bei 32 Zeichen Kennwort abschneidet, liegt wieder an dessen Entwickler.

Wo soll hier irgendeine Lücke vorhanden sein?
 
Zuletzt bearbeitet:
Interessant, und welche? Das kannst du doch sicher gerne erläutern.

Denn ich kenne einige, die eine Rufnummernübertragung nie freigeschaltet haben.

Hä?

Das Stichwort nennt sich "Rufnummernunterdrückung bei Werbeanrufen":
"Wie bei der unerlaubten Telefonwerbung gegenüber Verbrauchern kann die Bundesnetzagentur Bußgelder in den Fällen verhängen, in denen der Anrufer bei einem Werbeanruf die Anzeige der Rufnummer unterdrückt oder veranlasst, dass diese unterdrückt wird. Das Verbot der Rufnummernunterdrückung bei Werbeanrufen ist in § 102 Absatz 2 des Telekommunikationsgesetzes (TKG) geregelt. Dieser besagt, dass der Anrufer sicherzustellen hat, dass dem Angerufenen die dem Anrufer zugeteilte Rufnummer übermittelt wird, d. h. dem Angerufenen die dem Anrufer zugeteilte Rufnummer im Telefondisplay angezeigt wird. Mit dem Anrufenden ist nicht der Auftraggeber des Anrufers gemeint, sondern der faktisch Anrufende."

Bußgelder
"Die Bundesnetzagentur kann aufgrund von Beschwerden und eigener Ermittlungen unerlaubte Werbeanrufe und Werbeanrufe mit Rufnummernunterdrückung als Ordnungswidrigkeit verfolgen. Der Verstoß gegen das Verbot unerlaubter Telefonwerbung stellt eine Ordnungswidrigkeit dar, die seit dem Inkrafttreten des Gesetzes gegen unseriöse Geschäftspraktiken am 9. Oktober 2013 mit einer Geldbuße von bis zu 300.000 Euro durch die Bundesnetzagentur gemäß § 20 UWG geahndet werden kann.

Bis zum Inkrafttreten des Gesetzes war die Bundesnetzagentur ermächtigt, Verstöße gegen das Verbot der unerlaubten Telefonwerbung mit Geldbußen von bis zu 50.000 Euro zu verfolgen. Zuwiderhandlungen, die bis einschließlich 8. Oktober 2013 erfolgt sind, sind nach der bis dahin geltenden Rechtslage zu bewerten. Bei Verstößen gegen das Verbot der Rufnummernunterdrückung bei Werbeanrufen kann die Bundesnetzagentur gemäß § 149 Absatz 2 TKG Bußgelder bis zu 10.000 Euro verhängen."

Quelle:
[Edit Novize: Beiträge zusammengefasst, siehe Forumsregeln!]
Es geht voran:

In der aktuellen FB 6890 Beta Version 7.08xy, geht mittlerweile das folgende. Habe es daher aus meiner in der Beitragsfußzeile benannten Bugliste entfernt:

Livebild (am Dect Mobilteil):
# Zumindest bei der Fritzbox 68xx LTE, Firmware 7.08x, , lassen sich keine jpg und .png bei https Adressen wieder geben. Bei entsprechenden http Adressen geht es allerdings.
 
Zuletzt bearbeitet von einem Moderator:
Ich wünsche mir, dass man einstellen kann, dass nur Anrufe durchgestellt werden, deren Rufnummer in einem Telefonbuch stehen. Alle anderen sollen abgewiesen werden oder können über eine Rumumleitungsregel auf den Anrufbeantworter geführt werden. Das wäre ein gutes Instrument gegen Werbeanrufe, die zudem auch noch immer ihre gefakten Rufnummern ändern.

Mir ist bekannt, dass man das über einen Umweg realisieren kann, über „wichtige Person“ Markierung in einem Telefonbuch mit permanenter Anrufsperre. Dennoch ist das schwierig, das zu realisieren, wenn man schon mal eine große Anzahl an Telefonbucheinträgen hat, die man dann erst noch nachmarkieren müsste...

Eigentlich sollte es doch schon ausreichen, im Menuepunkt Telefonbuche ein entspr. "Kästchen" einzurichten: alle Personen im Telefonbuch xyz oder abc als wichtig einzustufen.
Die Werbeanrufe hier in Frankreich gehen mir fürchterlich auf den Zeiger, weil

a) Werbeanrufe nicht wie in D verboten sind
b) da die Angerufenen schon gar nicht mehr zum Telefon gehen wenn keine Rufnummer angezeigt werden, benutzen die Werbefuzzis jetzt entweder gefakte Nummern - die sich ständig ändern oder missbrauchen
Telefonnummern von existierenden Privatleuten (was 'ne - sorry - richtige Sauerei ist). Kurz: man kann zwar ein Spam Telefonbuch anlegen und auch ständig aktualisieren; es bringt aber nix. Und jeden Anruf annehmen und ständig "oui oui, d'accord" sagen (bis die Anrufer merken sie werden veräppelt) ist auf Dauer zu mühsam. Besonders wenn diese Knilche mittags oder abends anrufen.

Deshalb hab ich in meinen Fritte Telefonbüchern jeden Eintrag als wichtige Person definiert - alles andere landet auf dem AB. Aber bei gut 150 Einträgen ist die Markierung "wichtige Person" ein mühsames Unterfangen - auch wenn man nur die csv manuell ändern muss. Wäre wirklich schön - ein Häkchen setzen - alle Personen im Telefonbuch werden als wichtig markiert - danach die Klingelsperre einrichten. Und damit man keinen evt. wichtigen Anruf verschwitzt hört man einmal am Tag den AB ab. Und damit Adieu für diese Murk-Werbe-Anrufe.
 
Eigentlich sollte es doch schon ausreichen, im Menuepunkt Telefonbuche ein entspr. "Kästchen" einzurichten: alle Personen im Telefonbuch xyz oder abc als wichtig einzustufen.
Mann kann:
* Leute mit unterdrückter Rufnummer nicht klingeln lassen, auf den AB mit Daueransage "Bitte legen sie nicht auf, Ihr Anruf ist uns wichtig" schicken.
* Auch kann man zwei separate Teleonbücher an legen. Eines für Freunde und Co und eines für gesperrte Spam Nummern. In dem Fall muß man nicht jede Nummer einzeln sperren, sondern sperrt das Telefonbuch mit den Spamnummern.
 
Mann kann:
* Leute mit unterdrückter Rufnummer nicht klingeln lassen, auf den AB mit Daueransage "Bitte legen sie nicht auf, Ihr Anruf ist uns wichtig" schicken.
* Auch kann man zwei separate Teleonbücher an legen. Eines für Freunde und Co und eines für gesperrte Spam Nummern. In dem Fall muß man nicht jede Nummer einzeln sperren, sondern sperrt das Telefonbuch mit den Spamnummern.
Ja und dann ?
Dein Vorschlag löst doch mein Problem nicht. Die Werbeleute wechseln ständig die Telefonnummern - und benutzen inzwischen auch private Telefonnummern. Ruft man dann diese Nummer zurück, wird man mit erstaunten Teilnehmern konfrontiert: warum sollte ich bei Ihnen angerufen haben ?? Ein Spam Telefonbuch habe ich natürlich aber es hilft doch überhaupt weiter, wenn sich die Nummern ständig ändern !!!! Natürlich kann man das Spam Telefonbuch ständig erweitern und schauen ob sich z.B. die ersten 4 oder 5 Stellen ständig wiederholen. Nur - wenn es der Zufall will blockiert dann damit auch Nummern, die im Telefonbuch gelistet sind.

Und - wie auch geschildert - unterdrücken die Werbemafiosi auch die Rufnummer nicht mehr, denn die haben inzwischen auch gemerkt dass dann kein Teilnehmer mehr abnimmt. Davon abgesehen war eine meiner ersten Massnahmen bei Einrichtung der Fritte Anrufe ohne Anzeige der Nummer zu unterdrücken.

Nee nee, bislang ist nach meinem Verständnis die Klingelsperre die z.Zt. einzig sinnvolle Methode - die Anrufer haben ja immer die Möglichkeit auf dem internen Anrufbeantworter der Fritte eine Nachricht zu hinterlassen:
Bin aber für weitere Vorschläge immer offen.
 
Das Problem löse ich so:
Eine Firmware wird das nicht richten können, der Workaround kann es in meiner Konstellation aber durchaus. Wäre eventuell auch was für Dich?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,341
Beiträge
2,250,494
Mitglieder
373,997
Neuestes Mitglied
BerndBareth
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.