Loxone Kontenschutz ist eine Einladung für DOS Attacken?

[Grestorn]

Ich programmiere gerade ein Plugin für den Loxberry und im Rahmen dessen, musste ich das PW meines Hauptkontos in meiner Loxone Installation ändern (aus Sicherheit, denn das alte PW war u.U. kompromittiert).

Ok, das Ändern war nicht das Problem. Aber es gibt diverse Geräte (Tablets, andere PCs, mein Handy...) die noch das alte PW hatten. Ich habe die meisten geändert, aber wohl eines übersehen. Ggf. hat auch mein Plugin Mist gebaut. Jedenfalls war mein Konto auf einmal gesperrt. Erst für 120s, und als ich mich dann anmelden wollte (ziemlich sicher mit dem richtigen, neuen PW) auf einmal für 15 Minuten.

Ich bin mir ziemlich sicher, dass, wenn ich es nochmal probiere, der Lockout weiter verlängert wird. Und offensichtlich nicht nur von einem Client aus, sondern von ALLEN Clients aus, egal von welcher IP-Adresse.

Leute, das ist doch der perfekte DOS-Angriff! So kann ich jeden aus seinem Konto aussperren. Ich muss nur immer wieder einen Anmeldeversuch mit einem falschen PW wiederholen, bis das Konto endgültig gesperrt ist.

So kann ich JEDEN legitimen Nutzer aussperren.

Hat Loxone nicht mal eine Sekunde darüber nachgedacht, was sie da eigentlich treiben?!

[derhoeppi]

Moin,
das Anliegen verstehe ich nur teilweise. Bei vielen Diensten ohne cleveres MFA (bei denen z.B. der zweite Faktor zuerst abgefragt wird) ist das der Fall. Loxone verhält sich hier wie viele andere Dienste auch. Um dieses Problem zu lösen hat man für den Notfall ebenso einen Notfallnutzer um beispielsweise den betroffenen Account zu sperren oder zumindest an die Logs zu kommen.
Viele 0815 Nutzer haben solche Vorkehrungen nicht und geben ihren Miniserver im Internet ohne VPN frei. Was sollen diese Nutzer dann zur Lösung unternehmen? Klar könnte Loxone eine Prüfung einbauen, ob Internet vorhanden ist, aber so wie in deinem Fall bist du ja scheinbar Innentäter. Was ich nicht weiß, ob Loxone bei einem MS Neustart automatisch den Account aktiviert.

[Grestorn]

Ich kenne keinen anderen Dienst, der derart aggressiv ist. Außerdem scheint die Implementierung einen Bug zu haben.

Folgendes ist passiert:

Ich habe das PW meines Hauptkontos geändert. Ich habe versucht, gleichzeitig alle anderen Clients (Tablets, Handys usw.) sofort zu ändern. Zuerst scheint alles funktioniert zu haben.

Dann kam beim Anmelden plötzlich die Meldung, es seien zu viele Fehlversuche und ich solle 120 Sekunden warten. Ich hatte aber definitiv das richtige PW verwendet (aus dem PW-Manager kopiert, ja, das NEUE PW).

Ok, ich warte die 120 Sekunden. Selber Effekt, nur dass es jetzt noch eine längere Wartezeit war.

Am Ende waren es dann immer 10 Minuten Wartezeit, nach der ich mich aber IMMER noch nicht anmelden konnte. Immer mit derselben Meldung und einer immer wieder rausgezögerten Wartezeit.

Und als Anmerkung: Ich rede vom LOKALEN Zugriff! Ohne irgendwelchen Remote-Kram (das habe ich absichtlich deaktiviert, wenn ich remote an den Miniserver will, dann nur über einen eigenen VPN-Tunnel).

Am Ende musste ich eine Backup-SD-Karte nutzen, um den Miniserver damit neu zu starten. Ich konnte mich dann mit dem alten PW anmelden (logisch, war ja ein altes Backup). Als Erstes habe ich sofort den Stand der Config (also den aktuellen Stand mit dem neuen PW) eingespielt. Nach dem Reboot des Miniservers konnte ich mich ganz normal mit dem NEUEN PW anmelden (logisch, war ja Teil der wieder aktualisierten Config).

Und von da an funktioniert es auch sauber, alle Clients konnten sich sauber anmelden (überall war ja das neue PW hinterlegt). Ohne dass ich noch was tun musste. Da ich keinen Bock hatte, die Statistik zu verlieren, hatte ich dann testweise mit der ursprünglichen SD gebootet - und siehe da, auf einmal konnte ich mich auch mit der anmelden. Ohne irgendwo nochmal das PW geändert zu haben!

Wenn das kein Bug ist!

Um auf Deine Nachfrage einzugehen, @derhoeppi: Nein, das ist nicht normal. Und es hatten ja schon genügend Leute Probleme damit. Man verlängert die Wartezeit eines interaktiven Logons nicht progressiv. Es reicht normal eine Wartezeit von 10-20 Sekunden, um jeden Brute-Force-Angriff auszuhebeln. Aber Wartezeiten von 10 Minuten sind insane, und wenn dann offenbar auch noch ein Bug in der Implementierung dabei ist, ist es erst recht unakzeptabel.

Ich meine, wie viele Leute sperren sich so aus ihrer Haussteuerung aus und finden keinen Weg mehr rein? Nicht jeder weiß sich dann zu helfen!

(P.S.: Ja, selber Schuld, dass ich keinen Zweit-Account mit Admin-Rechten zur Hand hatte.) Wird mir auch eine Lehre sein!)

[bbi]

Danke für den Hinweis bzgl. Zweit-Account mit Admin Rechten ....

[baumschubser171]

Nur mal so…

AVM macht das bei Fritzboxen seit Jahren so.
Beginnt mit 4 Sekunden und verdoppelt sich mit jeder weiteren Falscheingabe.

Ist also nichts mit „Das macht man nicht“.

Und wenn Du nach der Backup-Karte auch wieder die normale nutzen konntest, bleiben nur zwei Möglichkeiten:
1. doch ein falsches PW eingegeben (Schreibfehler?)
2. Miniserver hatte sich verschluckt, war „nur“ Reboot notwendig

[Prof.Mobilux]

Sehe ich auch so. Viel Lärm um nichts.

Man kann auch nicht "jeden" aus seinem Konto aussperren. Dazu muss man nämlich den Kontonamen wissen. Wer da "admin" benutzt, dem ist dann auch nicht mehr zu helfen.

Und den gleichen Admin- und Configuser auf jedem Tablet zu verwenden ist jetzt auch nicht die allerbeste Idee.

[Grestorn]

Wie gesagt, DA IST EIN BUG DRIN.

Ich habe NICHT DAS FALSCHE PW EINGEGEBEN! Aber wenn man einmal in dem Zyklus ist, kommt man nicht mehr raus, egal ob man das richtige oder falsche PW angibt.

Und wie ihr den vielen Postings diesbezüglich entnehmen könnt, BIN ICH AUCH NICHT DER ERSTE, dem das passiert.

Mannomann.

Ihr müsst nicht gleich jeden für einen Idioten halten. Ihr könnt mir inzwischen durchaus glauben, dass ich nicht ganz neben der Spur bin.

[nufke]

Very interesting finding and thanks for sharing!

I actually noticed a similar behavior some months ago while developing my own app and LoxBerry plugin(s). I was not able to trace down to the root cause of all this, but I got the impression that the lock-out was caused by another client which is continuously trying to connect to the Miniserver. So this means if you try to connect with the new password, and another client/app is trying to connect (multiple times) with the old password, then the lock-out happens. Not because you used the new password, but because another client already caused the lock-out "in the background". In this context, we need to check all clients, meaning the mobile app, WebApp or even LoxBerry itself. On a Gen1 system, we can run wireshark to see who tries to connect multiple times (since establishing the connection for Gen1 is using non-secure protocols such as WS or HTTP).
Just my 2ct.

[Dimon]

habe den gleichen Scheiß tatsächlich, finde keine Lösung