RootForum Community

Wenn ein User mit "Passwort vergessen?" sein Passwort zurück setzt, bekommt er nicht etwa ein sicheres Passwort zugesendet, sonder eine Email mit folgendem Inhalt

Sehr geehrte(r) **********,
Ihr Passwort kann nicht versendet werden, da es in verschlüsselter Form gespeichert ist.

Um ein neues Passwort festzulegen, folgen Sie bitte diesem Link: https://***********.ch:8443/ch_pass_by_secret.php?secret=f597265554d70ddb5ed3783762049383

Damit kann ein unsicheres Passwort wie '123456' gesetzt werden - das trotz aktiviertem extended security modus, welcher innerhalb des Panels einen dazu zwingt, ein sicheres Passwort zu verwenden.

Wo siehst Du hier eine Sicherheitslücke?

Unsichere Passworte an einer Stelle erlauben, oder ein unauthorizierter Zugriff für jeden, ist schon ein Unterschied.

Das ist meinetwegen ein Bug aber noch keine Sicherheitslücke wegen der man unnötig Alarm schlägt.

ddm3ve wrote:Wo siehst Du hier eine Sicherheitslücke?

Ohne Plesk zu kennen, verstehe ich es so:
Innerhalb von Plesk kann man festlegen, dass Passworte gewissen Regeln (Gross/Kleinbuchstaben, Ziffern, Sonderzeichen, Länge) unterliegen müssen. Bei der Passwort-vergessen Funktion werden diese Regeln allerdings nicht berücksichtigt und somit lassen sich darüber "verbotene" Passworte setzen.

Das würde ich schon als Sicherheitslücke bezeichnen, aber nicht als schwerwiegende.

Das habe ich schon auch so verstanden. Aber das ist meines Erachtens erstmal nur ein Bug.

Denn Perse, hindert es den Benutzer nicht davor, sichere Passworte zu nutzen und ein Angreifer kann diese Lücke nicht direkt ausnutzen.
Wurden Accounts z.B. migriert bzw, und/oder diese Option für sichere Passworte erst später gesetzt, zwingt es niemanden dazu, die Passworte zu ändern. Dito Restore aus einem Backup.

Also trotz dieser Option könnten unsichere Passworte vorhanden sein.

BTW: Was wiki unter sicherheitslücke versteht.
http://de.wikipedia.org/wiki/Sicherheit ... oftware%29

Eine Sicherheitslücke stellt eine Bedrohung für die Sicherheit eines Computersystems dar. Es besteht das Risiko dass die Sicherheitslücke ausgenutzt und das betroffene Computersystem kompromittiert werden kann.

Nur in dem Fall, ist diese Option kein Garant für sichere Passworte und unsichere Passworte weden auch abgefragt, sind in einer Brutforceattacke jedoch schneller und einfacher zu erraten.
Anders hierzu der Bug bei Mysql der es einem erlaubte sich als root an zu melden ohne das Passwort zu kennen oder zu erraten.

Man darf aber gern auf Grund solcher "Bugs" und auch Vergangener echter Lücken/ Löcher, die Sicherheit des Produktes hinterfragen und bezweifeln.

Man darf aber gern auf Grund solcher "Bugs" und auch Vergangener echter Lücken/ Löcher, die Sicherheit des Produktes hinterfragen und bezweifeln

Ist wohl so. Andererseits kenne ich ein paar unserer Benutzer - was nützen die besten Passwörter, wenn einer zu Hause vor einem verseuchten Rechner sitzt.

Vor der "Dummheit" der Benutzer ist man leider nie gefeit.
Was ich aber meinte, waren Löcher, die Plesk auf einem anderen Level ausnutzen lies.

-> Also nicht nur der Zugang zum Kundensystem sondern den ganzen Host übernehmen.

Also nicht nur der Zugang zum Kundensystem sondern den ganzen Host übernehmen

Ja da haben die Buben bei Parallels in den letzten Monaten fleissig Löcher gestopft (Klartextpasswort, Mysql). Nur weiss kein Mensch, was da noch zum Vorschein kommen kann.

Wir hatten in der Vergangenheit mehrmals kompromitierte Domains. Daraus folgere ich, dass ein Angreifer nicht mehr unbedingt den ganzen Server hopps nehmen muss, ausser er will irgendwelche ilegale Dienste laufen lassen, was - notabene auch wieder von einer kompromitierten Webseite aus möglich ist.

Immerhin ist PLESK ein millionenfach verbreitetes Admininterface mit einer eigenen Community, wo auch immer wieder die neuesten Exploits kommuniziert werden. Im Moment scheint es ruhig zu sein.

danu wrote: Immerhin ist PLESK ein millionenfach verbreitetes Admininterface mit einer eigenen Community, wo auch immer wieder die neuesten Exploits kommuniziert werden. Im Moment scheint es ruhig zu sein.

Also die wenigstens grossen Provider, die Ihre Rootserver mit dem Zeug "aufwerten", nutzen es selber für die eigene Infrastruktur / Hostingkunden.

Was man Plesk im Bezug auf Mysql vorwerfen kann, ist, dass sie mysql aufs Netzwerk horchen lassen.
Es wäre besser, skip-networking wäre gesetzt.

Ein User, der das nicht geregelt bekommt, für den ist es wohl auch besser, wenn es wirklich deaktiviert ist.

Solange MySQL auf 127.0.0.1 gebunden ist, ist das auch kein Problem.

Das ist es aber in der Regel nicht.

Btw. Wenn ich den Bug noch richtig im Kopf habe, griff er auf Netzwerkverbindungen und nicht auf Sockets.

Ja, aber es war ein Bug in MySQL und nicht in Plesk, daher war Parallels ausnahmsweise mal unschuldig.

Hab auch nichts anderes behauptet.
Parallels könnte generell aber Netzwerkverbindungen zur Mysql pauschal erstmal verbieten. Schliesslich ist per default auch der Port zu.

Btw. ist eine Lokale Netzwerkverbindung im Vergleich zur socket Verbindung deutlich inperfomant und ein Listen auf 127.0.0.1 nur in wirklich wenige exotischen Fällen notwendig.
Stellt sich ebenfalls die Frage ob Parallels den Zugriff auch tatsächlich auf host beschränkt also im lokalen Fall user@localhost oder meinetwegen auch user@127.0.0.1#ich vermut jedoch, dass weiterhin user@% gesetzt wird.

vermut jedoch, dass weiterhin user@% gesetzt wird.

So ist es. Habe deshalb sämtliche User nachträglich auf localhost gesetzt.