前回の記事では、「こんな理由で認証情報に対する攻撃が増えそうだな～」という話と、「認証情報を悪用された場合はこんな調査をしてます」という内容（=タダの私のお気持ち表明）を書きました。
今回は、技術的に認証情報に対する攻撃の中で、「二要素認証（多要素認証）、二段階認証に対する攻撃」について、考察していることを書いてみようと思います。
二要素認証（多要素認証）、二段階認証への攻撃って？
前回記事で「認証情報」に対する攻撃で、認証情報を盗まれることによって発生する不正アクセスによる被害の懸念などをかきました。
その対策として、「二要素認証（多要素認証）、二段階認証」の利用が専門家から推奨されています。
「二要素認証（多要素認証）、二段階認証」とは、ログインなどの「認証」の際、IDに対し認証情報を複数示すことで自身を証明し、認証してもらう方法です。
多くの場合では、要素の一つに「パスワード」が用いられます。
二要素認証（多要素認証）では、パスワード（知識認証）に加えIDカードやスマホ（所持認証）や指紋・静脈（生体認証）などといった別の方法を１ないし複数使用することで、それが無い人は認証できない、という仕組みです。
（厳密には、パスワードを1つの要素にする必要はなく、パスワード以外の要素を複数使っても良い。・・・ハズなんだが、認証の一つにパスワードを使うことがほとんど。呪いか何かか？）
二段階認証では、同じ要素だが異なる情報を2つ使用する、という方法です。
多くの場合、「知識認証」になるパスワードを1段目に入力し、さらに別の方法で得られる知識認証情報（パスワード）を入力する、という方法が取られています。
こうした方法でアカウントを不正利用した不正アクセスを防止するため、セキュリティの専門家だけでなく意識が高い人でも「二要素認証（多要素認証）、二段階認証は常識」となっていると思います。
しかし、本記事は そんなセキュリティで大丈夫か？ ということを問いかけるものとなります。
ただし、「二要素認証（多要素認証）、二段階認証」を否定するものではなく、むしろ推奨することに変わりはありません。
しかし、一方で、
「二要素認証（多要素認証）、二段階認証という仕組みがどこに効くか？」ということをちゃんと理解しているか？
ということを問いかけたいと思います。
一言でいうと、
「二要素認証（多要素認証）、二段階認証」 ≠ アカウントの保護
です。
「二要素認証（多要素認証）、二段階認証」は、あくまで「認証」という手続きにおいてのみ有効なセキュリティ対策なのです（だって、名前にも認証ってかいてあるしね？）。
具体的に言うと、二要素認証のうち、よく利用される一つめの要素のパスワードが漏洩した（または、どんなに厳しく言っても一定数残るパスワードを使いまわすDQNがいる）場合でも、もう一つの認証情報が提示できないことにより、結果的に攻撃者が認証に成功できないという「だけ」であるといえます。
んなもん当たり前だろ
と思われたお方、素晴らしいです。
（もうこの記事のオチもわかりそうなので、ここで読むの止めてもいいかも。）
しかし、セキュリティの意識が高くて「二要素認証（多要素認証）、二段階認証」を導入している人でも、ここを勘違いしていると思われるケースをSNSなどで見かけることがあり、問題提起しました。
もちろん、「認証が通らなければ、アカウントが悪用できないんだから同じじゃん？」と思う方もいるかもしれません。
こういうときは、最近流行りの「攻撃者目線で考える」っていうのをやってみましょう。
私が攻撃者ならどうするか？
別に二要素認証（多要素認証）、二段階認証以外を突破のためのターゲットにすればいいんじゃないかねw
しかし、これは「二要素認証（多要素認証）、二段階認証」を使用しているアカウントをターゲットにしないという意味ではないのです。
「二要素認証（多要素認証）、二段階認証」のアカウントをターゲットにしているのに、二要素認証（多要素認証）、二段階認証以外を突破のためのターゲットにする？何言ってんだお前？
と思った方には、ぜひ続きを読んでほしいと思いますｗ
（相変わらず前置きがなげーぜ・・・）
認証によるセッションキーやトークン
では、「二要素認証（多要素認証）、二段階認証」を使っているアカウントに対し、「二要素認証（多要素認証）、二段階認証」を突破する方法以外で不正アクセスされる可能性について考察してみます。
1つめの例として、Webサービスでのセッションクッキーやアプリケーションサービスで使うトークンについて考えてみます。
OAuthでは、認証におけるトークンの要求や応答に関して規定されています。
参考記事：一番分かりやすい OAuth の説明
https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be
攻撃のイメージを図に示すと、このようになります。
正規のユーザが認証が必要なアプリケーションを利用しようとした場合、認証を受ける必要があります。
この際、「二要素認証（多要素認証）、二段階認証」を使って認証をします（①）。
認証が成功すると、今度はクライアントがトークンを要求します（②）。
認証サーバは、この時トークンを発行します（③）。
Webサービスのセッションクッキーも、認証を依頼して認証が成功すると、セッションクッキーを受け取ります。
クライアントは、以後このトークンやセッションクッキーを利用してサービスを利用することになります（④）。
では、攻撃者がこの流れで「二要素認証（多要素認証）、二段階認証」を突破せずに不正アクセスするにはどうすればいいでしょう？
図で見て分かるとおり、単純な実装の場合、原理的にはトークンまたはセッションクッキーを盗むことができれば、不正アクセスが可能になります。
Kerberos認証のチケット
Windowsで現在ADサーバの認証で主に利用されているKerberos認証ではどうでしょうか？
Kerberos認証の場合、クライアントの情報が暗号化されて含まれているチケットを利用しているため、単純にチケットを盗んだだけでは不正アクセスが困難なようにみえます。
しかし、これも既知の攻撃法が成功した場合、残念ながら「二要素認証（多要素認証）、二段階認証」を突破する方法以外で不正アクセスされる可能性について考察してみます。
（なお、ADサーバでの二要素認証、二段階認証の実装には詳しくないですが、ざっと調べてみると少なくともそういうサードパーティ製品はあるようです。）
攻撃のイメージを図に示すと、このようになります。
正規のユーザが認証が必要なアプリケーションを利用しようとした場合、ADサーバで認証し、最終的にサービスチケットを受け取る必要があります。
この際、「二要素認証（多要素認証）、二段階認証」を使って認証をします（①）。
ADサーバの認証サーバ(AS)は、認証に成功するとTGT（ざっくり言うと、サービスチケットを発行するためのチケット）をクライアントに発行します（②）。
この際、TGTには暗号化されたクライアント情報が入っているため、単純にこのTGTをパクっても不正アクセスは困難です。
クライアントは、サービスを利用するためにTGTを使ってサービスチケットの発行をチケット発行サーバ（TGS）に依頼します（③）。
TGSは、TGTとクライアント情報を検証し、問題がなければサービスチケットを発行します（④）。
クライアントは、受け取ったサービスチケットを利用してサービスを利用します（⑤）。
ややこしい手順なうえ、チケットの中身は暗号化されたデータや鍵が含まれており、仮にチケットを盗んでも単純には不正アクセスできません。
この仕組みを利用して、シングルサインオンを実現しています。
しかし、ADサーバでは既に「Golden Ticket」や「Kerberoasting」などの攻撃手法が知られています。
当然、様々な制約があるものの、チケットを偽造することは不可能ではなく、これに成功すれば、原理的には「二要素認証（多要素認証）、二段階認証」を突破することなく不正アクセスが可能になる、ということになります。
トークンやセッションクッキー等の窃取やそれに伴う不正アクセスの事例
実際に、既に事例が発生しつつあります。
2022年4月、Githubは盗まれたトークンを利用して不正アクセスがあったことをブログで公開しました。
Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators
https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/
このケースでは、どのようにして認証のトークンが盗まれたかまでは解説していません。
しかし、トークンが盗まれたことによって不正アクセスが発生したことは間違いないようです。
ユーザの認証方法も触れられていませんが、認証が一要素であろうと二要素であろうと、認証後に発行されたトークンが盗まれれば同様の不正アクセスが発生し得ることは、この事例からも容易に想像ができます。
2022年7月、MicrosoftはAiTM(Adversary-in-The-Middle)を行うフィッシングサイトを利用して、セッションクッキーを盗む攻撃について報告しました。
多要素認証を回避するサイバー攻撃、Microsoftが発見
https://news.mynavi.jp/techplus/article/20220715-2399206/
このケースでは、フィッシングサイトを中間者として認証を行わせ、最終的に発行されたセッションクッキーを盗んだものとみられます。これも、認証が一要素であろうと二要素であろうと、認証後に発行されたセッションクッキーが盗まれれば不正アクセスが発生し得ることをしめしていると思います。
二要素認証（多要素認証）、二段階認証は、他者がなりすまして認証することを防ぐことには大きな効果があることに変わりはありません。
しかし、トークンやセッションクッキーなど「認証後に利用される鍵となるデータ」を盗まれて不正アクセスされては、他者による認証をいくら防いでも意味がありません。
このため、トークンやセッションクッキーを安全に管理して盗まれないようにするか、という対策も行わなければ、対策として不十分ということになります。
特に、「二要素認証（多要素認証）、二段階認証を実装したアプリ」などは、その実装においてトークンやセッションクッキーの保護が不十分であれば、例に挙げた事故の当事者になってしまう恐れがあると考えます。
認証方法までは調べませんでしたが、「アクセスに使う鍵」であり、盗まれたら不正アクセスに利用されるという点では類似していると思ったのがクラウドサービスで利用されるアクセスキーです。
2019年と少し前ですが、AWSのアクセスキーが不注意により流出した結果、不正アクセスされたことが記事になっていました。
【実録】アクセスキー流出、攻撃者のとった行動とその対策
https://dev.classmethod.jp/articles/accesskey-leak/
鍵の流出原因はサイバー攻撃などではなく、パブリックに誤って鍵を置いてしまったという何ともオマヌケな理由ではありますが、このような鍵を入手した攻撃者がどのような行動をとったか、を記録しているところは面白いと思いました。
もちろん、サイバー攻撃で鍵が盗まれても同様の事件になり得るので、危険性の予見には十分な事例だと思います。
攻撃者の取り得る行動の推測や、不審な行動の発見のヒントになるかもしれません。
実際のところ、二要素認証（多要素認証）、二段階認証を回避して不正アクセスする方法は、攻撃者側もまだ研究段階かもしれません（上の説明で示した「トークンをパクる」部分ね）。
理由として、二要素認証（多要素認証）、二段階認証を利用していないユーザもサービスも多数あり、従来の方法でも攻撃対象に事欠かないということもあるのではないかと考えています。
しかし、二要素認証（多要素認証）、二段階認証が普及してこれば、攻撃者もこれに対する攻撃法を考えるようになってくると思います。
そして、こうなると発達しちゃうんですよね・・・。もっと良いことに労力使えと（ｒｙ
特に、前記事で述べた通り、リモートアクセスできる対象自体は増えているので、攻撃者にとっても魅力であるはずです。
アプリの脆弱性を利用したトークン窃盗、Man-in-the-Browserやメモリ監視・収集型のマルウェアによるトークンやセッションクッキーの窃盗などが、今後発見されるんじゃないかと気をもんでいます。
先に述べた通り、二要素認証（多要素認証）、二段階認証自体は大きな効果があるので、その他の部分でセキュリティ上の見落としや抜け・漏れが無いよう、仕組みをしっかりし、想定される攻撃とその対策を考察しておいたほうが良いでしょう、というのが、今回の記事の趣旨です。
先にのべたような攻撃方法は、ある意味「見えている地雷」なんですが、サイバーセキュリティサイドはこれを予見して対策・回避するのか、思い切り踏んで誘爆しまくって将来のインシデント上位に食い込むのか。
私の杞憂で済むことを切に願っていますよ。
いやホントに。
さいごに
前記事で述べた通り、フォレンジック調査では認証情報狙いの行動が最近気になります。
まあ、仕事柄、不正侵入を伴う攻撃の調査が多いというのも理由として考えられるため、一般論というより「オマエがいるところがそういうところじゃね？」と言われれば否定できないんですけどねw
（探偵系の小説や漫画では、なぜか主人公の周りでは殺人事件がしょっちゅう起きるというアレみたいな。おお、メタいメタい。）
内容的には、認証の仕様を考えれば分かる話ですし、私の感想も多いため、どこかのフォーラム等で話すほどではないかなと思いました。
（まあ、十数人規模のワークショップで話したんですけどね。）
そのため、さらっと読める程度のブログ記事にしてみました。
とはいっても、認証情報に対する攻撃の研究と被害、増えそうで嫌だなぁ・・・。
今回書いた記事は、色々調べながら書いているため、ひょっとするともうよりよい解決策があるのかもしれません。
そういった方法が分かれば、記事を訂正するかブログで反省文を兼ねた解説でも書くようにしようかと思います。
むしろ、この問題は私に見落としがあって、もう解決済みってなっていてくれないかなぁ。
こんな攻撃が可能なのではないかと、気になって夜しか寝れないw
もっとも、実際のところフォレンジック調査では認証情報を狙っていた痕跡がある、または認証情報を盗まれたことが原因で発生したと思われるインシデントの調査が一定数あることも事実であり。
攻撃者が認証情報に関する攻撃を行い、不正アクセスしようとしているモチベがあることには変わりなさそうなんだよなぁ・・・（溜息）。