Ich würde mich eigentlich überhaupt nicht als "Hacker" bezeichnen, für meine Begriffe gehören, um der eigentlichen Bedeutung dieser bezeichnung gerecht zu werden, noch deutlich mehr Kenntnisse dazu, als die, über die ich bis jetzt verfüge. Das bedeutet aber nicht, dass ich mich nur theoretisch mit IT-Security beschäftige. Mein Lieblingshobby sind SQL-Injections und zuweilen auch Local oder Remote File Inclusions (LFI/RFI), und dieses Hobby praktiziere ich auch durchaus oft und regelmäßig, allerdings ohne dabei irgendwelchen Schaden anzurichten oder gar Defacements oder ähnliche Kacke zu veranstalten.
In den meisten Fällen melde ich gefunde Sicherheitslücken auch, aber es gibt auch Härtefälle, wo ich das Aufgegeben habe, weil man sich auch nach der 3., 4., oder 5. (fast identischen) gefundenen Sicherheitslücke offenbar noch immer zu Schade ist, gutgemeinte Ratschläge in die Tat umzusetzen.
Beispielsweise gibt es in den BeNeLux-Staaten eine Kinokette, auf deren Seiten ich schon über ein halbes dutzend Sicherheitslücken entdeckt habe. Nach der 2. Lücke hat man sich wenigstens mal bequemt, den Safemode von PHP zu aktivieren, aber das grundlegende Problem, dass SQL-Statements generell überhaupt nicht aus den Benutzereingaben herausgefiltert wurden, obwohl es eigens dafür fix und fertige PHP-Befehle gibt.
Die Reaktion auf meine Meldungen war jedes mal, dass in genau dem Script, das ich gemeldet hatte, nur den jeweiligen SQL-Query dahingehend umgeändert, dass die eine Variable, die ich gemeldet hatte, in einer sicheren Art und Weise benutzt hat (Anstatt die Werte von Variablen, die bei normaler Benutzung der Webseite numerische Werte enthalten, weiterhin als Zahlen zu behandeln (diese unsichere Praxis macht die SQL-Injection erst möglich) hat man dann zumindest diese eine Variable im Query fortan als String behandelt. Kurze Zeit nachdem der Fehler behoben war, hatte ich dann schon wieder die nächste Variable im gleichen Script (und auch im gleichen SQL-Query in diesem Script!) gefunden, die für exakt die gleiche Sicherheitslücke anfällig war).
Zwischenzeitlich scheinen sie diese mit heißer Nadel gestickten Bugfixes auch wieder entfernt und durch eine halbherzige Filterung ersetzt zu haben (Die jedoch nur teilweise funktioniert und damit deutlich unsicherer ist als die ursprünglichen Bugfixes. Ich vermute mal, das Script bricht jetzt schlicht mit ner Fehlermeldung ab, wenn Leerzeichen in einer der Benutzereingaben gefunden wird, aber bin zu faul, das jetzt durchzutesten. Wenn meine Vermutung stimmt, und sie wirklich nur nach Leerzeichen suchen, hilft das freilicht überhaupt nicht gegen SQL-Injections.). Prinizpiell scheint die Seite jedoch wieder Injection-anfällig zu sein.
Seit ich nach der 2. Bugmeldung mal höflich nachgefragt hatte, ob vielleicht Kinotickets als kleine Entschädigung für meinen Aufwand drin wären, antwortet mir der Verein überhaupt nicht mehr und stellt sich tot (Die mit Abstand bedeutendste Kinokette im BeNeLux-Raum kann es sich nicht mehr leisten, Freitickets auszugeben. Da muss es *wirklich* scheisse um die Wirtschaft bestellt sein...).
Wenn man erstmal auf ein paar größeren Internetseiten Lücken gefunden hat, und dabei auf Dinge stößt stößt, für die der Entwickler der entsprechenden Webanwendung eigentlich an die Wand gestellt gehört, dann sieht man auch in Sachen Datenschutz und dem Umgang, den man selber mit seinen eigenen persönlichen Daten pflegt, die Dinge aus einer völlig anderen Perspektive. Ich habe beispielsweise binnen 1 oder 2 Monaten 2 Seiten gefunden (eine mit über 4000 angemeldeten Benutzern, die andere mit 7000-8000 angemeldeten Benutzern), wo nicht "nur" Handynummer, Telefonnummer, Geburtsdatum, volle Addresse, E-Mail-Addresse, voller bürgerlicher Name, und sogar das ungehashte Passwort im Klartext (!!!) in der Datenbank gespeichert waren, und man die Datenbank problemlos per SQL-Injection komfortabel auslesen konnte. Einmal die bereits oben erwähnte Kinokette, (4000 Benutzer, danach haben sie sämtliche Benutzeraccounts gelöscht, aber die eigentlichen Probleme nicht behoben, insbesondere das Problem mit den Klartext-Passwörtern in der Datenbank nicht), zum andern eine Jugendseite einer hiesigen Bank (da Konnte man praktischerweise auch gleich die Nummer der Bankkarte des jeweiligen Kunden aus der Datenbank auslesen).
Das sind zwar jetzt so ziemlich die spektakulärsten Fälle, die mir untergekommen sind, allerdings beschäftige ich mich auch erst seit wenigen Monaten mit SQL-Injections. Auf der Internetseite von so manchem deutschen Unternehmen (vom Autohaus bis zum Addressdatenhändler) habe ich allerdings auch schon *sehr* bedenkliche Lücken gefunden (z.B. Download-Scripte, über die man problemlos den Quellcode der Scripte auf dem Server runterladen konnte, inklusive enthaltener Zugangsdaten für diverse Datenbankserver u.ä. Das einzige, was da noch vor dem GAU geschützt hat, war die Firewall des Datenbankservers).
Natürlich beschäftige ich mich auch mit theoretischen Angriffsszenarien (ist ja hier im Forum oft genug mitzulesen
). Wenn man sich etwas mit heute aktuellen Sicherheitsproblemen auseinandersetzt, und das in Relation zu der Situation ein paar Jahre früher betrachtet, als man anfing, die Algorithmen, Methoden und Praktiken einzusetzen, die uns sicherheitsmäßig heute Probleme bereiten, dann betrachtet man vieles anders.
Beispielsweise ist MD5 mittlerweile ein *völlig* unsicherer Hash geworden. Mit einer 100€-Grafikkarte kann man alle möglichen 5- oder 6-stelligen Passwörter (weiss leider nicht mehr, ob es 5 oder 6 waren) (Groß- und Kleinschreibung, Zahlen und Sonderzeichen inbegriffen, wir reden hier von Bruteforce, und nicht von einer Dictionary-Attacke!) in 20 Minuten durchprobieren. Mit derselben Hardware kann man alles, was noch einer Stelle mehr hat, in ca 20 Stunden durchprobieren. Mit einem Quad-SLI-System mit 4 Geforce GTX-495 sind da natürlich noch ganz andere Dimensionen drin, je nach Anwendung kann sich für einen Kriminellen die Investition in diese Hardware auch durchaus lohnen.
//EDIT: 1 Abschnitt nach unten verschoben, und den MD5-Abschnitt hinzugefügt.
Würde mich glatt mal interessieren,
