The ART of Chaining Vulnerabilities から学ぶ

ソース:

ahmdhalabi.medium.com

脆弱性:SSRF, WAF, BrokenAccessControl 他

 

訳:

脆弱性を連鎖させる技術

コンセプト:

脆弱性を連鎖させるプロセスでは、ハッカーがアプリケーション内の複数のエラー/バグを利用して最大限の効果を発揮できるようにする一連の手順が必要です。

簡単な例としては、Open リダイレクトを XSS で連鎖させ、次に XSS をアカウント引き継ぎに連鎖させることができます。
SSRFからRCEへ。
私たちの場合、2 つまたは 3 つの脆弱性を連鎖させるだけではなく、ネットワークに侵入し、インフラストラクチャに軸足を移すためのあらゆる段階を連鎖させ、最終結果として「ターゲットへの完全なリモート アクセス」を獲得しました。

 

プロジェクト 1: モバイル アプリから会社を所有する。

開始するには、モバイル アプリ (apk ファイル) を用意します。

  1. 私の最初のステップは、apk ファイルを逆コンパイルすることでした。

 

APK file

「 jadx 」または「 apktool 」を使用できます、Dex ファイルと APK ファイルを読み取り可能な Java および Smali コードに逆コンパイルするのに役立つ。

 

Decompiling mobile app apk

2. ソースコードを確認したところ、設定ファイルが JSC 拡張機能で暗号化されていることがわかりました。 

 

JSC暗号化

JSC は、開発者が機密情報 (例: サーバー IP、資格情報、秘密キーなど) を含むファイルを暗号化するために使用する JavaScript コンパイル済みスクリプトの略です。 

 

3. 次のステップでは、ソース コードを明らかにするために JSC ファイルを復号化します。

JSC は Cocos2d-x (オープンソースクロスプラットフォーム開発フレームワーク) を使用します。

そこで、逆コンパイルされたアプリケーション ファイル内で Cocos2d-x ファイルを検索し始めました。

 

Cocos2d-x ファイル

4. 「libcocos2d-x.so」ファイルのリバースエンジニアリングを開始し、「main.js」関数を検索しました。

このためには、 IDA Pro を使用するのが最適です:)  

目的は、「Cocos2d-x」がファイルの暗号化に使用する復号キー「XXTEA」を見つけることです。

 

ファイルを復号化するための XXTEA キーの抽出

5. 次に、「XXTEA」キーを使用して JSC ファイルを復号化しました。

 

JSCファイルの復号化

JSC ファイルが復号化されると、JavaScript ファイルにアクセスできるようになり、ソース コードを簡単に読むことができるようになりました。
そして、JSC ファイルを復号化することで、アプリケーションの暗号化を解除することに成功しました。

6. ソース コード レビュー フェーズを開始すると、復号化された設定ファイルの 1 つに興味深い IP アドレスが見つかりました。

 

復号化されたJSファイル内のIPアドレスの識別

7. ポート スキャンを開始しましたが、パケットに大きな遅延が発生していたため、明らかに何らかの保護が行われていました。 

 

パケットの遅延とレイテンシ

8. そこで、代替オプションを使用してオープン ソース インテリジェンス (Shodan/Censys) を試し、オープン ポートを検出したところ、GitLab を実行しているオープン ポート `8100` を見つけました。 

 

 

9. IP:8100 に移動すると、「登録」ボタンのある Gitlab ページが見つかりました。
幸いなことに、それは機能していました。
そこでアカウントを登録し、会社の Gitlab にアクセスしました。 

 

 

通常の役割/権限を持つユーザーが利用できるパブリック プロジェクトはありませんでした。

10. コンテンツ検出を回避した結果、ユーザーの詳細を公開するエンドポイント「api/v4/users」が見つかり、そこに管理者のユーザー名が見つかりました。

 

 

11. ユーザー名をマークし、アカウントからログアウトして、管理者ユーザー名「root」を追加し、パスワードを総当たり攻撃するための単語リストを準備しました。

パスワードの単語リストはランダムではありませんでした。
私はソーシャル メディア、オープンソース (github など)、Web サイト、その他の情報源にあるすべての会社プロフィールを参照して、パスワードについて適切に理解し、正しい情報を得るのに数時間を費やしました。
管理者が使用している可能性のあるパスワード。

12. Web アプリケーションは、ブルート フォース メカニズムから保護するために WAF を使用していました。

私は WAF を騙し、「X-Forwarded-For:127.0.0.$1$」を使用してブルート フォース プロテクションをリクエストごとに 1 ずつバイパスすることに成功しました。

 

 

ログインに成功したことで、WAF 保護を解除することに成功しました。

したがって、アプリの暗号化と WAF 保護の両方が壊れています。

13. 管理者権限で Gitlab にアクセスし、プライベート リポジトリを表示できました。

 

 

14. ソース コードを確認して、会社のインフラストラクチャにアクセスするための資格情報を特定しました。

 

クラウドデータベース

SQLデータベース

Redis データベース

15. そしてデータベースから、ターゲットサーバーの資格情報を見つけました。 

 

サーバーのユーザー名

パスワードはハッシュ化されていましたが、解読は簡単でした。

 

サーバーパスワード

すべてのバックエンド管理システムにアクセスするための資格情報を取得しました。 

 

 

Redis から RCE にエスカレートし、別のサーバーにアクセスしました。

次に、あるサーバーから別のサーバーにピボットして侵入を開始し、最終的にすべてのサーバーにアクセスしました。

 


そしてそれによって、私は会社全体を所有し、誰にも気付かれずに粘り強く残りました:) 

 

参照:

BlackHat 2022 での講演の中で、このプロジェクトのいくつかの段階について詳しく説明しました。

 

https://youtu.be/Zb6oQXJdSsU?si=v9zr0aZ5LettzLfM

 

学んだ教訓:

複数のセキュリティ層/保護を実装する重要性:

ターゲット企業が コード暗号化 Web アプリケーション ファイアウォール をバイパスでき、 を実装していても、暗号化 を解除して WAF 後で を完全に侵害できることがわかりました。 ターゲット

1 つのセキュリティ層に依存しないでください。

  • コードの暗号化に加えて、 アプリケーションのソース コードには機密情報を追加しないでください。
  • WAF に加えて、 Web アプリケーション サーバーとコード内に Web セキュリティ保護を実装します。

 

ラウンド 2: 次に、2 番目のプロジェクトについて説明します。

プロジェクト 2: 前提条件として、IP アドレスを 1 つだけ持つことから会社全体を所有する。

  1. IP アドレスのポート スキャン [開いている SSH が見つかりましたが、脆弱ではありません + パスワードのブルート フォース攻撃は機能しませんでした]。
  2. IP 逆引き参照を実行しました [ドメイン名が見つかりました]。
  3. サブドメインの列挙を実行しました [解決中のサブドメイン ` vip.target.com ` が見つかりました]。
  4. ポート スキャン [実行中の Nginx、Xampp、Java が見つかりました]。
  5. 一般的な脆弱性と既知のエクスプロイトを確認します [CVE に対する脆弱性はありませんでした]。
  6. ディレクトリ ブルート フォース [ログイン ページが見つかりました]。
  7. 一般的なユーザー名とパスワード入力のブルート フォースを試してみましたが [うまくいきませんでした]。
  8. ページソースの表示 + JavaScript ファイルの読み取り [非表示の登録ページが見つかりました]。
  9. 登録には、ホワイトリストに登録された範囲の電話番号が必要でした。
  10. 何度か試した結果、電話番号のパターンが見つかりました。
  11. 認証コードは電話番号に送信され、登録には必要です [問題は、追加した電話番号にアクセスできないため、別のパターンを追加できないことです]。
  12. リクエストとレスポンスを傍受したところ、レスポンス内で検証コードが漏洩していることがわかりました。
  13. 認証コードを確認し、正常に登録されました。
  14. ログイン ページに移動します (ログインにはユーザー名とパスワードが必要です)。
  15. ログインできません [応答メッセージ: ユーザー名が無効です (登録時に同じユーザー名を使用したことがわかっています)]。
  16. ユーザー名の代わりに登録済みの電話番号を追加[ログイン成功]。
  17. サーバーは Xampp を実行しています。 ファイル アップロード エンドポイントを検索しました [すべての写真のアップロードは検証され、保護されていました]。
  18. 2 時間ダッシュボードを閲覧し、すべての機能をチェックした結果、アップロード アイコン拡張機能を検証するためのエンドポイントが欠落していることがわかりました。
  19. php リバース シェルをアップロードし、それが保存されているディレクトリに移動しました [シェルは実行されず、PHP はページにレンダリングされませんでした]。
  20. リクエストを確認すると、リクエスト URL に (.do) が見つかりました [アプリケーションは Xampp を実行していますが、バックエンドで Java を使用しています]。
  21. 簡単なJSPリバースシェルを書いてアップロードしました。
  22. リモート コード実行 (RCE) を取得し、管理者としてサーバーにアクセスしました。

 

 

学んだ教訓:

  • 脆弱性の連鎖は、時間と経験をかけて集められた考え方であり、考え方です。
  • リモートでのコード実行は脆弱性ではなく、プロセスです。
  • ターゲットをテストするときの献身、粘り強さ、忍耐。
  • 別のターゲットに進む前に、すべての可能性を確認してください。
  • 経験と練習を積むことで、このような高レベルのプロジェクトをより速く完了できるようになります。
  • Bug Bounty での経験は、RedTeaming プロジェクトと Pentesting プロジェクトに役立ちました。

 

ほなほな。