# OAuthを使用したアカウント乗っ取り
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * **サイバーセキュリティ企業**で働いていますか？ **HackTricksで会社を宣伝**したいですか？または、**PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロード**したいですか？[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！ * [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。 * [**公式のPEASS＆HackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。 * [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。** * **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
## 基本情報 OAuthにはいくつかの異なるバージョンがあります。[https://oauth.net/2/](https://oauth.net/2/)を読んで基本的な理解を得ることができます。 この記事では、現在最も一般的なフローである[OAuth 2.0認可コードグラントタイプ](https://oauth.net/2/grant-types/authorization-code/)に焦点を当てます。要するに、OAuthは開発者に対して、**別のアプリケーションからアカウントに対してデータにアクセスしたり、特定のアクションを実行するための認可メカニズムを提供します**（認可サーバー）。 例えば、ウェブサイト_**https://yourtweetreader.com**_には、**送信したすべてのツイート**（プライベートツイートも含む）を表示する機能があります。これを実現するために、OAuth 2.0が導入されます。_https://yourtweetreader.com_は、**Twitterアプリケーションがすべてのツイートにアクセスするためにあなたの許可を求めます**。同意ページが_https://twitter.com_に表示され、**どのような権限が要求されているか**、そして要求している開発者が誰かが表示されます。リクエストを承認すると、_https://yourtweetreader.com_は**あなたの代わりにツイートにアクセスできるようになります**。 OAuth 2.0のコンテキストで理解する必要がある要素： * **リソースオーナー**：`リソースオーナー`は、保護されたリソース（Twitterアカウントのツイートなど）へのアクセスを許可する**ユーザー/エンティティ**です。この例では、これは**あなた**です。 * **リソースサーバー**：`リソースサーバー`は、アプリケーションが`リソースオーナー`の代わりに`アクセストークン`を取得した後に認証されたリクエストを処理する**サーバー**です。この例では、これは**https://twitter.com**です。 * **クライアントアプリケーション**：`クライアントアプリケーション`は、`リソースオーナー`から**認可を要求するアプリケーション**です。この例では、これは**https://yourtweetreader.com**です。 * **認可サーバー**：`認可サーバー`は、`リソースオーナー`を**正常に認証**し、認可を取得した後に`クライアントアプリケーション`に`アクセストークン`を発行する**サーバー**です。上記の例では、これは**https://twitter.com**です。 * **client\_id**：`client_id`は、アプリケーションの**識別子**です。これは公開された**非秘密**の一意の識別子です。 * **client\_secret**：`client_secret`は、アプリケーションと認可サーバーの間でのみ知られている**秘密**です。これは`アクセストークン`を生成するために使用されます。 * **response\_type**：`response_type`は、要求されている**トークンのタイプ**（`code`など）を詳細に示す値です。 * **scope**：`scope`は、`クライアントアプリケーション`が`リソースオーナー`から要求している**アクセスレベル**です。 * **redirect\_uri**：`redirect_uri`は、認可が完了した後にユーザーがリダイレクトされる**URL**です。これは通常、事前にサービスに登録したリダイレクトURLと一致する必要があります。 * **state**：`state`パラメータは、ユーザーが認可サーバーにリダイレクトされ、再び戻ってくる間に**データを保持**するために使用されます。これは一意の値であることが重要であり、リクエストごとに一意またはランダムな値を含む場合は**CSRF保護メカニズム**として機能します。 * **grant\_type**：`grant_type`パラメータは、**グラントタイプ**と返されるトークンを説明します。 * **code**：この`code`は、このリクエストのクエリ文字列パラメータ「code」にある`認可サーバー`から受け取った認可コードです。このコードは、クライアントアプリケーションが`client_id`と`client_secret`と共に使用して`access_token`を取得するために使用されます。 * **access\_token**：`access_token`は、`リソースオーナー`の代わりに`クライアントアプリケーション`がAPIリクエストを行うために使用する**トークン**です。 * **refresh\_token**：`refresh_token`は、ユーザーにプロンプトを表示せずに新しい`access_token`を**取得する**ためのものです。 ### 実際の例 これらをすべて組み合わせると、**実際のOAuthフロー**は次のようになります： 1. [https://yourtweetreader.com](https://yourtweetreader.com)にアクセスし、「Twitterと連携する」ボタンをクリックします。 2. [https://yourtweetreader.com](https://yourtweetreader.com)は、リソースオーナーであるあなたに対して、https://yourtweetreader.comのTwitterアプリケーションがツイートにアクセスするための許可を求めるリクエストを[https://twitter.com](https://twitter.com)に送信します。リクエストは次のようになります： ``` https://twitter.com/auth ?response_type=code &client_id=yourtweetreader_clientId &redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback &scope=readTweets &state=kasodk9d1jd992k9klaskdh123 ``` 3\. 同意ページが表示されます: ![](https://miro.medium.com/max/1215/1\*y66EY3Fn2qn-NPI9nhZC7A.png) 4\. 承認されると、Twitterは`redirect_uri`に`code`と`state`パラメータを含んだリクエストを送信します: ``` https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123 ``` 5\. [https://yourtweetreader.com](https://yourtweetreader.com)は、その`code`を取得し、自分たちのアプリケーションの`client_id`と`client_secret`を使用して、サーバーにリクエストを行い、あなたの代わりに`access_token`を取得します。これにより、彼らはあなたが同意した権限にアクセスすることができます。 ``` POST /oauth/access_token Host: twitter.com ...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"} ``` 6\. 最後に、フローが完了し、[https://yourtweetreader.com](https://yourtweetreader.com) はあなたの `access_token` を使用してTwitterにAPIコールを行い、あなたのツイートにアクセスします。 ## バグバウンティの発見 さて、興味深い部分です！OAuthの実装では、多くの問題が発生する可能性があります。以下は、私が頻繁に見るバグの異なるカテゴリです。 ### 弱い `redirect_uri` の設定 `redirect_uri` は非常に重要です。なぜなら、認可後に `code` のような**機密データがこのURLに追加される**からです。もし `redirect_uri` が**攻撃者が制御するサーバー**にリダイレクトされることができれば、攻撃者は `code` を使用して**被害者のアカウントを乗っ取る**ことができ、被害者のデータにアクセスすることができます。 この問題を悪用する方法は、認可サーバーによって異なります。**一部のサーバー**は、クライアントアプリケーションで指定された**正確に同じ `redirect_uri` パスのみを受け入れる**場合がありますが、一部のサーバーは、`redirect_uri` のドメインまたはサブディレクトリ内の**任意のもの**を受け入れる場合があります。 サーバーが処理するロジックによっては、`redirect_uri` をバイパスするためのさまざまなテクニックがあります。例えば、`redirect_uri` が [https://yourtweetreader.com](https://yourtweetreader.com)/callback の場合、以下のような方法があります： * オープンリダイレクト：[`https://yourtweetreader.com`](https://yourtweetreader.com)`/callback?redirectUrl=https://evil.com` * パストラバーサル：`https://yourtweetreader.com/callback/../redirect?url=https://evil.com` * 弱い `redirect_uri` の正規表現：`https://yourtweetreader.com.evil.com` * HTMLインジェクションとrefererヘッダーを介したトークンの盗み出し：`https://yourtweetreader.com/callback/home/attackerimg.jpg` オープンリダイレクトの脆弱性がある可能性のある**他のパラメータ**には以下があります： * **client\_uri** - クライアントアプリケーションのホームページのURL * **policy\_uri** - リレーパーティクライアントアプリケーションが提供する、エンドユーザーがプロファイルデータの使用方法について読むことができるURL * **tos\_uri** - リレーパーティクライアントが提供する、エンドユーザーがリレーパーティの利用規約について読むことができるURL * **initiate\_login\_uri** - RPによってログインを開始するためにサードパーティが使用できるhttpsスキームを使用したURI。クライアント側のリダイレクトにも使用する必要があります。 これらのパラメータは、OAuthおよびOpenIDの仕様によれば**オプション**であり、特定のサーバーで常にサポートされているわけではないため、サポートされているパラメータを特定する価値があります。 OpenIDサーバーを対象にする場合、\*\*`.well-known/openid-configuration`\*\*には、"_registration\_endpoint_"、"_request\_uri\_parameter\_supported_"、"_require\_request\_uri\_registration_"などのパラメータが含まれることがあります。これらは、登録エンドポイントやその他のサーバーの設定値を見つけるのに役立ちます。 ### リダイレクトの実装におけるXSS このバグバウンティレポート [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) で言及されているように、リダイレクトの**URLがユーザーの認証後にサーバーのレスポンスに反映される**可能性があり、XSSの脆弱性があるかもしれません。テストする可能性のあるペイロード： ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - 状態パラメータの不適切な処理 非常に頻繁に、**`state`パラメータは完全に省略されるか、誤った方法で使用されます**。もし`state`パラメータが**存在しない**か、**変化しない静的な値**である場合、OAuthフローは非常に可能性が高く**CSRFに対して脆弱**になります。時には、`state`パラメータが存在していても、**アプリケーションがパラメータの検証を行わない**場合があり、攻撃が成功します。これを悪用する方法は、自分のアカウントで認可プロセスを進め、認可後に一時停止することです。その後、次のようなリクエストが表示されます： ``` https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1 ``` このリクエストを受け取った後、通常はこれらのコードは一度だけ使用されるため、リクエストを破棄することができます。その後、このURLをログイン済みのユーザーに送信すると、あなたのアカウントが彼らのアカウントに追加されます。最初は、これは犠牲者のアカウントに自分のアカウントを追加するだけなので、あまり敏感ではないように思えるかもしれません。しかし、多くのOAuthの実装はサインインのために行われるため、Googleアカウントを追加することができれば、Googleアカウントでログインすることで簡単にアカウント乗っ取りを行うことができます。 これに関する例は、[CTF writeup](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes_surfer.md)とOouchというHTBボックスで見つけることができます。 stateパラメータは追加のリダイレクト値として使用されることもあります。アプリケーションは最初のリダイレクトに`redirect_uri`を使用しますが、`state`パラメータは2番目のリダイレクトとして使用され、クエリパラメータまたはリファラヘッダー内に`code`を含むことがあります。 重要なことは、これは単にログインやアカウント乗っ取りのタイプの状況に適用されるだけではないということです。以下のような設定ミスが見られます。 - Slackの統合により、攻撃者は自分のSlackアカウントをすべての通知/メッセージの受信者として追加できます。 - Stripeの統合により、攻撃者は支払い情報を上書きし、被害者の顧客から支払いを受け取ることができます。 - PayPalの統合により、攻撃者は自分のPayPalアカウントを被害者のアカウントに追加できます。これにより、お金が攻撃者のPayPalに入金されます。 ### アカウント乗っ取り前 もう1つよく見かける問題は、「Xでサインインする」と「ユーザー名/パスワード」の両方を許可するアプリケーションです。攻撃する方法は2つあります。 1. アプリケーションがアカウント作成時にメールの確認を必要としない場合、被害者のメールアドレスと攻撃者のパスワードでアカウントを作成しようとしてみてください。被害者がGoogleなどのサードパーティで登録またはサインインしようとすると、アプリケーションは検索を行い、すでにメールが登録されていることを確認し、その後、被害者のGoogleアカウントを攻撃者が作成したアカウントにリンクする可能性があります。これは「アカウント乗っ取り前」と呼ばれ、被害者が登録する前に攻撃者がアクセスできる状態です。 2. OAuthアプリがメールの確認を必要としない場合、被害者のメールアドレスでそのOAuthアプリにサインアップしてみてください。上記と同じ問題が存在するかもしれませんが、被害者のアカウントにアクセスしてアカウント乗っ取りを行うことができます。 ### 秘密の漏洩 OAuthの多くのパラメータが秘密であることを認識し、それらを保護することは非常に重要です。たとえば、`client_id`の漏洩は完全に問題ありませんが、`client_secret`の漏洩は危険です。これが漏洩すると、攻撃者は信頼されたクライアントアプリケーションの信頼とアイデンティティを悪用して、ユーザーの`access_token`やプライベート情報/アクセスを盗む可能性があります。先ほどの例に戻ると、この手順をクライアントからではなくサーバーから実行する問題があります。 _5._ [_https://yourtweetreader.com_](https://yourtweetreader.com) _はその`code`を取得し、自分のアプリケーションの`client_id`と`client_secret`を使用して、あなたの代わりにサーバーから`access_token`を取得するリクエストを行います。これにより、あなたが同意した権限にアクセスできるようになります。_ **クライアントから実行すると、`client_secret`が漏洩し、ユーザーはアプリケーションの代わりに`access_token`を生成することができます**。ソーシャルエンジニアリングを使えば、OAuthの認可にさらにスコープを追加することもでき、すべてが信頼されたクライアントアプリケーションからのリクエストとして正当に見えます。 ### クライアントシークレットのブルートフォース アイデンティティプロバイダとサービスプロバイダの`client_secret`をブルートフォースしてアカウントを盗む試みを行うことができます。BFのリクエストは次のようになる場合があります。 ``` POST /token HTTP/1.1 content-type: application/x-www-form-urlencoded host: 10.10.10.10:3000 content-length: 135 Connection: close code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce] ``` ### Refererヘッダーの漏洩コード+ステート クライアントが**コードとステート**を持っている場合、異なるページに移動する際に**Refererヘッダー内に反映されている**場合、脆弱性が存在します。 ### ブラウザの履歴に保存されたアクセストークン ブラウザの履歴に移動し、アクセストークンが保存されているかどうかを確認します。 ### 永続的な認可コード **認可コードは一定の時間だけ存在するようにすることで、攻撃者がそれを盗み出して使用できる時間枠を制限します**。 ### クライアントにバインドされていない認可/リフレッシュトークン **認可コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます**。 ### ハッピーパス、XSS、iframe、ポストメッセージを使用してコードとステートの値を漏洩させる ### AWS Cognito このバグ報奨金レポート：[**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/)では、**AWS Cognito**がユーザーに返す**トークン**が、**ユーザーデータを上書きするための十分な権限を持っている可能性がある**ことがわかります。したがって、異なるユーザーのメールアドレスに**ユーザーのメールアドレスを変更できる場合**、他のアカウントを**乗っ取る**ことができるかもしれません。 ```bash # Read info of the user aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] # Change email address aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com { "CodeDeliveryDetailsList": [ { "Destination": "i***@f***.com", "DeliveryMedium": "EMAIL", "AttributeName": "email" } ] } ``` 詳細な情報については、AWS Cognitoの乱用方法については以下を参照してください： {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} ### 2つのリンクとクッキー [**この解説記事**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)によると、攻撃者のホストを指す**returnUrl**を持つページを被害者に開かせることが可能でした。この情報は**クッキー（RU）**として保存され、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。 このプロンプトをバイパスするために、**Oauthフロー**を開始し、**returnUrl**を使用してこのRUクッキーを設定し、プロンプトが表示される前にタブを閉じ、その値がない新しいタブを開くことが可能でした。そのため、**プロンプトは攻撃者のホストについて通知しません**が、クッキーはそれに設定されるため、リダイレクトで**トークンは攻撃者のホストに送信されます**。 ### SSRFパラメータ 見落とす可能性のある隠れたURLの1つは、**Dynamic Client Registrationエンドポイント**です。ユーザーを正常に認証するために、OAuthサーバーは「client\_name」、「client\_secret」、「redirect\_uris」など、クライアントアプリケーションに関する詳細を知る必要があります。これらの詳細はローカルの設定で提供することもできますが、OAuth認可サーバーには**特別な登録エンドポイント**も存在する場合があります。このエンドポイントは通常、"/register"にマップされ、以下の形式のPOSTリクエストを受け付けます： ```json POST /connect/register HTTP/1.1 Content-Type: application/json Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... { "application_type": "web", "redirect_uris": ["https://client.example.org/callback"], "client_name": "My Example", "logo_uri": "https://client.example.org/logo.png", "subject_type": "pairwise", "sector_identifier_uri": "https://example.org/rdrct_uris.json", "token_endpoint_auth_method": "client_secret_basic", "jwks_uri": "https://client.example.org/public_keys.jwks", "contacts": ["ve7jtb@example.org"], "request_uris": ["https://client.example.org/rf.txt"] } ``` このリクエストでパラメータを定義する2つの仕様があります：OAuthの[RFC7591](https://tools.ietf.org/html/rfc7591)と[Openid Connect Registration 1.0](https://openid.net/specs/openid-connect-registration-1\_0.html#rfc.section.3.1)です。 ここで見るように、これらの値のいくつかはURL参照を介して渡され、[Server Side Request Forgery](https://portswigger.net/web-security/ssrf)の潜在的なターゲットになる可能性があります。同時に、私たちがテストしたほとんどのサーバーは、登録リクエストを受け取ったときにこれらのURLをすぐに解決しないで、**これらのパラメータを保存してOAuth認可フローの後で使用します**。言い換えれば、これはより高度なSSRFであり、ブラックボックスの検出が困難になります。 以下のパラメータは、SSRF攻撃に特に興味があります： - **logo\_uri** - クライアントアプリケーションの**ロゴを参照するURL**です。**クライアントを登録した後**、新しい「client\_id」を使用してOAuth認可エンドポイント（"/authorize"）を呼び出してみることができます。ログイン後、サーバーはリクエストの承認を求め、**「logo\_uri」から画像を表示する**場合があります。サーバーが画像を自動的に取得する場合、このステップでSSRFがトリガーされるはずです。代わりに、サーバーは**クライアント側の "\" タグ**を使用してロゴを含める場合があります。これはSSRFにはつながりませんが、URLがエスケープされていない場合は**XSSにつながる可能性があります**。 - **jwks\_uri** - クライアントのJSON Web Key Set \[JWK]ドキュメントのURLです。このキーセットは、JWTを使用してクライアント認証を行う場合に、トークンエンドポイントに対して行われる署名済みリクエストの検証にサーバーで必要です\[RFC7523]。このパラメータでSSRFをテストするためには、**悪意のある「jwks\_uri」を使用して新しいクライアントアプリケーションを登録**し、任意のユーザーの認可コードを取得してから、以下のボディで"/token"エンドポイントを取得します： `POST /oauth/token HTTP/1.1`\ `...`\ \`\`\ `grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...` 脆弱な場合、サーバーはリクエストの「client\_assertion」パラメータの妥当性をチェックするために、このキーが必要なため、提供された「jwks\_uri」に対してサーバー間のHTTPリクエストを実行するはずです。これはおそらく**ブラインドSSRFの脆弱性**になるでしょうが、サーバーは適切なJSONレスポンスを期待しています。 - **sector\_identifier\_uri** - このURLは、単一の**リダイレクト\_uri値のJSON配列**を参照しています。サーバーがこれをサポートしている場合、動的登録リクエストを送信するとすぐにこの値を**取得する可能性があります**。すぐに取得されない場合は、サーバーでこのクライアントの認可を実行してみてください。認可フローを完了するためにリダイレクト\_urisを知る必要があるため、サーバーはあなたの悪意のあるsector\_identifier\_uriにリクエストを行うことになります。 - **request\_uris** - このクライアントの**許可されたrequest\_urisの配列**です。"request\_uri"パラメータは、認可エンドポイントでサポートされており、リクエスト情報を含むJWTが含まれるURLを提供するために使用されます（[https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2](https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2)を参照）。 動的クライアント登録が有効になっていない場合、または認証が必要な場合でも、単純に「request\_uri」を使用して認可エンドポイントでSSRFを実行することができます：\\ `GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt` 注意：このパラメータを「redirect\_uri」と混同しないでください。**「redirect\_uri」は認可後のリダイレクトに使用されますが、「request\_uri」は認可プロセスの開始時にサーバーによって取得されます**。 同時に、私たちが見た多くのサーバーは、任意の「request\_uri」値を許可していません。クライアント登録プロセス中に事前に登録されたホワイトリストに含まれるURLのみを許可しています。そのため、あらかじめ「request\_uris」を「https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt」として提供する必要があります。 ## OAuthプロバイダの競合状態 テストしているプラットフォームがOAuthプロバイダである場合は、[**競合状態をテストするためにこれを読んでください**](race-condition.md)。 ## 参考文献 - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * **サイバーセキュリティ企業で働いていますか？ HackTricksであなたの会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたりしたいですか？[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！** * [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけて、独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションを見つけてください。 * [**公式のPEASS＆HackTricksのスウェット**](https://peass.creator-spring.com)を手に入れましょう。 * [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または