1. 概要
不正ログインへの対策として、近年「二段階認証」が広く用いられるようになりました。しかし、当社が実施しているWebアプリケーションの脆弱性診断業務においては、二段階認証が適切に実装されておらず、迂回(回避)できてしまう事例が散見されます。
今回の記事では、二段階認証の不適切な実装に対する攻撃例と、その原因および対策について紹介します。
本稿がWebアプリケーションのセキュリティ対策の一助になれば幸いです。
2. 基礎知識
2.1 二段階認証とは
Webアプリケーションへの不正ログインに関するセキュリティインシデントは相変わらず数多く報告されています[1][2][3]。ユーザが強度の弱いパスワードを設定することによるパスワードの推測、Webアプリケーションの脆弱性を突かれることによるパスワードの漏えいなどが、不正ログインの原因として挙げられます。その対策の代表例として、「二段階認証」があります。
二段階認証のよくある実装の一例を図1に示します。この実装では、ログイン後や重要な処理実行前に、アカウントに登録済みのSMSやメールアドレスに「二段階認証コード」を送信し、そのコードを入力しないと処理が行われないような仕組みになっています。これにより、もし攻撃者がAさん(正規のユーザ)のアカウントのIDとパスワードを手に入れ、ログイン認証を突破しても、SMSやメールアドレスを受信できるのは基本的にAさんのみなので、攻撃者はAさんのアカウントを侵害することはできません。
図1：二段階認証による不正ログイン対策の例
2.2 二段階認証の突破
しかしながら、二段階認証が完全無欠の対策と言えるかというと、決してそのようなことはありません。MFA疲労攻撃[4]、リアルタイムフィッシング[5]など二段階認証に対する攻撃は実際に報告されています。
これらは二段階認証が正しく実装されているうえでの攻撃手法となります。一方、Webアプリケーションの脆弱性診断業務を行っていると、二段階認証の実装そのものに不備があり、二段階認証を回避可能な脆弱性がしばしば見受けられ、危惧しています。次の章では、そのような不適切な実装の一例と攻撃手法を紹介します。
3. 二段階認証の不適切な実装に対する攻撃例
3.1 攻撃対象の脆弱性のあるWebアプリケーション
今回例として用いる、二段階認証の実装に脆弱性のあるWebアプリケーションの正常遷移を図2に示します。決済機能を有するWebアプリケーションであり、以下のステップで送金処理手続きを行います。
Step1：ユーザは自身のIDとパスワードでログインします。
Step2：ユーザは重要な機能（以降、例として「送金」機能とします）の実行画面の表示を要求します。
Step3：Webアプリケーションは二段階認証コード入力画面を表示し、事前に登録したメールアドレス宛に二段階認証コードを送信します。
Step4：ユーザはその二段階認証コードを入力します。
Step5：送金実行画面を表示します。
Step6：ユーザは送金実行画面にて、送金ボタンを押します。
Step7：送金が完了し、送金完了画面を表示します。
図2：例として用いるWebアプリケーションの正常遷移
一見、このWebアプリケーションにおいては、送金の実行に二段階認証コードが必須であるように見えますが、不適切な実装のため、認証コード無しに「送金」を実行できる脆弱性が存在することを想定しています。
3.2 攻撃シナリオ
今回の攻撃シナリオでは、「攻撃者が被害者の認証情報(ID,パスワード)を使い、重要な機能を実行する」ことをゴールとしています。なお、前提として攻撃者は被害者のメールを見ることはできないことを仮定します。以下に、攻撃シナリオを示します。(図3)
Step1'：攻撃者は被害者の認証情報(IDとパスワード)を何らかの方法(単純なパスワードの推測やパスワード漏えいなど)で入手します。
Step2'：攻撃者は手に入れた認証情報でログインします。
Step3'：攻撃者は正常遷移のStep6の送金ボタン押下時と同等のHTTPリクエストを実行します。
Step4'：送金が完了し、送金完了画面を表示します。
図3：攻撃シナリオ
攻撃者は二段階認証コード無しに、送金を実行できてしまいました。では、二段階認証入力を経由していないのになぜ送金が実行できたのでしょうか？
4. 原因と対策
4.1 原因
結論から言うと、上記の脆弱性が生じた原因は、送金を実行したユーザが「二段階認証済みの状態」であるか「二段階認証済みではない状態」であるかをWebアプリケーションで区別できていない実装になっているためです。
通常の遷移では、二段階認証コードを入力すると送金画面が表示され、その画面から送金を実行しますが、あたかもその方法でしか実行できないかのように見えます。しかし、HTTPの特性上、攻撃シナリオのStep3'のようにユーザ(攻撃者)は任意のタイミングで任意のHTTPリクエストを送信できます。たとえば、Burp Suite[6]などの専用ツールや、Pythonなどのプログラミング言語を使用することで誰でも任意のリクエストを作成して、送信することが可能です。(図4)
図4：Burp Suiteによる任意リクエストの作成、送信例
つまり、二段階認証コードを入力して送金実行画面へ遷移せずとも、「送金のHTTPリクエストを送信」自体はいつでも可能なのです。本Webアプリケーションの開発者にはこの認識がなく、ユーザは送金する際、絶対に二段階認証コードを入力して送金実行画面へ遷移する必要があるという思い込みがあったため、二段階認証済みかそうでないかの状態をわざわざ区別することを怠り、今回の脆弱性が発生してしまいました。
4.2 対策
ユーザ(攻撃者)が任意のHTTPリクエストを送信できてしまうというHTTPの特性は、否定することはできず、受け入れなければなりません。そのため、実行画面への遷移可否のみに頼らず、HTTPリクエストを実行したユーザが「二段階認証済みの状態」なのか「二段階認証済みではない状態」なのかをアプリケーション側で区別することが根本的な対策となります。
上記は開発者側の対策ですが、利用者側でできる対策はあるでしょうか？残念ながら利用者側ではStep1'の被害をある程度抑えるくらいしかできることはありません。しかし、Step1'の被害は主にパスワードの基本的な使い方を守っていれば軽減することができます。
・推測可能な単純なパスワードを設定しない。
・複数のサービスで同じパスワードを使い回さない。
・パスワードを厳重に管理する。
5. まとめ
脆弱性のあるWebアプリケーションの例を用いて、二段階認証に対する攻撃およびその原因と対策を示しました。
Webアプリケーションにおける二段階認証の実装には、HTTPリクエストを実行するユーザが「二段階認証済みの状態」なのか「二段階認証済みではない状態」なのかをアプリケーション側で適切に区別することが重要です。
今回示した攻撃例はかなり単純化しており、実際は診断士がWebアプリケーションごとに様々な攻撃方法を試します。開発したWebアプリケーションの二段階認証機能にセキュリティ面の不安がある場合、是非弊社の脆弱性診断をご検討ください。
6. SSKのセキュリティ運用監視サービスおよび脆弱性診断サービスについて
コロナ禍を経て急速なデジタルシフトやDXの進展により、サイバー攻撃の標的となりうる範囲は大きく広がっています。更にランサムウェアをはじめとするサイバー攻撃の脅威は増す一方となり、企業活動においてサイバーセキュリティ対策は必要不可欠な課題となっています。
SSKのセキュリティ運用監視サービスでは、24時間365日、リアルタイムでセキュリティログの有人監視をおこなっております。セキュリティ対策として様々なセキュリティ機器やサービスを導入するケースも増加しており、当社ではUTM製品をはじめ、SASE、EDR等、新しいセキュリティソリューションも監視対象としてサービス展開を行っています。また、脆弱性診断サービスでは、診断経験豊富なセキュリティエンジニアがお客様のシステムを診断し、検出された脆弱性への対策をご提案しております。Webアプリケーションだけでなくネイティブアプリケーション診断やクラウドサービス設定診断も行っています。
セキュリティ運用監視サービス：
https://www.ssk-kan.co.jp/e-gate#e-gate--02
脆弱性診断サービス：
https://www.ssk-kan.co.jp/vulnerability-assessment
7. 参考情報
[1] Sansan株式会社, ログイン情報の管理に関する注意喚起, 2023年10月12日閲覧
https://jp.corp-sansan.com/news/2023/0921.html
[2] SMBC日興証券株式会社, 日興イージートレードにおける不正アクセスにご注意ください, 2023年10月12日閲覧
https://www.smbcnikko.co.jp/news/customer/2023/n_20230904_01.html
[3] ジュピターショップチャンネル株式会社, 不正ログインによる商品購入の発生について, 2023年10月12日閲覧
https://www.shopchannel.co.jp/pdf/pr230106.pdf
[4] 日本マイクロソフト株式会社, Microsoft Authenticator の MFA 疲労攻撃対策 - 数値の一致による MFA が 有効化されます, 2023年10月12日閲覧
https://jpazureid.github.io/blog/azure-active-directory/defend-your-users-from-mfa-fatigue-attacks/
[5] 日本放送協会, "見分けるのは無理" 知ってほしい「フィッシング詐欺」対策は, 2023年10月12日閲覧
https://www3.nhk.or.jp/news/special/jiken_kisha/kishanote/kishanote78/
[6] PortSwigger, What do you want to do with Burp Suite?, 2023年10月12日閲覧
https://portswigger.net/burp
※本資料には弊社が管理しない第三者サイトへのリンクが含まれています。各サイトの掲げる使用条件に従ってご利用ください。
リンク先のコンテンツは予告なく、変更、削除される場合があります。
※掲載した会社名、システム名、製品名は一般に各社の登録商標 または商標です。
≪お問合せ先≫
サービス＆セキュリティ株式会社
〒150-0011
東京都渋谷区東3丁目14番15号 MOビル2F
TEL 03-3499-2077
FAX 03-5464-9977
sales@ssk-kan.co.jp