Attack-Forum

Dieses Forum (Basierend auf PHP 4.3+ und SQLite 2.8) ist für die Verdeutlichung von Angriffen und Sicherheitslücken mit Cross-Site-Scripting und SQL-Injection gedacht!
Es soll zeigen, wie man es NICHT machen soll, und was passieren kann, wenn man es DOCH macht ;-)

Zur Demonstration wurden einige (abschaltbare) Sicherheitslücken eingebaut, die das Einschleusen von beliebigen Code vom Webbrowser ermöglichen!
Diese Lücken befinden sich in der Suchfunktion, Profilanzeige, Abmeldefunktion, Chat-Funktion und im Forum selbst, die z.B. mit vorgegebenen Beispielen ausgenutzt werden können. (Siehe unten!)

Für den Betrieb des Forums wird ein Apache-Server empfohlen, wo die Directive Pathinfo aktiviert ist. Als alternative geht auch der Eingebaute Webserver in PHP.
Als Datenbank wird SQLite 2.8 benötigt, was leider nur in PHP zwischen 4.4 und 5.3 unterstützt wird. (Ab PHP 5.4 ist nur noch SQLite 3 verfügbar, was ein zusätzliches Addon erfordert) PHP sollte so konfiguriert werden, dass Globals und Magic Quotes deaktiviert ist. Das Forum wird mit aktuellen PHP-Versionen (Ab Version 7.0 oder neuer) wegen preg_replace/eval, nicht mehr funktionieren. (Dazu wird es in Zukunft keinen Workaround geben!)

Alle Beispiel-Angriffe wurden für den Mozilla Firefox entwickelt und getestet.

Für andere Webbrowser wie z.B. Opera oder Internet_Explorer müssen die Angriffe eventuell entsprechend angepasst werden.
Für Google Chrome sind sämtliche Angriffe mit Cross-Site-Scripting, die per GET über die URL ergeschleust werden, nicht so ohne weiteres möglich, da sie erkannt und größtenteils abgefangen werden! Verschleierte Methoden, wie z.B. Base64 führen durchaus zum erfolgreichen Angriff! Entsprechende Angriffe sind mit "Chrome" gekenntzeichnet!
Alle Angriffe laufen über den Webbrowser - d.H. Wird der Webbrowser geschlossen, sind alle Angriffe beendet, bis dieses Forum wieder aufgerufen wird.

Für dieses Forum wurden drei verschiedene XSS-Würmer (In unterschiedlichen größen und Eigenschaften) entwickelt:

Der umfangreiche Bot-Wurm (knapp 3 KB) kopiert sich in das Benutzerprofil. Sobald man im Forum angemeldet ist und sich den Teil anschaut, der vom Wurm Infiziert wurde (z.B. das Benutzerprofil), kopiert sich der Wurm automatisch und unsichtbar in das eigene Benutzerprofil und greift dabei alle Persönlichen Daten ab. Ist kein Benutzer angemeldet, wird das Login-Formular modifiziert, um die eingegebenen Login-Daten abzugreifen. Anschließend wartet ein eingebauter Bot via Chat auf Befehle vom Control-Center. (Rückmeldungen vom Bot sind nur dann Möglich, wenn der Benutzer gerade angemeldet ist)
Der einfache Wurm (knapp 500 Bytes) kopiert sich ebenfalls in das Benutzerprofil, enthält aber dabei keine Tarnmöglichkeit oder weitere Angriffsfunktionen und löscht bei der Infizierung das ursprüngliche Benutzerprofil. Kann dafür optional unsichtbar eine Webseite aufrufen.
Der Mini-Tagline Wurm kann sich aufgrund seiner sehr kleinen größe (ca. 120 Bytes), nur über GET in die Tagline des aktuellen Benutzers kopieren! Dabei wird auch der Tagline-Text des Benutzers durch den Wurm überschrieben!

Genau genommen ist dieses Forum ein Hackerwerkzeug und fällt unter dem Hackerparagraf, da die einzelnen Beispiel-Angriffe Theoretisch auch auf andere Webpräsenzen im Internet angewendet werden können! Genauso wie eine Suchmaschine zum suchen von Informationen oder zum aufspühren von anfälligen Webseiten eingesetzt werden kann. Der eigentliche Zweck dieses Forums dient zur Aufklärung, damit Sie die Angriffe verstehen und ihre Webauftritte sicher machen können!

Das Forum selber besteht nur aus einer einzigen Quelltextdatei und wurde als Proof of Concept für unübersichtlichen und schlechten Programmierstil, ohne eigene Funktionen geschrieben. (Mit Ausnahme der Chat-Funktion und die Angriffe, die auf JavaScript basieren). Die Creole-Formatierung wurde mit einem Array von Regulären Ausdrücken umgesetzt, die Teilweise aktiven Code beinhalten.
Unterstützt werden alle für Foren üblichen Grundfunktion, wie: Administration, Backup, BBCode, Benutzerkonten, Ajax-Chat (Optional mit Diffie-Hellman & AES Ende-zu-Ende-Verschlüsselung oder auch Chat ohne JavaScript), Content-Management-System, Creole, Datei-Upload, Datensicherung, Debug-Modus, Feeds, Pagination, Salt-Login (Nur im Sicherheitsmodus), Session-Sitzung (Nur mit Cookies), Smilies, Suchfunktion, SQLite-Konsole und Unicodes.

Aus Sicherheitsgründen sind die Angriffe mit relativen bzw. lokalen Pfaden entwickelt worden, so dass die Daten das Forum nie wirklich verlassen. (Mit dem Nachteil, dass viele Security-Systeme die Angriffe als ungefährlich einstufen.) PHP-Code injection wurde aus Sicherheitsgründen im Quelltext deaktiviert. Und sollte nur im abgeschotteten Lokalen Netzwerk aktiviert und getestet werden!

Alle Daten werden in Klartext gespeichert und können durch Angriffe ausgelesen werden!

Lizenz zum Quelltext des Forums: GNU General Public License - Projektseite: MEngelke.de

Beschreibung und Erläuterungen:
Die ersten Angriffslinks beschränken sich auf Cross-Site-Scripting, was per JavaScript nur im Webbrowser selbst ausgeführt wird. Man kann beliebige Inhalte auslesen/erzeugen und Benutzereingaben abfangen/einschleusen. Und unter idealen Voraussetzungen, ist es möglich Schadsoftware auf dem Anwender-PC zu installieren.
Da Google Chrome die Angriffe über die URL erfolgreich abwehren kann, wurden einige Angriffe (Nicht alle) entsprechend mit Base64 verschleiert und mit "Chrome" gekennzeichnet. (Dieser Trick setzt voraus, dass die Webanwendung diese Kodierungsart unterstützt.)
Teilweise sind die Angriffslinks etwas länger geworden (bis zu 6 KB). d.H. einige Webbrowser kommen mit den überlangen Urls nicht klar. Im dem Fall können Sie die Chrome-Links probieren, da diese durch die alternative kodierung etwas kürzer sind.
Die Login-Angriffe sind Theoretisch auch ohne Cross-Site-Scripting möglich, da hierbei der Login-Prozess direkt mit Wörterbüchern / Brute-Force angegriffen wird. (Für solche Angriffe kommen normalerweise externe Hackerwerkzeuge zum Einsatz!)

Die Angriffe mit SQL-Injection tricksen die Webanwendung aus, um direkt auf die Datenbank zugreifen zu können. Da die meisten Webanwendung ihrer eigenen Datenbank vertrauen, werden die Inhalte meistens ungefiltert ausgegeben. Es können dabei auch beliebige (auch interne und geheime) Daten ausgelesen werden. Unter bestimmten Bedingungen, können auch Daten verändert oder hinzugefügt werden. Reine Angriffe mit SQL-Injection funktionieren auch ohne JavaScript, da nicht der Webbrowser vom Anwender, sondern die Datenbank des Betreibers angegriffen wird!

Kombiniert man verschiedene Schwachstellen (In diesem Fall Cross-Site-Scripting mit SQL-Injection), können dadurch neue Sicherheitslücken entstehen, da man die schwächen mit den stärken der einzelnen Varianten ausgleichen kann oder sich hinter einer Sicherheitslücke noch weitere Angriffsmöglichkeiten lauern können.

Ein XSS-Wurm ist besonders gefährlich, weil es nicht von jeden Antivirenprogramm gefunden werden kann. Der Wurm wird aus der Webanwendung geladen und kann ohne auf dem Computer gespeichert zu werden, vom Webbrowser ausgeführt werden. Auch wenn die Rechte im Webbrowser sehr bescheiden sind, kann der Wurm dennoch in gewissen Rahmen den Webbrowser kontrollieren. (z.B. sich weiter verbreiten und die Identität des Benutzer annehmen oder stehlen) Steht der Wurm in direkter verbindung zum Angreifer, so kann der "Bot" jederzeit beliebige Befehle auf dem Opfer-PC ausführen. In der Regel ist es ein ganzer Schwarm von Bots, die ganze Infrastrukturen angreifen und lahm legen können.

Mit Code injection ist alles möglich. Man kann den kompletten Server übernehmen und alles runterladen, was darauf gespeichert ist oder hochladen und ausführen, was man möchte. Die Lücke steckt hier in der Creole-Formatierung und muss explizit im Quelltext aktiviert werden. Die entsprechenden Angriffslinks benötigen hier nur zur Präsentation Cross-Site-Scripting und SQL-Injection. (Technisch wird nur der Server angegriffen!)