Methoden zur Website Infiltrierung
|
27. April 2010
Posted in
Tipps und Tricks -
Webmaster
| Beitragsseiten |
|---|
| Methoden zur Website Infiltrierung |
| sql-injection |
| remote-file-inclusion |
| cross-site-scripting |
| Alle Seiten |
Wer eine eigene Web-Präsenz hat, ob kleine Homepage oder großes Portal, kann Opfer eines Angriffes werden und muss damit rechnen, dass jemand die Webseiten auf dem Server manipuliert. Möglich werden dadurch z. B. das Einschleusen von Viren, das Fälschen von Informationen oder das Verbreiten von Dateien mit illegalem Inhalt.
Für die Betreiber und Verantwortlichen derart missbrauchter Server kann das schmerzliche materielle und immaterielle Folgen haben - deshalb sollte man seine Webseiten konsequent überwachen und die gebräuchlichsten Methoden kennen.
Bei der Absicherung von Websites gibt es 2 Variablen, auf die ich als "normaler" Webmaster nicht wirklich Einfluß habe:
Welcher Webserver wird eingesetzt? Da heute in aller Regel PHP als Scriptsprache und MySQL als Datenbank zur Seitengenerierung herangezogen wird, muß ich natürlich mein Augenmerk auch auf diese Variablen richten.
Diese Komponenten sollten immer aktuell sein....nur habe ich darauf keinen wirklichen Einfluß, da ein Hoster sich unter Umständen weigert, die Software upzudaten (wie es z.B. vor Jahren Strato hartnäckig getan hat)....da bleibt als letzte Konsequenz nur, den Hoster zu wechseln.
Einfluß habe ich jedoch auf die für meine Seite eingesetzte Software, z.B. Forensoftware.
Hier gibt es zwar viel kostenlos erhältliche Software aus dem Open Source Bereich, die weite Verbreitung macht sie aber auch zu einem bevorzugten Angriffsziel.
Wie beim Betriebssystem auf dem lokalen Rechner gilt auch hier: Sicherheitsupdates unbedingt zeitnah einspielen!
Viele Communitys der verbreiteten Systeme wie z.B. Joomla informieren darüber in Forum, in Newslettern oder per RSS-Feed.
Diese Informationen sollte jeder Webmaster abonnieren bzw. regelmäßig im dazu gehörenden Forum nach neuen Beiträgen schauen.
Dafür braucht man kein Wissen, wie man PHP und MySQL programmiert und einsetzt (obwohl das Wissen darum sehr von Vorteil ist), sondern ich muß nur wissen, wie ich die vorhandene Version aktualisieren kann.....dafür liest man sich die immer beiliegende Readme-Datei durch, bevor man anfängt.
Am besten nimmt man die Seite kurzfristig vom Netz, aktualisiert die Software und testet die Seite, bevor man sie wieder online schaltet.
Viele Software bietet dafür die Möglichkeit, die Site offline zu schalten, sie ist dann für Besucher nicht mehr erreichbar.
Ebenso bietet es sich an, Trockenübungen mit einem lokal installiertem Webserver ohne Netzzugang nach Außen zu machen.
Neben der eigentlichen Software (Joomla, TYPO3, Drupal, Wordpress,...) müssen natürlich auch die Erweiterungen, die man einsetzt, aktuell gehalten werden.
Die Methoden
Wer die Methoden der Angreifer kennt, kann sich besser schützen.
Deshalb erläutere ich jetzt einige der gebräuchlichsten Methoden.
SQL-Injection
Wie vorher gesagt, verwenden viele Webseiten zur Seitengenerierung PHP und MySQL.
Bei einer SQL-Injection versucht der Angreifer, über Sicherheitslöscher in der Anwendung, die den Zugriff auf die Datenbank bereitstellt, über eigene Datenbankbefehle entweder die Datensätze zu manipulieren oder durch Kontrolle über den Server zu erlangen.
Dabei bedient sich der Angreifer Schwächen der Scripsprache PHP sowie Sicherheitslücken des jeweiligen Scriptes.
Ein Beispiel:
//Login
$_SESSION['username'] = $mysql_row['username'];
//...
//Seite2
$sql = "SELECT * FROM table WHERE username = '".$_SESSION['username']."'";
Wenn ich mich nun mit dem Username " abc' OR '1'='1" registiere, sieht die SQL Anweisung auf einmal so aus:
SELECT * FROM table WHERE username = 'abc' OR '1'='1'
Zack, hat man eine verwundbare Stelle, die man nutzen kann.
Remote File Inclusion
Der Begriff Remote File Inclusion beschreibt eine Sicherheitslücke in Skript-basierten Webanwendungen, die es einem Angreifer ermöglicht, unkontrolliert Programmcode in den Webserver einzuschleusen und dort auszuführen.
Gebräuchlich ist der Begriff Remote File Inclusion vor allem im Zusammenhang mit der Skriptsprache PHP, trifft jedoch auch auf andere Skriptsprachen zu, die ähnliche Fähigkeiten wie PHP bieten.
Erklärung am Beispiel PHP
Die PHP-Anweisungen include und require (sowie include_once und require_once) dienen zum Einbinden von zusätzlichen PHP-Skriptdateien in das laufende Skript.
Die Sicherheitslücke entsteht dann, wenn Benutzereingaben ungenügend geprüft als Parameter für diese Anweisung verwendet werden.
Das kann dazu führen, dass ungewollte PHP-Skriptdateien ausgeführt werden.
Im schlimmsten Fall kann ein Angreifer damit sogar Programmcode, der von einem fremden Webserver ausgeliefert wird, zur Ausführung bringen.
Meist werden Remote File Inclusion Angriffe dazu genutzt Webseiten zu "hacken" ohne das weitere schädliche Maßnahmen vom Angreifer ergriffen werden.
Ein Remote File Inclusion Angriff kann jedoch auch dazu genutzt werden, die Kontrolle über die Webseite zu übernehmen und dann beispielsweise den Server für den Versand von Spam Mails zu missbrauchen.
Die Gefahr eines solchen Angriffs besteht darin, dass der Webmaster für die begangenen rechtswidrigen Taten haftbar gemacht werden kann. Wird also ein Remote File Inclusion Angriff dazu genutzt illegale Handlungen mit dem übernommenen Server auszuführen, kann der betroffene Webmaster große Probleme bekommen.
Die grundlegenste Maßnahme, diese Angriffe zu verhindern, liegt in der Konfiguration von PHP selbst:
Dazu sind die Optionen register_globals und allow_url_fopen zu deaktivieren.
Da der Webmaster daruf nicht wirklich Einfluß nehmen kann, müßte er dazu seinen Hoster bitten, dies zu deaktivieren.
Mit Logfile Analysern kann jedoch der Webmaster überprüfen, ob und wie diese Angriffe (und andere) auf seiner Webseite erfolgen.
Die beste und nachhaltigste Abwehrmaßnahme ist jedoch eine Code-Änderung der verwendeten Scripte.
Mit der Version 5.2 ist die Konfigurationsoption allow_url_include hinzugekommen, mit der separat nur das Einbinden und Ausführen entfernter Ressourcen mittels der genannten PHP-Anweisungen verboten werden kann.
Cross-Site-Scripting
Cross-Site Scripting (auch als XSS bezeichnet) ist eine der derzeitig weitest verbreiteten Schwachstellen in Web-Anwendungen.
Die grundlegende Idee hinter XSS ist die Annahme, daß die Eingabe des Nutzers nicht korrekt gefiltert und überprüft wird.
Das gefährliche an XSS ist die irrige Annahme, das keine wichtigen Informationen auf diese Art und Weise gestohlen werden können:
Oftmals werden sensitive Inhalte wie Zugangsdaten oder persönliche und finanzielle Informationen in Cookies abgelegt, im Körper der Webseite selbst auftauchen oder ein Bestandteil der URL sein.
In all diesen Situationen kann die Information vom Angreifer gestohlen werden.
Grundsätzlich ist jede dynamisch generierte (der eigentliche Inhalt wird erst im Moment der Anforderung per Script generiert und als html ausgegeben) Website für XSS gefährdet, die Nutzereingaben nicht oder nur ungenügend filtert.
Verhindert werden kann XSS, indem das verwendete Script die Eingaben des Nutzers entsprechend filtert.
Methoden Code einzubetten
Die verwundbare Webseite direkt mit purem Skript-Code zu versorgen ist nur eine aus vielen Möglichkeiten, weitere Möglichkeiten sind, den Code in Links oder MouseOver-Effekte einzubetten.
Indem man die Webseite Skript-Code aus einer Datei einbauen lässt, erhält man die Möglichkeit, Größenbeschränkungen zu umgehen. Weiterhin erscheint der Code nicht direkt im HTML-Code und wird dadurch schwerer zurückverfolgbar.
Mitunter ist es möglich, JavaScript-Code innerhalb eines Image-Tags unterzubringen. Diese Schwachstelle kann in Fällen missbraucht werden, in denen die angegriffene Webseite zwar die Eingabe eines Nutzers korrekt filtert aber ein anderes Formular nutzt, um dem Nutzer zu erlauben, Bilder ohne Filterung in den Text einzubauen.
Sollte es nicht möglich sein einfache und doppelte Anführungszeichen gleichzeitig zu verwenden, besteht die Möglichkeit, Anführungszeichen innerhalb des JavaScript-Codes mit ihren entsprechenden Escapesequenzen zu ersetzen.
Browser, die auf der Gecko Rendering Engine aufbauen, wie z.B. Mozilla Firefox, werden oftmals Codeblöcke
ausführen, die keine schließenden Tags enthalten, da diese Engine automatische Schließungen vornimmt:
Codebeispiel: <a href="javascript:alert('vulnerable'); <
Das obige Beispiel schafft einen Link , welcher von einem < repräsentiert wird und beim Anklicken Code ausführt. Dies kann sehr hilfreich sein, wenn die Injektion innerhalb eines anderen Tags stattfindet, z.B. innerhalb eines iframe: Codebeispiel: <iframe src="javascript:alert('vulnerable');"></iframe>
Natürlich kann Script-Code auch direkt in einen Iframe injiziert werden.
XSS bietet jedoch wesentlich mehr Optionen als das simple Stehlen von Cookies:
Fehlinformation
Die document.write() Funktion hat großes Potential, Fehlinformationen zu platzieren.
Stelle Dir vor, eine große Nachrichtenseite sei anfällig für XSS. Ein Angreifer könnte jetzt eine URL erstellen, welche einen Artikel über nukleare Angriffe irgendwo in der Welt in die Seite einbaut und diese URL über E-Mails und Foren verbreiten. Die Nachricht selbst wird durch die Webseite Glaubwürdigkeit
erhalten und viele werden ihrem Inhalt glauben.- Verunstaltung
Beispielsweise könnte ein Bild auf der Webseite platziert werden oder der Browser des Nutzers zu einer anderen Seite weitergeleitet werden.
Nutzer überwachen
Ein cleverer Angreifer könnte Code erstellen, welcher jeden Link, auf den ein Nutzer klickt, zusammen mit der Zeit des Klicks an einen anderen Server sendet. Dieser Mechanismus an sich ist von Tools zur Erhebung von Website-Statistiken bekannt. - Generieren von Bandbreite
Nehmen wir einmal mehr die große Nachrichtenseite als Beispiel. Sie wird höchstwahrscheinlich täglich mehrere Tausend Besucher haben.
Wenn ein Angreifer Code injiziert, der bei jeder Ausführung die größte verfügbare Datei vom Server eines Opfers lädt, generiert dies massive Bandbreite, welche genug sein sollte, um jeden beliebigen kleinen und auch noch viele mittlere Server per DoS (Denyl of Service)außer Gefecht zu setzen.
Abwehrmaßnahmen
Es gibt im Großen und Ganzen zwei Ansätze, XSS-Attacken zu verhindern:
Entweder escapet man alle Sonderzeichen, oder man nutzt umfassende Listen und reguläre Ausdrücke, um gefährliche Tags zu entfernen. Beide Methoden haben sowohl Vorteile als auch Nachteile.
Alle Sonderzeichen zu escapen ist der einfachste und sicherste Weg mit XSS umzugehen. Der große Nachteil ist jedoch, dass alle Sonderzeichen und somit auch alle Tags geblockt werden. Dies hält den Nutzer davon ab, jegliche HTML-artige Tags zum Formatieren seines Textes zu nutzen. Soll dies, z.B. in Foren, dem Nutzer dennoch erlaubt werden, muß ein Interface eingebaut werden, welches die Formatierung ohne Tags
vornimmt.
Listenbasiertes Filtern hingegen muß sich mit diesem Problem nicht auseinandersetzen, da es nicht
alle, sondern lediglich gefährliche Tags entfernt, für die reguläre Ausdrücke geschrieben wurden. Dies ist auch gleich der größte Nachteil dieses Ansatzes, denn von Zeit zu Zeit entstehen neue Angriffsmuster, die dann XSS-Attacken ermöglichen. Aus diesem Grunde müssen die regulären Ausdrücke der Filterlisten permanent auf dem neusten Stand gehalten werden. Ebenso macht diese Methode anfällig gegen Attacken, die noch nicht veröffentlicht wurden.
Bitte beachtet die Nutzungsbedingungen
Zu beachten sind auch diese Regeln.
Wer sich nicht an diese Regeln hält, bekommt das Schreibrecht für eine gewisse Zeit entzogen.
Dauerndes Verstoßen gegen die Regeln zieht eine Sperrung des Zugangs nach sich.