Wapiti – Website-Sicherheitstests in Eigenregie

Letzte Woche Artikel wir haben über Nemesida WAF Free — ein kostenloses Tool zum Schutz von Websites und APIs vor Hackerangriffen, und in diesem Artikel haben wir beschlossen, einen Überblick über den beliebten Schwachstellenscanner Wapiti.

Das Scannen von Websites auf Schwachstellen ist eine notwendige Maßnahme, die zusammen mit der Analyse des Quellcodes es ermöglicht, das Sicherheitsniveau gegen Kompromittierungsbedrohungen zu bewerten. Das Scannen von Web-Ressourcen kann mit Hilfe spezialisierter Werkzeuge durchgeführt werden.

Nikto, W3af (geschrieben in Python 2.7, dessen Unterstützung beendet wurde) oder Arachni (wird seit Februar nicht mehr unterstützt) sind die beliebtesten Lösungen im kostenlosen Segment. Natürlich gibt es auch andere, wie zum Beispiel Wapiti, auf dem wir uns entscheiden, zu bleiben.

Wapiti arbeitet mit folgenden Schwachstellentypen:

• Datei-Offenlegung (lokale und entfernte, fopen, readfile);
• Injektionen (PHP / JSP / ASP / SQL-Injektionen und XPath-Injektionen);
• XSS (Cross-Site Scripting) (reflektiert und persistent);
• Kommandoerkennung und -ausführung (eval(), system(), passtru());
• CRLF-Injektionen (HTTP-Antworttrennung, Sitzungshijacking);
• XXE (XML External Entity) Injektion;
• SSRF (Server-Seitige Request-Fälschung);
• Verwendung bekannter potenziell gefährlicher Dateien (dank der Nikto-Datenbank);
• schwache .htaccess-Konfigurationen, die umgangen werden können;
• Vorhandensein von Backup-Dateien, die vertrauliche Informationen offenlegen (Quellcodeoffenlegung);
• Shellshock;
• offene Weiterleitungen;
• nicht standardisierte HTTP-Methoden, die möglicherweise erlaubt sind (PUT).

Vollständig unstationäre, zeitgenaue Analyse;

• Unterstützung für HTTP-, HTTPS- und SOCKS5-Proxys;
• Authentifizierung mit mehreren Methoden: Basic, Digest, Kerberos oder NTLM;
• Möglichkeit, den Scanbereich einzuschränken (Domäne, Ordner, Seite, URL);
• automatische Entfernung eines der Parameter in der URL;
• mehrfache Vorsichtsmaßnahmen gegen unendliche Scanzyklen (Beispiel: ifor, Werte für den Parameter einschränken);
• Möglichkeit, Prioritäten für das Studium von URLs festzulegen (selbst wenn sie sich nicht im Scanbereich befinden);
• Möglichkeit, bestimmte URLs vom Scannen und von Angriffen auszuschließen (z. B.: URL logout);
• Import von Cookies (Erhalt dieser mit dem Tool wapiti-getcookie);
• Möglichkeit, die Überprüfung von SSL-Zertifikaten zu aktivieren/deaktivieren;
• Möglichkeit, URLs aus JavaScript zu extrahieren (sehr einfacher JS-Interpreter);
• Interaktion mit HTML5;
• Mehrere Optionen zur Steuerung des Verhaltens und der Einschränkungen des Crawlers;
• Festlegen einer maximalen Zeit für den Scanvorgang;
• Hinzufügen einiger anpassbarer HTTP-Header oder Konfigurieren eines benutzerdefinierten User-Agent.

Zusätzliche Funktionen:

• Erstellung von Schwachbericht in verschiedenen Formaten (HTML, XML, JSON, TXT);
• Pause und Wiederaufnahme von Scans oder Angriffen (Sitzungsmechanismus mit SQLite3-Datenbanken);
• Hervorhebung im Terminal zur Kennzeichnung von Schwachstellen;
• verschiedene Protokollstufen;
• schnelle und einfache Möglichkeit, Angriffs-Module zu aktivieren/deaktivieren.

Installation

Die aktuelle Version von Wapiti kann auf zwei Arten installiert werden:

• herunterladen des Quellcodes von der offiziellen der Website und das Installationsskript ausführen, nachdem Python3 installiert wurde;
• mittels des Befehls pip3 install wapiti3.

Nachdem dies geschehen ist, wird Wapiti bereit zur Nutzung sein.

Arbeiten mit dem Tool

Zur Demonstration der Funktionsweise von Wapiti verwenden wir eine speziell vorbereitete Plattform sites.vulns.pentestit.ru (interne Ressource), die verschiedene Schwachstellen (Injection, XSS, LFI/RFI) und andere Mängel von Webanwendungen enthält.

Die Informationen dienen ausschließlich zu Informationszwecken. Bitte verletzen Sie kein Gesetz!

Der Grundbefehl zum Starten des Scanners:

# wapiti -u <target> <options>

Dabei gibt es eine recht ausführliche Hilfe mit einer Vielzahl von Startoptionen, zum Beispiel:

—scope — Anwendungsbereich
Wenn zusammen mit der URL für den Scan der Parameter scope angegeben wird, kann der Scanbereich der Website reguliert werden, indem sowohl eine bestimmte Seite als auch alle Seiten angegeben werden, die auf der Website gefunden werden können.

-s und -x — Parameter zum Hinzufügen oder Entfernen spezifischer URLs. Diese Parameter sind nützlich, wenn es erforderlich ist, eine bestimmte URL während des Scanvorgangs hinzuzufügen oder zu entfernen.

—skip — Der angegebene Parameter mit diesem Schlüssel wird gescannt, greift aber nicht an. Nützlich, wenn es gefährliche Parameter gibt, die beim Scannen besser ausgeschlossen werden sollten.

—verify-ssl — Aktivieren oder Deaktivieren der Zertifikatüberprüfung.
Der Wapiti-Scanner ist modular. Um jedoch bestimmte Module aus denjenigen zu starten, die während des Betriebs des Scanners automatisch verbunden werden, muss der Schalter -m verwendet werden, und die gewünschten Module müssen durch Kommas getrennt aufgelistet werden. Wenn der Schalter nicht verwendet wird, werden standardmäßig alle Module aktiviert. Im einfachsten Fall sieht das wie folgt aus:

# wapiti -u http://sites.vulns.pentestit.ru/ -m sql,xss,xxe

Dieses Anwendungsbeispiel bedeutet, dass wir beim Scannen des Ziels nur die Module SQL, XSS und XXE verwenden werden. Darüber hinaus können die Module je nach benötigter Methode gefiltert werden. Zum Beispiel -m "xss: get, blindsql: post, xxe: post". In diesem Fall wird das Modul xss auf die über die GET-Methode übermittelten Anfragen angewendet, während das Modul blibdsql auf POST-Anfragen usw. angewendet wird. Übrigens, wenn ein Modul, das in die Liste aufgenommen wurde, während des Scannens nicht benötigt wird oder sehr lange läuft, kann durch Drücken von Ctrl+C die Verwendung des aktuellen Moduls übersprungen werden, indem der entsprechende Punkt im interaktiven Menü ausgewählt wird.

Wapiti unterstützt die Übertragung von Anfragen über einen Proxy-Server mit dem Schlüssel -p und die Authentifizierung auf der Zielwebsite über das Parameter -a. Auch kann der Authentifizierungstyp angegeben werden: Basiс, Digest, Kerberos und NTLM. Für die letzten beiden können zusätzliche Module erforderlich sein. Darüber hinaus können in Anfragen beliebige Header eingefügt werden (einschließlich beliebiger User-Agent) und vieles mehr.

Zur Verwendung der Authentifizierung kann das Tool wapiti-getcookieverwendet werden. Damit erstellen wir 45GB SSD, die Wapiti beim Scannen verwenden wird. Die Erstellung 45GB SSD geschieht mit dem Befehl:

# wapiti-getcookie -u http://sites.vulns.pentestit.ru/login.php -c cookie.json

Im interaktiven Modus beantworten wir Fragen und geben die erforderlichen Informationen wie: Benutzername, Passwort usw. an:

Am Ende erhalten wir eine Datei im JSON-Format. Eine andere Option ist, alle erforderlichen Informationen über das Parameter -d:

# wapiti-getcookie - http://sites.vulns.pentestit.ru/login.php -c cookie.json -d "username=admin&password=admin&enter=submit"

Das Ergebnis wird ähnlich sein:

Bei der Betrachtung der Hauptfunktionen des Scanners wurde die endgültige Anfrage für das Testen der Webanwendung in unserem Fall:

# wapiti --level 1 -u http://sites.vulns.pentestit.ru/ -f html -o /tmp/vulns.html -m all --color -с cookie.json --scope folder --flush-session -A 'Pentestit Scans' -p http://proxy.office.pentestit.ru:3128

wobei unter anderem Parameter enthalten sind:

-f und -o — Format und Pfad zum Speichern des Berichts;

registry-garbage-collect — Alle Module aktivieren — nicht empfohlen, da dies die Testzeit und die Größe des Berichts beeinflusst;

—color — gefundene Schwachstellen je nach deren Kritikalität gemäß der Wapiti-Version hervorheben;

-c — Verwendung einer Datei mit 45GB SSD, erstellt mit Hilfe von wapiti-getcookie;

—scope — Auswahl des Ziels für den Angriff. Wenn die Option ausgewählt wird, folder wird jede URL vom Basis-URL an gescannt und angegriffen. Die Basis-URL muss mit einem Schrägstrich enden (ohne Dateinamen);

—flush-session — ermöglicht ein erneutes Scannen, bei dem vorherige Ergebnisse nicht berücksichtigt werden;

-A — eigene User-Agent;

-p — Adresse des Proxy-Servers, falls erforderlich.

Ein wenig über den Bericht

Die Ergebnisse des Scans werden in Form eines detaillierten Berichts zu allen gefundenen Schwachstellen in einem HTML-Seitenformat dargestellt, klar und verständlich. Der Bericht enthält die Kategorien und die Anzahl der gefundenen Schwachstellen, deren Beschreibung, Anfragen, Befehle zur curl und Ratschläge, wie man sie schließen kann. Zur Erleichterung der Navigation wird in den Kategorieüberschriften ein Link hinzugefügt, über den man zu ihnen wechseln kann:

Ein wesentlicher Nachteil des Berichts ist das Fehlen einer Karte der Webanwendung, ohne die unklar bleibt, ob alle Adressen und Parameter analysiert wurden. Es besteht auch die Möglichkeit von Fehlalarmen. In unserem Fall werden im Bericht „Backup-Dateien“ und „potenziell gefährliche Dateien“ aufgeführt. Ihre Anzahl entspricht nicht der Realität, da es solche Dateien auf dem Server nicht gab:

Es ist möglich, dass nicht korrekt funktionierende Module im Laufe der Zeit behoben werden. Ein weiterer Nachteil des Berichts ist das Fehlen von Farbkennzeichnungen für die gefundenen Schwachstellen (je nach Kritikalität) oder zumindest deren Unterteilung in Kategorien. Das einzige Indiz für die Kritikalität einer gefundenen Schwachstelle, das wir indirekt nutzen können, ist, den Parameter —color beim Scannen anzuwenden, woraufhin die gefundenen Schwachstellen in verschiedenen Farben dargestellt werden:

Doch im eigentlichen Bericht ist eine solche Farbgestaltung nicht vorgesehen.

Schwachstellen

SQLi

Der Scanner hat teilweise bei der Suche nach SQLi funktioniert. Bei der Suche nach SQL-Schwachstellen auf Seiten, für die keine Authentifizierung erforderlich ist, treten keine Probleme auf:

Es wurde nicht gefunden, dass auf Seiten, die nur nach Authentifizierung zugänglich sind, eine Schwachstelle vorhanden ist, selbst mit gültigen 45GB SSD, da wahrscheinlich nach erfolgreicher Authentifizierung eine "Abmeldung von der Sitzung" erfolgt und 45GB SSD ungültig wird. Wenn die Funktion zur Abmeldung als separates Skript implementiert wäre, das für die Verarbeitung dieses Verfahrens zuständig ist, könnte man sie vollständig über den Parameter -x ausschließen und somit deren Auslösung verhindern. Andernfalls ist eine Ausnahme in der Verarbeitung nicht möglich. Dies ist kein Problem eines bestimmten Moduls, sondern des Werkzeugs insgesamt, aber aufgrund dieses Nuanses konnten mehrere Injektionen im geschützten Bereich der Ressource nicht entdeckt werden.

XSS

Der Scanner hat die gestellte Aufgabe hervorragend gemeistert und alle vorbereiteten Schwachstellen gefunden:

LFI/RFI

Der Scanner hat alle vorhandenen Schwachstellen gefunden:

Insgesamt zeigt Wapiti, trotz falsch positiver Treffer und übersehener Schwachstellen, als kostenloses Tool recht gute Ergebnisse. Es ist anzuerkennen, dass der Scanner ziemlich leistungsfähig, flexibel und multifunktional ist, und das Wichtigste — kostenlos, weshalb es hilfreich ist, um Administratoren und Entwicklern grundlegende Informationen über den Sicherheitszustand von Webanwendungen zu bieten.

Bleiben Sie gesund und geschützt!

Quelle: habr.com