Amazon の 2段階認証(2SV)が突破された？
Amazon の 2段階認証(2SV) が突破されたのではないかという件が話題になっています。
私もこれについてはとても気になっており、できるだけ早く真相が解明されることを願っています。
そこで、ふと疑問に感じたことが、2SV は何をどの程度防いでくれるのかということです。
ここでは、Amazon を例に、いろんなことを考えていきたいと思います。
フィッシングの前には無力
まず、2SVの突破と言っても様々な手口があります。
徳丸先生の動画が示す通り、中継型フィッシングであれば、自ら正しい認証情報を入力することになるので、2SVを設定していようがいまいが突破されてしまいます。
フィッシングではなく、かつ、TOTPでも突破されたケースも
今回の被害者には、中間者攻撃やフィッシングを受ける状態になかったと仰っている方がいました。
なので、何かしらの経路で認証情報が流出した可能性も考えられます。
認証情報が流出している場合、2SV では不正な認証を完全には防げない
認証情報が流出してしまった場合、2SV を設定していても速やかにパスワードを変更する必要があります。
これはそのサービスの認証制御の仕様によって何度も試行できるケースがあるためです。
Amazon はどうなっているか
認証情報が正しいかを確認できる
多くのサイトでは 2SV の前に Email + パスワード などの認証情報が正しいかどうかを確認できます。(添付画像の上部のように、パスワードが正しくないことをユーザに伝えています。)
これは、認証情報が流出していた場合に、攻撃者もその認証情報が正しいかどうかを確認できることを意味します。
例えば 6桁の数字が 2SV の認証コードとして使われている場合、 2SV の確認画面に遷移したら、攻撃者は 100万分の1以上の確率で認証を突破することができます。
TOTP 認証アプリケーション を利用している場合に、不正なログインの試行に気づきにくいケースも
2SV の認証コードがどのように生成され、どのように受信されるかの設定によっては、利用者は不正なログインの試行が行われたことを気付けない場合があります。
例えば、Email や SMS で 認証コード を受け取る設定をしている場合、利用者は想定外の通知を受け取ることで不正なログインの試行に気づくことができます。
一方で、Google Authenticator などの TOTP 認証アプリケーション を利用している場合、サービス の仕様によっては、認証の失敗を通知されず、利用者は 不正なログインの試行 に気づきにくくなります。
特定時間に、何回 2SV の認証コードの入力ができるのか
- 一度の 2SV の認証で、12回失敗後の13回目に正しい 2SV の認証コードを入力したらログインできた
- なぜ 12回なのかといえば、特に理由はありません...(プライベートなので許して)
- 一度の2SVの確認で、50回失敗後の51回目に正しい 2SV の認証コードを入力したらログインできなかった
- 50回失敗後、再度認証をやり直し、1回目に正しい 2SV の認証コードを入力してもログインできなかった
- 50回失敗後、1時間経過後に認証し、1回目に正しい 2SV の認証コードを入力したらログインできた
ロック条件と年間の最大試行回数
上記の情報から、一定回数以上の2SVの認証失敗 で 一時的なロック状態 になると考えられます。
認証情報が流出していた場合、サービス側でそれ以外の対策をしていなければ、特定時間以内に2SVが突破される確率は高くなります。
今回の実験で成功した回数が、ロックが始まるギリギリの回数だったと仮定して、13回 失敗するとロックがかかり、ロックが解除されるまで 1時間 かかる という仕様であれば、単純計算で 1年間に11万回以上 は 2SV の認証の試行ができます。(下添付表の一番下の項目)
年間 11万回 試行できれば、複数人の認証情報が流出している場合、1年間 に数件は 2SV を突破されても不思議ではありません。
以下は 上記のような単純な仕様の場合に、 ロックが始まる試行回数 と、 ロックが解除される時間 を変数とした、 2SV の年間最大試行回数の表です。
ただし、実際にはそんなたくさん試行はできないようになっているはずです。
サービス側での対策
上記のような単純計算をもとにすると、2SV を設定していても特定期間内に突破されやすくなってしまいます。しかし、 Amazon などの有名サービスは、おそらく以下のような対策がされているはずです。
- 同一IPによる試行回数の制限
- 何度か連続して 2SV の認証に失敗し続けた場合に、アカウントを休止状態にする(今回、さすがに休止状態になるまでの回数などの検証をする体力はありませんでした)
- 2SV を試行したことを正当な利用者に気付かせる仕組み
上記の表のような単純計算で「年間最大試行回数」で仮に 10万回 であったとしても、アカウントを休止状態にする仕組みがあれば、アカウントが休止状態になるまでの試行回数しか攻撃者は認証に挑戦できません。
利用者としてすべき対策
有名サービス以外でも、IDaaS などを使わずに自前で 2SV を実装しているサービスはたくさんあります。そのすべてが認証情報の流出を防いでいて、適切に不正な認証からの保護が実装されているとは限りません。そのため、利用者側では、上記の サービス側での対策 がされていないことを想定した対応が必要でしょう。
対策の一部としては以下があります。
- パスワードを定期的に変更する
- 過去のパスワードと同じパスワードを利用しない
- 2SV の認証コードをEmailなど、利用者が意識して受け取れる状態にする
- SMSは非推奨とされている (こちらがその理由としてまとまっててわかりやすい)
- SMSインターセプトについては知見がないので、日本ではそこまで脅威でないという意見を目にしたこともありますが、それが本当か、通知が来なくなるのか中継されるだけなのかも含めてどなたか教えていただけると嬉しいです
- SMSは非推奨とされている (こちらがその理由としてまとまっててわかりやすい)
- サービスに2SVの認証の失敗を通知する設定があれば、それを有効化する
- Amazon では TOTP を使っていると、この仕組みがないので気付けないか
(余談) AWS で認証失敗を検知するには
AWSアカウントで、 AWSのコンソールへの認証の失敗を通知する設定をしていますでしょうか。
この設定であれば、TOTPであっても認証の失敗に気づくことができます。
以下の記事をもとに簡単に行えるのでおすすめです。
パスワードの定期変更って不要なのでは？
2018年に総務省がパスワードの定期的な変更は不要とし、一般的にそれが常識だと広まってきていると思います。様々な権威の見解は以下のとおりです。
NIST
記憶シークレットを任意で(例えば，定期的に)変更するよう要求すべきではない(SHOULD NOT)．しかしながらAuthenticatorが危殆化した証拠がある場合は，変更を強制するものとする(SHALL)．
NIST Special Publication 800-63Bによると、記憶シークレット(私たちが一般的に考えているwebサービスのパスワード)は、定期的な変更を要求すべきではないとしています。
NISC
むしろ、パスワードの基準を定めず、定期的な変更のみを要求することで、パスワードが単純化したり、ワンパターン化したり、サービス間で使い回しするようになることの方が問題となります。一方、アカウントが乗っ取られたり、流出の事実を知った場合は速やかにパスワードを変更し、その原因も特定しましょう。
NISC の インターネットの安全・安心ハンドブック Ver5.00 (p.114) によればパスワードの定期変更が不要である理由は、それによるパスワードの単純化のデメリットの方がメリットより上回るからだと説明されています。また、どこかしらで流出の可能性が疑われる場合は、パスワードの変更は有効な手段と考えて良いと思います。
IPA
ＩＰＡでも「定期変更をしなくてもいいんですよね？」と問い合わせを受けることが増えましたが、私たちとしては定期変更を肯定も否定もしないという立場です。
こうしたケースも踏まえると、定期変更が役に立つ場面はゼロではないと考えています。
定期変更が役にたつケースは存在するとのことです。
ただし、IPA としては否定も肯定もしないという立場のようです。
パスワードの定期変更と非推奨の診断
甲状腺がんの超音波検査は検出感度が高すぎるため手術が不要な小さながんを見つけてしまう弊害が大きく、諸外国のガイドラインでも超音波検査による甲状腺がん検診は非推奨となっています。
パスワードの定期変更は一見有効そうなのに、IPAが「否定も肯定もしない」と述べているのは、甲状腺がんの特定の検査が非推奨なのと構図が似ているのかなと思います。
甲状腺がんの場合、 「偽陽性の診断を受けた患者の心理的負担の増加や不要な手術による侵襲」 と 「過剰診断」 というデメリット と、「陽性患者の寛解」 というメリットを比較すると、マクロで考えればあまりにデメリットの方が大きくなるため、検査が推奨されていません。
パスワードの定期変更もこれと似ていて、「パスワードの定期変更による単純化、それによる攻撃による被害」や「サービスに対するUXの低下」というデメリットの方が「定期変更で防いだ攻撃」というメリットよりもマクロでは大きいため非推奨になったと考えられます。
なので、権威がある機関が推奨してしまうと、マクロでみた時にはデメリットが上回るので肯定できないのだと思います。
しかし、ミクロでは診断を受けることでしか助からない陽性患者がいるように、定期変更でしか回避できない攻撃の存在は否定できません。また、がん検査と比較すると、デメリットについては利用者のリテラシーがあれば十分コントロール可能なものであるので、リテラシーが高い人(パスワードを単純化させない、他のサービスと共通のパスワードを使ってはいけないことを理解している人)については、作業が面倒だという点以外にはデメリットはないようにも思えます。
Amazon の件の仮説
個人的な意見を言えば、他サイトなどで Amazon で使われている認証情報と同じ認証情報が流出していたのではないかと考えています。
X で 「Amazon SMS」 で検索すると、認証にトライされているという報告をいくつか見つけることができます。
これは、最初の認証は突破されていることを示唆します。
仮に、 Amazon が 2SV の認証失敗をもとにアカウントを休止状態にするまでに、 2SV を 25回 トライすることができるのであれば、4万分の1以上 の確率で突破することができます。また、このアカウント休止状態にするまでの認証に失敗したという情報が3ヶ月でリセットされてしまうとすれば、1年間に100回はトライすることができてしまいます。その場合、1年で突破される確率は 1万分の1以上 となります。
もし 1万件 以上、Amazon で使われている認証情報と同じ認証情報が流出していた場合、数件の 2SV 突破が発生してもおかしくありません。
流出した情報をもとに雑に認証を試していたら、おそらく大量のアカウントが休止状態になったいう報告が X 上でされると思うので、攻撃者は 2SV 確認画面に遷移したことを確認し、休止になるギリギリまで認証を試しているかもしれません。
Amazon に問題があるのか？
私の仮説が正しければ、Amazon に責任があるとは思えません。
本件は昔からある古典的な問題であり、他のサイトでも同じような事態がしばしば発生しているのではないかと考えます。
認証情報が流出してしまった場合には、不正ログインなどをサービス側で防ぐには限界があります。
2SVを設定しているから安全だと考えるのではなく、それは緩和策でしかないことを意識して 「利用者としてすべき対策」 を意識するべきだと考えます。
締め
昨今では、闇サイトでこうした情報を売買することで金銭を得ることができ、サービス内部からも個人情報を流出させる動機付けがあります。
また、さまざまなサービスで 2SV を設定できますが、 2SV を設定したからといって安全ではなく、認証情報が流出した場合には、設定次第では期待する効果を発揮できない場合があります。
本件が話題になった際に、「2SVの話なのにパスワードを強固にする意味がない」という意見をいくつか目にしましたが、私個人としては逆ではないかと考えています。
仮にサービス側の 2SV の仕様に不備があったとしても、最初のパスワード認証を突破できなければ 2SV にすら辿り着かないからです。
なので、真相が明らかになるまでは、暫定対応としては パスワードを変更することが望ましいのではないでしょうか。