Hackerangriff auf Losedepot.de

[Kriegstreiber]

**Losedepot.de bleibt nach einem Hackangriff bis ca. 21 Uhr geschlossen! Ein User hat sich Zugriff auf die Datenbank erhackt. Vermutlich über eine Sicherheitslücke, und Losedepot.de um 350 Mio Lose erleichtert. Eure Kontostände sind nicht betroffen! Da wir aber noch auswerten müssen, wie genau er vorgegangen ist, werten wir das Serverprotokoll vollständig aus, um
A - Die Sicherheitslücke zu schließen.
B - Eure Lose zu schützen!
c - Werden wir mit einer Strafanzeige reagieren, da wir uns sowas nicht mehr gefallen lassen.
Die Klamm.de Administratoren wurden bereits benachrichtigt, diese Lose sicherzustellen!

Wir bitten um euer Verständniss.**

Ich Frage mich ganz ehrlich, wie sollche Sicherheitslücken entstehen können und was kann ich machen, um sollches Vorzubeugen?

Hab gehört, das VMS allgemein n bisschen unsicher sein soll und deswegen auch schon nen Proger mein Script prüfen lassen, bevor ich irgendwan in den nächsten Tagen mit meiner Seite online gehe.

Gibt es noch irgendwelche zusätzlichen goldenen Regeln, damit mir soetwas nicht passieren kann, was Losedepot heute passiert ist?

 

[MiD]

Sichere AGB schreiben, überprüfen/lassen, jeden veränderung im Script, Slots etc. überprüfen/lassen

 

[bartman]

• Deinen Server sicher halten, wenn du shared hosting hast faellt das weg.
• Keine leicht erratbaren Passwoerter fuer _irgendwas_ nehmen. (Schwere Passwoerter muessen nicht unbedingt alphanumerisch sein, hauptsache, sie sind lang!)
• Sicher sein, dass die Person die dein VMS durchgeguckt hat sich auch _wirklich_ auskennt, am besten noch jemand anderes konsultieren.

Soweit die Grundregeln, das folgende stelle ich mir unter "optimal" vor, wenn auch nicht leicht zu erreichen und je nach Format der Seite nicht unbedingt "noetig".

• Heuristiken im Script, meiner Meinung nach das A und O. Ein neuer User der direkt mit hohen Summen agiert ist potentiell "gefaehrlich", jemand der ungeheuerlich viele Auszahlungen/sehr hohe Auszahlungen macht ist "gefaehrlich", genauso jemand der viele Jackpots gewinnt. Natuerlich kann man die "Verurteilung" nicht automatisieren, aber wenn man sowas merkt und dann eine Warnung an den Betreiber rausgibt, kann der nachpruefen.
• Statistiken, Statistiken, Statistiken. Losevolumen, Auszahlungen, Einzahlungen, Aktivitaet, ... alles Sachen, durch die man auf potentielle Fehler aufmerksam wird. (Gewinnen die Leute durchschnittlich mehr als sie einzahlen? Wahrscheinlich ist dann irgendeine Berechnung nicht ganz korrekt.)
• Traue keinem, kauf nicht leichtsinnig Scripte, auch wenn sie von "namenhaften" Programmierern stammen. Lass sie von wem durchgucken, der wirklich Ahnung hat - jeder kann was uebersehen. Teste sie bevor sie live geschaltet werden! Nichts ist schlimmer, als ein cachefreier Slot der nicht ausreichend getestet wurde und mehr wirft als er sollte.

 

[ice-breaker]

muss bartmann zustimmen und der wichtigste Punkt ist JEGLICHEN user-input zu validieren ich habe wirklich noch kein script hier gesehen, dass dies macht, und da es dann dauerhaft zu Hacks etc kommt ist kein Wunder.

 

[david_007]

Alle Client Eingaben zu validieren wird so ziehmlich das wichtigste sein, im VMS Basisscript gibt es eine Eingaben(eine habe ich zumindest gefunden) die nicht validiert wird, ich habe diese an die Admins von designerscripte.net geschickt doch getan hat sich leider nichts.

Nimm zum validieren

mysql_real_escape_string()

und kein

addslashes()

addslashes ist unsicher.

Setzte bei MySQL Abragen immer ein: ' , ohne ' bringt das validieren nichts.
Also

UPDATE `tabelle` SET `spalte` = ''.mysql_real_escape_string($_POST['anzahl']).'' LIMIT 1

 

[ice-breaker]

david,
validieren != escapen

einfach alles sinnlos zu escapen ist totaler quatsch, die validierung muss schon rein als IntrusionDetection escapen sollte man dann immernoch.
Und dein Beispiel ist totaler Humbug
Warum sollte man MySQL einen Integer als String übergeben?
Ne ordentliche IntrusionDetection und es kommt gar net erst soweit, dass nen Integer Wert nen String übergeben bekommt. nebenbei ist meine mysql_queryf dann noch besser, weil es erst gar nicht dazu kommt, dass du nen Integer in der Datenbank mit nem String füttern könntest (was bei dir geht, viel Spaß, SQLInjections gehen immernoch ;-) )

Edit: die ganzen Begriffe sagt man nunmal auf Englisch und da kommt nix deutes hin^^ SQLInjection oder IntrusionDetection übersetzen? neee ^^

 

[sonobene]

Naja bei wievielen Seiten passiert sowas "wirklich"?

Viele verwenden es nur als Ausrede, dass sie mit dem Userguthaben abhaun können( Lose sowie auch € Seiten!)

Aber sieht man dass sie bemüht sind um ihre Mitglieder und ihr Projekt!

 

[MiD]

Naja der der den Bug versehentlich oder gehackt hat oder mit absicht den Bug ausgenutzt hat, wurde ja anscheinend gefunden

 

[bartman]

Naja bei wievielen Seiten passiert sowas "wirklich"?

Jede Seite bei der sowas passiert ist eine zuviel