Achtung: Sicherheitslücke mit Fritz!OS bis 06.50 | 2016.06.07

Beispiel: wenn es mal wieder eine Lücke in Android gibt, informiert Google und stellt Patches zur Verfügung (oder eben nicht). Hersteller stellt es dann den Kunden zur Verfügung (oder eben nicht).

In diesem Fall informiert AVM öffentlich, aber stellt wohl nicht oder nur lückenhaft Infos den Partnern zur Verfügung. UM ist ein Reseller, haben als solches wenig Einfluss und können dir schon mal gar keine Firmware backen. Ich sehe AVM in der Pflicht, aber natürlich soll UM hier massiv Druck auf AVM ausüben (bzw. den Kundendruck weitergeben - falls es welchen gibt).

Aber egal, ist alles OT. AVM soll mal deutlich sagen was ist und wann es wofür welche Patches gibt (eben genannten UM-Geräte oder 7270v3 von denen es ja noch reichlich gibt).
 
Ganz schlechtes Beispiel, denn das Smartphone gehört nicht dem Provider. Unitymedia ist auch kein Reseller, von Kabelboxen schon gar nicht. Überleg mal, bevor du schreibst. :)
 
In dem Heise-beitrag steht das, was auch in einem dazu passenden heise-Artikel stand:
Beim Neuanlegen außer auf ein starkes Passwort ....

Wer nicht auf ein starkes Passwort bei aus dem Internet erreichbaren SIP-Accounts achtet, ist selber schuld.

Muss man echt mal sagen.


Und noch etwas dazu:
Bei jedem Online-Konto ein anderes Passwort.
Wenn möglich auch unterschiedliche Mail-Accounts. ( die immer wieder genannte Möglichkeit, mit seinem Google-Mail-Account so eine Art 'Catch-All' zu erzeugen ist eine solche Möglichkeit. Sie schützt aber nicht vor SPAM)
[Unterschiedliche Mail-Accounts, da die oft zum Anmelden verwendet werden. Werden diese nur für die Registrierungs/Reaktivierungs-Mail verwendet, gilt das SPAM-Problem oben.]
 
Generell scheint AVM aber inzwischen auch bei der Überzeugung angekommen zu sein, daß man den Kunden zu seiner Sicherheit auch zwingen darf (nur die letzte Konsequenz in der Durchsetzung fehlt für meinen Geschmack noch) ... die aus Fehlern von Kunden entstehenden Probleme werden nur in den seltensten Fällen so differenziert betrachtet, daß Probleme durch (erfolgreiches) "password guessing" auch wirklich auf das Konto des Kunden gehen würden bei der "Berichterstattung".

Wobei sich der Anbieter der Firmware dann vielleicht wieder den Vorwurf gefallen lassen muß, daß er es seinen Kunden allzu gerne zu leicht macht, wenn er die Konfiguration von unsicheren Eingaben überhaupt zuläßt.

Zwar kann man das "entropy meter" an verschiedenen Stellen als Schritt in die richtige Richtung sehen (wenn das nicht dank Javascript nach jedem Change ohnehin wieder witzlos wäre, weil es nur die vier Sterne bewertet), aber wenn das "schwach" sagt und dann wird das Kennwort trotzdem akzeptiert, ist das bei einem "Profi" sicherlich das Problem des Kunden ... zumindest in der "Standard-Ansicht" würde ich tatsächlich erwarten, daß die Firmware keine unsicheren Kennwörter akzeptiert (macht inzwischen fast jede Internet-Präsenz so).

Meinetwegen soll man in den Tiefen der (nur per Editor erreichbaren) ar7.cfg noch eine Einstellung einführen, die bei absolut erkenntnisresistenten Kunden dann die Verwendung von schlechten Kennwörtern ermöglicht (bzw. die neue Vergabe eines solchen, denn bestehende wird man damit auch nicht ändern, das wäre die Aufgabe der "Sicherheitsseite", auf solche Probleme hinzuweisen), aber hier muß man eben auch den Kunden etwas vor sich selbst schützen. Noch vor wenigen Jahren wurden solche Router auch mit unverschlüsseltem WLAN ausgeliefert, das traut sich heute (fast) kein Anbieter mehr.

Das hat auch nichts mit Bevormundung zu tun (in meinen Augen) ... bei auftauchenden Problemen fragt kein Mensch mehr, ob es auch sicherer einzustellen war ... die Schuld wird vom "normalen Kunden" weiter dem Hersteller zugewiesen werden, denn schließlich sind das "die Spezialisten". Daher sollte hier immer gelten: Zuerst sichere Vorgaben für die Einstellungen und erst dann, wenn der Benutzer wenigsten ansatzweise mit der Materie vertraut ist (und sei es nur, weil er sich erst anlesen mußte, wie er die unsichere Einstellung durch die Prüfungen bringt), dann soll er meinetwegen machen, was er nicht lassen will.

Daß es bei SIP-Anmeldungen generell möglich ist, mittels Wörterbuch-Attacken auf unsichere Kennwörter loszugehen, ist nun mal prinzipbedingt ... hier einen Zähler vorzugeben, nach wievielen vergeblichen Versuchen die weitere Anmeldung dieses SIP-Clients für eine bestimmte Zeit zu sperren ist, kann sich allzu schnell als Bumerang herausstellen ... dann ist (bei UDP mit leicht zu fälschendem Absender) im Handumdrehen wieder ein Ansatz für einen DoS-Angriff daraus geworden (weil bei UDP eben eine Filterung nach Absender auch ziemlich sinnlos ist).

Wobei auch AVM noch an allen möglichen Stellen geradezu hanebüchene Einstellungen vollkommen klaglos zuläßt - ein sehr unfeines Beispiel dafür ist die Eingabe eines PSK für eine LAN-LAN-Verbindung in der VPN-Implementierung. Da gibt es nicht einmal das "entropy meter" und welchem "normalen Kunden" ist es schon in vollem Umfang bewußt, daß die Sicherheit der VPN-Verbindung beim verwendeten "aggressive mode" mit der Stärke dieses PSK steht und fällt? Wenn da auch das Kennwort "kennwort", "password" oder "1234" akzeptiert wird, ist das vielleicht immer noch die Schuld des Kunden, wenn er ein solches Kennwort wählt ... daß er es überhaupt eintragen kann, ohne daß da zwei bis drei warnende Seiten zusätzlich im GUI erscheinen, ist aber genauso ein Problem und das laste ich nicht dem Kunden an.
 
Der Vollständigkeit halber

da u.U. Abbonnenten hier im Topic, die sich wegen der Vodafone 7270 Gedanken machen und nicht "jedewede Topics" verfolgen ... ein Quoting des relevanten Abschnittes sei mir erlaubt?

...

Zur Frage der Sicherheit der 7270v3 ... ich kann Dir soviel versichern, daß diese Firmware aus dem LAN von jedem mit ihr per Kabel verbundenen Gerät (bzw. von einem WLAN-Gerät aus über einen per Kabel verbundenen AP) beim Start der Box angegriffen werden kann (sogar ohne jedes Problem).

In späteren Versionen ist dieses Problem beseitigt, in der 06.06 wurde es dann Ende Sept. 2015 (neben anderen) trotzdem weiter mitgeschleppt. Meine Meldung an AVM erfolgte Weihnachten 2014, im Februar 2015 habe ich dafür einen "Bug Bounty Reward" erhalten. Die dabei getroffene Vereinbarung verbietet es mir leider, von mir aus Einzelheiten preiszugeben ... mein Primärziel der besseren Absicherung wurde aber (bei dieser Lücke) prinzipiell umgesetzt (für relevantere Modelle) und so warte ich genauso wie alle anderen, daß/ob AVM die Details dazu veröffentlicht - man kann dieses Problem auch selbst mit einer eigenen modifzierten Firmware ausräumen (auch weitere) ... das macht m.E. bei älteren Boxen, für die AVM selbst keine neuen Versionen mehr veröffentlichen will, sogar richtig Sinn. Aber das liegt nicht in meinem Einflußbereich ... ich hoffe hier darauf, daß AVM irgendwann ein Einsehen haben wird.

Kommt so eine Veröffentlichung, gibt es von mir zeitnah die passenden Skripte, um das ggf. sogar unter Windows 10 zu realisieren ... mal schauen, wie weit die Linux-Integration in Windows 10 gehen wird und ob man nicht demnächst generell auf diesem Wege auf eine Linux-VM verzichten kann, wenn man nur kleinere Änderungen vornehmen will.

Da ich diese Probleme in meiner eigenen Firmware für die 7270v3 natürlich entfernt habe, gibt es die Patches prinzipiell auch schon ... ich werde trotzdem erst nach der Veröffentlichung durch AVM (oder nach deren Freigabe, daß ich es machen darf) die mir bekannten Lücken so detailliert erklären können, daß man sich dagegen schützen kann.

Eine ausschließlich von außen zu nutzende Lücke in der 7270v3 kenne ich jedenfalls nicht, es ist immer (bei den mir bekannten Problemen) die "Mitarbeit" von innen notwendig (UI=R im CVSS) und die ist bei einem Angriff, der nur auf die gerade startende Box erfolgen kann, nur dann möglich, wenn es parallel dazu noch eine weitere Internetverbindung gibt (bei einer "live"-Attacke) - ein programmgesteuerter Ablauf kann selbstverständlich auch ohne Internetverbindung zum Erfolg kommen und die erbeuteten Daten erst später absetzen bzw. über eine parallele Mobilfunkverbindung (bei Smartphones/Tablets) senden.

Wenn jetzt tatsächlich auch bei den KNB die letzten Reste der 6360 auf eine neuere Version angehoben werden, dann sind dort auch einige weitere Lücken geschlossen, die ansonsten bei den 06.0x-Versionen noch zu finden waren ... vielleicht ist das ja dann Anlaß, die zur 06.20/06.30 hin geschlossenen Lücken so weit zu dokumentieren, daß der Benutzer selbst einschätzen kann, ob er sie in eigener Regie schließt oder sich lieber einen neueren Router zulegt oder ob ihn das am Ende auch ganz kaltläßt.

Quelle: http://www.ip-phone-forum.de/showthread.php?t=240840&p=2167426&viewfull=1#post2167426

wobei auch hier ein wiederholtes "DANKE" nicht verkehrt ;) Dass genauere Hinweise fehlen dezidiert, liegt wohl anschaulich in der Natur der Sache wie oben zitiert ... Nachfragen eher sinnlos und löchtert PeterPawn damit BITTE nicht ;)

Für eine persönliche Einschätzung sollte dies genügen ;) um die grobe Richtung zu erkennen!

LG

P.S.: Bitte diesen Thread Nutzen für RE`s da der ursprüngliche eh etwas üppig ;)
 
Zuletzt bearbeitet:
Daß es bei SIP-Anmeldungen generell möglich ist, mittels Wörterbuch-Attacken auf unsichere Kennwörter loszugehen, ist nun mal prinzipbedingt ... hier einen Zähler vorzugeben, nach wievielen vergeblichen Versuchen die weitere Anmeldung dieses SIP-Clients für eine bestimmte Zeit zu sperren ist, kann sich allzu schnell als Bumerang herausstellen ...
Man sollte es aber wenigstens in den Ereignissen protokollieren, auch mit Zähler!
Das ist IMO die größte Sicherheitslücke bei AVM.
Beim Login auf die FB hat man es ja nun nach vielen Jahre endlich hin bekommen:
Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.178.20.
und
Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.178.20 gescheitert (falsches Kennwort).
Wieso geht das nicht auch für FTP, SIP und anderes? :mad:
 
Zuletzt bearbeitet:
eisbaerin schrieb:
Wieso geht das nicht auch für FTP, SIP und anderes?
Das frage ich mich auch ... bei mir rennt man damit offene Türen ein.

Schon die Behandlung der Logins (die SIP-Accounts benutzen ja zumindest getrennte Credentials, wo man mangels Notwendigkeit der permanenten Eingabe problemlos auch starke Kennwörter "erzwingen" könnte, ohne daß der Bedienkomfort für den Benutzer wirklich leidet) ist höchst unterschiedlich.

Selbst bei der aktuellen Labor-Version für die 7490 (33566) kann man noch problemlos ein Konto für ein IP-Telefon mit dem Kennwort "test1" einrichten und für den Zugriff aus dem Internet freigeben. Ob da dann auch noch eine Anmeldung möglich ist oder nicht (weil die "Verbesserung" vielleicht erst bei der Benutzung so eines SIP-Accounts greifen sollte), habe ich nicht weiter getestet.

Solange die Maßnahmen nicht abgestimmt sind, führt das ja nur zu mehr Konfusionen beim Kunden und wenn der ein IP-Telefon mit Kennwort "test1" anlegen und extern freigeben kann, dann bleibt mir einfach nur die Spucke weg. Hier sähe ich AVM sogar in der Pflicht, einfach beim Anlegen ein Kennwort vorzugeben und das muß der Kunde dann eben in sein Endgerät übernehmen.

Das macht er in der Regel genau ein einziges Mal ... und hier geht m.E. Sicherheit vor Bequemlichkeit und das heißt, so ein Kennwort hat mind. 16 Stellen (alphanumerisch, am besten Base64-Zeichensatz, dann gibt es auch wenige Probleme mit ASCII > 128 oder anderen Zeichensätzen) und das ist auch schon ein Kompromiß aus Sicherheit und Bequemlichkeit für den Kunden (beim WLAN-Kennwort sind es ja inzwischen auch 20 Ziffern, die AVM erst einmal vorgibt). Wenn das einem Kunden nicht passen sollte und er unbedingt eigene Kennwörter vergeben will (und sei es dreist, weil ihm persönlich 16 Zeichen zu wenig sind), dann muß er eben zu einem Editor greifen (oder AVM erlaubt beim "Editieren" dann doch wieder die Vergabe eines eigenen, aber eben nicht beim Anlegen, was 90% schon davon abhält, da mit "test1" einzusteigen). Bei 16 Zeichen könnten wirklich nur noch ausgesprochen paranoide Zeitgenossen von einem per se unsicheren Kennwort reden.


-Zum zweiten ... leider wird auch nie so richtig kommuniziert von AVM, was sich bei dieser ganzen Protokollierung nun wann ändert (bzw. ändern soll) - oder ich kann das nur nie finden, weil ich mich zu blöd anstelle.

Die Protokollierung beim FTP-Server ist (nach den veröffentlichten Quellen) ja tatsächlich vorgesehen (wenn auch in einer Routine, die (vermutlich) nicht explizit/exklusiv für den FTP-Server geschaffen wurde, dazu komme ich später) ... sie funktioniert nur leider nicht im Ansatz (die Nachricht 460 dürfte eine Ausnahme bilden, die kommt auch aus dem ftpd selbst) und vermutlich hat das schon sehr lange niemand mehr wirklich getestet bei AVM - ganz im Gegenteil.

Da wurde zwar zur 06.20 hin die Art des Aufrufs von "eventadd" entschärft und von "system()" auf "execl()" umgestellt, damit da keine "command injection" mehr möglich ist. Vorher (bei der 7490 bis zur 06.05) gab es da einen Aufruf:
Code:
static void Event(unsigned  id, const char *display_name)
{
    char buf[256];
    snprintf(buf, sizeof(buf)-1, "/sbin/eventadd %u %s", id, display_name);
    buf[sizeof(buf)-1] = '\0';
    system(buf);
}
und man kann sich ja leicht ausmalen, was man mit einem in "display_name" eingeschmuggelten Shell-String da bewirken könnte (da spielte es auch keine Rolle, ob das "eventadd" erfolgreich gewesen wäre oder nicht, da hilft es also auch nicht, daß die ganze Protokollierung ohnehin nicht klappt).

Das hat man - wie gesagt - geändert, an den anderen Stellen bzgl. der Protokollierung mit den Event-IDs 7xx kann man (bzw. ich) da nichts sehen ... daher die Feststellung "ganz im Gegenteil", die sich natürlich auf das Testen der Änderung beim Ersetzen von "system()" bezog - dabei hätte die fehlende Protokollierung ja auffallen müssen.

Wenn ich es richtig in Erinnerung habe, war aber zumindest beim FTP-Server das (externe) Einschmuggeln von Shell-Code in den Benutzernamen beim (vergeblichen) Protokollieren nicht ganz so einfach, weil bereits vorher nach dem Benutzernamen gesucht wurde (beim Mapping vom AVM-Namen auf den Linux-Benutzer) und es deshalb nie bis zur Protokollierung kam.

Aber der gesamte Code in logincontrol.c könnte (und da geht die Spekulation dann auch schon los) natürlich genauso bei den Versionen vor 06.20 noch an anderen Stellen in der Firmware benutzt werden und wenn man sich ansieht, daß es in der Firmware eine libavmacl2.so gibt, dann kann man auch annehmen, daß andere Komponenten sie benutzen:
Code:
# grep -r libavmacl2
Binary file sbin/ftpd matches
Binary file sbin/smbd matches
Binary file lib/libwebusb.so.0.0.0 matches
Binary file lib/libavmacl2.so.0.0.0 matches
Binary file usr/www/cgi-bin/nasupload_notimeout matches
Binary file usr/share/ctlmgr/libctlusb.so matches
(das ist die 06.05 der 7490). Hier führte dann aber jeder Versuch, die folgende Routine:
Code:
void LoginControlWrongPassword(const char *display_name, int from_internet)
{
    if (!display_name || !IsOEM_tcom()) return;

    struct record *r = LockRecordWithCreate(display_name);
    if (!r) {
        return;
    }
    if (r->blocked && !IsStillBlocked(r->blocked)) {
        // reset
        r->blocked = 0;
        r->failed_logins_local = 0;
        r->failed_logins_extern = 0;
    }
    if (from_internet) r->failed_logins_extern++;
    else r->failed_logins_local++;
    if (r->failed_logins_local > 5 || r->failed_logins_extern > 5) {
         struct timespec ts;
         clock_gettime(CLOCK_MONOTONIC, &ts);
        r->blocked = ts.tv_sec + BLOCK_TIME; // login blocked for some time
        Event(from_internet ? 718 : 717, display_name);
    }
    WriteAndUnlockRecord(r);
}
mit einem vielleicht doch nur unzureichend geprüften "display_name" aufzurufen, beim sechsten falschen Login-Versuch zur Ausführung von zusätzlichem Shell-Code im "display_name" ... nicht vergessen, ist in aktueller Firmware Geschichte und damit nicht mehr akut - nur ältere Versionen sind eventuell(!) betroffen.

Jetzt könnte man mit sehr viel Geduld zwar noch im smbd nachsehen, ob da alles korrekt ist ... bei den anderen drei Vorkommen (die vierte Datei ist ja die Lib selbst) beißt man aber (zumindest in Quelltext-Form) ohnehin auf Granit und damit lohnt sich auch der Blick in den smbd nicht.

Zwar müssen die auch nicht unbedingt eine der "LoginControl..."-Funktionen mit Protokollierung von Ereignissen aufrufen, dafür ist es nicht auszuschließen, daß AVM-Komponenten ähnlichen Code auch direkt benutzen. Die oben zu sehenden Binärdateien für die beiden ausführbaren Dateien (ftpd und smbd) sind ja auch diejenigen, die von AVM als Source-Code veröffentlicht werden müssen und wo die Verwendung einer gesonderten Library anstelle der Interprozess-Kommunikation mit dem ctlmgr wohl auch darauf zurückzuführen ist, daß AVM ansonsten diesen IPC-Mechanismus (hinter dem "msgsend") hätte offenlegen müssen. Da braucht es allerdings dann auch keinen Aufruf von "eventadd" als externes Kommando, weil man da gleich die passenden AVM-Libraries linken kann. Trotzdem sind solche Spekulationen m.E. durchaus erlaubt ... sichtbare Fehler an der einen Stelle sind eben in sehr vielen Fällen auch darauf zurückzuführen, daß da jemand vorhandenen Code falsch angepaßt hat nach dem Kopieren.

Daher bitte auch diese - wirklich nur theoretische - Schwachstelle nicht damit verwechseln, daß ich irgendwie behaupten will, man könne sie konkret ausnutzen (und schon gar nicht von außen). Solange immer alle, die an solchem Code mitarbeiten oder den von jemand anderem benutzen, die entsprechenden Vorsichtsmaßnahmen auch einhalten, sind selbst solche Stellen im Code noch kein echtes Problem ... erst beim ersten Programmierer, der dann seinerseits eben den Benutzernamen nicht bereits vorher einer Validierung unterzogen hätte, würde das zum Problem ... und genau deshalb vermeidet man solche unsicheren Konstrukte besser von Beginn an, dann kann kein anderer später an solchen Stellen in die Falle laufen.

Man kann nur konstatieren (und sei es auch nur aus reiner Vorsicht), daß man eben bei den Modellen, wo AVM keine Updates mehr ausliefert, selbst Hand anlegen kann/soll/muß ... meine 7270v3 ist eben so ein Kandidat.

Für die 06.06 gibt es kein OpenSource-Paket bei AVM und damit muß man erst einmal unterstellen, daß sich da nichts geändert hat und ein Blick in die Firmware zeigt das auch:
Code:
# strings lib/libavmacl2.so | grep eventadd
/sbin/eventadd %u %s
Das ist die 06.06 und da bleibt einem dann nichts weiter als Gottvertrauen (oder AVM-Vertrauen, wobei ich das nicht unbedingt gleichsetzen würde), daß da niemals ein Aufruf von "LoginControlWrongPassword()" mit einem unzureichend geprüften Benutzernamen erfolgt (da reicht auch keine vorherige Prüfung in irgendeinem HTML-Formular per Javascript).

Oder man geht eben selbst hin und ändert die libavmacl2.so aus reiner Vorsicht selbst (für die gibt es tatsächlich die Quellen), daß da auch nichts mehr passieren kann in den älteren Versionen.

Das war jetzt ein Beispiel für eine potentielle Lücke, für die kein Stillschweigen vereinbart war ... AVM hat eben viele (fast alle) der unsicheren Aufrufe von Shell-Kommandos aus den eigenen Komponenten heraus so überarbeitet, daß da auch bei unzureichender Prüfung der Eingaben nicht mehr direkt ein Ausführen von Kommandos möglich ist. Es gibt fast keine Aufrufe von "system()" mehr, wo dann eben die Shell automatisch aufgerufen wurde und auch die exec()-Aufrufe für /bin/sh (die natürlich ähnliche Probleme erzeugen können, wenn da Parameter nicht richtig geprüft werden) sind deutlich weniger geworden (noch nicht vollkommen verschwunden, aber auch nicht jeder dieser Aufrufe hat noch eine Zeichenketten-Ersetzung in der Parameterliste).

Der FTP-Server wäre jetzt per se auch der einzige Service gewesen, der von extern zugänglich sein könnte ... alle anderen Funktionen (event. mit Ausnahme von nasupload, das müßte ich glatt noch einmal prüfen) sind normalerweise nur von intern zugänglich und damit könnte man auch nur von innen den Streßtest für die Validierung der übergebenen Benutzernamen machen.

Das lohnt sich aber nicht mehr wirklich ... es ist wesentlich einfacher, einfach generell auf FRITZ!Boxen mit Firmware < 06.20 zu verzichten (und auch meine 7270v3 dient eigentlich nur noch zum (erweiterten) Testen und als Notnagel, falls das DSL mal nicht will - hier geht ohnehin kein eingehender Verkehr von extern wegen des Mobilfunks).

Aber für den Angriff von innen (sprich, für das Erlangen eines Shell-Zugriffs auf eine 6360) konnte das eben auch verwendet werden ... wenn man in einer so alten Firmware einen passenden Benutzernamen eingetragen hatte (z.B. "ftpuser$(/var/media/ftp/<usb_stick>/my_command.sh)", über den FBEditor kein großes Kunststück und auch auf anderen Wegen möglich, die S44-hostname-Lücke war ja ähnlich zu initiieren) dann konnte man den selbstverständlich auch beim Login in den FTP-Server verwenden (das geht selbst bei aktuellen Versionen noch, kann jeder selbst austesten) und sich sogar erfolgreich anmelden. Damit kam dann irgendwann der Versuch, das erfolgreiche Login auch zu protokollieren (selbst wenn das nie funktionierte, erhält man doch eine Vorstellung, wie gefährlich solche Relikte dann sein können).

Die Quellen dazu gab es irgendwann auch mal von AVM, ich weiß nicht mehr genau, ob ich dazu erst anfragen mußte oder ob die generell verfügbar waren, heute sind sie es wohl nicht mehr - jedenfalls finde ich die Datei nicht bei AVM auf dem FTP-Server.

Aber das ist tatsächlich derselbe Code wie bei den DSL-Modellen und damit kann man auch dort sehen, daß da bei erfolgreichem Login (je nach extern oder intern) die Nachricht mit der Event-ID 713 oder 715 ausgegeben werden soll und das führt dann wieder zur Ausführung der (Skript-)Datei unter "/var/media/ftp/<usb_stick>/my_command.sh", die man natürlich vor dem Login passend auf einem USB-Stick bereitstellen muß (Linux-Dateisystem und die passenden Rechte sind Pflicht).
Code:
void LoginControlPasswordOk(const char *display_name, int from_internet)
{
        if (!display_name || !IsOEM_tcom()) return;

        if (from_internet) Event(701, display_name); // EVENT_ID_TCOM_FW102
   [COLOR="#FF0000"]     Event(from_internet ? 715 : 713, display_name);[/COLOR]

        struct record *r = LockRecordIfExists(display_name);
        if (!r) return;
        short modified = 0;
        if (!from_internet && r->failed_logins_local) { modified = 1; r->failed_logins_local = 0; }
        if (from_internet && r->failed_logins_extern) { modified = 1; r->failed_logins_extern = 0; }
        if (r->blocked) {
                r->blocked = 0;
                modified = 1;
        }
        if (modified) WriteAndUnlockRecord(r);
        else UnlockRecord(r);
}
Aber diese alten Versionen sind ja nun wenigstens bei den KNB ebenfalls Geschichte ... damit kann man das auch mal zeigen, wie so ein Relikt an ziemlich unerwarteter Stelle einen Angriff (hier eben zum Rooten des DOCSIS-Gerätes) ermöglichen konnte.

Da ich selbst auch keine 6360 mehr habe, ist diese "Story" nur aus dem Gedächtnis und ich würde die Hand nicht ins Feuer legen, daß es 1:1 so funktionierte. Das ist fast drei Jahre her und ich habe seitdem so viele Tests an anderen Stellen gemacht, da wirft man dann auch mal versehentlich die Modelle und/oder Versionen durcheinander. Wenn sich jemand mit einer 6360 mit einer ausreichend alten Firmware-Version findet, kann er ja mal ausprobieren, ob das skizzierte Vorgehen bei seiner Version noch funktioniert. Mein Firmware-Archiv geht nur bis zur 06.05 und selbst das kann ich nicht wirklich testen, seit mir die Box dazu fehlt.

-Zurück zur Protokollierung ... selbst die Nachricht 460 aus dem FTP-Server heraus ist eher witzlos für den normalen Benutzer. Sie enthält zwar die Angabe, daß ein erfolgreiches(!) Login für FTP aus dem Internet erfolgte, aber dann auch nur, von welcher IP-Adresse aus dieser Zugriff erfolgt(e). Die wesentlich wichtigere Information wäre aber (meine Meinung) der verwendete Benutzername. Wer kennt schon beim mobilen Internet-Zugang seine eigene IP-Adresse und kann damit einschätzen, ob er das selbst war (oder eine App auf seinem Smartphone im Hintergrund, die das durchaus darf) oder ob es doch ein fremder Zugriff auf ein unzureichend gesichertes anderes Konto war.


-Die fehlende Benachrichtigung für fehlgeschlagene NAS-Logins (bzw. die nicht funktionierende ... warum das so ist, kann man sich in den Quellen von AVM (avmacllib2/logincontrol.c) ansehen) zieht sich inzwischen endlos durch die Historie (mindestens seit 06.05, eigentlich schon seit der 05.59 bei der 7490 nachweisbar) ... im Rahmen eines anderen Problems habe ich die gerade noch einmal an AVM gemeldet (bzw. bei dieser anderen Meldung erneut erwähnt).

Manchmal geht so etwas als (anonymes) Feedback zu Labor-Versionen ja auch unter ... wobei das bei vielen anderen kleinen Problemen ja (früher zumindest) auch so war - die Verbesserungen bei den AVM-Bemühungen konnte man zwischenzeitlich konstatieren, im Moment habe ich wieder die Befürchtung, es geht in die Gegenrichtung beim offeneren Umgang mit Problemen der Firmware.

Meiner Meinung nach sind da aber auch die Kunden nicht ganz unschuldig ... wenn sich aus der Veröffentlichung beseitigter Lücken für 7 Jahre alte Router (meinetwegen auch 5 Jahre, falls die 7270v-irgendwas länger vertrieben wurde) beim Kunden dann die Frage ergibt: "Und was ist mit meinem Router, muß ich etwa nach nur fünf Jahren jetzt schon den nächsten anschaffen?", dann stimmt für mich (auch wieder nur meine Meinung) etwas mit der Erwartungshaltung der Kunden nicht.

Die Geräte haben 5 Jahre Herstellergarantie, mir fällt beim besten Willen kein Grund ein, wieso ein Hersteller bei diesen (vergleichsweise auch noch preiswerten) Geräten noch Firmware über diesen Zeitraum hinaus aktualisieren sollte. Das macht auch kein anderer Hersteller, da ist (mit sehr viel Glück) vielleicht noch in den ersten zwei Jahren ein Security-Update drin ... wenn ich dann ab und an lese, daß man wegen genau dieses (unausgesprochenen) Update-Versprechens zu einem AVM-Gerät gegriffen hätte, dann frage ich mich da schon, ob die anderen Preise wirklich so niedrig sind, daß man die Rechnung "eine AVM-Box in 5 Jahren ist immer noch teurer als 2,5 andere Router in diesen 5 Jahren" aufmachen könnte oder sollte (vom Funktionsumfang will ich nicht schreiben, da sind die Bedürfnisse des einzelnen Kunden ohnehin entscheidend und nicht zu verallgemeinern).

Auf das (bei sehr vielen) auch regelmäßig aktualisierte Smartphone habe ich oft genug Bezug genommen ... warum geht das bei einem (preiswerter zu habenden) Router nicht ebenfalls? Wenn dann ein Shitstorm losbricht, wie AVM es wagen kann, nach 5 Jahren keine weiteren Updates mehr zu liefern, dann muß man sich auch nicht wundern, wenn das Management bei AVM wieder das Visier fallen läßt.

Am Ende schaden solche Rufe (auch wieder nur mein Standpunkt) dann den Kunden, die neuere Boxen besitzen und dank einer "Verschwiegenheit" in Bezug auf vorhandene Probleme nur raten können, ob ihr Internet-Zugang nun sicher ist oder nicht.

Dieser Fall hier (also die AVM-Warnung, auf der dieser Thread basiert) ist nahezu ein klassischer Fall der selbsterfüllenden Prophezeiung, daß so etwas immer negativ für das Image ausgehen muß. Dank nur sehr schwammiger Fakten (also einer eher halbherzigen Warnung) in der Meldung rätselt die ganze Welt herum, wo diese neue Lücke nun wieder liegen möge (für die dürftige Faktenlage ist allerding ganz klar AVM verantwortlich), aber die Alternativen wären (m.E.) nur zwei gewesen: Hinsetzen, ducken und die Klappe halten (wird schon nicht so schlimm werden) oder tatsächlich die Versionen zu benennen, die angreifbar sind (ohne genaue Details zur Lücke).

Aber dann wären eben sofort wieder die Fragen gekommen, was denn nun die Besitzer der ganzen alten Boxen (die hoffentlich in absehbarer Zeit den elektronischen Tod erleiden, hier ist Langlebigkeit ein echter Fluch) machen sollen ... auf die Idee, sich dann einfach eine neuere FRITZ!Box zuzulegen, kommen wahrscheinlich die wenigsten.

Nun will ich auch diejenigen nicht aus den Augen verlieren, die sich keinen neueren Router leisten können ... denen wäre dann trotzdem mit einer besseren Risikoabschätzung (und möglichen Gegenmaßnahmen) eher geholfen und diejenigen, die sich keinen neuen Router zulegen wollen, für die kann ich persönlich tatsächlich kein Mitleid aufbringen. So ein Router ist kein wirkliches "Haushaltsgerät", was man einmal anschafft und das dann auch mal 10 Jahre und länger seinen Dienst tun sollte, wenn es eine entsprechende Qualität hat ... schon die technische Entwicklung dürfte das in vielen Fällen verhindern.


-Zurück zum Support ... ich habe seit der Umstellung der Feedback-Funktion für die Labore zugegebenermaßen dieses Formular eigentlich nicht mehr benutzt - kann denn jemand tatsächlich positive Erfahrungen berichten, wenn er dort ein Problem (keinen Verbesserungsvorschlag) meldet?

In Anbetracht vieler eher negativer Feststellungen hier im Forum - vor allem bei "langfristigen Problemen" - habe ich da zugegebenermaßen meine Vorbehalte, ob sich der zu investierende Aufwand für eine solche Meldung tatsächlich rentiert - mit einer "danke für Ihr Feedback, wir melden uns bei Nachfragen"-Mail, einer ausbleibenden Nachfrage und trotzdem regelmäßig weiterhin neu erscheinenden, "problembelasteten" Labor-Versionen ist es ja eher unwahrscheinlich, daß da jemand bei AVM diese Meldungen auch wirklich liest (ja, das ist unzulässig verallgemeinert - absichtlich ... eine öffentlich einsehbare Liste von akzeptierten, registrierten und zu behebenden Problemen (das muß ja nicht immer sicherheitsrelevant sein) würde hier wahre Wunder bewirken). Da hat dann so ein länglicher Beitrag im IPPF vermutlich mehr Leser ... leider.

Mein Fazit (sorry, ist wieder mal überlang geworden): Der Einsatz von älterer Firmware ist - genau wie AVM es (wenn auch nur sehr allgemein) anmerkt - risikobehaftet. Es wurden viel mehr (potentielle) Lücken geschlossen, als in irgendeinem Changelog zu finden sind ... insofern ist die (leider auch hier noch anzutreffende) Haltung, auch mal mit älterer Firmware ins Internet zu gehen, nicht so auf die leichte Schulter zu nehmen.
 
Bei der 7490-Labor von heute wurde nachgelegt:
Telefonie

  • Verbessert - Anforderung für Kennwörter von IP-Telefonen bei Ersteinrichtung und späterem Bearbeiten weiter erhöht
 
Im Unitymediaforum wird in diesem Thread nun folgende Anweisung von Unitymedia an einen User mit 6360 gegeben. Des weiteren steht bei UM ein PDF-Download mit Instruktionen zur Verfügung.

Da auch ich heute merkwürdige Log-Einträge auf meiner 6360 bzgl. Internettelefonie mit 620@<meine externe IP> und user=phone hatte, habe ich nun auch ALLE Passwörter, die auf der 6360 gespeichert sind, geändert:

- myfritz.net
- ALLE FB-Benutzer
- Mail-Konto
- ALLE WLAN/LAN-IP-Telefone (meine 6360 fungiert als SIP-Registrar)
- Alle Sipgate-Nummern-Passwörter inkl. Benutzer-Passwort

Vom Unitymedia Business Support wurde ich jedoch bisher nicht wieder kontaktiert; offizielle Klärung mir gegenüber, wie es nun mit der 6360 weitergehen soll, steht immer noch aus.
 
Zuletzt bearbeitet:
Wie sehen die merkwürdigen Log-Einträge genau aus? Kannst du mal ein Beispiel posten?
 
Leider nicht; der UM-Anweisung folgend habe ich die 6360 nach dem Ändern der Passwörter durchgestartet, aber ich habe trotz Pushmail-Config keine Mail mit den letzten Log-Einträgen bekommen. Das war dumm von mir, diese zuvor nicht zu sichern. In den jeweiligen Log-Einträgen kam aber neben den user=phone noch eine recht lange Hex-Nummer vor. :(
 
Was mich ja mal interessieren würde ... welche Firmware-Version ist denn nun auf der 6360 installiert?

- - - Aktualisiert - - -

Ich habe mir gerade mal das Eventlog der 6490 von einem UM-User angesehen, bei dem offenbar seit Ende Mai Brute-Force-Angriffe auf das GUI stattfinden/stattgefunden haben (das wohl zu allem Überfluß auch noch auf dem Port 443 erreichbar ist, was nun wirklich unnötig ist).

Dabei fällt es ja schon auf, daß die Abstände zwischen den protokollierten Login-Versuchen nur bei 3 Minuten liegen (vermutlich quälen die Bots im Zeitraum zwischen zwei Versuchen dann andere Router/Kunden) ... ein Angriff mit so langen Pausen zwischen den möglichen Versuchen ist meines Wissens auch relativ neu.

Wenn man da nicht ständig dieselben Benutzernamen und Kennwörter testen will, muß man das ja schon mit "ordentlicher Protokollierung" machen und auch davon ausgehen können, daß die IP-Adressen einen Neustart überleben oder man hat doch noch andere Informationen (z.B. geklaute DynDNS-Konten, auch MyFRITZ! käme in Frage, wenn es nur FRITZ!Boxen treffen sollte, was ich fast nicht glaube), um so einen Client auch nach mehreren Stunden oder Tagen noch finden zu können ... sonst lohnt sich der ganze Aufwand ja nicht, weil man immer wieder von vorne beginnen müßte und das wären bei max. 20 Versuchen pro Stunde und 24 Stunden am Tag gerade mal 480 Kombinationen an einem Tag, die man da durchspielen könnte.

Wobei man für das Auffinden des Routers im Internet ja nicht einmal die Daten für die DynDNS-Änderung bräuchte, hier reicht es ja schon aus, wenn man die Adresse (eigentlich ja den DNS-Namen) an sich hat - die Abfrage braucht keine Authentifizierung.

Da stellt sich natürlich die Frage, wie Angreifer an diese DNS-Namen gelangen sollten ... aber auch das ist mit einem Android-Trojaner leicht erledigt, der bräuchte ja nur die DNS-Abfragen von irgendwelchen Apps (bei FRITZ!Boxen dann eben die FRITZ!App irgendwas, bei Speedports die Telekom-Apps) abfangen. Damit hätte er allerdings noch keinen Port, den kriegt er nur beim Zugriff auf die (hoffentlich verschlüsselt gespeicherten) Einstellungen oder beim Paketmitschnitt auf einem Android-Gerät ... das ist wesentlich mehr Aufwand und besser gesichert als z.B. das Auslesen des DNS-Resolver-Caches.

Da ist dann ein abweichender Port (ohnehin zu empfehlen, weil ansonsten schon der versuchte Verbindungsaufbau mit seinem Schlüsselaustausch die FRITZ!Box an den Rand des Nervenzusammenbruchs treiben kann, da braucht man noch gar keinen Login-Versuch) auch noch ein gewisser Schutz gegen solche Ausspähungen ... es gibt über den Daumen 65000 verwendbare Portnummern und die müßte so ein Angreifer (auf das freigegebene GUI) auch erst einmal durchsuchen, wenn er den richtigen Port nicht auf anderem Wege erfährt.

Allerdings kann man so einen DNS-Namen (und sogar die zugehörige Portnummer) auch problemlos bei einem erfolgreichen Angriff auf einen Mail-Provider erbeuten, wenn denn die Kunden dort FRITZ!Boxen besitzen und dort auch (sinnigerweise, die Push-Mail-Möglichkeit stelle ich damit nicht in Frage) den Push-Mail-Versand aktiviert haben. So eine Push-Mail enthält dann bequemerweise direkte Links auf die externen Adressen der FRITZ!Box ... für einen Angreifer ein gefundenes Fressen. Hier würde es nur helfen, wenn die Box selbst ihre Push-Mails einfach verschlüsselt (und der Benutzer sie natürlich dann auch nicht entschlüsselt in seinem IMAP-Postfach ablegt aus reiner Bequemlichkeit). Der zwangsweise verschlüsselte Versand ist m.W. ja bereits umgesetzt ... ohne TLS zum SMTP-Server gibt es keine Push-Mails bei aktuellen Versionen. Das verhindert aber nur, daß der Briefträger die Postkarte unterwegs lesen kann ... wenn die dann im Postverteilzentrum sortiert werden (oder im HBK landen), kann sie trotzdem wieder jeder lesen (und das machen die Provider auch, spätestens wenn das Postfach eingehende Mails auf Malware untersuchen soll).

Früher gab es bei der AVM-Firmware mal den Algorithmus, daß jeder fehlgeschlagene Versuch die Wartezeit bis zum nächsten verdoppelte ... u.a. deshalb klappte es ja mit einem frisch installierten FBEditor beim kleinsten Vertipper nicht auf Anhieb, weil man einfach (wegen der Art, wie der FBEditor nach jeder Eingabe von Adresse, Benutzernamen und Kennwort sofort die Anmeldung probiert und dann in der Regel erst einmal scheitert) ziemlich schnell in die Bereiche der Wartezeit gelangen kann, wo das Timeout für die erfolgreiche Anmeldung nicht mehr groß genug ist.

Inzwischen scheint es da aber eine Begrenzung nach oben zu geben und die liegt vermutlich irgendwo bei den drei Minuten, die man in dem Log sehen kann. Wobei da vielleicht vom Angreifer auch noch ein "Sicherheitsaufschlag" dazugegeben wird ... bei einem schnellen Test mit dem GUI einer 7412 (06.50) liegt die maximal zu erzielende Wartezeit zwischen zwei Versuchen bei 128 Sekunden. Ob da nicht im OS (also ohne den JS-Code, der die Eingabe solange sperrt) am Ende nur eine noch kürzere Zeit erzwungen wird, müßte man mal testen.

Das ist zwar immer noch eine recht effektive Begrenzung (auch 60 Sekunden wären das noch), aber das sind auch gezielte Angriffe auf die FRITZ!Box-Oberfläche bzw. auf das TR-064-Protokoll von der WAN-Seite (bei "Benutzer" sollte es aber um das GUI gehen), denn daß eine FRITZ!Box-Anmeldung (auch der Versuch einer solchen) nicht mit den "normalen HTTP-Mechanismen" funktioniert (sondern AVM da einen Challenge-Response-Mechanismus wie bei "digest auth" in Javascript nacherfunden hat), hat sich sicherlich inzwischen auch herumgesprochen.

Das ist also nicht mehr nur "Beifang", das sind gezielte Angriffe - oder die Protokolleinträge stimmen nicht ganz ... beim TR-064-Zugriff aus dem WAN ist tatsächlich "basic auth" gefordert für eine bestimmte URL (TLS ist ja Pflicht, da wäre das auch sicher) und das kann man dann wieder "allgemeiner" angreifen. Aber dann sollte da etwas von einem App-Zugriff protokolliert werden.

Aber das verdeutlicht eben auch wieder, daß man keinesfalls normale Wörter oder die üblichen Verdächtigen aus dem sozialen Umfeld (vom Namen des Hundes bis zum Geburtstag der Oma) als Kennwort verwenden sollte, denn es gibt einerseits "Wörterbuch-Attacken" (das wird ja nicht blind von A bis ZZZZZZZZ - für achtstellige Kennwörter aus lauter Großbuchstaben - probiert, das wäre auch zum Scheitern verurteilt) und für Kennwort-Raten auf der Basis von "social engineering" sind die "sozialen Medien" ja geradezu prädestiniert. Wenn dann wieder mal irgendwo Kundendaten geklaut werden (hatten wir das letztens nicht erst bei LinkedIn?), dann lassen sich aus den Kontakten eben auch solche denkbaren Kennwörter herleiten ... auch da werden die Methoden eben immer ausgefeilter.
 
Bei mir ist 06.33 auf der 6360 installiert.

Ich denke, ich kann von meiner Seite Entwarnung geben, da ich solche Einträge auch in den Pushmails vom letztem Samstag gefunden habe:

Code:
25.06.16 12:24:20	Internettelefonie mit [email protected];user=phone über 81.210.162.30;user=phone war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:24:09	Internettelefonie mit [email protected];uniq=6F3C63200D03C714EFA28A7D233A6 über 192.168.178.110;uniq=6F3C63200D03C714EFA28A7D233A6 war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:24:06	Internettelefonie mit [email protected];user=phone über 81.210.162.30;user=phone war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:58	Internettelefonie mit [email protected];uniq=6F3C63200D03C714EFA28A7D233A6 über 192.168.178.110;uniq=6F3C63200D03C714EFA28A7D233A6 war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:56	Internettelefonie mit [email protected];user=phone über 81.210.162.30;user=phone war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:48	Internettelefonie mit [email protected];uniq=6F3C63200D03C714EFA28A7D233A6 über 192.168.178.110;uniq=6F3C63200D03C714EFA28A7D233A6 war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:46	Internettelefonie mit [email protected];user=phone über 81.210.162.30;user=phone war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:38	Internettelefonie mit [email protected];uniq=6F3C63200D03C714EFA28A7D233A6 über 192.168.178.110;uniq=6F3C63200D03C714EFA28A7D233A6 war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:36	Internettelefonie mit [email protected];user=phone über 81.210.162.30;user=phone war nicht erfolgreich. Ursache: Temporarily not available (480)
25.06.16 12:23:28	Internettelefonie mit [email protected];uniq=6F3C63200D03C714EFA28A7D233A6 über 192.168.178.110;uniq=6F3C63200D03C714EFA28A7D233A6 war nicht erfolgreich. Ursache: Temporarily not available (480)

81.210.162.30 war die externe IP meiner 6360, 192.168.178.110 war die lokale IP meiner 7390 hinter der 6360.
Die Einträge gehören zu einer auf der 7390 gesperrten Rufnummer, die von einem Bot angerufen wurde. Sorry für diese Bandbreite hier. :oops:
 
Zuletzt bearbeitet:
12 Wochen nach der offiziellen Warnung seitens AVM:

Neue Software 06.50 für Ihre AVM FRITZ!Box 6360


Kundennummer(n): ...

Sehr geehrter Kunde,

für Ihre AVM FRITZ!Box steht Ihnen ab dem 06.09.2016 ein Software-Update bereit. Die wichtigsten Neuerungen sind:
• Neues Design der Benutzeroberfläche - optimal für Tablet und Smartphone
• Das ganze Heimnetz auf einen Blick - FRITZ!-Produkte zentral aktualisieren
• Neues WLAN-Analysetool und privater WLAN-Hotspot
Um die neue Software aufzuspielen, führen Sie bitte einfach einen Stromreset durch. Bitte beachten Sie, dass es bis zu 30 Minuten dauern kann, bis Ihnen Ihr Anschluss wieder in vollem Umfang zur Verfügung steht.

Sollten Sie das Update bis zum 20.09.2016 nicht selbst durchgeführt haben, werden wir in der Nacht auf den 20.09.2016 das Update durch einen automatischen Stromreset durchführen. Bitte trennen Sie die FRITZ!Box während dieser Updatezeit nicht vom Strom.

Sichern Sie individuelle Konfigurationen Ihrer FRITZ!Box lokal, um diese zu einem späteren Zeitpunkt wieder nutzen zu können.


Sollten Sie Fragen haben, erreichen Sie uns rund um die Uhr unter der Rufnummer 0800 / 910 03 00. Unter http://avm.de/produkte/fritzos/fritzos-650/ finden Sie aktuelle Informationen und nützliche Hinweise.


Freundliche Grüße
Ihr Unitymedia Business Team
 
ui, was ist da passiert?
ein neuer Abteilungsleiter?
na dann warten mir mal den 06.09. ab
 
also die 6360 von KabelDeutschland meines Vaters hat immer noch die FW 06.06. Habe die Box schon zigmal stromlos gemacht, nur genützt hat es nichts......
 
Das deckt sich ja dann mit den "innerfamiliären" Erkenntnissen zur OS-Version der 6360 bei KDG, die ich an anderer Stelle schon geschildert habe (für Leipzig Südost).

Es war also doch kein Einzelfall und lag auch nicht an meiner Modifikation der Firmware (inzwischen gibt es dort einen anderen Router) ... das wirft dann wieder die alte Frage auf, welche CM-Zertifikate denn diese alten 6360 bei KDG wohl verwenden, sofern BPI+/SEC zum Einsatz kommt.
 
Heute Nacht hat KDG auf die 6360 meines Vaters endlich die 6.50 draufgebügelt.
 

Statistik des Forums

Themen
246,284
Beiträge
2,249,437
Mitglieder
373,876
Neuestes Mitglied
ungworld
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.