AWS - Identity Center & SSO Unauthenticated Enum
AWS Device Code Phishing
このブログ記事で最初に提案されたように、AWS SSOを使用しているユーザーにリンクを送信し、ユーザーが承認すると、攻撃者はトークンを取得してユーザーになりすまし、Identity Centerでユーザーがアクセスできるすべてのロールにアクセスできるようになります。
この攻撃を実行するための要件は次のとおりです:
被害者がIdentity Centerを使用していること
攻撃者が被害者が使用しているサブドメイン
<victimsub>.awsapps.com/start
を知っていること
前述の情報だけで、攻撃者はユーザーにリンクを送信し、承認されると攻撃者はAWSユーザーアカウントにアクセスできるようになります。
攻撃
サブドメインの特定
攻撃者の最初のステップは、被害者の会社がIdentity Centerで使用しているサブドメインを特定することです。これはOSINTや推測 + BFを通じて行うことができます。ほとんどの会社はここで自社の名前やその変形を使用しているためです。
この情報を使って、Identity Centerが設定されたリージョンを取得することが可能です:
被害者のためのリンクを生成して送信
被害者が認証できるようにAWS SSOログインリンクを生成するために、以下のコードを実行します。 デモのために、このコードをpythonコンソールで実行し、後でトークンを取得するためにいくつかのオブジェクトが必要になるので、コンソールを終了しないでください:
被害者にリンクを送信し、あなたの素晴らしいソーシャルエンジニアリングスキルを使ってください!
被害者がリンクを承認するのを待つ
被害者がすでにAWSにログインしている場合、権限を付与することを承認するだけで済みます。ログインしていない場合は、ログインしてから権限を付与することを承認する必要があります。 現在のプロンプトはこのようになっています:
SSOアクセス・トークンを取得する
被害者がプロンプトを承認した場合、次のコードを実行してユーザーになりすましてSSOトークンを生成します:
SSOアクセス トークンは8時間有効です。
ユーザーを偽装する
フィッシング不可能なMFAをフィッシング
前述の攻撃が**「フィッシング不可能なMFA」(webAuth)が使用されている場合でも機能することを知るのは楽しいです。これは、前述のワークフローが使用されるOAuthドメインを離れないためです。他のフィッシング攻撃ではユーザーがログインドメインを偽装する必要がありますが、この場合、デバイスコードワークフローはデバイスがコードを知っているため、ユーザーは異なるマシンでもログインできます。プロンプトが承認されると、デバイスは初期コードを知っているだけでユーザーの資格情報を取得**できます。
詳細についてはこの投稿をチェックしてください。
自動ツール
参考文献
Last updated