iOSセキュリティコードの自動入力によるアカウント乗っ取りのリスク[ビデオ付き]

過去12か月で、ユーザー認証、トランザクション認証、またはデバイスバインディングの目的で、SMSテキストメッセージを介してセキュリティコードを顧客に送信する組織のセキュリティとサイバーセキュリティの状況に大きな変化が見られました。 OneSpanのケンブリッジイノベーションセンターの研究者であるAndreasGutmannによるこの記事では、そのような組織がサービスとユーザーのオンラインアカウントのセキュリティを向上させるために実行できる手順について説明しています。

アカウント乗っ取り（ATO）詐欺詐欺師がユーザーのオンラインアカウントへの不正アクセスを取得することは、多くの組織が直面する最大のセキュリティ脅威の1つです。 頻繁に使用されるアカウント乗っ取り方法には、ソーシャルエンジニアリング、man-in-the-middle攻撃、Webブラウザー攻撃、パブリックWiFi攻撃、Webページまたは電子メールの添付ファイルを介したマルウェア、および資格情報の詰め込みが含まれます。 アカウント乗っ取り詐欺に対する最も一般的な防御策は、多要素認証（MFA）、トランザクション認証、およびモバイルアプリケーションのデバイスバインディングを実現するためのセキュリティコードの使用です。 このようなセキュリティコードは通常、SMSを介して消費者の携帯電話に送信されます。 過去に私たちは発見しましたiPhoneがそのようなセキュリティコードを処理する方法における固有のセキュリティリスクオートコンプリート機能を使用し、Appleは2020年の終わりに報告された自動入力の脆弱性のいくつかにパッチを適用しました。

iOS 14のセキュリティコードの自動入力機能：iOS12の脆弱性の部分的な修正

iOSのセキュリティコードオートフィル機能は、ユーザーエクスペリエンスの摩擦を取り除き、SMS経由でiPhone（および消費者がデバイス間でSMSを共有する場合はMacBook / iMac）に配信されるセキュリティコードを処理する際の消費者エクスペリエンスを向上させる便利な機能です。 この機能は、着信SMSからセキュリティコードを自動的に抽出し、消費者がシングルタップでそれらのコードをWebサイトまたはアプリに挿入するためのインターフェイスを提供します。

図1：iOSのセキュリティコードの自動入力機能による提案。キーボードの上にある自動入力の提案を1回タップして、Webサイトのフォームフィールド（この画像には表示されていません）にセキュリティコード834956を入力します。

重要なのは、消費者が自動入力の提案に従うときに、SMSアプリケーションを開いてSMSを読む必要がなくなったことです。 ただし、自動入力の提案自体は、SMSから読み取ることができる受信したセキュリティコードに関する重要なコンテキスト情報を提供しません。 結果として、消費者は誰がどのような目的でセキュリティコードを送信したかを知らない可能性があります。 以前に示したように、これらの状況は悪意のある攻撃者によって悪用される可能性がありますここに。

その後、2020年後半のiOS 14のリリースにより、ドメインバインディングと呼ばれるセキュリティテクノロジーのサポートがセキュリティコードのオートフィル機能に追加されました。 これにより、SMSの送信者は、セキュリティコードを挿入するWebサイトを指定できます。 SMSにこの仕様がない場合、セキュリティコードの自動入力機能により、任意のWebサイトにセキュリティコードを挿入することが提案される可能性があります。 SMSのセキュリティコードのドメインバインディングに必要な構文は、次の図に視覚化されています。

図2：セキュリティコードオートフィルを使用したドメインバインディングに必要な構文の図。 最初の行は、SMSアプリケーションを開き、セキュリティコードを手動でコピーする消費者向けの人間が読めるテキストです。 2行目は機械可読コードであり、@example .comはhttps://example.comのWebドメインを指し、＃123456はそのドメインを対象としたセキュリティコードです。

iOS 14は、iPhone 5S、iPhone 6、およびiPhone 6Plusをサポートしていないことに注意してください。 これらのデバイスは脆弱なままであり、ドメインバインディングテクノロジーの統合によるAppleの部分的な修正の恩恵を受けることはありません。

次のビデオは、英国のノーサンブリア大学でこのトピックについて私が行った講義の記録です。 この講義では、iOSで見つかったセキュリティの脆弱性と、Appleによって実装された部分的な修正について詳しく説明します。

多要素認証の改善

多要素認証のユースケースは、セキュリティコードのオートフィル機能にドメインバインディングテクノロジーを追加することの主なメリットです。 SMSを介して配信されるセキュリティコードを利用して、顧客のWebサイトへのログイン時の保護を強化する組織は、ドメインバインディングを備えたセキュリティコードの自動入力機能を利用して、使いやすく安全な顧客エクスペリエンスを提供できます。

セキュリティのヒント：

このようなユースケースを持つ組織は、ドメインバインディングテクノロジーを採用し、対応するSMSのレイアウトを適応させる必要があります。 組織がモバイルアプリケーションでMFAのSMSを介してセキュリティコードを使用する（まれな）ケースでは、以下に追加のセキュリティのヒントを含めました。

デバイスバインディングに必要な変更

Appleによって実装されているドメインバインディングテクノロジーは、iPhone上のモバイルアプリケーションのユースケースをサポートしていません。つまり、組織はWebサイトのみを指定でき、セキュリティコードを入力する場所としてモバイルアプリケーションを指定することはできません。 したがって、このようなセキュリティコードの自動入力の提案は、フィッシングWebサイトなどの他のアプリケーションやWebサイトに表示される可能性があります。

セキュリティのヒント：

この問題を解決するために、組織は、セキュリティコードがiOSによってセキュリティコードとして認識されないように、対応するSMSを表現することができます。 組織は、SMSを組織に送信することにより、さまざまなレイアウトを評価できます。 セキュリティコードに細い灰色の線で下線が引かれている場合、iOSはそれをセキュリティコードとして認識します。 例として、組織はSMSのセキュリティコードの前に組織を識別するいくつかの文字を追加し、顧客が入力する必要がある対応するフォームフィールドにそれらの文字を事前に入力できます。 銀行Aのこのような実装では、セキュリティコード「124680」を送信するときに「BA-124680」を使用し、アプリケーションの対応するフォームフィールドに記号「BA-」を事前に入力できます。 iOSは現在、セキュリティコードなどの構造を認識していませんが、将来変更される可能性を排除することはできません。 したがって、そのような進展を積極的に監視する必要があるでしょう。

トランザクション認証の影響

トランザクション認証は、セキュリティコードの自動入力機能のサポートが最も少ないユースケースであり、SMSを介してセキュリティコードを配信する組織に最大のリスクをもたらします。

最初の問題は、ドメインバインディングテクノロジが、トランザクション認証に関連する一般的なセキュリティリスクを軽減するのに適切ではないことです。このリスクの主なセキュリティ上の懸念は、フィッシングではなくトランザクションの操作です。 セキュリティコードの自動入力機能はセキュリティコードのコンテキストを解除するため、ユーザーはその機能を利用するときにトランザクションが操作されていないことを確認できません。

さらなる問題は、セキュリティコードの自動入力機能が認識された通貨で金額を検出した場合、自動入力の提案の横にこの金額を表示しますが、機能は多くの通貨を認識しないことです。 結果として、認識された通貨を持つ国（たとえば英国）の顧客は、取引を承認するたびにこの情報を見ることに慣れることができます。 それでも、取引を操作するときに敵が通貨を認識できない通貨に変更した場合（たとえば、通貨を英ポンドからスウェーデンクローナSEKに変更した場合）、顧客はこれが多要素認証のコードであると誤解する可能性があります。

図3：左側の画像は、100ポンド相当の取引にリンクされた取引承認セキュリティコードの自動入力の提案を示しています。 右側の画像は、値SEK1500のトランザクションにリンクされたトランザクション認証セキュリティコードの自動入力の提案を示しています。

セキュリティのヒント：

組織は、トランザクション認証のセキュリティコードがiOSによってセキュリティコードとして認識されないように、対応するSMSを表現できます。 このアプローチの詳細については、上記のデバイスバインディングのユースケースのセキュリティのヒントを参照してください。

さらに、SMS経由で送信されるセキュリティコードよりも強力なセキュリティメカニズムの使用を検討してください。

• オンラインバンキングでのトランザクション認証の場合、ソフトウェアベースまたはハードウェアベースのオーセンティケーター使用することができます。
• オンライン決済でのトランザクション認証では、SMSを介したセキュリティコードの代わりに、帯域外認証（OOB）またはトランザクション認証用のアプリ内コードを使用できます。