Hoster OVH gehackt, Kunden in ganz Europa betroffen
von caschy | 23 Kommentare
Der nach eigenen Angaben 400.000 Kunden starke Hoster OVH ist Opfer eines Hacks geworden, in dessen Zuge die Datenbank der Kunden in Europa abgerufen wurde. Die Datenbank der Kunden in Europa enthält die persönlichen Angaben der Kunden: Name, Vorname, Kundenkennung, Adresse, Stadt, Land, Telefon, Fax und das verschlüsselte Passwort. Die Verschlüsselung des Passworts erfolgt mit „salted“ SHA512, um Brute Force Angriffe zu verhindern.
Es erfordert umfangreiche technische Ressourcen, das Passwort im Klartext herauszufinden. Aber es wäre möglich, wie man seitens OVH mitteilt. Man empfiehlt, das Passwort umgehend zu ändern. Informationen zu Kreditkarten werden nicht bei OVH gespeichert, diese wurden demzufolge weder abgerufen noch kopiert.
[werbung]
Ebenfalls gelang es den Hackern, sich Zugang zum Installationssystem der Server in Québec zu verschaffen. Dies eröffnet ein weiteres Problem. Wenn ein Kunde den SSH Key nicht von seinem Server entfernt hat bestand die Möglichkeit, dass der Hacker sich vom System aus mit dem Server verbindet, um das in der .p Datei gespeicherte Passwort auszulesen.
Der SSH Key kann nicht von einem anderen Server aus verwendet werden, sondern ausschliesslich vom Backoffice in Québec aus. Bei den Kunden, die den SSH Key nicht entfernt und das root-Passwort nicht geändert haben, hat man seitens OVH unverzüglich das Passwort der Server im Rechenzentrum BHS geändert, um diese Möglichkeit zu unterbinden.
(Bildquelle: Shutterstock, Hacker typing on a laptop with binary code in background)
Wird geladen ...
Traurig, dass ich das hier erfahren muss und nicht von OVH selbst per E-Mail informiert werde.
traurig keine Frage. Bei Web.de scheint auch was am Laufen zu sein. Wöchentlich sperren die mein Konto zur Sicherheit und ich darf mir noch was längeres ausdenken. Kotzt das an!
„umfangreiche technische Ressourcen“ ein paar Cent für ein wenig Rechenzeit in der AmazonCloud und gut ists^^
@caschy: „Die Verschlüsselung des Passworts erfolgt mit “salted” SHA512, um Brute Force Angriffe zu verhindern.“
Egal wie gut das Passwort verschlüsselt ist, Brute-Force-Angriffe kann man so aber ganz sicher nicht verhindern, da bei solchen Angriffen einfach jedes mögliche Passwort durchprobiert wird. Hier ist allein die Länge und Komplexität des Passworts ausschlaggebend dafür, wie lange ein solcher Angriff dauert. 😉
Die Nachricht ist auch im OVH-Forum:
http://forum.ovh.de/showthread.php?p=71406#post71406
Also ein salted Hash mit SHA512 ist immerhin einigermaßen state of the art. Da braucht man schon mehr als ein paar Cent für die Amazon Cloud. Allerdings lohnt es sich das bei 400.000 Datensätzen eines Hosters auch, wenn über die Passwörter theoretisch ganze Server gekapert werden können.
Naja, für einen Brute-Force-Angriff brauche ich aber nicht vorher die Kundendaten hacken.
Heiko
@Heiko Bernhörster, doch natürlich. Mit einer offline verfügbaren DB der Passwörter gibt’s keine Zugriffslimitierung, kannst also so schnell bruteforcen wie’s die Kiste hergibt. Live auf einem Online-System macht’s keinen Sinn, da wird in der Regel nach so und so vielen Fehlversuchen die Login-Rate gedrosselt.
Eventuell geht es bei solchen Attacken auch schlicht um Datensätze mit Adresse u. Telefon. Da meist auch ne Domain im Spiel ist sind dann diese Daten quasi auch auf Aktualität u. Gültigkeit verifiziert, solche Datensätze lassen sich natürlich zu Geld machen.
@Kizune Damit ist eigentlich gemeint die Angriffe zu erschweren. Durch Salt und SHA512 werden Rainbowtables nutzlos und man müsste jedes Accountpasswort manuell Bruteforcen. Deshalb ist die „Verschlüsselung“ – eigentlich ist es ja eine Hash-Funktion – mehr oder weniger schlecht knackbar. Also vermutlich wird sich da keiner wirklich die Mühe machen und die Passwörter rekonstruieren, sondern eher die Adressen und den direkten Zugang über das Installationssystem nutzen.
Geil… ich hab dort 2 Dedi´s und 2 Sharedhostings… die bekommen morgen einen gepfefferten Anruf!
Ich habn Kollegen der direkt gekündigt hat 😀
Eine Mail habe ich auch nicht bekommen. Immerhin haben die sich Anscheinend über ihre Verschlüsselung bereits im Vorhinein Gedanken gemacht, was man ja auch nicht von jedem Unternehmen behaupten kann.
Mail kam um 22.16Uhr an :-/
Dann doch mal Richtung Host Europe schauen, oder war da auch schon was? 😀
@Phadda: Ich bin/war sowohl bei OVH als auch bei Hosteurope Kunde. Beide Anbieter haben gute Angebote. Hosteurope bietet in meinen Augen dennoch eine bessere Qualität. Wenn es um Datengräber geht bist du natürlich bei OVH deutlich günstiger dabei. Allerdings sei an dieser Stelle auch mal gesagt, dass kein Online-Angebot vor Hackangriffen sicher ist. Und wie es bislang scheint, hat OVH doch ziemlich viel richtig gemacht. Klar, die Mails hätten eher kommen müssen. Aber ansonsten?!
@foxylion: Mir ist klar, was eigentlich gemeint ist, aber so wie der Satz da steht ist er schlicht falsch. (Ist übrigens nicht caschys Schuld, der selbe Satz steht auch in der Meldung im OVH-Forum)
it was an inside job!
Tja, sehr toll. Ich habe schon vor langer Zeit bei OVH gekündigt und dennoch war mein Login und alles weitere immer noch gespeichert und konnte mich anmelden. Nun dürfen wir uns alle über einen Missbrauch unserer Daten freuen. Anzeige gegen Unbekannt erstatten wegen Datendiebstahl, mehr kann man nicht machen. Bravo OVH. Ich bereue jegliche Zeitverschwendung eure 3 Buchstaben des Firmennamens bei google eingetippt zu haben.
Vorneweg, ich bin kein Kryptologe, dafür habe ich vor einigen Jahren eine Vorlesung über Crypto teilgenommen.
Wenn ich die Sachen noch richtig im Kopf habe (und das was ich auf Wikipedia schnell nahchgeschlagen habe, sieht stark danach aus), dann ist ein SHA-512 Hash SEHR sicher. Man muss sich dafür vor Augen halten, dass das Passwort NICHT auf dem Server gespeichert wird, sondern nur der Hashwert. Bei Eingabe des Passwortes wird dann wieder der Hash erzeugt und gegen das gespeicherte Hash validiert.
Mit Brute-Force wären bei n-Bit 2^n Möglichkeiten zu durchprobieren (wobei der Erwartungswert natürlcih bei der Hälfte liegt, also 2^(n-1) ).Allerdings reicht es ja, wenn man einen Eingabewert finden, der den selben Hashwert erzeugt. Also eine sogenannte Kollision. Dafür sagt das Geburtstagsparadoxon, das es bei n-Bits 2^(n/2) Möglichkeiten gibt.
Angewendet auf diesen Fall heißt das 2^256 Möglichkeiten, bzw. 2^255 als Erwartungswert. Als Laufzeit wird das O(2^255) geschrieben und das ist so unglaublich weit weg von allem was wir hier auf der Erde an Rechenleistung aufbringen können, dass wir selbst wenn man alle Rechner parallel laufen lassen würde, die Berechnung länger dauern würde als das Universum derzeit (geschätzte 14 Milliarden Jahre) alt ist!
Das vorberechnen von Passwort-Hshwerten in sogenannten Rainbow Tables sollte auch ausgeschlossen sein, wenn der SALT richtig genutzt wurde. Da dann der Speicherplatz aller Festplatten dieser Erde nicht ausreichen würde.
Das einzige was ich sehe, was man versuchen kann ist eine Wörterbuch Attack und schauen, ob die Nutzer vielleicht normale geläufige Wörter genutzt haben, was immer noch durch das SALT erschwert wird und außerdem genauso hättte stattfinden können OHNE die Datensätze vorher zu klauen.
VG
Sven
@Sven2: In deiner Ausführung ist noch anzumerken, dass das Finden eines anderen Eingabewertes als des Passworts der zum selben Hash auflöst für den Nutzer erst einmal gar kein Problem darstellt. Die einzige Gefahr die bei so etwas besteht (von den Adressdaten mal abgesehen) ist eben die, dass der Nutzer das selbe Passwort auch für andere Dienste verwendet hat. Hat der Angreifer nun dieses Passwort geknackt, kann er sich (wenn er auch den Nutzernamen hat) auch bei anderen Diensten in das Konto des Nutzers einloggen. Im schlimmsten Fall in dessen Mail-Konto. Findet er nun allerdings einen anderen korrekten Eingabewert als das vom Nutzer verwendete Passwort, kann er sich mit diesem noch lange nicht bei einem anderen Dienst in das Konto des Nutzers einloggen. Dazu müsste dieser andere Dienst schon exakt die selbe Art der Verschlüsselung/der Hash-Methode und den selben Salt für diesen Nutzer verwenden. Die einzige Gefahr die besteht ist die, dass er sich mit dem ermittelten Eingabewert natürlich in das OVH-Konto des Nutzers einloggen kann, sollte dieser nicht sein Passwort geändert haben. Wozu er dies allerdings noch machen sollte, nachdem er bereits viel umfangreicheren Zugriff auf das Gesamtsystem hatte, sehe ich nicht.