Selbst wenn Sie die Ereignisse der Hacker-Gruppen Anonymous und LulzSec nur lose verfolgt haben, haben Sie wahrscheinlich von gehackten Websites und Diensten wie den berüchtigten Sony-Hacks gehört. Haben Sie sich jemals gefragt, wie sie das machen?
Es gibt eine Reihe von Tools und Techniken, die diese Gruppen verwenden. Wir versuchen zwar nicht, Ihnen ein Handbuch zu geben, um dies selbst zu tun, aber es ist hilfreich zu verstehen, was los ist. Zwei der Angriffe, von denen Sie regelmäßig hören, sind "(Distributed) Denial of Service" (DDoS) und "SQL Injections" (SQLI). So funktionieren sie
Bild von xkcd
Denial-of-Service-Angriff
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 Anforderungen gleichzeitig empfängt, dass die Serverressourcen überlastet sind und das System einfach abstürzt und fährt herunter. Das 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 anhand eines Beispiels erklären.
Stellen Sie sich vor, eine Million Menschen (die Angreifer) kommen zusammen, um das Geschäft von Unternehmen X zu behindern, indem sie ihr Callcenter herunterfahren. Die Angreifer koordinieren sich so, dass sie am Dienstag um 9 Uhr alle die Telefonnummer von Unternehmen X anrufen. Höchstwahrscheinlich kann das Telefonsystem von Unternehmen X nicht eine Million Anrufe gleichzeitig verarbeiten, sodass alle eingehenden Leitungen von den Angreifern gebunden werden. Das Ergebnis ist, dass legitime Kundenanrufe (d. H. Solche, die nicht die Angreifer sind) nicht durchkommen, weil das Telefonsystem die Anrufe der Angreifer bearbeitet. Im Wesentlichen verliert Unternehmen X möglicherweise sein Geschäft, da legitime Anfragen nicht durchkommen können.
Ein DDoS-Angriff auf einen Webserver funktioniert genauso. Da es praktisch keine Möglichkeit gibt, festzustellen, welcher Datenverkehr von legitimen Anforderungen im Vergleich zu Angreifern stammt, bis der Webserver die Anforderung verarbeitet, ist diese Art von Angriff in der Regel sehr effektiv.
Den Angriff ausführen
Aufgrund der „Brute Force“ -Natur eines DDoS-Angriffs müssen viele Computer gleichzeitig für einen Angriff koordiniert sein. Bei einem erneuten Besuch unseres Callcenter-Beispiels müssten alle Angreifer wissen, dass sie um 9 Uhr morgens anrufen und zu diesem Zeitpunkt tatsächlich anrufen müssen. Während dieses Prinzip sicherlich funktioniert, wenn es darum geht, einen Webserver anzugreifen, wird es erheblich 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 auf Ihrem System inaktiv sind und gelegentlich „nach Hause telefonieren“, um Anweisungen zu erhalten. Eine dieser Anweisungen könnte beispielsweise darin bestehen, wiederholte Anfragen um 9 Uhr morgens an den Webserver von Unternehmen X zu senden. Mit einem einzigen Update des Heimatorts der jeweiligen Malware kann ein einzelner Angreifer sofort Hunderttausende kompromittierter Computer koordinieren, um einen massiven DDoS-Angriff auszuführen.
Das Schöne an der Verwendung von Zombie-Computern liegt nicht nur in ihrer Effektivität, sondern auch in ihrer Anonymität, da der Angreifer seinen Computer überhaupt nicht verwenden muss, um den Angriff auszuführen.
SQL Injection Attack
Was ist es?
Ein SQLI-Angriff (SQL Injection) ist ein Exploit, der schlechte Webentwicklungstechniken und in der Regel eine fehlerhafte Datenbanksicherheit nutzt. Das Ergebnis eines erfolgreichen Angriffs kann von der Identität eines Benutzerkontos bis zu einem vollständigen Kompromiss der jeweiligen Datenbank oder des jeweiligen Servers reichen. Im Gegensatz zu einem DDoS-Angriff kann ein SQLI-Angriff vollständig und leicht verhindert werden, wenn eine Webanwendung entsprechend programmiert ist.
Den Angriff ausführen
Wenn Sie sich auf 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 gesetzt werden, weshalb sie um die vom Benutzer eingegebenen Werte herum angezeigt werden.
Die Kombination aus dem eingegebenen Benutzernamen (myuser) und dem Kennwort (mypass) muss daher mit einem Eintrag in der Users-Tabelle ü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, bei der wir die Werte ersetzen können, die der Benutzer in das Webformular eingibt:
SELECT UserID FROM Users WHERE Benutzername = '[user]' UND Passwort = '[pass]'
Auf den ersten Blick scheint dies ein einfacher und logischer Schritt für die einfache Validierung von Benutzern zu sein. Wenn jedoch eine einfache Ersetzung der vom Benutzer eingegebenen Werte für diese Vorlage durchgeführt wird, ist sie anfällig für einen SQLI-Angriff.
Angenommen, "myuser" - wird in das Feld "Benutzername" und "Falschpass" in das Kennwort eingegeben. Durch einfaches Ersetzen in unserer Vorlagenabfrage erhalten wir Folgendes:
SELECT UserID FROM Users WHERE UserName = 'myuser' - 'AND Password =' falsepass '
Ein Schlüssel zu dieser Aussage ist die Aufnahme der beiden Striche
(--)
. Dies ist das Anfangskommentar-Token für SQL-Anweisungen, sodass alle nach den beiden Bindestrichen (einschließlich) angezeigten Zeichen ignoriert werden. Im Wesentlichen wird die obige Abfrage von der Datenbank wie folgt ausgeführt:
SELECT UserID FROM Users WHERE UserName = 'myuser'
Das krasse Versäumnis hier ist das Fehlen der Passwortprüfung. Durch das Einfügen der beiden Striche in das Benutzerfeld 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 erzielen, ist ein SQL-Injection-Angriff.
Welcher Schaden kann angerichtet werden?
Ein SQL-Injection-Angriff wird durch fahrlässige und verantwortungslose Anwendungscodierung verursacht und ist vollständig vermeidbar (was wir gleich behandeln werden). Das Ausmaß des Schadens, der angerichtet werden kann, hängt jedoch vom Datenbank-Setup 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 einem Benutzer-Login auf der Website selbst). Abhängig davon, welche Berechtigungen die Webanwendung benötigt, kann dieses jeweilige Datenbankkonto alles von Lese- / Schreibberechtigungen in vorhandenen Tabellen bis hin zum vollständigen Datenbankzugriff erfordern. Wenn dies jetzt nicht klar ist, sollten einige Beispiele zur Verdeutlichung beitragen.
Anhand des obigen Beispiels können Sie dies sehen, indem Sie beispielsweise Folgendes eingeben:
"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 wirklich dieser Benutzer sind, sodass wir vollen Zugriff auf das jeweilige Konto haben. Datenbankberechtigungen bieten hierfür kein Sicherheitsnetz, da eine Website normalerweise mindestens Lese- / Schreibzugriff auf ihre jeweilige Datenbank haben muss.
Nehmen wir nun an, dass die Website die vollständige Kontrolle über ihre jeweilige Datenbank hat, wodurch Datensätze gelöscht, Tabellen hinzugefügt / entfernt, neue Sicherheitskonten hinzugefügt usw. werden können. Es ist wichtig zu beachten, dass einige Webanwendungen diese Art von Berechtigung benötigen könnten Es ist nicht automatisch eine schlechte Sache, dass die volle Kontrolle gewährt wird.
Um den Schaden zu veranschaulichen, der in dieser Situation angerichtet werden kann, verwenden wir das im obigen Comic bereitgestellte Beispiel, indem wir Folgendes in das Feld Benutzername eingeben:
"Robert '; DROP TABLE-Benutzer; -".
Nach einfacher Ersetzung lautet die Authentifizierungsabfrage:
SELECT UserID FROM Users WHERE UserName = 'Robert'; DROP TABLE Benutzer; - 'AND Password =' Falschpass '
Hinweis: Das Semikolon in einer SQL-Abfrage kennzeichnet das Ende einer bestimmten Anweisung und den Beginn einer neuen Anweisung.
Was von der Datenbank ausgeführt wird als:
SELECT UserID FROM Users WHERE UserName = 'Robert'DROP TABLE Benutzer
Einfach so haben wir einen SQLI-Angriff verwendet, um die gesamte Benutzertabelle zu löschen.
Natürlich kann viel schlimmeres geschehen, da der Angreifer abhängig von den zulässigen SQL-Berechtigungen Werte ändern, Tabellen (oder die gesamte Datenbank selbst) in eine Textdatei sichern, neue Anmeldekonten erstellen oder sogar die gesamte Datenbankinstallation entführen kann.
Verhindern eines SQL-Injection-Angriffs
Wie bereits mehrfach erwähnt, kann ein SQL-Injection-Angriff leicht verhindert werden. Eine der Grundregeln der Webentwicklung ist, dass Sie Benutzereingaben niemals blind vertrauen, wie wir es getan haben, als wir in unserer obigen Vorlagenabfrage eine einfache Ersetzung durchgeführt haben.
Ein SQLI-Angriff kann leicht vereitelt werden, indem Ihre Eingaben bereinigt werden (oder entkommen). Der Bereinigungsprozess ist eigentlich ziemlich trivial, da er im Wesentlichen alle Inline-Zeichen in einfachen Anführungszeichen (‘) angemessen behandelt, sodass sie nicht zum vorzeitigen Beenden einer Zeichenfolge innerhalb einer SQL-Anweisung verwendet werden können.
Wenn Sie beispielsweise "O’neil" in einer Datenbank nachschlagen 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 steht vor jedem Anführungszeichen mit einem \ -Symbol. "O'neal" würde also als "O \ 'neil" bereinigt.
Diese einfache Hygiene verhindert so ziemlich einen SQLI-Angriff. Schauen wir uns zur Veranschaulichung unsere vorherigen Beispiele noch einmal an und sehen uns die resultierenden Abfragen an, wenn die Benutzereingaben bereinigt werden.
myuser '-
/
falscher Pass
:
SELECT UserID FROM Users WHERE UserName = 'myuser \' - 'AND Password =' falsepass '
Da das einfache Anführungszeichen nach dem Escapezeichen von myuser maskiert wird (was bedeutet, dass es als Teil des Zielwerts betrachtet wird), 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, anstatt als SQL-Kommentar interpretiert zu werden.
Robert'; DROP TABLE Benutzer; -
/
falscher Pass
:
SELECT UserID FROM Users WHERE UserName = 'Robert \'; DROP TABLE Benutzer; - 'AND Password =' Falschpass '
Wenn Sie einfach das einfache Anführungszeichen nach Robert maskieren, 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, löschen.
In Summe
Während sich Webangriffe weiterentwickeln und komplexer werden oder sich auf einen anderen Einstiegspunkt konzentrieren, ist es wichtig, sich vor bewährten Angriffen zu schützen, die von mehreren frei verfügbaren „Hacker-Tools“ inspiriert wurden, die diese ausnutzen sollen.
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 verursacht werden kann, kann jedoch je nach den getroffenen Vorsichtsmaßnahmen von einer Unannehmlichkeit bis zu einer Katastrophe reichen.
