情報処理安全確保支援士 2.5 セッションハイジャック

セッションハイジャックとは、クライアントとサーバの正規のセッション間に割り込んで、そのセッションを奪い取る行為である。ここでは、セッションハイジャックについて、その仕組みと対策を解説する。

2.5.1 セッションハイジャックの概要

攻撃者がセッションハイジャックに成功した後は、「サーバに成り済ます」「クライアントになりすます」「両者になりすます」などして次のような不正行為を働くことが考えられる。

正規のサーバになりすましてクライアントの機密情報（クレジットカード番号、暗証番号、個人情報など）を盗む。
正規のサーバ（DNSサーバなど）になりすましてクライアントに偽の応答を返し、不正なサイトに誘導する。
正規のクライアントになりすましてサーバに侵入し、不正なリクエストの発行、管理者権限の奪取、機密情報の閲覧、情報の改竄、消去などを行う。
クライアントに対しては正規のサーバに、サーバに対しては正規なクライアントにそれぞれなりすまし、通信データを投了しつつ、不正なリクエストやレスポンスを紛れ込ませるなどしてセッションをコントロールする（このような手法をMan-in-the-middle Attack（中間者攻撃）ともいう）

セッションハイジャックは次のような脆弱性をついて行われる。

プロトコルの使用上の脆弱性
プロトコルの実装上（OSレベル）の脆弱性
アプリケーション（セッション管理）の脆弱性

2.5.2 セッションハイジャックの種類と実行方法

- TCPにおけるセッションハイジャック

TCPでは、コネクションの確立時にお互いのシーケンス番号（初期シーケンス番号）が交換される。コネクション確立後は、発信者が送信するデータをオクテット単位で数え、その値をシーケンス番号に換算して相手に送ることで、受信者は正しくデータが受信できていることを確認することができる。TCPでは、この仕組みによって通信社の信頼性を高めているが逆にこの仕組みを悪用してシーケンス番号を矛盾なく操作することができればセッションハイジャックが可能となる。（当然IPアドレスなどの偽装も必要である）

TCPにおけるシーケンス番号のやりとりのイメージ

TCPセッションのハイジャックは、初期シーケンス番号の推測、もしくはパケットの登頂によってシーケンス番号を突き止め、それを元に偽装したパケットを発信することで、正規の相手ホストになりすます。

TCPにおけるセッションハイジャックのイメージ

各OSのTCPの実装では、初期シーケンス番号を推測されないようにするため、コネクションごとに乱数が用いられるが、一部の旧バージョンOSでは、乱数を用いていないがらもそこに一定の規則性があったため、高い確率で推測ができてしまうという脆弱性があった。これを悪用して発信元のIPアドレス（ソースIPアドレス）を偽称し、相手ホスト（UNIX環境）の「./rhosts」ファイル（信頼するホストを定義するファイル）にechoコマンドで「＋＋」（全てのホストを信頼するという意味）を追加し、無条件でアクセスを可能にしてしまうという攻撃手法（IPスプーフィング）がよく知られている。この手法は、発信者のIPアドレス（ソースIPアドレス）だけで接続を許可するrcp、rloginなどのサービスが稼働してる場合に有効であるため、今日のインターネット環境で行われる可能性は極めて低い。

- UDPにおけるセッションハイジャック

UDPにはTCPのようなコネクション確立手順がないため、セッションハイジャックの手法も、より単純かつ容易である。UDPではクライアントからリクエストに対し、正規のサーバよりも先にレスポンスを返すことでセッションハイジャックを行う。

UDPセッションハイジャックのイメージ

UDPセッションハイジャックが行われる具体的な例としては、DNSキャッシュポイズニング攻撃などがある。

- Webサーバとクライアント間のセッションハイジャック

Webサーバのセッション管理の脆弱性を突いて、セッションハイジャックを成立させるもので、Webアプリケーション全盛を今日のインターネット環境では、最も行われる可能性の高い手法と言える。そもそも、HTTPでは、一つのセッションが単発で完結するため、その連続性や状態を管理することができない。そのため、Webアプリケーション側で各セッションを管理するための識別情報（セッションID）を生成し、URLやクッキーにセットしてクライアントとやり取りすることで、各クライアントの識別や状態管理を行う必要がある。Webアプリケーションの開発では、この仕組みを安全かつ確実に実装することが最大の課題となっているが、脆弱な状態で公開されているサイトも数多い。攻撃者はURL、クッキー、hiddenフィールドなどにセットされたセッション管理情報を推測するか、盗聴することによって自身のパケットを偽装し、正規のユーザーとウェブサーバのセッションをハイジャックする。

Webサーバとクライアント側のセッションハイジャックのイメージ

次のようなセッション管理の脆弱性により、この攻撃が成立する可能性が高まる。

セッションIDが単純であるために推測・偽装される
詳細なセッション管理情報が丸見えになっているために悪用される
セッション管理情報が暗号化されていないために盗聴され、悪用される
クロスサイトスクリプティング（XSS）の脆弱性により、クッキーにセットされたセッション管理情報が盗まれ、悪用されるなど

- 認証サーバとクライアント間のセッションハイジャック

認証を行なっているサーバ（認証サーバ）になりすましてクライアントからアクセス要求を受け付け、セッションハイジャックを成立させる手法である。認証プロセスにおいて、クライアント側でサーバの信頼性を確認する手段がない場合にこの問題が発生する可能性がある。

- 偽装ARPによるセッションハイジャック（ARPポイズニング/ARPスプーフィング）

ハイジャックの対象となるセッションが貼られているLAN上で、攻撃者自身のMACアドレスと正規のホストのIPアドレスとを組み合わせた偽のARP応答パケットを送信することでARPキャッシュの内容を書き換え、セッションをハイジャックする手法であり、ARPポイズニングもしくはARPスプーフィングとも呼ばれる。多くのOSがARP応答パケットを受け取ると無条件にARPキャッシュを更新することを悪用した攻撃である。ハイジャックを成立させるためには偽のARP応答パケットを送信するだけではなく、TCPシーケンス番号も偽装する必要があるが、これらを自動的に行うツールも存在する。

2.5.3 セッションフィクセーションの実行方法

セッションフィクセーション（Session Fixation：セッションIDの固定化）とは、Webアプリケーションシステムにおけるセッションハイジャックの手法の一つである。これは既に確立されているセッションをハイジャックするわけではなく、ターゲットユーザーに対して攻撃者が生成したセッションIDを含む不正なURLを送りつけることで意図的にセッションを確立させ、そのセッションをハイジャックするというものである。セッションフィクセーションは次のように実行される。

攻撃者がターゲットとなるWEBサイトのログイン画面などにアクセスし、実際に発行されたセッションIDを入手する。
入手したセッションIDを含むURLをリンク先としてセットしたフィシングメールをターゲットユーザーに送付する
ターゲットユーザーがそのリンクをクリックしmターゲットサイトにログインする
攻撃者も同じセッションIDを使ってターゲットサイトへのアクセスに成功し、正規のユーザーになりすまして不正な捜査などを行う。

セッションフィクセーションのイメージ

この攻撃が成立するのは、次のような条件を満たす場合である。

正規のセッションIDを容易に入手可能であること（会員制サイトなどで、ログイン画面を表示した時点でセッションIDが発行され、ログイン後も同じセッションIDを使用する仕様となっている場合など）
ターゲットとなるWebサーバでURL Rweriting機能（URLでセッションIDを指定する機能）が有効になっていること
当該サイトへのログイン権限を持つユーザを知っており、フィッシングメールなどを送ることが可能であること
ユーザーがフィッシングメールに騙され、ログインすること

こうしたことから、成立する可能性は決して高いとは言えないが、WEBサーバの設定については見直す必要がある。なお、”Cookie Monster Bug”のあるブラウザではこの攻撃が成立する可能性が高まる。”Cookie Monster Bug”とは、クッキーのdomain属性が正しく機能せず、指定した範囲を超えてクッキーが有効となってしまうバグである。これにより、セッションフィクセーションの他、クロスサイトリクエストフォージェリ（CSRF）なども成立しやすくなる。

2.5.4 セッションハイジャックへの対策

セッションハイジャックへの対策は次の通りである。

- 予防・防止

TCP、UDPにおけるセッションハイジャック

OS及び使用しているソフトウェアのバージョンを再進化し、バッチを適用する
TLS、IPsec、SSHなど、パケットの偽装が困難な暗号化プロトコルなどを使用する
脆弱性検査を実施し、セッションハイジャックに繋がる可能性のあるセキュリティホールの有無を確認する

Webサーバとクライアント間のセッションハイジャック

TLSを使用してWeb通信を暗号化する
セッション管理システムを自社で開発せず、アプリケーションサーバなどに実装されている機能を使用する
セッション管理システムを自社で開発する場合は、乱数やハッシュ関数を使用して推測困難なセッションIDを生成するようにする
セッション管理情報の推測、漏洩、偽装などが発生しにくいように、利用者携帯やサーバ構成などに応じたセッション管理機能を実装する
Webアプリケーションに対する脆弱性診断を実施し、セキュリティホールの有無を確認する
Webサーバーのフロント(前面)にリバースプロキシサーバーやWebアプリケーションファイアウォール(WFA)を設置し、セッション管理をついた攻撃を排除する

認証サーバとクライアント間のセッションハイジャック

TLSなど、サーバの正当性が確認でき、かつパケットの偽装が困難なプロトコルを使用する。

偽装APPによるセッションハイジャック

ハブを物理的に保護することで、不正な機器が物理的に接続されるのを防ぐ
不正PC接続検知システムによって不正な接続を排除する
ARPポイズニングを検知/防止する機能を持った製品（ハブ）を用いる

セッションフィックセーション

※前述の「Webサーバとクライアント間のセッションハイジャック」の対策に加えて次の対策を実施

WebサーバのURL Rewriting機能を無効にする
セッション管理を自社で開発している場合は、ユーザーがログインに成功した後で、新たにセッションIDを発行するようにする（ログイン権限のないものがセッションIDを入手して悪用するのを防ぐ）

- 検知・追跡

ターゲットホストのログから不審なセッションを探し出し、攻撃を検知する。
ネットワーク監視方IDS、ホスト監視方IDS、IPS、リバースプロキシサーバ、Webアプリケーションファイアウォールなどを用いて検知する
不正PC接続検知システムによってLAN上に接続された不正な機器を検知する

- 回復

被害状況を調査し、必要に応じてシステム及びデータの普及う作業を行う
攻撃が成立した原因となった脆弱性を特定し、飛鳥な対策を実施する
再発防止のため、予防・防止にあげた対策を実施する

Check!

セッションハイジャックにはどのような手法があるか。
Webサーバとクライアント間のセッションハイジャックが成立する原因となる脆弱性とは何か
webサーバとクライアント間のセッションハイジャックに対してはどのような対策が有効か
認証サーバとクライアント間のセッションハイジャックに対してはどのような対策が有効か
セッションフィクセーションとはどのような攻撃手法か
どのような脆弱性があるとセッションフィクセーションが成立する可能性があるのか
セッションフィクセーションへの対策にはどのようなものがあるか

確認問題

デジタル証明書を使わず、通信社同士が、通信によって交換する公開鍵を用いて行う暗号化通信において、通信内容を横取りする目的で当事者に成り済ますものはどれか。

ア　Man-in-the-middle攻撃
イ　war driving
ウ　トロイの木馬
エ　ブルートフォース攻撃

解答：ア
問題文に該当するのはMan-in-the-middle攻撃（中間者攻撃）である。Man-in-the-middle攻撃は、通信を行うクライアント、サーバの間に不正なホストが介在し、クライアントに対しては正規のサーバに、サーバに対しては正規のクライアントになりすまし、通信データを盗聴しつつ不正なリクエストやレスポンスを紛れ込ませるなどしてセッションをコントロールしたり、通信内容を横取りしたりする手法である。したがってアが正解。