証券サービスの騒動から考える、サービスが意識しておきたい3層のセキュリティ

ritouです。

話題になったのは少し前ですが、証券会社のサービスを狙った攻撃が報じられました。

www.bloomberg.co.jp

news.yahoo.co.jp

規模など考えるととにかく大変そうです。が、起こったことはわりと普通のサービス悪用の話です。

自分達がやってるサービスに同じようなことが起こらないためにも、ざっくりこの辺りは意識しておきましょうというのを書いておきます。

攻撃側の視点で考える

表題に3層って書いたのはこの辺りからです。攻撃者が成し遂げたいもの、そのために何が必要かを考えましょう。

お金を受け取る、市場を操作できるような動きをさせるなど、最終的に意図した取引が完了すればOK - オレオレ詐欺とかAPP詐欺とか呼ばれてるものなど
ターゲットとしてログイン状態になって取引ができればOK - 取引パスワード、ログインセッションの奪取
ターゲットとしてログインするための情報、取引するための情報を取得できればOK - フィッシングなどで静的なパスワード類を奪取

悪い人たちには、他人に決済してもらって商品を手にいれる、お金を振り込ませるといった最終的なGOALがあるわけです。電話をかけてうまく言いくるめてアプリなどを操作させてそれが実現できたら、一番楽です。 昔は電話でATMまで連れてって、そこから...だったものが今はアプリの操作で完結するかもしれません。サービス側として、何より操作しているのが本人だというのが事後対応含めて色々厄介そうですよね。

それができなくて攻撃者自らその取引処理を行う必要がある場合、セッションと取引に関する情報を狙うはずです。紹介した記事で出ていたインフォスティーラーなどでぶっこ抜くことができれば試合終了です。

それができない場合、リアルタイムフィッシングみたいな手法を用いてログインセッション奪取を狙うはずです。証券系のサービスはパスワード認証がまだまだ使われている、かつ取引パスワードなるものも静的なものが多いと聞いたのでフィッシングが大きな脅威となったのだと推測できます。

3層のセキュリティ

脅威を整理した上で、対策を考えましょう。

お金を受け取る、市場を操作できるような動きをさせるなど、最終的に意図した取引が完了すればOK - 取引状況の監視、同業サービス間の情報共有など
ターゲットとしてログイン状態になって取引ができればOK - 取引パスワード、ログインセッションの奪取 - ログインセッション保護を含めたセッション管理機能の強化
ターゲットとしてログインするための情報、取引するための情報を取得できればOK - フィッシング耐性のあるログイン方法やリスク判定、他に穴を残さないID管理機能

1番目、これはサービスのドメインの中での不正利用対策をしっかりしましょうということ ですね。仕事でID+決済の基盤をくっつけて色々やってると、決済部分での制約がここにかかってくるのでわりとイメージしやすいところです。サービス内での挙動の解析、リスク判定みたいなところはAIの使い所でもあるでしょう。IDの分野でも同業者同士で情報を共有する仕組みが出てきていたりしますので、サービスドメインの中でもそのような動きが起こるかもしれませんね。

2番目、3番目はID基盤側が頑張る機能です。やっていきましょう。

2番目はセッションを盗まれないようにしようって話です。今のHTTP Cookieは文字列を別の環境に持っていってHTTPヘッダにつけてやればログイン状態が再現してしまうでしょう。認証認可の世界ではこういうのをBearer(ベアラー) Tokenと呼んだりします。それに対して、特定の環境からしか使えない送信者を制限する仕組みとしてSender-Constrained Tokenと呼ばれているものがあります。今回はそれをHTTP Cookieとかにも必要だよねというところです。

この辺りで、ブラウザが頑張っている仕組みがあります。Device Bound Session Credentials(DBSC)と呼ばれており、ブラウザに秘密鍵を安全に保持しつつそれとセッションクッキーを紐付ける「有効期間の短い認証 Cookie 」なるものを発行します。詳しくは以下の記事を参照ください。

developer.chrome.com

最後のはまさにパスキーだったりで認証機能を強化しつつ、その周囲のアカウントリカバリーなどを含めて強化する話ですね。ここはいくらでもかけますが長くなるので省略します。基本的なところから武装を強化しておきましょう。