26Aug
Selbst wenn Sie die Ereignisse der Hacker-Gruppen Anonymous und LulzSec nur lückenlos verfolgt haben, haben Sie wahrscheinlich schon von Websites und Diensten gehört, die gehackt wurden, wie die berüchtigten Sony-Hacks. Hast du dich 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 zu tun, ist es nützlich zu verstehen, was vor sich geht. Zwei der Angriffe, die Sie regelmäßig über sie hören, sind "(Distributed) Denial of Service"( DDoS) und "SQL Injections"( SQLI).So arbeiten sie.
Bild von xkcd
Denial of Service Angriff
Was ist das?
Ein "Denial of Service"( manchmal als "Distributed Denial of Service" oder DDoS bezeichnet) Angriff tritt auf, wenn ein System, in diesem Fall ein Webserver, so viele Anfragen gleichzeitig erhält, dass die Serverressourcen überlastet sind und das System einfach sperrtrauf und runter. Ziel und Ergebnis eines erfolgreichen DDoS-Angriffs ist, dass die Websites auf dem Zielserver für legitime Datenverkehrsanforderungen 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) würden sich zusammenschließen, um das Geschäft von Unternehmen X zu behindern, indem sie ihr Call-Center ausschalten. Die Angreifer koordinieren, so dass sie am Dienstag um 9 Uhr morgens die Telefonnummer von Firma X anrufen. Höchstwahrscheinlich wird das Telefonsystem von Firma X nicht in der Lage sein, eine Million Anrufe gleichzeitig zu verarbeiten, so dass alle eingehenden Leitungen von den Angreifern gebunden werden. Das Ergebnis ist, dass legitime Kundenanrufe( d. H. Diejenigen, die nicht die Angreifer sind) nicht durchkommen, weil das Telefonsystem mit den Anrufen der Angreifer verbunden ist. Im Grunde genommen verliert Unternehmen X aufgrund der legitimen Anfragen, die nicht durchkommen können, möglicherweise Geschäft.
Ein DDoS-Angriff auf einen Webserver funktioniert genau so. Da es praktisch keine Möglichkeit gibt, zu ermitteln, 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.
Ausführen des Angriffs
Aufgrund der Brute-Force-Natur eines DDoS-Angriffs müssen viele Computer gleichzeitig koordiniert werden, um gleichzeitig anzugreifen. Bei einem erneuten Besuch unseres Call-Center-Beispiels müssten alle Angreifer wissen, dass sie um 9:00 Uhr anrufen und zu diesem Zeitpunkt tatsächlich anrufen. Während dieses Prinzip sicherlich funktioniert, wenn es darum geht, einen Webserver anzugreifen, 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, einmal auf Ihrem System, ruhend sind und gelegentlich "nach Hause telefonieren", um Anweisungen zu erhalten. Eine dieser Anweisungen könnte beispielsweise sein, um 9 Uhr morgens wiederholte Anfragen an den Webserver von Company X zu senden. Mit einem einzigen Update auf den Heimatstandort der jeweiligen Malware kann ein einzelner Angreifer sofort Hunderttausende kompromittierter Computer koordinieren, um einen massiven DDoS-Angriff durchzuführen.
Die Schönheit der Verwendung von Zombie-Computern ist nicht nur in ihrer Effektivität, sondern auch in ihrer Anonymität, da der Angreifer seinen Computer nicht wirklich benutzen muss, um den Angriff auszuführen.
SQL Injection Attacke
Was ist das?
Ein SQL Injection-Angriff( SQL Injection) ist ein Exploit, der schlechte Webentwicklungstechniken ausnutzt und typischerweise mit fehlerhafter Datenbanksicherheit kombiniert wird. Das Ergebnis eines erfolgreichen Angriffs kann von der Identität eines Benutzerkontos bis zu einer vollständigen Kompromittierung der jeweiligen Datenbank oder des Servers reichen. Im Gegensatz zu einem DDoS-Angriff ist ein SQLI-Angriff vollständig und leicht vermeidbar, wenn eine Webanwendung entsprechend programmiert wird.
Ausführen des Angriffs
Wenn Sie sich auf einer Website anmelden und Ihren Benutzernamen und Ihr Kennwort eingeben, kann die Webanwendung eine Abfrage wie die folgende ausführen, um Ihre Anmeldeinformationen zu testen:
SELECT BenutzerID FROM Benutzer WHERE Benutzername = 'myuser' UND Kennwort= 'mypass';
Hinweis: Zeichenfolgenwerte in einer SQL-Abfrage müssen in einfache Anführungszeichen eingeschlossen sein, weshalb sie in der Umgebung der vom Benutzer eingegebenen Werte angezeigt werden.
Daher muss die Kombination aus dem eingegebenen Benutzernamen( myuser) und dem Kennwort( mypass) mit einem Eintrag in der Tabelle "Benutzer" übereinstimmen, damit eine Benutzer-ID zurückgegeben werden kann. Wenn keine Übereinstimmung vorhanden ist, wird keine Benutzer-ID zurückgegeben, sodass die Anmeldedaten ungültig sind. Während eine bestimmte Implementierung abweichen kann, sind die Mechaniken ziemlich Standard.
Betrachten wir nun eine Vorlagenauthentifizierungsabfrage, die wir durch die Werte ersetzen können, die der Benutzer in das Webformular eingibt:
SELECT UserID FROM Benutzer WHERE UserName = '[user]' UND Password = '[pass]'
Auf den ersten Blickkann als einfacher und logischer Schritt für die einfache Validierung von Benutzern erscheinen, 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" eingegeben, und "falsepass" wird im Kennwort eingegeben. Mit einer einfachen Ersetzung in unserer Template-Abfrage würden wir dies erhalten:
SELECT UserID FROM Benutzer WHERE UserName = 'myuser' - 'AND Password =' falsepass '
Ein Schlüssel zu dieser Aussage ist die Einbeziehung der zwei Bindestriche( -).Dies ist das Begin-Kommentar-Token für SQL-Anweisungen. Daher wird alles, was nach den zwei Bindestrichen( einschließlich) angezeigt wird, ignoriert. Im Wesentlichen wird die obige Abfrage von der Datenbank wie folgt ausgeführt:
SELECT UserID FROM Benutzer WHERE UserName = 'myuser'
Das eklatante Unterlassen hier ist das Fehlen der Kennwortüberprüfung. Durch die Einbindung der beiden Bindestriche in das Benutzerfeld haben wir die Passwortüberprüfung vollständig umgangen und konnten uns als "myuser" anmelden, ohne das entsprechende Passwort zu kennen. Dieser Vorgang der Manipulation der Abfrage, um unbeabsichtigte Ergebnisse zu erzeugen, ist ein SQL-Injection-Angriff.
Welcher Schaden kann verursacht werden?
Ein SQL-Injection-Angriff wird durch nachlässige und unverantwortliche Anwendungscodierung verursacht und ist vollständig vermeidbar( was wir gleich behandeln werden), jedoch hängt das Ausmaß des Schadens, der durchgeführt werden kann, von der Datenbankeinrichtung ab. Damit eine Webanwendung mit der Back-End-Datenbank kommunizieren kann, muss die Anwendung eine Anmeldung an die Datenbank liefern( beachten Sie, dass sich dies von einer Benutzeranmeldung auf der Website selbst unterscheidet).Je nachdem, welche Berechtigungen die Webanwendung benötigt, kann dieses Datenbankkonto von Lese- / Schreibberechtigungen in vorhandenen Tabellen nur bis zum vollständigen Datenbankzugriff reichen. Wenn das jetzt nicht klar ist, sollten einige Beispiele helfen, Klarheit zu schaffen.
Auf der Grundlage des obigen Beispiels können Sie sehen, dass wir uns beispielsweise mit "youruser" - "", "admin" - "oder einem anderen Benutzernamen sofort auf der Website als dieser Benutzer anmelden können, ohne das Kennwort zu kennen. Sobald wir im System sind, wissen wir nicht, dass wir nicht wirklich dieser Benutzer sind, so dass wir vollen Zugriff auf das entsprechende Konto haben. Datenbankberechtigungen bieten hierfür kein Sicherheitsnetz, da eine Website normalerweise mindestens Lese- / Schreibzugriff auf ihre jeweilige Datenbank haben muss.
Nun nehmen wir an, dass die Website die volle Kontrolle über ihre jeweilige Datenbank hat, die die Möglichkeit bietet, 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ötigenEs ist nicht automatisch eine schlechte Sache, dass die volle Kontrolle gewährt wird.
Um den Schaden zu verdeutlichen, der in dieser Situation möglich ist, verwenden wir das obige Beispiel, indem Sie Folgendes in das Feld "Benutzername" eingeben: "Robert '; DROP TABLE Users; -".Nach einer einfachen Ersetzung wird die Authentifizierungsabfrage zu:
SELECT BenutzerID FROM Benutzer WHERE Benutzername = 'Robert';DROP TABLE Benutzer; - 'AND Password =' falsepass '
Hinweis: Das Semikolon in einer SQL-Abfrage wird verwendet, um das Ende einer bestimmten Anweisung und den Beginn einer neuen Anweisung zu bezeichnen.
Was von der Datenbank ausgeführt wird als:
SELECT UserID FROM Benutzer WHERE UserName = 'Robert'
DROP TABLE Benutzer
Also haben wir einfach einen SQLI-Angriff benutzt, um die gesamte Users-Tabelle zu löschen.
Natürlich kann viel Schlimmeres erreicht werden, da der Angreifer abhängig von den erlaubten SQL-Berechtigungen Werte ändern, Tabellen( oder die gesamte Datenbank selbst) in eine Textdatei ablegen, neue Anmeldekonten erstellen oder sogar die gesamte Datenbankinstallation übernehmen kann.
Verhindern eines SQL-Injection-Angriffs
Wie bereits mehrfach erwähnt, ist ein SQL-Injection-Angriff leicht vermeidbar. Eine der Hauptregeln der Webentwicklung ist, dass Sie niemals blind auf Benutzereingaben vertrauen, wie wir es getan haben, als wir eine einfache Ersetzung in unserer Template-Abfrage oben durchgeführt haben.
Eine SQLI-Attacke wird leicht durch die so genannte Bereinigung Ihrer Eingaben verhindert. Der Bereinigungsvorgang ist eigentlich ziemlich trivial, da er im Grunde genommen alle Inline-Anführungszeichen( ') so behandelt, dass sie nicht dazu verwendet werden können, einen String innerhalb einer SQL-Anweisung vorzeitig zu beenden.
Wenn Sie beispielsweise "O'neil" in einer Datenbank suchen wollten, konnten Sie keine einfache Ersetzung verwenden, da das einfache Anführungszeichen nach dem O dazu führen würde, dass die Zeichenfolge vorzeitig beendet würde. Stattdessen bereinigen Sie es mithilfe des Escape-Zeichens der entsprechenden Datenbank. Nehmen wir an, dass das Escape-Zeichen für ein Inline-Anführungszeichen jedem Anführungszeichen ein \ -Symbol vorangestellt ist. So würde "O'neal" als "O \ 'neil" saniert werden.
Dieser einfache Sanierungsvorgang verhindert ziemlich genau einen SQLI-Angriff. Um dies zu veranschaulichen, lassen Sie uns unsere vorherigen Beispiele noch einmal ansehen und die resultierenden Abfragen sehen, wenn die Benutzereingabe bereinigt wird.
myuser '- / falsches :
SELECT BenutzerID FROM Benutzer WHERE Benutzername =' myuser \ '-' AND Passwort = 'falsches Passwort'
Da das einfache Zitat nach myuser maskiert ist( dh es wird als Teil des Ziels betrachtet)Wert), sucht die Datenbank nach dem Benutzernamen von "myuser '-".Da die Bindestriche im Stringwert und nicht in der SQL-Anweisung selbst enthalten sind, werden sie zusätzlich als Teil des Zielwerts betrachtet und nicht als SQL-Kommentar interpretiert.
Robert ';DROP TABLE Benutzer; - / false pass :
SELECT BenutzerID FROM Benutzer WHERE Benutzername = 'Robert \';DROP TABLE Benutzer; - 'AND Password =' falsepass '
Durch einfaches Umgehen des einfachen Anführungsstrichs nach Robert sind das Semikolon und die Bindestriche in der UserName-Suchzeichenfolge enthalten, so dass die Datenbank wortwörtlich nach "Robert" sucht; DROP TABLE Benutzer;- "anstatt die Tabelle zu löschen,
Zusammenfassung
Während sich Web-Attacken weiterentwickeln und ausgereifter werden oder sich auf einen anderen Zugangspunkt konzentrieren, ist es wichtig, sich vor bewährten Angriffen zu schützen, die von mehreren frei verfügbaren "Hacker-Tools" inspiriert wurden.
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 Arten von Angriffen verursacht werden kann, kann jedoch von Unannehmlichkeiten bis hin zu Katastrophen reichen, abhängig von den getroffenen Vorkehrungen.