Introduction
QRコード、正式にはクイックレスポンスコードは、多様な英数字や複雑な情報を埋め込むのに適しています。また、見た目も洗練されています。QRコードは、従来のバーコードに対する革新的な改良であり、1次元のバーコードと異なり水平方向と垂直方向の2次元構造を持ちます。最大4296文字(または7089桁)まで格納可能で、アクセント記号や特殊文字にも対応しています。文章、フレーズ、ウェブURL、ログイン情報なども幅広く埋め込むことができます。
しかしながら、QRコードはその利便性にもかかわらず、QRコード攻撃として知られるウェブ攻撃の手法でもあります。
QRL(クイックレスポンスコードログイン)は、パスフレーズ不要の認証方法です。QRコードに利用者のログイン情報が埋め込まれており、これを読み取る(QRコード生成)ことでアカウントにサインインできます。もちろん、QRコードを読み取れるカメラ付きの機器が必要ですが、今日販売されているほとんどのスマホやPCにはその機能が備わっています。
日本の製造企業、デンソーウェーブがQRコードを開発しました。同社は従来のバーコード以上の情報量を扱える、新たなコード体系を求めていました。増加する車両や部品の管理のために必要とされたこの技術は、デンソーウェーブの原雅弘さんが2人の協力者と共に生み出し、1994年頃から利用可能となりました。
QRLジャッキングは、利用者が本物のログイン用QRコードではなく、攻撃者の用意したQRコードを読み取るよう騙されるウェブ攻撃です。利用者が悪意あるQRコードを読み取ると、攻撃者がアカウントにアクセスし、様々な被害が発生します。
QRLジャッキングは、他のウェブ攻撃同様、ソーシャルエンジニアリングで利用者を騙し、改ざんされたQRコードを読み取らせる手法に依存しています。
QRLジャッキング(Quick Response Code)は、QRコードログインを利用した攻撃手法を指します。基本的ではありますが危険なこの攻撃は、『QRコードでログイン』機能に依存する全てのアプリに影響を及ぼします。基本は、被害者に攻撃者のQRコードを読み取らせることに尽きます。
前述のとおり、攻撃が容易であることがこの手法の利点の一つです。攻撃者は、期限付きのQRコードを定期的に複製し、フィッシングサイトに表示させるコンテンツを作成するだけで、効果的なQRLジャッキング攻撃を実行できます。ご存知のように、セキュリティが施されたQRログインではQRコードに有効期限が設定されていますが、Wallarmのテストでは一部のサービスにその仕組みが欠けていることが確認されました。
つまり、必要なのは攻撃者(最低限スクリプトキディ)と、攻撃者側で動作するQRコード更新スクリプト、巧妙に作り込まれたフィッシングサイトのページまたはスクリプト、そして被害者という構成になります。
クリックジャッキングは、巧妙なウェブページのデザインを悪用し、一部の要素を隠すことで利用者に騙され、例えばアカウントの主要メールアドレスやパスワードを攻撃者のものに変更させる手法です。しかし、攻撃者が仮に成功しても、後に二要素認証が有効になったアカウントにログインしようとして失敗する可能性があり、結果的に攻撃は成立しません。
QRログイン機能がシングルサインオンおよび二要素認証と併用されているため、安全性と利便性を両立する最後の防衛手段となっています。「読み取ってログイン」は非常に簡単で安全、かつ効果的な認証方法です。しかし、QRLジャッキングは利便性とセキュリティ体制に大きな影響を及ぼす恐れがあります。
これにより、なぜQRLジャッキング攻撃が従来のクリックジャッキング攻撃よりも深刻なのか、ご理解いただけると思います。
QRLジャッキング攻撃により、攻撃者は脆弱なQRコードログイン機能を悪用し、アカウント乗っ取りや評判の損失などの被害を引き起こす可能性があります。
利用者がQRコードを読み取ると、攻撃者に所在地(正確なGPS位置、デバイス種、IMEI、SIMカード情報など、そのアプリがログイン時に提供する個人情報)が渡される恐れがあります。
攻撃者が「データ開示」セクションで取得した情報の一部は、サービスサーバと通信してアプリ内で利用されるデータを説明するために使われます。しかし、この情報は安全性の低いネットワークを経由することが多く、攻撃者が改ざんや削除を容易に行える場合があります。
複数の攻撃手法を組み合わせることで、さらに効果的な攻撃が可能となります。そのため、QRLジャッキングは多様な強力な攻撃手法と連携することが考えられます。以下のケースを考えてみてください。
ウェブアプリのログインページ全体を複製し、見分けがつかない偽ページに自分の攻撃用QRコードを組み込むことで、熟練のソーシャルエンジニアは確実に被害者にQRコードを読み取らせることが可能です。
利用者が特定のモバイルアプリでこのQRコードを読み取ると、ハッキングされたサイトは広告表示や新機能の埋め込みといった改変に対して無防備となり、結果としてアカウントが乗っ取られる危険性があります。
SSLストリッピングは、SSLサイトの安全性を低下させ、非安全モードでの動作を強いる攻撃です。HSTSポリシーが有効でないサイトは特に脆弱で、攻撃者がサイト内容(例えばQRコードログイン部分)を操作する手段となります。
HTTPSで動作し、HSTSを採用しているサイトでは、標準的なQRコードログイン機能はbase64でエンコードされたQRコード画像を生成し、固定ページに掲載するため改ざんが困難です。しかし、多くのウェブアプリやサービスはCDNを利用したQRコード画像生成プロセスを採用しており、これらのCDNがHTTPSダウングレード攻撃に対して脆弱なサーバ上に配置されている場合、攻撃者がCDNのURLを自らのQRコードに差し替えることで安全な接続を低下させる狙いがあります。なお、QRコードは画像ですので、ログインページに表示される形でも問題は生じにくいです。
攻撃者は、ネットワーク上でMITM(Man in the Middle Attack)を実行し、通信中の各非SSLサイトにJSコードを注入することで、被害者を狙います。これは、安全でないLAN上のサイトやトラフィックを狙う最も現実的な攻撃手法です。
QRコードログインの実装に不備がある場合、アカウント乗っ取りが一層頻発する恐れがあります。調査の中で、あるSNSアプリが他人のQRコードを読み取ってフレンド申請ができるようにしている事例が確認されました。しかし、ログイン機能と同じ画面で実行されるため、攻撃者がログイン用QRコードを複製し「これがQRコードです。友達追加のために読み取ってください」と誘導された場合、アカウントが乗っ取られる危険性があります。
QRLの利用を控える以外、利用者がQRLジャッキング攻撃から完全に守る手段は限られています。実際、OWASPもこれを推奨しています。
さらに、サイト管理者は攻撃リスクを低減するための方法をいくつか検討できますが、原則として認証手段としての利用は避けるべきです。どうしてもQRLを使う必要がある場合、以下のセキュリティ対策を講じることが望ましいでしょう。
Email/SMSによる認証
QRコードでログインした後、サイトやサービスから利用者に認証用のメールまたはSMSが送信されます。認証メッセージが届かない場合、不正の可能性が考えられます。
IPアドレスの制限
QRLジャッキング攻撃を防ぐもう一つの手段は、QRコードを利用できるIPアドレスを制限することです。利用者がサイトやサービスからQRコードを要求し、サーバ側で利用者のIPアドレスを認識する仕組みを整えれば、攻撃者のサーバが認証リクエストを処理するのを防げます。ただし、攻撃者はIPアドレスを偽装する可能性があるため、完全な対策とはなりません。
地域制限
もう一つの対策は、認証リクエストを受け付ける地域を限定することです。サイトやサービスは利用者のIPアドレスからその地域を把握できるため、攻撃者のサーバが対象と異なる地域にある場合、被害のリスクを低減できます。
しかし、これらの対策は全体的に実用性に乏しく、どれも万能ではありません。第一は理論上の対策で、第二は容易に回避され、第三は攻撃者のサーバが対象と同一地域にある場合には効果がありません。
したがって、最も有効な対策は、基本的にQRLの利用を控えることです。
認証にQRLを組み込む必要がある場合は、以下のセキュリティのベストプラクティスを検討してください。これはQRLジャッキング対策に限らず有効です。
ファイアウォールを利用 — 主要なOSにはインバウンドファイアウォールが、企業用ルーターにはNATファイアウォールが搭載されています。有害なリンクをクリックした際の保護になるため、これらが有効になっているか確認してください。
ブラウザがアクセス先のサイトやSSL証明書に関して警告を表示した場合は、そのサイトへのアクセスを控えてください。
送信者が確認でき、内容に信頼が持てる場合のみ、メール内のリンクや添付ファイルをクリックしてください。
最新情報を購読