Wie Hacker Websites mit SQL Injection und DDoS übernehmen
Selbst wenn Sie die Ereignisse der Hacker-Gruppen Anonymous und LulzSec nur locker verfolgt haben, haben Sie wahrscheinlich schon von gehackten Websites und Diensten gehört, wie den berüchtigten Sony-Hacks. Haben Sie sich jemals gefragt, wie sie das machen??
Es gibt eine Reihe von Tools und Techniken, die diese Gruppen verwenden, und obwohl wir nicht versuchen, Ihnen ein Handbuch zu geben, um dies selbst durchzuführen, ist es nützlich zu verstehen, was los ist. Zwei der Angriffe, von denen Sie regelmäßig hören, dass sie verwendet werden, sind "(Distributed) Denial of Service" (DDoS) und "SQL Injections" (SQLI). So funktionieren sie.
Bild von xkcd
Denial of Service-Angriff
Was ist es?
Ein Angriff auf "Denial of Service" (manchmal auch als "Distributed Denial of Service" oder DDoS bezeichnet) erfolgt, wenn ein System, in diesem Fall ein Webserver, so viele Anforderungen auf einmal empfängt, dass die Serverressourcen überlastet sind und das System einfach blockiert und schließt sich. Das Ziel und das Ergebnis eines erfolgreichen DDoS-Angriffs besteht darin, dass Websites auf dem Zielserver für legitime Datenverkehrsanfragen nicht zur Verfügung stehen.
Wie funktioniert es?
Die Logistik eines DDoS-Angriffs lässt sich am besten anhand eines Beispiels erklären.
Stellen Sie sich vor, eine Million Menschen (die Angreifer) treffen sich mit dem Ziel, das Geschäft von Unternehmen X zu behindern, indem Sie ihr Callcenter herunterfahren. Die Angreifer koordinieren so, dass sie am Dienstag um 9:00 Uhr alle die Telefonnummer von Company X anrufen. Höchstwahrscheinlich wird das Telefonsystem von Company X nicht in der Lage sein, eine Million Anrufe gleichzeitig zu bearbeiten, so dass alle eingehenden Leitungen von den Angreifern gebunden werden. Das Ergebnis ist, dass legitime Kundenanrufe (d. H. Solche, die nicht die Angreifer sind) nicht durchkommen, da das Telefonsystem an die Anrufe der Angreifer gebunden ist. Unternehmen X verliert also im Wesentlichen Geschäft, weil legitime Anfragen nicht durchkommen können.
Ein DDoS-Angriff auf einen Webserver funktioniert genauso. Da es so gut wie keine Möglichkeit gibt, herauszufinden, welcher Datenverkehr von legitimen Anfragen gegen Angreifer stammt, bis der Webserver die Anfrage verarbeitet, ist diese Art von Angriff in der Regel sehr effektiv.
Angriff ausführen
Aufgrund der „rohen Gewalt“ eines DDoS-Angriffs müssen Sie viele Computer gleichzeitig koordinieren, um anzugreifen. Um unser Call-Center-Beispiel erneut zu betrachten, müssten alle Angreifer um 9 Uhr morgens anrufen und dann tatsächlich anrufen. Während dieses Prinzip sicherlich beim Angriff auf einen Webserver funktioniert, wird es wesentlich einfacher, wenn Zombie-Computer anstelle von tatsächlich bemannten Computern verwendet werden.
Wie Sie wahrscheinlich wissen, gibt es viele Varianten von Malware und Trojanern, die, sobald Sie sich auf Ihrem System befinden, inaktiv sind und gelegentlich "nach Hause telefonieren", um Anweisungen zu erhalten. Eine dieser Anweisungen könnte beispielsweise darin bestehen, wiederholte Anforderungen um 9:00 Uhr an den Webserver des Unternehmens X zu senden. So kann ein einziger Angreifer mit einem einzigen Update am Heimatort der jeweiligen Malware Hunderttausende gefährdeter Computer sofort koordinieren, um einen massiven DDoS-Angriff durchzuführen.
Die Schönheit der Verwendung von Zombie-Computern liegt nicht nur in ihrer Wirksamkeit, sondern auch in ihrer Anonymität, da der Angreifer seinen Computer gar nicht zur Ausführung des Angriffs verwenden muss.
SQL-Injektionsangriff
Was ist es?
Ein SQLI-Angriff ("SQL Injection") ist ein Angriff, bei dem schlechte Webentwicklungstechniken und in der Regel in Kombination mit einer fehlerhaften Datenbanksicherheit Vorteile ausgenutzt werden. Das Ergebnis eines erfolgreichen Angriffs kann vom Identifizieren eines Benutzerkontos bis zu einem vollständigen Kompromiss der jeweiligen Datenbank oder des Servers reichen. Im Gegensatz zu einem DDoS-Angriff kann ein SQLI-Angriff vollständig und leicht verhindert werden, wenn eine Webanwendung entsprechend programmiert wird.
Angriff ausführen
Wenn Sie sich bei einer Website anmelden und Ihren Benutzernamen und Ihr Kennwort eingeben, kann die Webanwendung zum Testen Ihrer Anmeldeinformationen eine Abfrage wie die folgende ausführen:
SELECT UserID FROM Benutzer WHERE UserName = "myuser" AND Password = "mypass";
Hinweis: Zeichenfolgenwerte in einer SQL-Abfrage müssen in einfache Anführungszeichen gesetzt werden. Deshalb werden sie um die vom Benutzer eingegebenen Werte angezeigt.
Die Kombination des eingegebenen Benutzernamens (myuser) und des Passworts (mypass) muss also mit einem Eintrag in der Tabelle Users übereinstimmen, damit eine UserID zurückgegeben werden kann. Wenn keine Übereinstimmung vorliegt, wird keine Benutzer-ID zurückgegeben, sodass die Anmeldeinformationen ungültig sind. Während eine bestimmte Implementierung unterschiedlich sein kann, sind die Mechaniken ziemlich Standard.
Schauen wir uns nun eine Vorlagenauthentifizierungsabfrage an, mit der wir die Werte ersetzen können, die der Benutzer im Webformular eingibt:
SELECT UserID FROM Benutzer WHERE UserName = "[Benutzer]" AND Password = "[Pass]"
Auf den ersten Blick mag dies wie ein einfacher und logischer Schritt für die einfache Überprüfung der Benutzer erscheinen. Wenn jedoch eine einfache Ersetzung der vom Benutzer eingegebenen Werte in dieser Vorlage vorgenommen wird, kann dies zu einem SQLI-Angriff führen.
Angenommen, "myuser'-" wird in das Feld für den Benutzernamen und "falsepass" in das Kennwort eingegeben. Mit einer einfachen Ersetzung in unserer Vorlagenabfrage würden wir Folgendes erhalten:
SELECT UserID FROM Benutzer WHERE UserName = "myuser" - 'AND Password = "wrongpass"
Ein Schlüssel zu dieser Aussage ist die Einbeziehung der zwei Bindestriche (-). Dies ist das Start-Kommentar-Token für SQL-Anweisungen, sodass alles, was nach den zwei Bindestrichen (einschließlich) erscheint, ignoriert wird. Im Wesentlichen wird die obige Abfrage von der Datenbank ausgeführt als:
SELECT UserID FROM Benutzer WHERE UserName = "myuser"
Das krasse Versäumnis hier ist das Fehlen der Passwortprüfung. Durch das Einfügen der zwei Bindestriche als Teil des Benutzerfelds haben wir die Bedingung für die Kennwortprüfung vollständig umgangen und konnten uns als "myuser" anmelden, ohne das entsprechende Kennwort zu kennen. Diese Manipulation der Abfrage, um unbeabsichtigte Ergebnisse zu erzeugen, ist ein Angriff der SQL-Injektion.
Welchen Schaden kann man anrichten??
Ein SQL-Injection-Angriff wird durch nachlässige und unverantwortliche Anwendungscodierung verursacht und ist vollständig vermeidbar (was wir gleich behandeln werden). Das Ausmaß des möglichen Schadens hängt jedoch von der Datenbankkonfiguration ab. Damit eine Webanwendung mit der Backend-Datenbank kommunizieren kann, muss die Anwendung ein Login für die Datenbank bereitstellen (Hinweis: Dies unterscheidet sich von einer Benutzeranmeldung an der Website selbst). Abhängig von den Berechtigungen, die die Webanwendung benötigt, kann dieses Datenbankkonto alle Rechte von Lese- / Schreibrechten in vorhandenen Tabellen bis hin zum vollständigen Datenbankzugriff erfordern. Wenn dies jetzt nicht klar ist, sollten einige Beispiele dazu beitragen, Klarheit zu schaffen.
Anhand des obigen Beispiels können Sie dies beispielsweise durch Eingabe von sehen, "youruser" - "," admin "-" oder einen anderen Benutzernamen können wir uns sofort als dieser Benutzer anmelden, ohne das Kennwort zu kennen. Wenn wir erst einmal im System sind, wissen wir nicht, dass wir nicht wirklich dieser Benutzer sind, sodass wir vollen Zugriff auf das jeweilige Konto haben. Datenbankberechtigungen bieten hierfür kein Sicherheitsnetz, da eine Website in der Regel mindestens über Lese- und Schreibzugriff auf die jeweilige Datenbank verfügen muss.
Nehmen wir nun an, die Website hat die volle Kontrolle über die jeweilige Datenbank. Dadurch können Sie Datensätze löschen, Tabellen hinzufügen / entfernen, neue Sicherheitskonten hinzufügen usw. Es ist wichtig zu beachten, dass einige Webanwendungen diese Berechtigung benötigen Es ist nicht automatisch eine schlechte Sache, dass die volle Kontrolle gewährt wird.
Um den Schaden zu veranschaulichen, der in dieser Situation entstehen kann, verwenden wir das oben im Comic angegebene Beispiel, indem Sie Folgendes in das Feld für den Benutzernamen eingeben: "Robert"; DROP TABLE-Benutzer; - ". Nach der einfachen Ersetzung wird die Authentifizierungsabfrage zu:
SELECT UserID FROM Benutzer WHERE UserName = "Robert"; DROP TABLE-Benutzer; - 'AND Password = "wrongpass"
Hinweis: Das Semikolon in einer SQL-Abfrage wird verwendet, um das Ende einer bestimmten Anweisung und den Beginn einer neuen Anweisung anzuzeigen.
Welche wird von der Datenbank ausgeführt als:
SELECT UserID FROM Benutzer WHERE UserName = "Robert"DROP TABLE Benutzer
Wir haben also einfach einen SQLI-Angriff verwendet, um die gesamte Users-Tabelle zu löschen.
Natürlich kann noch viel schlimmer vorgegangen werden, da der Angreifer abhängig von den zulässigen SQL-Berechtigungen Werte ändern, Tabellen (oder die gesamte Datenbank selbst) in eine Textdatei speichern, neue Anmeldekonten erstellen oder sogar die gesamte Datenbankinstallation übernehmen kann.
Einen SQL-Injection-Angriff verhindern
Wie bereits mehrfach erwähnt, ist ein SQL-Injection-Angriff leicht zu verhindern. Eine der Hauptregeln der Webentwicklung besteht darin, dass Sie der Benutzereingabe niemals blind vertrauen, wie wir es getan haben, als wir in unserer obigen Vorlagenabfrage eine einfache Ersetzung vorgenommen haben.
Ein SQLI-Angriff wird durch das, was als Desinfektion (oder Flucht) Ihrer Eingaben bezeichnet wird, leicht vereitelt. Der Desinfektionsprozess ist eigentlich ziemlich trivial, da er im Wesentlichen alle Inline-Anführungszeichen (') so handhabt, dass sie nicht dazu verwendet werden können, einen String innerhalb einer SQL-Anweisung vorzeitig zu beenden.
Wenn Sie beispielsweise nach "O'neil" in einer Datenbank suchen möchten, können Sie keine einfache Ersetzung verwenden, da das einfache Anführungszeichen nach dem O den String vorzeitig enden würde. Stattdessen bereinigen Sie es mit dem Escape-Zeichen der jeweiligen Datenbank. Nehmen wir an, das Escape-Zeichen für ein Inline-Anführungszeichen setzt jedes Anführungszeichen mit einem \ -Zeichen voran. "O'neal" würde also als "O \ 'neil" desinfiziert.
Dieser einfache Vorgang der Hygiene verhindert einen SQLI-Angriff weitgehend. Lassen Sie uns zur Veranschaulichung unsere vorherigen Beispiele noch einmal durchgehen und die resultierenden Abfragen sehen, wenn die Benutzereingaben bereinigt werden.
myuser '-- / falscher Pass:
SELECT UserID FROM Benutzer WHERE UserName = "myuser \" - 'AND Password = "wrongpass"
Da das einfache Anführungszeichen nach myuser mit Escapezeichen versehen ist (dh, es wird als Teil des Zielwerts betrachtet), sucht die Datenbank buchstäblich nach dem Benutzernamen von "myuser" - ". Da die Bindestriche im String-Wert und nicht in der SQL-Anweisung selbst enthalten sind, werden sie als Teil des Zielwerts betrachtet und nicht als SQL-Kommentar interpretiert.
Robert'; DROP TABLE-Benutzer;-- / falscher Pass:
SELECT UserID FROM Benutzer WHERE UserName = "Robert \"; DROP TABLE-Benutzer; - 'AND Password = "wrongpass"
Indem Sie einfach das einfache Anführungszeichen nach Robert verwenden, sind sowohl das Semikolon als auch die Bindestriche in der UserName-Suchzeichenfolge enthalten, sodass die Datenbank buchstäblich danach sucht "Robert"; DROP TABLE-Benutzer; - " anstatt die Tabelle zu löschen.
In Summe
Während sich Internetangriffe weiterentwickeln und komplexer werden oder sich auf einen anderen Einstiegspunkt konzentrieren, ist es wichtig, sich vor erprobten und echten Angriffen zu schützen, die von mehreren frei verfügbaren "Hacker-Tools" inspiriert wurden, um sie auszunutzen.
Bestimmte Arten von Angriffen, wie z. B. DDoS, können nicht einfach vermieden werden, während andere, z. B. SQLI, dies verhindern können. Der durch diese Art von Angriffen verursachte Schaden kann jedoch je nach den getroffenen Vorsichtsmaßnahmen von unbequem bis katastrophal sein.
