VPN機器などの脆弱性を突くのではなく、堂々と正面突破してくるサイバー攻撃の脅威が高まっている。闇市場で安価に調達できる「インフォスティーラー」を使い、攻撃者はユーザーの認証・認可情報を容易に窃取して侵入する。どんな企業であっても、このインフォスティーラーを正しく理解し、正しく恐れることが必須になっている。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
最近のセキュリティ事案の報道を見ていると、「VPNが原因」という表現を非常によく見聞きする。私はこれに強い違和感を覚えている。私は「脱VPN」や「VPN擁護」といった極端なことを言いたいわけではない。大切なのは事象の「原因」に正しくフォーカスするべきであるということだ。脆弱(ぜいじゃく)性を悪用されたのか。認証が弱かったのか。原因が分からなければ何をするべきかという判断ができないのではないかと考えている。
機器の脆弱性を修正するのはベンダーの責任だが、パッチを当てるかどうかの判断、そして何より「認証情報の管理」はユーザー側の責任だ。重要なのは、VPN(SSL-VPN)は侵入の「経路」であっても、必ずしも「原因」ではない。この切り分けは極めて重要だ。メディアの報道やベンダーの主張において若干のミスリードがあるように感じる。
脆弱性を悪用されたのであれば、それはNデイなのか、ゼロデイなのか。それとも脆弱性を突かれたのではなく、認証が突破されたのか。認証を突破されたのであれば、それは脆弱なパスワードだったのか、窃取されたパスワードだったのか。そして、多要素認証は有効になっていたのかどうかなど、原因によって対策や方針は大きく異なってくる。
VPNという、ユーザーがアクセスすることが前提となっているエッジデバイスという性質上、脆弱性対策だけではなく、認証に関する管理も重要になってくる。仮に脆弱性対策がしっかりされていたとしても、パスワードが「password」や「12345678」のような脆弱なものであったり 、どこかで窃取されていたものであったりした場合、攻撃者は正面玄関から堂々と入ってきてしまう。実際に私がインシデント対応をしている中でもパスワードが脆弱であったことに起因するものが少なくない。そこで今回は、認証、認可にフォーカスしたい。
私たちが守るべきものを整理するために、私たちの頭を悩ませているテーマでもある「認証」と「認可」の違いを明確にしておこう。おそらくこれは、パスワードという仕組みが消えない限りなくならないテーマだ。
IDとパスワードで本人であることを証明する認証というプロセスは、専門的な言葉を抜きにして例えるなら「建物の受付や入り口で行う本人確認」と言える。
一方で認可とは、本人確認後に渡される「通行証」のようなものと考えてほしい。パスを首から下げれば、有効期限内なら、通行可能な場所を何度でも出入りでき、再度本人確認を求められることもないだろう。Webの世界でこの通行証の役割を果たすのが「セッションクッキー」と呼ばれるものだ。ブラウザがこれを管理し、利用者はあまり意識せずともログイン状態を保持し、ページ間の情報をやりとりできるようになっている。
では、認証と認可はどのように奪われていくのだろうか。脆弱性、フィッシング、マルウェアに分類して考えてみよう。下記の表では、「○」は攻撃者が情報を奪えるパターン、「×」が奪えないパターンを示している。
| パターン | 手法 | 認証 | 認可 | 備考 |
|---|---|---|---|---|
| 脆弱性 | ― | ○ | X | 取得先次第で入手はハッシュの場合がある。脆弱性修正後も悪用され続けるケースを招く |
| フィッシングサイト | 通常 | ○ | X | 入力情報以外は窃取されないが、リアルタイムにモニタされると二要素認証も突破される |
| AiTM | ○ | ○ | 攻撃者はプロキシ型で中継を行うため、認証情報だけではなくセッションクッキーも窃取可能 | |
| マルウェア | キーロガーなど | ○ | X | 入力情報やクリップボードの内容を窃取 |
| インフォスティーラー | ○ | ○ | 保存されているあらゆる認証情報だけでなく、セッションクッキーも窃取可能 | |
| 認証・認可情報の窃取パターン | ||||
上の表で分かるように、「脆弱性」を利用して侵入され、制御を奪われた場合、端的に言えば何でも取られてしまう。認証情報、認可情報共に奪うことができる。
フィッシングについては、偽ページを作ってそこに誘導するような手法であれば、IDおよびパスワードそのもの、リアルタイムフィッシングであれば二要素認証の突破も可能だ。だが、ユーザーから直接認可情報を奪うことはできない(認可状態を得ることは可能)。一方、プロキシ型のAiTM(Adversary-in-the-Middle)攻撃では、中継されるサーバで通信情報も窃取可能なため、セッションクッキー、つまり認可情報も奪われてしまう。
マルウェアが認証・認可情報を取得する方法は、キーロガーと「インフォスティーラー(InfoStealer)」に分けられる。
キーロガーであれば、キーボードから入力されたIDとパスワード文字列を、入力されたタイミングで奪うことができる。しかし、認可情報そのものは奪えない。
問題は、認証・認可の両方を効率的に奪うことに特化したインフォスティーラーだ。
認証・認可情報の窃取に対する、私たち側の保護手法をまとめた下の表を見ていただきたい。ID/パスワードのみ、多要素認証の利用、そして証明書の利用などが挙げられる。脆弱性、フィッシングサイト、マルウェアそれぞれに対し、保護施策として有効かどうかをまとめた。「○」が付いているものが、条件付きでも守れるものだ。
注目していただきたいのは、多要素認証であっても「×」が並んでいるという点。そして残念ながらインフォスティーラーに対しては、全て「×」、つまり、ここに挙げた保護手段では守り切れない。
| 大分類 | 小分類 | 脆弱性 | フィッシングサイト | マルウェア | |||
|---|---|---|---|---|---|---|---|
| ― | 通常 | AiTM | キーロガーなど | インフォスティーラー | |||
| ID/パスワード | ― | X | X | X | X | X | |
| 多要素認証 | メール | ○ | X | X | X | X | |
| SMS/音声 | ○ | X | X | X | X | ||
| アプリ認証 | ○ | X | X | ○ | X | ||
| ハードウェア | ○ | ○ | ○ | ○ | X | ||
| 証明書 | ― | ○ | ○ | ○ | ○ | X | |
| 認証・認可情報の窃取に対する保護 | |||||||
インフォスティーラーとは、感染したコンピューターやモバイル機器などから機密情報を窃取することに特化したマルウェアだ。窃取する情報としては、認証情報をはじめ暗号通貨情報、クレジットカード情報、その他のスクリーンショットなどである。これらは窃取した攻撃者が自身で利用する場合もあるが、販売目的のケースがあることには注意が必要だ。
もちろん、多要素認証を有効にすることは必須である。しかし、インフォスティーラーのようなマルウェアに感染すると、多要素認証を済ませた後に発行されるセッションクッキーが窃取されてしまう。攻撃者は盗んだクッキーを自分のブラウザに読み込ませるだけで、IDやパスワードの入力から多要素認証といった手順をスキップし、ログインすることができる。これは認証の「突破」というより、ログイン済みの「認可状態」を盗まれていると言える。
インフォスティーラーは、感染した端末内にあるさまざまな機密情報を盗むが、中でも主要なターゲットとなるのはブラウザに保存された各種のサービスで利用されているパスワードやセッションクッキーだ。これは攻撃者にとっては宝の山であるため、私はブラウザに認証情報を保存することはあまり好ましくないと考えている。
Copyright © ITmedia, Inc. All Rights Reserved.