1. 始めに
こんにちは、morioka12 です。
本稿では、AWS マネジメントコンソールに焦点を当てたフィッシングによる MFA (Multi-Factor Authentication) 認証の回避や事例、セキュリティ対策について紹介します。
- 1. 始めに
- 2. AWS マネジメントコンソール
- 3. フィッシング (Phishing)
- 4. フィッシングによる AWS ログインの仮想 MFA デバイス認証の回避
- 5. フィッシングによる AWS ログインの SSO 認証の回避
- 6. AWS ログインをターゲットにしたフィッシングの事例
- 7. その他
- 8. セキュリティ(フィッシング)対策
- 9. 終わりに
免責事項
本稿の内容は、セキュリティに関する知見を広く共有する目的や自己啓発の目的で執筆されており、悪用行為を推奨するものではありません。
想定読者
- 普段 AWS を利用している開発者
2. AWS マネジメントコンソール
AWS マネジメントコンソールとは、AWS (Amazon Web Services)のクラウドサービスを管理するためのウェブベースのユーザーインターフェースです。
ログイン方法は、ルートユーザー・IAM ユーザー・SSO (Single Sign-On)があり、セキュリティ設定で多要素認証(Multi-Factor Authentication: MFA)のオプションがあります。
MFA (Multi-Factor Authentication)
MFA (Multi-Factor Authentication, 多要素認証)とは、ユーザーの身元確認を行うためのセキュリティ概念で、パスワードに加えて他の認証要素を提供する必要がある ID 検証方法の一つです。
主に以下のような要素があります。
- SMS (Short Message Service)やテキストメッセージ
- 専用の認証アプリ
- 物理的なデバイス
- USB キー、スマートカード、ワンタイムパスワードジェネレータなど
- 生体認証
また、AWS マネジメントコンソールのログインに設定できる MFA は以下があります。
詳しくは、以下をご覧ください。
3. フィッシング (Phishing)
フィッシング (Phishing)とは、悪意のある者が信頼性のある組織や個人のふりをし、被害者から個人情報や機密情報を詐取しようとする行為です。
フィッシングの主な目的は、以下のようなものがあります。
IPA が提供する「情報セキュリティ10大脅威 2023」のでは、以下のようになっています。
- 個人編
- 1位：フィッシングによる個人情報等の詐取
- 組織編
- 7位：ビジネスメール詐欺による金銭被害
このことから、フィッシングは日常的に起こりうる脅威とわかります。
フィッシング対策協議会が提供している「フィッシングレポート 2023」によると、「1.3.1. フィッシングのターゲットとなっているブランド」で以下のようにあり、主に個人のクレジットカード情報を狙うことが多くあるようです。
2022 年は、クレジットカードをかたるフィッシングの報告件数が最多となり、その割合は全体の約 42.6%、そのブランド数は 39 ブランドであった。EC系（インターネットショッピングなど）をかたるフィッシングも継続に行われていて、その割合は約 30.0%であった。
詳しくは、フィッシング対策協議会が提供している「フィッシングレポート 2023」をご覧ください。
https://www.antiphishing.jp/report/phishing_report_2023.pdf
MITRE ATT&CK
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge)とは、サイバーセキュリティの専門家や研究者が、攻撃者の戦術、技術、および手順を理解、模倣、そして防御するための知識ベースおよびフレームワークです。
MITRE ATT&CK では、14の戦術の中に初期アクセス(Initial Access)としてフィッシングが該当し、3つの攻撃方法(Sub-technique)が記載されています。
- Spearphishing Attachment
- 特定の個人/組織/グループを標的にして、悪意のある添付ファイルを送りつけ、被害者に感染させようとする攻撃手法
- Spearphishing Link
- 特定のターゲットを標的にして、誘惑的なリンクを含むメッセージを送り、被害者を危険な Web サイトに誘導しようとする攻撃手法
- Spearphishing via Service
- 特定のオンラインサービスやプラットフォームを標的にして、サードパーティのサービスを偽装したフィッシングを行う攻撃手法
よくあるテクニックとしては、以下のようなものもあります。
詳しくは以下をご覧ください。
また、IBM が2022年に公開しているレポートでは、2021年のすべての攻撃のほぼ半数(41%)が初期アクセスとしてフィッシングを利用されていたそうです。
詳しくは以下をご覧ください。
https://www.ibm.com/downloads/cas/ADLMYLAZ
4. フィッシングによる AWS ログインの仮想 MFA デバイス認証の回避
仮想 MFA デバイスによる認証を有効化した状態でもフィッシングによって、不正ログインされる可能性があります。
今回紹介するのは、AWS マネジメントコンソールに IAM ユーザーでログインする際に「仮想 MFA デバイス」を利用していたユーザーに対してフィッシングにより認証を回避する方法になります。
まずは、フィッシングなどの中間者攻撃で MFA に対応した認証情報とセッションの Cookie を取得できるフレームワークが OSS でいくつかあります。
これらのほとんどは、被害者となるクライアントとターゲットの Web サイトとの間にリバース・プロキシ(中間者)として機能してフィッシングを行います。これを「MITM (Man-in-the-middle)フィッシング」と言います。
中間者として攻撃者はログインの通信を傍受しながら、有効かつ動的で正当に見える偽のフィッシングページを被害者に表示して提供します。
詳しくは、以下をご覧ください。
本稿は、あくまで事例紹介と現象紹介をするだけのため、具体的な内容は省いて簡易的に紹介します。
Modlishka の動作
そこで、今回は「Modlishka」を使用します。
インストールは、Golang が動くサーバーで以下のようにしてインストールします。
go get -u github.com/drk1wi/Modlishka
Modlishka をコンパイルする前にセキュリティ強化とし、「Modlishka Cookie Jar」のデフォルト URL を変更します。
Modlishka Cookie Jar は、被害者がフィッシングページに対して認証した後に認証情報と Cookie を保存する場所を指します。
デフォルトのパスでは、「/plugin/control.go」に設定されていて、パスは「/SayHello2Modlishka/」になっています。
これを予測可能な場所ではなく、長くて分かりにく場所に移動するようにパスを変更しました。
次に「make」でバイナリをコンパイルします。
すると用意してたドメインにアクセスすると、以下のように AWS マネジメントコンソールの偽ページが表示されました。
Modlishka は AWS マネジメントコンソールの Web ページをターゲットにしてプロキシしているだけであるため、MFA が有効であっても、ユーザーをフィッシングすることができます。 (root ユーザーはセットアップ時に少し手を加える必要があるそうです)
実際に用意したフィッシングページからテスト用のアカウントで「ユーザー名・パスワード・MFA Code」を入力してログインを試してみると、以下のような項目を攻撃者は入手することができます。
以下のような手順で、入手したアカウントを用いて AWS マネジメントコンソールにログインすることが可能です。
- 正規のログインページ「
https://console.aws.amazon.com/」にアクセスする。 - HTTP Response の Set-Cookie ヘッダーに入手した有効なログインセッションを付与します。
- その後、HTTP Response のステータスコードが「
302 Found」の際に、Location ヘッダーを以下のような形にします。
https://console.aws.amazon.com/console/home?state=hashArgs#&isauthcode=true&code=REALLY-LONG-AUTH-CODE
入手したセッションは、 MFA 認証されたセッションとしてカウントされるため、MFA を必要とするアクセス許可も同様に利用できます。
また、取得した被害者の IAM ユーザーの Cookie はログアウトに関わらず約12時間の有効期限付きで利用できたそうです。
The only other limitation that we found was that the cookies expire after approximately 12 hours. This means that if you phish a user and steal their cookies, you have 12 hours of unrestricted access to their IAM user, regardless of whether they change their MFA device and/or password and log themselves out. After about 12 hours, however, we found that the cookies no longer worked.
このようにして、MFA 認証を使ったユーザーでも、MITM フィッシングによって不正に認証情報を取得され AWS リソースに不正ログインされる可能性があります。
詳しくは、以下をご覧ください。
5. フィッシングによる AWS ログインの SSO 認証の回避
AWS のログイン方法として SSO (Single Sign-On)がありますが、これも同様にフィッシングによって認証情報を取得されて攻撃者に不正ログインされる可能性があります。
主な流れは以下のようになります。
- 攻撃者はターゲットとなる被害者の組織の AWS SSO の URL (
<something>.awsapps.com)を特定します- これはサブドメインの列挙などで特定することが可能です
- 攻撃者によるデバイス コード認証フローを開始する
- ステップ2のデバイス認証の URL をフィッシングで被害者に送る
- 被害者がプロントにログインして攻撃者は sso-oidc:CreateToken で SSO アクセストークンを取得する
- ここで取得した SSO アクセストークンは8時間有効です
- 攻撃者は自身の AWS SSO のログインページを開いて、Cookie の
x-amz-sso_authnを入手した被害者のに置き換えて、AWS にログインします
このようにして、AWS SSO 認証もフィッシングによって攻撃者に不正ログインされる可能性があります。
詳しくは、以下をご覧ください。
6. AWS ログインをターゲットにしたフィッシングの事例
AWS のマネジメントコンソールからのログインをターゲットにしたフィッシングの事例は、既に存在します。
事例1 (Google 検索)
直近では、2023年1月30日の時点であった Google 検索の広告を悪用した事例について紹介します。
これは Sentinel Labs が発見したフィッシングサイトで、以下のように Google で「aws」と検索すると2番目に広告として表示されていました。
攻撃者は「us1-eat-a-w-s.blogspot[.]com」を広告の宛先としていて、自動リダイレクトによって「aws1-console-login[.]us/login」に遷移して偽の AWS マネジメントコンソールのログインページが表示されました。
また、この偽サイトは「window.location.replace」を利用して、本物に見せかけた偽の AWS ログインのページをホストしていたようです。
それで実際にユーザーが認証情報を入力してログインしようとすると、最終的に「zconfig01.php」がリロードされて、以下の部分で正規のログインページに遷移していました。
今回のフィッシングページの特徴として、以下の JavaScript の関数で「マウスの右ボダン／中ボタンおよび、キーボード・ショートカットを無効にする」ものが組み込まれていたそうです。
そのため、「アクセスしたユーザーが意図的な操作および誤操作により、ページから脱出するのを防ぐ仕組みである可能性が高い」とのことです。
他にも同様に AWS マネジメントコンソールの似せた偽のドメインがいくつか発見されていました。
- aws1-console-login[.]us - aws2-console-login[.]xyz - aws1-ec2-console[.]com - aws1-us-west[.]info
このようなフィッシングページによって、もしユーザーが認証情報を入力した場合、攻撃者にアカウントの認証情報が漏洩して、AWS リソースに侵入される可能性があります。
今回は MFA のフローは加味されていなかったようなため、MFA を有効化していたユーザーは未然に不正ログインを防げた可能性があります。
詳しくは、以下をご覧ください。
Cloud Credentials Phishing | Malicious Google Ads Target AWS Logins - SentinelOne
ちなみに、DNpedia などのフィッシングドメインの可能性があるドメインが毎日登録されているデータベースで「aws」と検索してみると、以下のように怪しいドメインがいくつか確認できます。
事例2 (メール)
次は、2020年5月27日に公開されたフィッシングメールの誘導による偽の AWS マネジメントコンソールからの認証情報を狙った事例について紹介します。
実際に以下のような AWS からの自動メールがきたような偽のメールが送られてきました。
URL にアクセスすると、最終的には別のドメインにリダイレクトされて、以下のように偽の AWS のログイン画面が表示されました。
この偽のログインページからもしユーザーが認証情報を入力した場合、先ほどの事例と同様に攻撃者にアカウントの認証情報が漏洩して、AWS リソースに侵入される可能性があります。
詳しくは、以下をご覧ください。
事例3 (メール)
次は、Cado Security が実際に偽の AWS マネジメントコンソールに誘導するフィッシングメールを受信して、テストアカウントを入力して攻撃者の行動を観測した調査事例について紹介します。
実際に以下のようなフィッシングメールが送られてきました。
以下のメールにある偽の AWS マネジメントコンソールのページにアクセスして、テスト用のアカウント名と偽のパスワードを入力すると「https://howitfix[.]com/app/aws/」に送られたそうです。
すると、早くも約1時間後に AWS CloudTrail がログインして失敗しているログが確認されました。 ("responseElements": {"ConsoleLogin": "Failure"},)
{ "eventVersion": "1.05", "userIdentity": { "type": "Root", "principalId": "809xxx", "arn": "arn:aws:iam::809xxx:root", "accountId": "809xxx", "accessKeyId": "" }, "eventTime": "2020-06-07T04:25:51Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "105.155.37.247", "userAgent": "Mozilla/5.0 (Linux; Android 8.0.0; SAMSUNG SM-G930F) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/11.2 Chrome/75.0.3770.143 Mobile Safari/537.36", "errorMessage": "Failed authentication", "requestParameters": null, "responseElements": { "ConsoleLogin": "Failure" }, "additionalEventData": { "LoginTo": "https://console.aws.amazon.com/console/home?nc2=h_mo&state=hashArgs%23&isauthcode=true", "MobileVersion": "No", "MFAUsed": "No" }, "eventID": "164ed813-9818-4ad0-9d09-xxx", "eventType": "AwsConsoleSignIn", "recipientAccountId": "809xxx" }
次にパスワードが偽と判明した段階でパスワードリセットを行なっているログも確認されています。 ("responseElements": {"PasswordRecoveryRequested": "Success"},)
{ "eventVersion": "1.05", "userIdentity": { "type": "Root", "principalId": "809xxx", "arn": "arn:aws:iam::809xxx:root", "accountId": "809xxx", "accessKeyId": "" }, "eventTime": "2020-06-07T04:26:12Z", "eventSource": "signin.amazonaws.com", "eventName": "PasswordRecoveryRequested", "awsRegion": "us-east-1", "sourceIPAddress": "105.155.37.247", "userAgent": "Mozilla/5.0 (Linux; Android 8.0.0; SAMSUNG SM-G930F) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/11.2 Chrome/75.0.3770.143 Mobile Safari/537.36", "requestParameters": null, "responseElements": { "PasswordRecoveryRequested": "Success" }, "eventID": "59b12bc4-f826-4c2d-9879-xxx", "eventType": "AwsConsoleSignIn", "recipientAccountId": "809xxx" }
このように実際にフィッシングによって AWS の認証情報を取得した攻撃者は AWS マネジメントコンソールにログインして更なる侵害が行われる可能性があります。
また、調査した Cado Security によると、多くの攻撃者は盗んだ AWS アカウントを売り買いの取引にされるそうです。ただし、フィッシングによって入手した AWS のアカウントは、 Amazon SES でマルウェア配布に活用して同様の手法で他のフィッシングに繋げることが多いようです。
Many attackers trade AWS accounts on forums where stolen accounts are exchanged. AWS Accounts limited to the free tier go for as little a $4. Accounts with larger limits can go for significantly more. AWS API keys stolen from users who accidentally commit them to public code repositories are normally used to mine crypto-currencies. However, the market for AWS accounts stolen by phishing is mainly for people looking for accounts to use Amazon Simple Email Service (SES).
詳しくは、以下をご覧ください。
これらの事例2,3のようなフィッシングメールによる偽のログインページに誘導する場合、攻撃者が特定の組織に対して狙いを定めた上でメールを送っている可能性もあります。
7. その他
Web アプリケーションにおける MFA 認証の回避
今回は、AWS マネジメントコンソールの認証に焦点を当てましたが、実際の Web アプリケーションでも同様に MFA 認証の回避がフィッシングによって不正ログインが行われる可能性があります。
また、根本的に Web アプリケーションの実装の不備によって、MFA 認証の回避が行える可能性もあります。(フィッシングとは関係ないため軽く紹介だけ)
HackerOne というバグバウンティプラットフォームでの MFA 認証の回避 に関する脆弱性報告では、実際に以下のような報告書が公開されています。
詳しくは、以下をご覧ください。
8. セキュリティ(フィッシング)対策
このようなフィッシングに対して行える対策としては、以下のようなものがあります。
ユーザー
- 常に公式ページが提供するログインページの URL からログインを行う (また URL を確認する)
https://console.aws.amazon.com/
- 可能な場合は AWS ログインに仮想 MFA デバイスではなくハードウェア MFA デバイスを利用する
- 最低限は仮想 MFA デバイスを利用する
- Web ブラウザのセキュリティ拡張機能を活用する
- ノートン セーフウェブ などのセキュリティベンダーが提供する信頼性のある拡張機能
- AWS 側で異常な地域からのログインや高額なサービスの利用を検出した際にアラートを受け取る設定にする
組織
- 定期的にフィッシング研修を行なって組織内の認識を高める
- 組織の範囲外の IP アドレスに対する AWS へのログイン試行を監視する
- AWS CloudTrail を活用して異常なアクティビティや不正なログインを検出する
- ユーザーや IAM ロールの権限を定期的にレビューし、不要な権限を削除する
認証において MFA はセキュリティの重要な層の一つですが、それだけで十分とは言えません。多層的なセキュリティアプローチを採用し、リスクを最小限に抑えることが重要です。
そのため、不正ログインや情報漏洩などを未然に防ぐ事前対策と、侵入された際の被害を最小限に抑えられるような事後対策を行うことをお勧めします。
フィッシングに関しては、フィッシング対策協議会が提供する「フィッシング対策ガイドライン」をご覧ください。
AWS ログインにおける MFA の設定は、以下の公式をご覧ください。
もし AWS の偽造であると思われるフィッシングメールを受け取った場合は、以下のフォームからレポートを送信して知らせることができます。
9. 終わりに
本稿では、AWS マネジメントコンソールに焦点を当てたフィッシングによる MFA 認証の回避や事例、セキュリティ対策について紹介しました。
今回のような MFA 認証の回避は、どの Web アプリケーションでも起こりうる現象になります。
また、フィッシングは実際にレッドチーム演習などでも「ソーシャルエンジニアリングによる初期侵入」として行われたりもします。
そのため、フィッシングによる脅威を適切に認識して、ユーザーや組織が日頃から対策を施すことをお勧めします。
ここまでお読みいただきありがとうございました。
