Logo

Attack-Forum

Startseite / ImpressumInfos | Impressum | Mitglieder | Blog | Suche

Login Benutzername oder eMail:

Kennwort: (Vergessen?)




Neues Mitglied werden
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 dieses Forum wurden drei verschiedene XSS-Würmer (In unterschiedlichen größen und Eigenschaften) entwickelt:

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

© 08.03.2023 by Michael Engelke

Server: Apache/2.4.57 (Debian) PHP/5.3.10-1ubuntu3.23 SQLite/3.40.1

URL-Attack (Weitere Informationen in der Link-Beschreibung)
  1. Cross-Site-Scripting (Sicherheitslücke in der Suchfunktion)
  2. Session-ID-Angriffe durch Festlegung und Enführung
  3. SQL-Injection (Sicherheitslücke in der Profilanzeige - zum Daten auslesen)
  4. SQL-Injection (Sicherheitslücke beim Abmelden - für Daten Änderungen)
  5. SQL-Injection & Cross-Site-Scripting (Sicherheitslücken Kombinieren)
  6. XSS-Wurm mit Cross-Site-Scripting in der Profilanzeige (Daten vom Wurm)
  7. Code-Injection (SQL-Injection & XSS) über die Creole-Formatierung:

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!)


© 08.03.2023 by Michael Engelke