gulli: Paros Man in the Middle-Proxy mit eigenen Plugins erweitern

Paros Man in the Middle-Proxy mit eigenen Plugins erweitern

Der Web Proxy Paros, einer der beliebtesten Web Proxies für Penetrationstests (In der 2006 Liste der Top 100 Tools von sectools.org landete er auf Platz 16), wurde in der Version 2.0 mit einem integrierten Securityscanner ausgestattet. Paros verfügt in der aktuellen Version (3.2.13) bereits über eine Reihe von nützlichen Plugins, kann jedoch, was den Umfang betrifft, nicht mit kommerziellen Produkten mithalten. Durch die Veröffentlichung dieses praktischen Tools als Open Source, kann dieser Misstand behoben werden.

Der Scanner

Der in Paros integrierte Scanner wird direkt aus Paros selbst aufgerufen. Um ihn nutzen zu können, wird der Paros Proxy als lokaler Proxy in die Konfiguration des Webbrowsers eingetragen und die Webseite besucht. Danach ist auf der linken Seite der Paros GUI (im Sites Panel) die zu untersuchende Webseite auswählbar. Hierbei kann entweder ein kompletter Host, aber auch eine einzelne Seite einer Webapplikation selektiert werden. Die Anwahl des Menüpunktes Analyse>Scan startet dann den eigentlichen Scanvorgang.
Nach welchen Schwachstellen genau geprüft werden soll, kann über die so genannte Scanpolicy (erreichbar über den Menüpunk Analyse>Scan Policy…) festgelegt werden. Hier hat man die Möglichkeit, ganze Kategorien von Tests zu aktivieren, Paros erlaubt aber auch die gezielte Auswahl einzelner Tests.

Paros Scan Policy: Einstellungen

Die ausgewählten Tests werden dann auf jedem, der im Sites Panel selektierte Ziele (sowie deren Unterordner) durchgeführt.

Die einzelnen Testkategorien

Wie schon erwähnt fasst Paros die einzelnen Tests in einer Reihe von Gruppen bzw. Kategorien zusammen. Im Einzelnen handelt es sich dabei um:

Information gathering
Hierunter verstehen sich alle Tests, die einem Angreifer zusätzliche Informationen für spätere Angriffe bieten könnten. Beispiele hierfür sind das Auffinden von internen IP Adressen im HTML Dokument oder aber die Suche nach Backups oder veralteten Versionen der momentan getesteten Datei (diese haben oft die Endungen bak oder old).

Client Browser
In der Kategorie Client Browser befinden sich Tests, die mit der Sicherheit auf der Seite des Clients zu tun haben. Ein Beispiel hierfür ist der Test, ob Passwortfelder im Browser gecachet werden.

Server Security
Hier sind alle Tests zusammengefasst, welche sich mit der Sicherheit des Webservers, der die Webanwendung hostet befassen. Ein typischer Vertreter dieser Kategorie ist das Suchen nach Default Files, also Dateien, die bei einer typischen Installation eines Webservers existieren. Dadurch lässt sich oft der verwendete Webserver identifizieren.

Miscellaneous
Tests, die nicht in eine der anderen Kategorien passen sind in dieser Gruppe zusammengefasst. In der aktuellen Version von Paros existiert noch kein Plugin in dieser Kategorie.

Injection
Alle Tests, die sich mit dem Einschleusen von Befehlen befassen, sind in dieser Kategorie versammelt. Prominente Vertreter hierfür sind beispielsweise Tests für SQL- oder HTML Injection.

Das Testscript

Wie bereits beschrieben sind die mitgelieferten Plugins von Paros nicht besonders umfangreich. Dies soll an einem kleinen Beispiel demonstriert werden: Listing 1 ist ein PHP Script (tatsächlich handelt es sich nur um eine Zeile PHP Code). Es macht nichts anderes, als die aufgerufene URL anzuzeigen. Die Variable SERVER['PHP_SELF'] findet man in vielen PHP Scripten, beispielsweise in Formularen, die auf sich selbst verweisen.

Listing 1. PHP Demoscript für eine Cross Site Scripting Lücke (xsstest.php)

<html><head>

<title>hakin9 xss test</title></head>

<body>

<h1>

<?php echo $_SERVER['PHP_SELF']; ?>

</h1>

</body></html>

Leider haben wir uns mit diesem kleinen Script auch schon eine so genannte Cross Site Scripting (XSS) Lücke eingefangen. Dies beweist folgender Aufruf:

h**p://zielhost/xsstest.php/<script>alert("hakin9");</script>

Demonstration der XSS-Lücke im Testscript

Nun wollen wir das Script durch den Scanner von Paros laufen lassen. Hierzu tragen wir, falls noch nicht geschehen, Paros als lokalen Proxy in den Proxyeinstellungen unseres Browsers ein und besuchen danach das Testscript auf dem Webserver. Dieses erscheint darauf als Eintrag im „Site“ Panel von Paros. Wir vergewissern uns, dass in der Scanpolicy alle Tests aktiviert sind und lassen den Scanner das Script prüfen.
Der Scanner von Paros hat die XSS Lücke, trotz aktivierter XSS Tests nicht gefunden. Offensichtlich wird eine solche Schwachstelle vom Scanner nicht geprüft. Das lässt sich aber durch Implementierung eines eigenen Tests ändern. Warum die internen Tests von Paros diese Schwachstelle nicht gefunden haben, klären wir im Laufe des Artikels.
Die einzelnen Tests des Scanners werden in Form von Plugins implementiert. Machen wir uns also an das Erstellen eines solchen Plugins.

Paros in Eclipse laden

Wie viele Javaprogramme wurde auch Paros mit Hilfe der IDE Eclipse entwickelt. Daher liegt es nahe, diese auch für die Entwicklung des eigentlichen Plugins zu verwenden. Hierzu laden wir zunächst den Paros Quellcode von der SourceForge Seite herunter und entpacken ihn in ein eigenes Verzeichnis.
In Eclipse wird der Quellcode dann per Menüpunkt File->Import in den Workspace importiert. Dort muss unter dem Ordner General die Option Existing Projects into Workspace ausgewählt werden. Ein Klick auf den Button Next> bringt uns in das nächste Dialogfeld. Hier wird in dem Eingabefeld Select root directory der Ordner des Quellcodes eingetragen. Danach wird im Feld Projects das Projekt parosng ausgewählt. Optional kann man sich den Quellcode über die Checkbox Copy projects into workspace in den Workspace kopieren. Ein Klick auf den Button Finish importiert dann das eigentliche Projekt.

Der Aufbau der verschiedenen Klassen unterscheidet sich dabei nur minimal, viel wichtiger ist, wann Paros die verschiedenen Klassentypen aufruft:

AbstractHostPlugin
Plugins, welche sich von dieser Klasse ableiten werden nur für den Host selbst ausgeführt. Ein Beispiel für ein solches Plugin ist ein Test, der nach einer Standartdatei eines Webservers sucht.

AbstractDefaultFilePlugin
Diese Klasse ist AbstractHostPlugin nicht unähnlich (tatsächlich ist es eine Erweiterung der Klasse). Sie funktioniert genau gleich wie AbstractHostPlugin, jedoch ersetzt Sie den String @cgibin in einem Teststring durch eine Reihe verschiedener Strings (beispielsweise cgi-bin, cgi-local, cgi). Diese Klasse ist ideal für die Suche nach Scripts, die sich typischerweise im CGI Verzeichnis eines Servers befinden.

AbstractAppPlugin
Plugins, die sich von dieser Klasse ableiten, werden auf jeder Seite einer Webapplikation ausgeführt. Ein Beispiel hierfür ist das Suchen nach alten Versionen einer Datei.

AbstractAppParamPlugin
Plugins dieses Typs werden von Paros für die Parameter eines Scripts aufgerufen, also alle Parameter die per GET in der URL (in der Form page.php?paramter1=wert1) oder per POST Request übermittelt werden. Beispiele hierfür sind die Plugins für Cross Site Scripting oder SQL Injections.
Mit diesem Wissen kennen wir schon die Ursache, warum die bisherigen Plugins an unserem Testscript scheitern: Alle Tests für XSS Schwachstellen leiten sich von der Klasse AbstractAppParamPlugin ab. Der schadhafte Scriptcode wird jedoch nicht als GET- oder POST-Parameter an das Script übergeben, sondern er befindet sich in der URL selbst. Wir benötigen also ein Plugin, welches sich von AbstractAppPlugin ableitet.

Das eigentliche Plugin
Wir erzeugen also im Package org.parosproxy.paros.core.scanner.plugin eine neue Klasse mit den Namen TestCrossSiteScriptInPath. Der Quellcode der Klasse findet sich in Listing 2.

Ein großer Teil des Codes besteht aus der Implementierung der Methoden, die von der abstrakten Basisklasse AbstractPlugin vorgegeben werden. Diese sind im Kasten Methoden von AbstractPlugin erklärt. Der eigentliche Test findet in der Methode scan statt. Hier wird zunächst die aktuelle URL ausgelesen und in der Variable path gespeichert. Danach wird diese mit den String XSS kombiniert. Als nächstes wird diese neue URL an den Server gesendet und die Antwort in der Variable result gespeichert. Befindet sich in der Antwort nun der injizierte Code so haben wir mit hoher Wahrscheinlichkeit eine Cross Site Scripting Lücke gefunden. Darauf wird ein neuer Alert mit der Methode bingo() erzeugt.
Prüfung und Ausblick
Ein Scan mit unserem neuen Plugin zeigt, dass die Schwachstelle diesmal erfolgreich erkannt wird. Wir haben also den Scanner von Paros um ein sinnvolles Plugin erweitert. Leider ist dieses Plugin noch nicht perfekt, da der XSS Code nur am Ende der URL eingefügt wird, dies kann jedoch durch eine entsprechende Reprogrammierung gelöst werden.
Auch sind eine Reihe weiterer Plugins denkbar, mit denen man das Testen von Webanwendungen vereinfachen kann, beispielsweise ein Plugin, welches die Datei robots.txt auswertet oder automatisiert versucht Kommandos auf Betriebssystemebene auszuführen.

Listing 2. Java Quellcode des neuen Plugins (TestCrossSiteScriptInPath.java)

package org.parosproxy.paros.core.scanner.plugin;

// © it.sec 2007

// Hans Martin Muench

// Version 1.0


import java.io.IOException;

import java.util.regex.Pattern;


import org.apache.commons.httpclient.URI;

import org.parosproxy.paros.Constant;

import org.parosproxy.paros.core.scanner.AbstractAppPlugin;

import org.parosproxy.paros.core.scanner.Alert;

import org.parosproxy.paros.core.scanner.Category;

import org.parosproxy.paros.network.HttpMessage;


public class TestCrossSiteScriptInPath extends AbstractAppPlugin {


  private static final String XSS =

    "<SCRIPT>alert(\"hackin9\");</SCRIPT>";

  public int getId() {

    return 40006;

  public String getName() {

    return "Cross site scripting in path";

  public String[] getDependency() {

    return null;

  public String getDescription() {

     return "XSS in path is possible";

  public String getSolution() {

    return "Check all entries from the client";


  public String getReference() {

    return "http://www.cgisecurity.org/articles/xss-faq.shtml";

  public int getCategory() {

    return Category.INJECTION;

  public void init() {

  public void scan() {


    String result = null;

    String path = null;

    URI uri = null;

    int pos = 0;

    HttpMessage msg = getNewMsg();

    try {

      uri = msg.getRequestHeader().getURI();

      path  = uri.getPath();

    } catch (Exception e) {

      e.printStackTrace();

    if (path == null || path.equals("")) {

      return;

   msg = getNewMsg();

   String newPath = path + "/" + XSS;


   try {

     uri.setPath(newPath);

     msg.getRequestHeader().setURI(uri);

     sendAndReceive(msg);

   } catch (Exception e) {

     e.printStackTrace();

   result = msg.getResponseBody().toString();

   pos = result.indexOf(XSS);

   if (pos == -1) return;

   bingo(Alert.RISK_MEDIUM, Alert.WARNING,

     uri.toString(), "", "", msg);

Über den Autor
Hans-Martin Münch besitzt mehrjährige Erfahrung im IT Security Bereich. Er arbeitet als Consultant für die Firma it.sec, bei der er hauptsächlich für die Durchführung von Penetrationstests verantwortlich ist.

AbstractPlugin
Wie bereits erwähnt basieren alle Plugins indirekt auf der abstrakten Basisklasse AbstractPlugin. Diese gibt eine Reihe von Methoden vor, die von jedem Plugin implementiert werden müssen:
   getID( ) – Liefert eine eindeutige ID des Plugins zurück. Diese kann prinzipiell frei vergeben werden, jedoch sollte man sich hier an die Vorgaben in der Datei test_list.txt im doc Verzeichnis des Quellcodepaketes von Paros halten;
   getName( ) – Der Name des Plugins. Dieser wird im Report und bei der Auswahl der Scanpolicy angezeigt;
   getDependency( ) – Gibt ein StringArray mit den Namen der Plugins zurück, die vor diesem Plugin ausgeführt werden müssen;
   getDescription( ) – Gibt einen String mit einer kurzen Beschreibung des Tests wieder. Dieser wird später im HTML Report des Scans aufgeführt;
   getCategory( ) – Gibt die Kategorie des Plugins zurück. Dabei handelt es sich um ein Element der Klasse Category;
   getSolution( ) – Ein String, der erklärt, wie die Schwachstelle am besten beseitigt wird. Dieser Text wird in den HTML Report eingebaut;
   GetReference( ) – String mit Verweisen auf Referenzen, beispielsweise CVE Ids. Auch dieser String wird Teil des HTML Reports;
   Scan( ) – Der Aufruf dieser Methode führt den eigentlichen Test durch.

Im Internet
   www.parosproxy.org – Paros Proxy Webseite;
   www.eclipse.org – Seite der Eclipse IDE;
   www.sectools.org – Seite der Top 100 Security Tools.