ソース：
脆弱性：GraphQL、SQLインジェクション
訳：
GraphQL クエリでの SQL インジェクション
標的の範囲は広範でしたが、サブドメインは除外されていました。
スコープは「target.*」として定義され、広範囲の ccTLD (target.co.uk、target.it、target.ae、target.co.in、target.com など) を網羅します。
これはさまざまな国コードのトップレベル ドメインをカバーしているため、特に興味深いと思いました。
ターゲットが世界中の国で運用されていることを知っていたため、証明書透明性 (CT) サービスを使用して TLD を特定するのは比較的簡単であることがわかりました。
次に進むために、メイン Web サイトである target.com を Firefox で開き、SSL 証明書から組織名を抽出し (以下のスクリーンショットの例を参照)、さらなる分析のためにそれをコピーしました。
確かに、多くの組織が「Twitter, Inc.」などの組織名で SSL 証明書を登録していることは注目に値します。
したがって、サブドメインまたは ccTLD ドメインの検索を実行するときは、検索条件の一部として組織名を使用することが重要です。
このアプローチは、より正確で包括的な結果を保証するのに役立ちます。
次に、netlas.io や crt.sh などのツールを利用して、特定された組織に関連付けられている可能性のあるすべての ccTLD ドメインを検索しました。
両方のソースからの結果を組み合わせることで、サブドメインを含む 7,000 件を超える結果が得られました。
しかし、徹底的なフィルタリングと分析を適用した後、焦点を当てるエンドポイントのリストを約 64 個に絞り込みました。
この選択プロセスは、さらなる調査のために最も関連性があり潜在的に脆弱なターゲットを特定することを目的としていました。
HTTP プローブとパラメータ検出
リストを Kali VM にコピーした後、httpx 経由でエンドポイントのリストを送信し、プローブを実行しました。
調査プロセスの後、57 のエンドポイントが稼働しており、応答していることがわかりました。
エンドポイントの包括的な分析を行うために、次のコマンドを使用して ParamSpider を使用し、サブドメインを除外するように設定しました。 -subs Falseフラグ：
cat targets | xargs -n 1 -I {} python3 ~/ParamSpider/paramspider.py --subs False --domain {} --level high | urldedupe >> all-param.txt
これにより、追加情報を収集し、対象のエンドポイント内の脆弱性や関心のある領域を特定できる可能性がありました。
ParamSpider を使用すると、URL が約 20,000 行に及ぶかなりの量のデータに遭遇しました。
リストを絞り込み、無関係または無関係な情報を削除するために、不要なデータを慎重にフィルタリングして取り除き、12,000 件の関連 URL の最終リストを作成しました。
その後、パラメータと URL の検査を開始しましたが、それらの大部分が製品ページへの同様のリンクであることがわかりました。
このような URL の例は、 https://www.target.co.xx/en/xxxx/category2/men/t-shirts.xxx?n=xx&s=xx&ww=xxx です。
残念ながら、これらの URL には 10,000 を超えるインスタンスにわたって同じパラメータ構造が含まれていたため、調査に役立つ情報は得られませんでした。
これらの URL のサブセットに対して SQL インジェクションと XSS のテストをいくつか実行しましたが、脆弱性は見つかりませんでした。
リストをさらに絞り込むために、すべての製品 URL をフィルターで除外した結果、さらなる分析と脆弱性テストがより有望と思われる約 1,600 個の URL からなる厳選されたリストが作成されました。
Nucleiスキャン
厳選された URL リストの背後にあるテクノロジーを調査する目的で、Nuclei を使用してデフォルトのスキャンを実行しました。
数秒以内にスキャン結果が得られました。
複数の発見がありましたが、ある特定の結果がすぐに私の注意を引きました。
国別のトップレベル ドメイン (TLD) Web サイトの 1 つが GraphQL を利用しているようでした。
ただし、GraphQL 実装に設定ミスがあったようで、潜在的なセキュリティ脆弱性を示しています。
この発見により、構成ミスの性質と影響をより深く理解するためにさらなる調査が必要になりました。
バープスイートスキャン
ヒントがあるときは必ずBurp Scannerで確認するのですが、今回はBurpを使ってURLをさらに調査してみました。
アクティブ スキャンを開始した後、肯定的な結果を受け取りました。
Burp Scanner は、リクエスト本文で一重引用符 (') が送信されたときに、潜在的な SQL インジェクションの脆弱性を検出しました。
サーバーは「500 Internal Server Error」で応答しました。
これは、入力によってサーバーからの予期しない応答がトリガーされたことを示します。
この発見は、悪用される可能性がある SQL インジェクションの脆弱性の存在を強く示唆しています。
ただし、Burp Suite の調査結果に関しては、この問題は 暫定的 なままです。
したがって、実際に SQL インジェクションの脆弱性が存在するかどうか、あるいはそれが誤検知である可能性があるかどうかはわかりません。
SQLMAP と Ghauri はインジェクションを見つけることができませんでした
さらに分析するために、リクエストをコピーして SQLMAP と Ghauri の両方に送信して続行しました。
ただし、これらの追加テストにもかかわらず、どちらのツールもインジェクションや脆弱性を特定できませんでした。
この結果は、Burp Scanner によって検出された最初の潜在的な SQL インジェクションが誤検知であった可能性があることを示しています。
私は問題を自分で解決し、潜在的な SQL インジェクションの脆弱性を手動で調査することにしました。
Burp Suite にはそのような脆弱性を識別する能力があると強く信じていたからです。 SQLインジェクションが可能かどうか確認できるまでは、他のエンドポイントはとりあえず無視しました。
適切な GraphQL クエリを見つける
まず、別の画面で Burp Community エディションを開き、脆弱な URL にリクエストを送信しました。
次に、リクエストのキャプチャを開始して、さまざまな種類のクエリに対して提供された応答を分析しました。
このタスクに 1 時間を費やした後、最終的に、ユーザーの「性別」データを取得または変更するために使用される完全なクエリをキャプチャしました。 クエリでは、男性を表す「M」、女性を表す「F」、および該当なしを表す「NA」の 3 つのキーワードを受け入れます。
クエリの例は次のとおりです。
{
"query":
"query ($_key***_0:String!, $_***_0:Int!) {*****
(keyword:$_key***_0, ****:$_***_0){ key***_text, number_of_result,
number_of_uses, ***_id, gender_cd, url }}",
"variables":{
"_key***_0":"M",
"_***_0":"1"
}
}
ブラインド SQL インジェクションの検索
特定したクエリを用意して、さまざまなペイロードを試して脆弱性をテストしました。 Nuclei スキャンから収集された情報 (アプリケーションが Apache 上で実行される PHP を使用していることが明らかになった) に基づいて、私は MySQL Sleep ペイロード の送信に焦点を当てました。
画期的な出来事は、特定のペイロードを送信したときに発生し、サーバーの応答に正確に 10.121 秒の遅延が生じました。
これにより SQL インジェクションの脆弱性の存在が確認され、遅延時間の異なるさまざまなペイロードを使用して脆弱性をさらに検証しました。
脆弱性の悪用が成功したことで、その存在と潜在的な影響がさらに強固になりました。
XOR(if(now()=sysdate(),sleep(9),0))XOR\"Z
私が送信したクエリに合わせてサーバーの応答が遅れたのを確認して、大きな安堵感を感じました。
私はすぐに報告書を作成し、提出しました。
さらに、SQLMap を実行してホスト名、データベース、現在のユーザーなどの詳細情報を収集するかどうかをトリガーに問い合わせました。
彼らは、クライアントに指導を求めると相談すると応じた。
それにもかかわらず、レポートはブラインド SQL インジェクションとしてトリアージされ、ターゲットは私の努力を認めて、3,500 ドルと 40 ポイントを私に与えました。
ほなほな。
