vBulletin 3.8.6 verfügbar - Feedback

[cellarius]

Und so ein Fehler soll sich durch die Änderung einer einzelnen Tabelle ändern lassen?

Genau genommen wird keine Tabelle geändert, sondern nur ein Eintrag aus der Phrasentabelle gelöscht. Aber wie auch immer, die Antwort auf Deine Frage lautet: ja.

[Onur]

@Bachsau
man lösche die anzuzeigende Phrase und gut ist

schau dir halt das Patchpaket an, da sieht man ja schön was passiert

das Problem war/ist ja auch primär das jemand ein Skript geschrieben hat, das automatisiert sämtliche über $SUMA auffindbare vBs nach eben diesen Daten abgeklappert hat und ja vermutlich auch geloggt

hier ist eben davon auszugehen das man versuchen wird entweder ins vB einzudringen, oder noch wahrscheinlicher, ebenso automatisiert die DBs abzuernten und die vorhandenen Nutzerdaten zu verkaufen

[Bachsau]

Ja, okay.

Hab mir gerade mal ein Backup lokal installiert, weil ich einfach zu neugierig war.
Versteh jetzt auch das Problem... Was ja mal echt krass ist. Wurde das testweise eingefügt, und dann einfach vergessen? o_O Sowas darf bei 'nem kommerziellen Produkt eigentlich nicht passiert. Die Phrase ist ja erst in 3.8.6. reingekommen...

[jazde86]

Was ist an dieser einen Phrase so gefährlich und was steht in dieser Phrase drin?

Heißt ich kann mir da 'ne falsche Phrase einbauen und dann liegen meine Zugangsdaten offen herum?!? Verstehe das gerade nicht wirklich. Eine Phrase war für mich bisher reiner Text der irgendwo anstelle einer Variable eingesetzt wird.

[kevin2007]

Das Phrase hat auf die (MySQL Verbindungs-)Variablen in der vBulletin config.php zugegriffen (bzw. hat diese direkt angesprochen) und dann wiedergeben.

[Bachsau]

[...]

Nur so nebenbei: Was da passiert ist, ist schon grob fahrlässig. Wenn's dadurch irgendwo richtig Ärger gibt, dürfte sich Adduco wahrscheinlich auf Haftung einstellen.

@jazde86:
Es ist auch reiner Text, mit möglichen weiteren Variablen. Wenn ma es also bewusst drauf anlegt, kann man damit Interna offenlegen. Ich hab's auch erst nicht verstanden, weil es einfach so behämmert ist, dass ich's nicht für Möglich gehalten hätte, dass soetwas einfach mal "passieren" kann.

Die Phrase heißt "database_ingo". Inhalt:

Datenbank-Name: {$vbulletin->config['Database']['dbname']}<br />
Datenbank-Server: {$vbulletin->config['MasterServer']['servername']}<br />
Datenbank-Port: {$vbulletin->config['MasterServer']['port']}<br />
Datenbank-Benutzername: {$vbulletin->config['MasterServer']['username']}<br />
Datenbank-Kennwort: {$vbulletin->config['MasterServer']['password']}

[LoC]

Ich habe erst durch Heise mitbekommen, was genau PL1 gepatcht hat und bin jetzt wirklich schockiert, dass solche eine große Lücke in einer Software wie vBulletin vorkommt.

Noch viel schlimmer finde ich, dass hier nicht genauer offen gelegt wurde, wie gefährlich die Lücke ist - so habe ich nicht sofort nach der Veröffentlichung des PL1 aktualisiert sondern mir noch einige Stunden Zeit gelassen. Wäre ich mir über die Schwere klar gewesen, hätte ich sicherlich meinen TV-Marathon unterbrochen.

[cellarius]

Ein Sicherheitspatch ist ein Sicherheitspatch ist ein Sicherheitspatch. Man kann IB sicher einiges vorwerfen in dieser Sache - dass Du Dir aber noch einige Stunden Zeit lässt, einen Sicherheitspatch einzuspielen, das doch eher nicht.

[RolandCP]

Seit wann ist diese Phrase denn drin?

[cellarius]

3.8.6

[Phobos]

Hallo!

Ich bin wirklich entäuscht über dieses unverzeihlichen Fehler.

Da ich drei Tage lang nicht online sein konnte, stand in dieser Zeit mein Forum mit heruntergelassenen Hosen im Netz.
Als ich heute Mittag meine eMail checkte, musste ich sogar festellen, dass mir jemand mit russischer eMail-Adresse einen freundlichen Hinweis incl. meiner SQL-Benutzerdaten über das Kontaktformular geschickt hat.

Ich möchte daher vom vB-Team wissen, welche Auswirkungen dieser Sicherheitskrater für mich konkret hat!
Was konnte man innerhalb der zwei Tage mit meiner Datenbank anstellen? Herunterladen? Auslesen? Einen Code einfügen? Sie war übrigens nicht für den externen Zugriff zugelassen.
Ich bitte um Antwort!

[cellarius]

Sie war übrigens nicht für den externen Zugriff zugelassen.

Dann gar nichts. Ändere das Datenbankpasswort, und gut.

[rellek]

Dann gar nichts.

Es sei denn auf den Server befindet sich ein phpMyAdmin, das mit MySQL-Zugangsdaten zufrieden ist.

(Deshalb ja, PW ändern verhindert das)

[cellarius]

Ein phpMyAdmin ohne .htaccess-Schutz? Wer sowas macht, sollte weder Server noch Internetseiten betreiben.

[rellek]

Du hattest lang nicht mehr mit einem (Massen-) Hoster zu tun, kann das sein?

[cellarius]

Du hattest lang nicht mehr mit einem (Massen-) Hoster zu tun, kann das sein?

Das ist richtig. Aber bei denen, bei denn ich früher war, gab es auch kein phpMyAdmin, das einfach über den Webspace ohne jeden zusätzlichen Passwortschutz hätte aufgerufen werden können.

[rellek]

Die Regel ist, dass irgendwo beim Hoster ein phpMyAdmin installiert ist (meist domain.tld/mysqladmin oder sowas) und da kann man sich mit MySQL-User und -Passwort anmelden. Das kenne ich mindestens von Domainfactory und all-inkl.

Bei _einer_ zentralen PMA-Installation auf so einem shared Server ist das anders auch nicht wirklich sinnvoll hinzubekommen - es sei denn man machts wie Hetzner, dort hängt das PMA-Login zusätzlich noch an der Session für die Kundenverwaltung. Dafür muss man PMA aber umbauen, das macht afaik so gut wie niemand. Was so wichtig auch nicht ist, weil nicht viele Web-Softwares ihre MySQL-Daten ausplaudern.

[Phobos]

Wie ich gerade festgestellt habe, kommt man auch bei HostEurope ohne Probleme zum phpMyAdmin, wo man dann mit den im Forum angezeigten Zugangsdaten wunderbar an die Datenbank drankommt...

Werden solche Zugriffe geloggt? Kann man die im Serverlog einsehen? Wohl eher nicht, oder?

[Bachsau]

Normal schon. Und wenn du ganz lieb bitte bitte sagst, schaut dein Hoster eventuell für dich nach... falls er kundenfreundlich ist.

Die Regel ist, dass irgendwo beim Hoster ein phpMyAdmin installiert ist [...] und da kann man sich mit MySQL-User und -Passwort anmelden

Jupp. Ist bei meinem leider auch so. Normal legen die sogar noch db.* subdomains unter der eigenen Domain an. Einen Wahnsinn, den ich bei mir schon verhindert habe. Zum Glück sehr guter Support.