sqlmap で Level と Risk を使用してスキャンの攻撃性を調整する

はじめに

sqlmap は、SQL インジェクションの脆弱性を検出および悪用するプロセスを自動化する、強力なオープンソースのペネトレーションテストツールです。スキャンを実行する際、制御できる最も重要なパラメータは --level と --risk の 2 つです。これらのパラメータは、スキャンの徹底度と攻撃性を決定します。

• Level: 実行するテストの数を制御します。1 から 5 までの範囲で、レベルが高いほど、より多くのインジェクションポイント（HTTP ヘッダーなど）に対して、より広範なテストを実行します。
• Risk: 使用されるペイロードのリスクレベルを制御します。1 から 3 までの範囲で、リスクが高いほど、データベースの速度を低下させる可能性のある時間ベースのクエリのような、潜在的に破壊的なペイロードを使用します。

この実験では、これらの 2 つのパラメータを使用して sqlmap スキャンを微調整する方法を学びます。デフォルトのスキャンから開始し、レベルとリスクを徐々に上げて、スキャンの範囲、期間、および使用されるペイロードの種類にどのように影響するかを観察します。

デフォルトのレベル (1) とリスク (1) を理解する

このステップでは、level または risk を指定せずに基本的な sqlmap スキャンを実行します。デフォルトでは、sqlmap は --level=1 と --risk=1 を使用します。これは最も網羅性が低く、最も安全なスキャンです。

Level 1 は GET および POST パラメータのみをテストします。Risk 1 は、基本的なブールベースおよびエラーベースのインジェクションテストなど、Web アプリケーションに一般的に無害なペイロードを使用します。

あなたのためにセットアップされた脆弱なアプリケーションに対して、デフォルトのスキャンを実行しましょう。--batch オプションは、すべての質問にデフォルトの選択肢で自動的に回答するため、スキャンは非対話的になります。

ターミナルで次のコマンドを実行してください。

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

sqlmap がテストプロセスを開始するのを確認できます。最後に表示されるサマリーに注目してください。これは、実行されたリクエスト数と検出された脆弱性を示しています。

...
[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'
...

この最初のスキャンは比較的迅速であり、id パラメータの脆弱性を確認します。

スキャン深度を --level=3 で増加させる

このステップでは、レベルを 3 に設定してスキャンの深度を上げます。レベルが高いほど、sqlmap はより多くのテストを実行し、追加の場所で脆弱性をチェックするようになります。

• --level=2 は HTTP Cookie ヘッダーのテストを追加します。
• --level=3 は HTTP User-Agent および Referer ヘッダーのテストを追加します。

レベルを上げることで、sqlmap により徹底的にスキャンするように指示しています。これにより、当然ながらリクエスト数とスキャン時間が長くなります。

それでは、再度スキャンを実行しますが、今回は --level=3 オプションを追加します。

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

出力を観察してください。sqlmap が Cookie や User-Agent のようなヘッダーのテストを明示的に言及していることに気づくでしょう。

...
[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'
...

私たちのシンプルなアプリケーションはこれらのヘッダーを通じて脆弱ではありませんが、実際のアプリケーションではそうである可能性があります。前回のステップ（XXX）よりも HTTP リクエストの総数（YYY）が増加していることに気づくはずです。

スキャン侵襲度を --risk=2 で増加させる

このステップでは、--risk パラメータを探求します。このパラメータは、使用されるペイロードの「危険度」を制御します。

• --risk=1 (デフォルト): ほとんど無害なペイロードを使用します。
• --risk=2: 重いクエリ時間ベースのブラインドインジェクションテストを追加します。これらはデータベースサーバーに大きな負荷をかける可能性があります。
• --risk=3: OR-ベースの SQL インジェクションテストや、データを変更する可能性のあるその他の潜在的に破壊的なペイロードを追加します。

リスクが高いほど、安全なテストでは見逃される可能性のある脆弱性を発見できますが、ターゲットシステムの機能を妨害する可能性も高まります。注意して使用する必要があります。

リスクを上げた状態でスキャンを実行しましょう。リスクパラメータの効果を分離するために、デフォルトレベル（1）に戻ります。

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

このスキャン中、sqlmap がより攻撃的な時間ベースのテクニックを採用しているのがわかるでしょう。これらのペイロードは、データベースに時間のかかる操作（ベンチマークや sleep 関数など）を実行させ、サーバーの応答時間を測定して情報を推測することで機能します。

...
[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
...

--risk=2 を使用したスキャンは、ペイロード自体がより複雑であるため、同じレベルであってもデフォルトのスキャンよりも集中的です。

--level=5 と --risk=3 を組み合わせたスキャンの実行

このステップでは、可能な限り包括的で攻撃的なスキャンのために、最高レベルとリスク設定を組み合わせます。

• --level=5: 最高レベル。HTTP Host ヘッダーを含む、考えられるすべてのインジェクションポイントをテストします。
• --risk=3: 最高リスク。データベースエントリを変更する可能性のあるペイロードを使用します。これは危険であり、破壊的なテストの明示的な許可があるシステムでのみ使用する必要があります。

この組み合わせは、非常に長く集中的なスキャンにつながります。これは「シンクアプローチ」であり、ターゲットに対して既知のすべてのテストを実行します。

以下のコマンドを実行してください。このスキャンは、以前のものよりも大幅に時間がかかることに注意してください。

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

sqlmap が、最も強力なペイロードを使用して、考えられるすべてのインジェクションポイントに対して膨大な数のテストを実行しているのがわかるでしょう。

...
[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
...

このスキャンは、sqlmap の最大能力を示していますが、トレードオフを理解することの重要性も強調しています。このようなスキャンは、標準的なエンゲージメントでは非現実的でリスクが高すぎることがよくあります。

ペイロードとスキャン時間の増加を観察する

この最終ステップでは、以前のスキャンの結果を振り返ります。実行する新しいコマンドはありません。目標は、スキャン概要を比較することによって、level と risk を調整した影響を理解することです。

各ステップのターミナル出力を確認すると、明確なパターンに気づくでしょう。

1. デフォルトスキャン (--level=1, --risk=1): ベースライン。高速で、最も少ないリクエストを送信しました。
2. レベル増加 (--level=3): sqlmap がより多くのインジェクションポイント（Cookie、User-Agent）をテストしたため、リクエスト数が増加しました。それに伴い、期間も増加しました。
3. リスク増加 (--risk=2): スキャン時間は増加しましたが、必ずしもリクエスト数が増えたからではなく、時間ベースのペイロードは本質的に遅いためです。
4. 最大攻撃性 (--level=5, --risk=3): このスキャンは、はるかに多くのリクエストを送信し、大幅に長い時間をかけて完了しました。

期待される動作の概要は次のとおりです。

重要な点は、直接的なトレードオフがあるということです。level と risk を増やすと、より徹底的なテストが可能になり、見つけにくい脆弱性を発見する可能性が高まりますが、その代償としてスキャン時間が大幅に増加し、ターゲットシステムを妨害するリスクも高まります。

まとめ

この実験では、--level および --risk パラメータを使用して sqlmap スキャンの攻撃性を調整する方法を効果的に探求しました。

以下のことを学びました。

• --level はスキャンの範囲を制御し、HTTP リクエストのどの部分が脆弱性に対してテストされるかを決定します。レベルが高いほど包括的になります。
• --risk はスキャンの侵襲性を制御し、使用される SQL ペイロードの種類を決定します。リスクが高いほど脆弱性を見つけやすくなりますが、ターゲットデータベースにとって危険な場合があります。
• デフォルト設定（level=1、risk=1）は、高速かつ安全になるように設計されています。
• これらの値を増やすと、スキャン時間が長くなり、より注意が必要になります。

ベストプラクティスとして、常に低い level と risk 設定から開始してください。初期スキャンが成功せず、より攻撃的なテストを実行するための適切な承認がある場合にのみ、それらをエスカレートしてください。この実験の完了おめでとうございます！