第67話 強い多要素認証と弱い多要素認証
フィッシング中間者攻撃
マイクロソフトから、多要素認証を回避するAiTMフィッシング攻撃についてのレポートが発表された。
クッキー窃盗からBECへ：攻撃者はAiTMフィッシングサイトを入口としてさらなる金銭的詐欺を行う
最近のウェブサービスはすべて、認証に成功するとユーザーとのセッションを実装し、 ユーザーが新しいページにアクセスするたびに認証を受ける必要がないようにしています。このセッション機能は、最初の認証の後に認証サービスによって提供されるセッションクッキーによって実装されます。セッションクッキーは、ウェブサーバーにとって、ユーザーが認証され、ウェブサイト上でセッションが継続していることを証明するものです。AiTMフィッシングでは、攻撃者はターゲットユーザーのセッションクッキーを取得し、認証プロセス全体をスキップしてターゲットユーザーの代わりに行動することを試みます。
そのために、攻撃者はWebサーバーを設置し、フィッシング・サイトにアクセスしたユーザーから攻撃者がなりすましたいターゲット・サーバーにHTTPパケットをプロキシし、その逆を行います。こうすることで、フィッシング・サイトは視覚的に元のウェブサイトと同一になる（すべてのHTTPが元のウェブサイトとの間でプロキシされるため）。また、攻撃者は、従来のフィッシング・キャンペーンで行われていたような独自のフィッシング・サイトを作成する必要がない。フィッシング・サイトと実際のサイトの違いは、URLだけです。
このAiTM攻撃の手法は「フィッシング詐欺と組み合わせた中間リバースプロキシ攻撃」と言える。
AiTMの原理
Step１
ユーザはフィッシングメールに誘われて偽のログインサイトに接続する。
この偽サイトは証明書としては（偽ドメインであっても）正規のCA局が発行した証明書を使用することで、ブラウザの警告は表示されない。
Step２
そしてこのリバースプロキシは一旦SSLを終端させ、暗号通信をほどき、そして再度クライアントとして（ブラウザとして）正規のサイトのログイン画面に接続する。
Step３
利用者が入力したIDとパスワードはそのまま中継しする。
またOTPなどの多要素認証もそのまま中継し、攻撃者のリバースプロキシは正規サイトへの認証に成功する。
Step４
結果的に、利用者は何も不都合を感じない。ブラウザも警告を出さない。しかし攻撃者は通信の中身を盗み見ることは出来る。IDやパスワードだけでなく、認証成功のクッキーも盗むことが出来るため、利用者が出ていったあと、セッションがまだ維持されていれば、そのクッキーを利用してサイトに自由に入ることが出来る。
攻撃者はリバプロ上にアクセストークンを保持しているため、ユーザが明示的にログアウトを行わなければ（セッションタイムアウトの前に操作を行えば）ユーザになりすまして、サーバへの操作を行うことが出来る。
このAiTM攻撃の対策は大きく分けて二つ考えられる。
対策１：サーバ側での防御（クライアント証明書など）
これは攻撃者の「ユーザになりすましたブラウザ」をサーバ側が見抜く対策だ。
最も一般的な方法は「クライアント証明書」である。
サーバ側は、アクセスしてきたクライアントが正規のものであるかを、クライアントが提示する証明書で確認する。
フィッシングを手口として中間に挟まれたリバースプロキシが、正規クライアントの証明書を偽造することは事実上不可能なので、クライアント証明書認証はAiTM攻撃への有効な対策といえる。
対策２：クライアント側での防御（WebAuthn/FIDOなど）
これはクライアントがサーバにアクセスする時に、フィッシングで誘導された偽サーバにアクセスさせない対策だ。
たとえば最近では、WebAuthn（FIDOなど）などの認証方式が
これはブラウザにオーセンティケータと呼ばれる認証器と組み合わせられる。FIDOの場合は指紋認証器などの生体認証機器がオーセンティケータとなる。
WebAuthnは、接続するべきサーバのドメインが保存されているため、攻撃者が用意した中間のリバースプロキシに接続することは、DNSスプーフィング攻撃などと組み合わせない限り不可能となる。
この他、セッションIDをクライアントやサーバの鍵によって動的に変更する対策も考えられる。
これはユーザが退出したあと、攻撃者がセッションを乗っ取ることを防ぐ効果がある。
しかしいずれにせよ、上記の対策１または２など「中間サーバによる盗聴」を防ぐ対策の補助手段としての位置づけになる。
フィッシング攻撃対策として有効と言われている多要素認証だが、これからは「対AiTM多要素認証」であることが、求められていくだろう。
まとめ
中間盗聴攻撃（AiTM）を防ぐためには下記のいずれかの対策が必要。
対策１：サーバ側が正規のクライアントを検証する。（クライアント証明書など）
対策２：クライアント側が正規のサーバを検証する。
