Privatsphäre und Sicherheit

Wie Hacker Websites mit SQL Injection und DDoS übernehmen


Auch wenn Sie die Geschehnisse der Hacker-Gruppen Anonymous und LulzSec nur grob 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 Werkzeugen und Techniken, die diese Gruppen verwenden, und obwohl wir nicht versuchen, Ihnen ein Handbuch zu geben, um dies selbst zu tun, ist es nützlich zu verstehen, was vor sich geht. Zwei der Angriffe, von denen Sie immer wieder hören, dass sie sie verwenden, sind „(Distributed) Denial of Service“ (DDoS) und „SQL Injections“ (SQLI). So funktionieren sie.

Bild von xkcd

Denial-of-Service-Angriff

1622843951 43 Wie Hacker Websites mit SQL Injection und DDoS uebernehmen

Was ist es?

Ein „Denial-of-Service“-Angriff (manchmal auch als „Distributed Denial of Service“ oder DDoS bezeichnet) tritt auf, wenn ein System, in diesem Fall ein Webserver, so viele Anfragen auf einmal erhält, dass die Serverressourcen überlastet sind und das System einfach abstürzt und schließt ab. Ziel und Ergebnis eines erfolgreichen DDoS-Angriffs ist, dass die Websites auf dem Zielserver für legitime Verkehrsanforderungen nicht verfügbar sind.

Wie funktioniert es?

Die Logistik eines DDoS-Angriffs lässt sich am besten an einem Beispiel erklären.

Stellen Sie sich vor, eine Million Menschen (die Angreifer) verbünden sich mit dem Ziel, das Geschäft von Unternehmen X zu behindern, indem sie ihr Callcenter ausschalten. Die Angreifer koordinieren sich so, dass sie am Dienstag um 9 Uhr alle die Telefonnummer von Unternehmen X anrufen. Höchstwahrscheinlich wird das Telefonsystem von Unternehmen X nicht in der Lage sein, eine Million Anrufe auf einmal zu bearbeiten, sodass alle eingehenden Leitungen von den Angreifern belegt werden. Das Ergebnis ist, dass legitime Kundenanrufe (dh solche, die nicht die Angreifer sind) nicht durchkommen, weil die Telefonanlage mit der Bearbeitung der Anrufe der Angreifer beschäftigt ist. Im Wesentlichen verliert Unternehmen X also möglicherweise Geschäfte, da die legitimen Anfragen nicht durchkommen.

Ein DDoS-Angriff auf einen Webserver funktioniert genauso. Da es praktisch keine Möglichkeit gibt zu wissen, welcher Datenverkehr von legitimen Anfragen im Vergleich zu Angreifern stammt, bis der Webserver die Anfrage verarbeitet hat, ist diese Art von Angriff in der Regel sehr effektiv.

Ausführung des Angriffs

Aufgrund des „Brute-Force“-Charakters eines DDoS-Angriffs müssen viele Computer gleichzeitig für den Angriff koordiniert sein. Wenn wir unser Callcenter-Beispiel noch einmal betrachten, müssten alle Angreifer sowohl wissen, dass sie um 9 Uhr morgens anrufen, als auch tatsächlich zu dieser Zeit anrufen. Während dieses Prinzip bei Angriffen auf einen Webserver sicherlich funktioniert, wird es deutlich einfacher, wenn Zombie-Computer anstelle von echten bemannten Computern verwendet werden.

Wie Sie wahrscheinlich wissen, gibt es viele Varianten von Malware und Trojanern, die einmal auf Ihrem System schlummern und gelegentlich „nach Hause telefonieren“, um Anweisungen zu erhalten. Eine dieser Anweisungen könnte beispielsweise sein, um 9 Uhr wiederholte Anfragen an den Webserver von Firma X zu senden. So kann ein einzelner Angreifer mit einem einzigen Update am Heimatstandort der jeweiligen Malware sofort Hunderttausende von kompromittierten Computern koordinieren, um einen massiven DDoS-Angriff durchzuführen.

Die Schönheit des Einsatzes von Zombie-Computern liegt nicht nur in seiner Effektivität, sondern auch in seiner Anonymität, da der Angreifer seinen Computer überhaupt nicht verwenden muss, um den Angriff auszuführen.

SQL-Injection-Angriff

1622843951 182 Wie Hacker Websites mit SQL Injection und DDoS uebernehmen

Was ist es?

Ein „SQL-Injection“ (SQLI)-Angriff ist ein Exploit, der sich schlechte Webentwicklungstechniken zunutze macht und typischerweise mit einer fehlerhaften Datenbanksicherheit kombiniert wird. Das Ergebnis eines erfolgreichen Angriffs kann vom Identitätswechsel eines Benutzerkontos bis hin zur vollständigen Kompromittierung der jeweiligen Datenbank oder des Servers reichen. Im Gegensatz zu einem DDoS-Angriff ist ein SQLI-Angriff bei entsprechender Programmierung einer Webanwendung vollständig und einfach zu verhindern.

Ausführung des Angriffs

Wenn Sie sich bei einer Website anmelden und Ihren Benutzernamen und Ihr Kennwort eingeben, führt die Webanwendung zum Testen Ihrer Anmeldeinformationen möglicherweise eine Abfrage wie die folgende aus:

SELECT UserID FROM Users WHERE UserName="myuser" AND Password='mypass';

Hinweis: Zeichenfolgenwerte in einer SQL-Abfrage müssen in einfache Anführungszeichen eingeschlossen werden, weshalb sie um die vom Benutzer eingegebenen Werte herum erscheinen.

Die Kombination aus eingegebenem Benutzernamen (myuser) und Passwort (mypass) muss also mit einem Eintrag in der Tabelle Users übereinstimmen, damit eine UserID zurückgegeben wird. Wenn keine Übereinstimmung vorliegt, wird keine Benutzer-ID zurückgegeben, sodass die Anmeldeinformationen ungültig sind. Während eine bestimmte Implementierung abweichen kann, ist die Mechanik ziemlich Standard.

Schauen wir uns nun eine Vorlagenauthentifizierungsabfrage an, die wir durch die Werte ersetzen können, die der Benutzer in das Webformular eingibt:

SELECT UserID FROM Users WHERE UserName=“[user]‘ UND Passwort=“[pass]‘

Auf den ersten Blick mag dies wie ein einfacher und logischer Schritt erscheinen, um Benutzer leicht zu validieren, aber wenn eine einfache Ersetzung der vom Benutzer eingegebenen Werte in dieser Vorlage durchgeführt wird, ist sie anfällig für einen SQLI-Angriff.

Nehmen wir beispielsweise an, dass „myuser’–“ in das Feld für den Benutzernamen und „wrongpass“ als Passwort eingegeben wird. Durch einfache Ersetzung in unserer Vorlagenabfrage erhalten wir Folgendes:

SELECT UserID FROM Users WHERE UserName="myuser"--' AND Password='wrongpass'

Ein Schlüssel zu dieser Aussage ist die Einbeziehung der beiden Bindestriche (--). Dies ist das Startkommentartoken für SQL-Anweisungen, sodass alles, was nach den beiden Bindestrichen (einschließlich) erscheint, ignoriert wird. Im Wesentlichen wird die obige Abfrage von der Datenbank ausgeführt als:

SELECT UserID FROM Users WHERE UserName="myuser"

Das eklatante Versäumnis hier ist das Fehlen der Passwortprüfung. Durch die Aufnahme der beiden Bindestriche in das Benutzerfeld haben wir die Passwort-Check-Bedingung komplett umgangen und konnten uns als „myuser“ anmelden, ohne das jeweilige Passwort zu kennen. Diese Manipulation der Abfrage, um unbeabsichtigte Ergebnisse zu erzielen, ist ein SQL-Injection-Angriff.

Welcher Schaden kann angerichtet werden?

Ein SQL-Injection-Angriff wird durch fahrlässige und unverantwortliche Anwendungscodierung verursacht und ist vollständig vermeidbar (wir werden gleich darauf eingehen), jedoch hängt das Ausmaß des Schadens, der angerichtet werden kann, von der Datenbankeinrichtung ab. Damit eine Webanwendung mit der Backend-Datenbank kommunizieren kann, muss die Anwendung eine Anmeldung zur Datenbank bereitstellen (beachten Sie, dass dies anders ist als eine Benutzeranmeldung auf der Website selbst). Je nachdem, welche Berechtigungen die Webanwendung benötigt, kann dieses jeweilige Datenbankkonto alles von nur Lese-/Schreibberechtigung in bestehenden Tabellen bis hin zum vollständigen Datenbankzugriff erfordern. Wenn dies jetzt nicht klar ist, sollen ein paar Beispiele etwas Klarheit schaffen.

Anhand des obigen Beispiels können Sie dies erkennen, indem Sie z. "youruser'--", "admin'--" oder einem anderen Benutzernamen, können wir uns sofort als dieser Benutzer auf der Website anmelden, ohne das Passwort zu kennen. Sobald wir im System sind, wissen wir nicht, dass wir nicht dieser Benutzer sind, also haben wir vollen Zugriff auf das jeweilige Konto. Datenbankberechtigungen bieten hierfür kein Sicherheitsnetz, da eine Website normalerweise mindestens Lese-/Schreibzugriff auf ihre jeweilige Datenbank haben muss.

Nehmen wir nun an, die Website hat die volle Kontrolle über ihre jeweilige Datenbank, die es ermöglicht, Datensätze zu löschen, Tabellen hinzuzufügen/zu entfernen, neue Sicherheitskonten hinzuzufügen usw. Es ist wichtig zu beachten, dass einige Webanwendungen diese Art von Berechtigung benötigen könnten, damit sie Es ist nicht automatisch eine schlechte Sache, dass volle Kontrolle gewährt wird.

Um den Schaden zu veranschaulichen, der in dieser Situation angerichtet werden kann, verwenden wir das Beispiel im obigen Comic, indem wir Folgendes in das Feld für den Benutzernamen eingeben: "Robert'; DROP TABLE Users;--". Nach einfacher Ersetzung lautet die Authentifizierungsabfrage:

SELECT UserID FROM Users WHERE UserName="Robert"; DROP TABLE Users;--' AND Password='wrongpass'

Hinweis: Das Semikolon wird in einer SQL-Abfrage verwendet, um das Ende einer bestimmten Anweisung und den Beginn einer neuen Anweisung anzuzeigen.

Was von der Datenbank ausgeführt wird als:

SELECT UserID FROM Users WHERE UserName="Robert"

DROP TABLE-Benutzer

Also haben wir einfach einen SQLI-Angriff verwendet, um die gesamte Benutzertabelle zu löschen.

Natürlich geht noch viel Schlimmeres, denn je nach erlaubten SQL-Berechtigungen kann der Angreifer Werte ändern, Tabellen (oder die gesamte Datenbank selbst) in eine Textdatei kopieren, neue Login-Konten erstellen oder sogar die gesamte Datenbankinstallation kapern.

Verhindern eines SQL-Injection-Angriffs

Wie bereits mehrfach erwähnt, lässt sich ein SQL-Injection-Angriff leicht verhindern. Eine der wichtigsten Regeln der Webentwicklung ist, dass Sie Benutzereingaben niemals blind vertrauen, wie wir es bei der einfachen Ersetzung in unserer obigen Vorlagenabfrage getan haben.

Ein SQLI-Angriff wird leicht durch das sogenannte Bereinigen (oder Entkommen) Ihrer Eingaben vereitelt. Der Bereinigungsprozess ist eigentlich ziemlich trivial, da er im Wesentlichen nur alle Inline-Anführungszeichen (‚) angemessen behandelt, sodass sie nicht verwendet werden können, um einen String innerhalb einer SQL-Anweisung vorzeitig zu beenden.

Wenn Sie beispielsweise in einer Datenbank nach „O’neil“ suchen möchten, können Sie keine einfache Ersetzung verwenden, da das einfache Anführungszeichen nach dem O dazu führen würde, dass die Zeichenfolge vorzeitig endet. Stattdessen bereinigen Sie es, indem Sie das Escape-Zeichen der jeweiligen Datenbank verwenden. Nehmen wir an, das Escape-Zeichen für ein einfaches Inline-Anführungszeichen stellt jedem Anführungszeichen ein -Symbol voran. Also würde „O’neal“ als „O’neil“ bereinigt.

Dieser einfache Akt der Hygiene verhindert so ziemlich einen SQLI-Angriff. Sehen wir uns zur Veranschaulichung unsere vorherigen Beispiele noch einmal an und sehen wir uns die resultierenden Abfragen an, wenn die Benutzereingabe bereinigt wird.

myuser'-- / Fehlpass:

SELECT UserID FROM Users WHERE UserName="myuser"--' AND Password='wrongpass'

Da das einfache Anführungszeichen nach myuser maskiert ist (d. h. es wird als Teil des Zielwerts angesehen), sucht die Datenbank buchstäblich nach dem Benutzernamen von "myuser'--". Da die Bindestriche im Zeichenfolgenwert und nicht in der SQL-Anweisung selbst enthalten sind, werden sie außerdem als Teil des Zielwerts betrachtet und nicht als SQL-Kommentar interpretiert.

Robert'; DROP TABLE Users;-- / Fehlpass:

SELECT UserID FROM Users WHERE UserName="Robert"; DROP TABLE Users;--' AND Password='wrongpass'

Durch einfaches Escapezeichen des einfachen Anführungszeichens nach Robert werden sowohl das Semikolon als auch die Bindestriche in der Suchzeichenfolge Benutzername enthalten, sodass die Datenbank buchstäblich nach "Robert'; DROP TABLE Users;--" anstatt die Tabelle delete auszuführen.

Zusammenfassend

Während sich Web-Angriffe weiterentwickeln und ausgefeilter werden oder sich auf einen anderen Eintrittspunkt konzentrieren, ist es wichtig, sich vor bewährten Angriffen zu schützen, die die Inspiration für mehrere frei verfügbare „Hacker-Tools“ waren, die sie ausnutzen.

Bestimmte Arten von Angriffen, wie DDoS, können nicht einfach vermieden werden, während andere, wie SQLI, dies können. Der Schaden, der durch diese Art von Angriffen angerichtet werden kann, kann jedoch je nach getroffenen Vorkehrungen von unbequem bis katastrophal reichen.



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ähnliche Artikel

Schaltfläche "Zurück zum Anfang"