Neighbor Discovery Spoofing
近隣探索スプーフィング
- 2010年 5月15日 初版
- 2010年 6月28日 改編
目次
- はじめに
- ARPキャッシュを汚染する方法
- 近隣キャッシュを汚染する方法
- 3.1 シナリオ
- 3.2 パケットヘッダーの操作
- 3.3 近隣キャッシュの状態変化
- 効果が継続する時間
- 実験
- 対策
- 6.1 SEND
- 6.2 ネットワークの信頼モデル
- 関連する問題
- おわりに
1 はじめに
Ethernetスイッチで構成されたネットワークであってもARPスプーフィング（ARP spoofing）と呼ばれる技法によってIPv4のパケットが盗聴されることは、セキュリティに関心のあるネットワーク技術者に広く知られています。この問題について考察したことがある技術者は、きっとある疑問を抱いたことがあるのではないでしょうか。それは、IPv6でもIPv4と同様にパケットが盗聴されるおそれがあるのだろうかという疑問です。
従来のARPスプーフィングに対する耐性に限って言えば、ARPを使わないIPv6には従来のARPスプーフィングのプログラムコードはすべて無力です。しかし、IPv6においてもIPアドレスとMACアドレスとを関係付ける仕組みは必要です。IPv6では、ARPに代わってICMPv6による近隣探索(Neighbor Discovery)という技法を使って目的IPアドレスのMACアドレスを探し出し、知り得たMACアドレスを近隣キャッシュ（Neighbor cache）と呼ばれるデータベースに登録します。それなら、IPv6の近隣キャッシュを汚染すれば他のノード宛のパケットを横取することができるかもしれません。
一方、IPv4の後継であるIPv6は暗号化や認証の仕組みを包括しており、IPv4に比べてより安全性の高いプロトコルであるといわれています。それなら、IPv6には近隣キャッシュが汚染されることを防ぐための仕組みが備わっているのでしょうか。また、もし攻撃が可能であるならどのような対策を施せばよいのでしょう。
今回、これらの疑問について実験したり調査したりした結果をまとめ、この記事を書きました。
2 ARPキャッシュを汚染する方法
まず、IPv4におけるARPキャッシュを汚染する方法について概要を述べます。
RFC 826 (An Ethernet Address Resolution Protocol)によると、ARPメッセージを処理するためのプログラムは、ARPメッセージを受け取ったとき、そのメッセージに含まれているプロトコルタイプ（例えばIP）と発信元プロトコルアドレス（Source Protocol Address）の組み合わせ（エントリー）が既にARPキャッシュの中にある場合、そのエントリーに関連付けされている物理アドレスを受信したメッセージの発信元物理アドレス（Source Physical Address）で書き換えるとこになっています。 一方、受信したARPメッセージに含まれているプロトコルタイプと発信元プロトコルアドレスの組み合わせがARPキャッシュない場合は、そのメッセージの目標プロトコルアドレス（Target Protocol Address）が自ホストのアドレスと同じであるなら、そのARPメッセージに含まれているプロトコルタイプと発信元プロトコルアドレス、ならびに発信元物理アドレスをARPキャッシュに登録します。
リモートホストのARPキャッシュの汚染を企てる人物（以下、攻撃者といいます）は、ARPメッセージの目標プロトコルアドレスに犠牲者のホストのIPアドレス、発信元プロトコルアドレスになりすますための偽りのIPアドレス、そして発信元物理アドレスに攻撃者のホストのEthernetアドレスを格納した偽のARPメッセージを生成し、犠牲者のホスト宛に送信します。
3 近隣キャッシュを汚染する方法
IPv6は、ICMPv6の近隣探索という技法により目標プロトコルアドレスを持ったホストの物理アドレスを探し出します。そこで、ARPキャッシュを汚染するのと同じように、偽の近隣要請（Neighbor solicitation）メッセージを生成して犠牲者のホストの近隣キャッシュが汚染できるか試してみます。
3.1 シナリオ
まず、構成図を以下に示します。
+---------+
| SMTP SV | * SV: Server
+----+----+
| IPv6 (Linklocal): fe80::211:85ff:fe00:1
| IPv6 (Global) : 2001:db8:0:2:211:85ff:fe00:1/64
| Ethernet : 00:11:85:00:00:01
|
| [eth1]
+----+----+
| Gateway |
+----+----+
| [eth0]
| IPv6 (Linklocal): fe80::211:85ff:fe00:3
| IPv6 (Global) : 2001:db8:0:1:211:85ff:fe00:3/64
| Ethernet : 00:11:85:00:00:03
|
+--------+--------+
| Ethernet Switch |
+---+---------+---+
| |
+-------------+ +-------------+
| | [eth0]
+---+---+ +---+---+
| HostA | | HostB |
+-------+ +-------+
IPv6 (Linklocal): fe80::214:85ff:fe00:a IPv6 : fe80::214:85ff:fe00:b
IPv6 (Global) : 2001:db8:0:1:214:85ff:fe00:a IPv6 : 2001:db8:0:1:214:85ff:fe00:b/64
Ethernet : 00:14:85:00:00:0a Ethernet: 00:14:85:00:00:0b
【図 3-1】構成図
構成図の中で、HostAは犠牲者のホスト、HostBは攻撃者のホストです。攻撃者はHostAが送信する電子メールの内容を盗み見るために、HostAから送り出されたGateway宛のEthernetフレームを横取りしようと企んでいると仮定します。
Gatewayは二つのEthernetインターフェースを持っていますが、SMTP Server側のインターフェースのアドレスを気にする必要はありません。また、Ethernet Switchは単にレイヤー2の転送を行うだけで、パケットフィルタリングなどのセキュリティ機能は何も実装していないものと仮定します。
3.2 パケットヘッダーの操作
通常、OSの標準コマンドを使って偽の近隣要請メッセージを送信することはできません。攻撃者は偽のメッセージを送信するために特別なプログラムを必要とします。
プログラムの処理で重要なことは、IPv6ヘッダーとICMP6ヘッダーの値を操作することです。GNU Cライブラリーを利用してプログラムを作成する場合、IPv6ヘッダーの構造体はヘッダーファイル netinet/ip6.h の中で定義されています。
struct ip6_hdr
{
union
{
struct ip6_hdrctl
{
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC,
20 bits flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};
【図 3-2】IPv6ヘッダーの構造体定義
また、ICMPv6ヘッダーおよび近隣要請メッセージの構造体はヘッダーファイル netinet/icmp6.h の中にあります。
struct icmp6_hdr
{
uint8_t icmp6_type; /* type field */
uint8_t icmp6_code; /* code field */
uint16_t icmp6_cksum; /* checksum field */
union
{
uint32_t icmp6_un_data32[1]; /* type-specific field */
uint16_t icmp6_un_data16[2]; /* type-specific field */
uint8_t icmp6_un_data8[4]; /* type-specific field */
} icmp6_dataun;
};
【図 3-3】ICMPv6ヘッダーの構造体定義
struct nd_neighbor_solicit /* neighbor solicitation */
{
struct icmp6_hdr nd_ns_hdr;
struct in6_addr nd_ns_target; /* target address */
/* could be followed by options */
};
【図 3-4】近隣要請の構造体定義
偽の近隣要請メッセージを生成するには、IPv6ヘッダーの発信元IPアドレス（ip6_src）になりすます偽のIPアドレスを、宛先IPアドレス（ip6_dst）にマルチキャストアドレスを格納します。そして、犠牲者のホストのIPアドレスは近隣要請メッセージの目標アドレス（nd_ns_target）に格納します。
さらに、ICMPv6の基本ヘッダー（構造体 nd_neighbor_solicit）の後にオプションヘッダーとオプションデータを続けます。オプションヘッダーのオプションタイプ（nd_opt_type）には定数 ND_OPT_SOURCE_LINKADDR を格納し、オプションデータとして攻撃者のホストのEthernetアドレスを格納します。
struct nd_opt_hdr /* Neighbor discovery option header */
{
uint8_t nd_opt_type;
uint8_t nd_opt_len; /* in units of 8 octets */
/* followed by option specific data */
};
【図 3-5】ND(Neighbor discovery)オプションヘッダーの構造体定義
IPv6の近隣探索の詳細は、RFC 4861 (Neighbor Discovery for IP Version 6)に記載されています。この記事で説明していないヘッダーの個々のフィールドについてはRFC 4861をご覧ください。
こうして生成した偽の近隣要請メッセージをネットワークに送出して、リモートホストの近隣キャッシュを汚染します。
3.3 近隣キャッシュの状態変化
システム構成や実験手順などの詳細はあとで説明するとして、先に攻撃によって犠牲者のホスト（HostA）の近隣キャッシュがどのように変化するかを観ます。
まず、偽の近隣探索メッセージが届く前の状態を確認します。仮にHostAのOSがマイクロソフト社のWindows Vistaだとすると、その近隣キャッシュは以下のように表示されます。
【正常な近隣キャッシュ】
C:\Users\goodboy> netsh interface ipv6 show neighbors
（省略）
インターフェース 8: ローカル エリア接続
インターネット アドレス 物理アドレス 種類
--------------------------------------------- ----------------- -----------
fe80::211:85ff:fe00:3 00-11-85-00-00-03 Stale (ルーター)
（省略）
【図 3-6】正常な近隣キャッシュ
近隣キャッシュの中には、GatewayのIPv6リンクローカルアドレスとEthernetアドレスの組み合わせが保持されています。種類の欄に表示されている「Stale」というのは「古い」という意味で、最後にそのアドレスへ到達できることを確認した時点から到達可能時間（Reachable time）が経過した場合に表示されます。到達可能時間についてはあとで述べます。
次に、HostBから偽の近隣要請メッセージを送ったあと、HostAの近隣キャッシュがどのように変化したかを示します。
【汚染された直後の近隣キャッシュ】
C:\Users\goodboy> netsh interface ipv6 show neighbors
インターフェース 8: ローカル エリア接続
インターネット アドレス 物理アドレス 種類
--------------------------------------------- ----------------- -----------
fe80::211:85ff:fe00:3 00-14-85-00-00-0b プローブ (ルーター)
【図 3-7】汚染された直後の近隣キャッシュ
HostAの近隣キャッシュの中にあるエントリーの物理アドレスが変更され、種類が「プローブ」と表示されています。これは、HostAが該当アドレス宛にパケットを送って、それに対する応答を受け取っていないことを意味しています。HostAはこのアドレスへ到達できるかを確かめるために、目標のインターネットアドレス宛の近隣要請メッセージを作成し、宛先Ethernetアドレスにユニキャストアドレスを入れて送信します。この近隣要請メセージはHostBに届きますので、攻撃者がこれに応えて近隣広告（Neighbor Advertisement）メッセージを送ると、犠牲者のホストは偽りのアドレスを到達可能と決定します。
【偽のアドレスが確定した近隣キャッシュ】
C:\Users\goodboy> netsh interface ipv6 show neighbors
インターフェース 8: ローカル エリア接続
インターネット アドレス 物理アドレス 種類
--------------------------------------------- ----------------- -----------
fe80::211:85ff:fe00:3 00-14-85-00-00-0b 到達可能 (ルーター)
【図 3-8】偽のアドレスが確定した近隣キャッシュ
上の図で、汚染されたエントリーの種類に「（ルーター）」と表示されているのは、犠牲者のホストに返す偽の近隣広告メッセージのフラグに定数 ND_NA_FLAG_ROUTER が加えられているからです。
以上のように、偽の近隣要請メッセージによって犠牲者のホストの近隣キャッシュが汚染されてしまうことが判りました。
4 効果が継続する時間
HostAの近隣キャッシュが汚染された後、HostAからGateway宛に送信されたEthernetフレームはHostBに届きます。攻撃者は受信したフレームのEthernetヘッダーの発信元アドレスにHostBのEthernetアドレスを、また、送信先アドレスにGetewayの正しいEthernetアドレスを埋め込んでフレームをネットワークに送り出します。
しかし、この盗聴は長くは続きません。
IPv6の近隣探索には到達可能時間（Reachable time）という要素があります。到達可能時間は、近隣（ノード）へ到達することが可能であると想定する時間で、RFC 2461では30,000ミリ秒と定義されています。近隣への到達が可能であることを確認できるメッセージを受信した場合、例えば、近隣要請メッセージに対する近隣広告メッセージを受信した場合、その近隣は到達可能であると判断されます。最後に到達可能と判断されてから到達可能時間が経過した近隣に対してパケットを送信する必要が生じた場合、パケットを送信するノードはその近隣に対して改めて到達の可能性を確認します。
HostBは、HostAから横取りしたEthernetフレームをGateway宛に送り出します。そして、そのフレームを受信したGatewayは応答をHostAへ送信します。このときHostAに対する到達可能時間が時間切れであるなら、Gatewayは改めてHostA宛の近隣要請メッセージを生成してネットワークに送出します。これを受信したHostAはGatewayの正しいEthernetアドレスを知ることができます。その結果、攻撃者が盗聴できるのは初めの1フレームだけになります。
このように、送受信を行う二つのノード間のパケットを横取りしたいとき、片方の近隣キャッシュだけを汚染するだけではその効果は長続きしません。したがって、攻撃者は、HostAからGateway宛のパケットを継続して横取りするためにはGatewayの近隣キャッシュも汚染する必要があります。そうすれば、Gatewayからの近隣要請メッセージはHostAには届きませんので、HostAがGatewayの正しいEthernetアドレスを知る機会が減ります。
しかし、攻撃者がGatewayの近隣キャッシュを汚染出来たとしても、このシナリオでは、盗聴できる時間は限られています。なぜなら、Gatewayはルーター広告（Router Advertisement）をマルチキャストアドレス（ff02::1）宛に定期的に送信しているからです。ルーター広告を受信した時点で、HostAはGatewayの正しいEthernetアドレスを知ります。
攻撃者は、ルーターが定期的に送信するルーター広告をリモートホストから止めることは出来ません。その為、ホストとルーター間の通信を継続して盗聴することは出来ないのです。
ただし、FTPサーバーやSMTP/POPサーバーが利用者端末と同じサブネット内に設置されている場合は、利用者端末とそれらのサーバー間の通信が継続的に盗聴される可能性があります。このような場合、サーバーを異なるサブネットに移すことを検討してください。
5 実験
今回、実験を行うために一つのプログラムnsspfを作成しました。nsspfは偽の近隣要請メッセージを生成してリモートホストの近隣キャッシュを汚染し、通信内容を盗聴します。nsspfが偽の近隣要請メッセージを送信するのは1度だけです。nsspfは偽の近隣要請メッセージを繰り返し生成して犠牲者のホストの近隣キャッシュを汚染し続けません。犠牲者のホストが何らかの理由で近隣キャッシュの中の汚染されたエントリーを正しいアドレスで上書きをした場合、それ以降は通信内容を盗聴することはできません。
5.1 実験環境
近隣探索スプーフィングの実験を行うために、図3-1の構成図のとおりに実験環境を構築します。
構成図の中のSMTP SVに実際にsendmailやpostfixなどのメールサーバー（ソフトウェア）をインストールする必要はありません。ICMP6をサポートしているだけで充分です。
Gatway用のネットワーク専用機器がない場合は、Ethernetインターフェースを二つ装備したPCにLinuxをインストールし、IPv6のフォワーディングを有効にします。それから、ルーター広告を配信するためにソフトウェアパッケージradvdをインストールし、設定ファイル/etc/radvd.confを図5-1のとおり編集します。
interface eth0
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 40;
prefix 2001:db8:0:1::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 40;
prefix 2001:db8:0:2::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
【図 5-1】/etc/radvd.conf
設定ファイルの編集が終わったら、スクリプトを使ってradvdを起動します。
# /etc/init.d/radvd start
HostAにインストールするOSは何でも構いません。今回はマイクロソフト社のWindows Vistaを使いました。
HostBにはx86用Linux2.6をインストールし、nsspfをインストールします。
5.2 実験手順
まず、HostAからSMTP ServerにICMPv6 Echoメッセージを継続的に送ります。Windows Vistaの場合、コマンドは次のようになります。
# ping -t -6 2001:db8:0:2:211:85ff:fe00:1
次に、HostBでtcpdumpやWiresharkなどのパケットキャプチャーツールを使って Gatewayが配信するルーター広告を観察します。そして、ルーター広告を検出したあとnsspfを実行します。nsspfは三つの引数を必要とします。一つ目はインターフェースの名前、二つ目は騙す相手ノードのIPv6アドレス、そして三つ目はなりすますノードのIPv6アドレスです。今回のシナリオの場合、nsspfのコマンドラインは次のようになります。
# ./nsspf eth0 fe80::214:85ff:fe00:a fe80::211:85ff:fe00:3
なお、ルーター広告が配信されるタイミングを無視してnsspfを実行すると、1つか2つのEthernetフレームを盗聴して終わってしまうことがあります。
nsspfは、起動するとまず、Gatewayの実際のEthernetアドレスを調べます。その後、HostAに向けて偽の近隣要請メッセージを送ります。偽の近隣要請メッセージを受け取ったHostAは、直ちに近隣キャッシュのエントリーを上書きし、Gateway（正確にはGatewayになりすましているHostB）に近隣広告メッセージを送ります。このときnnspfはHostAのEthernetアドレスを記録します。HostAが偽の近隣要請メッセージを受け取って以降、HostAからGateway宛てに送信されるEthernetフレームはHostBに届きます。nsspfは受信したEthernetフレームのうち、次の条件を満たすフレームをGatewayに向けて転送します。
・ 発信元EthernetアドレスがHostAのアドレスである。 ・ 宛先EthernetアドレスがHostBのアドレスである。 ・ 宛先IPv6アドレスがHostBのアドレスではない。
ただし、途中、HostAからGatewayに向けてに到達確認の為の近隣要請メッセージが送られた場合は、nsspfはそのフレームを転送する替わりにGatewayになりすまして近隣広告メッセージを送り返し、相手の近隣キャッシュが汚染されていることを知らせるメッセージを表示します。
以下に実行時の出力を示します。
# ./nsspf eth0 fe80::214:85ff:fe00:a fe80::211:85ff:fe00:3
Discovering real ethernet address for the spoofed host is succeed.
A neighbor advertisement came from the target host.
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
The target neighbor cache has been poisened.
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
A packet has been transfered to 2001:db8:0:2:211:85ff:fe00:1
【図 6-1】nsspfの実行例
nsspfは30秒の間、何もフレームを受信しなければ終了します。また、[CTRL]＋[C]キーで中断することもできます。
6 対策
実は、このような近隣探索におけるなりすましの問題は、既にRFC 3756 (IPv6 Neighbor Discovery Trust Models and Threats)の中で言及されています。RFC 3756ではこの問題に対して、アドレスの組み合わせを承認するための自己認証テクニック、例えば CGA（Cryptographically Generated Addresses）を使うことや、タイムアウトする前にキャッシュの上書きを拒否する実装を使うことが提案されています。
6.1 SEND
CGAは公開鍵暗号方式とハッシュ関数を用いて発信元アドレスの改竄を防ぐ技術であり、SEND（SEcure Neighbor Discovery）のオプションです。CGAはRFC 3972 (Cryptographically Generated Addresses)で、SENDはRFC 3971 (SEcure Neighbor Discovery)で定義されています。しかし、SENDは特許の問題があるとしてオープンソースコミュニティにおいてほとんど実装がありません。（FreeBSDではports/net-mgmtの中にsend-0.2.1 Secure Neighbor Discovery implementation for IPv6が含まれています。）また、マイクロソフト社は、2008年2月11日に公開した文書「IPv6 Security Considerations and Recommendations」の中で次のように表明しています。
IPv6 Security Considerations
For Neighbor Discovery-based IPv6 configuration, SEcure Neighbor Discovery (SEND) (described in RFC 3971) can provide protection for Router Solicitation and Router Advertisement messages. SEND can also be used to provide protection for Neighbor Solicitation and Neighbor Advertisement message exchanges for address resolution or neighbor unreachability detection, providing protection against Neighbor Discovery-based denial of service (DoS) attacks by nodes with statically configured IPv6 addresses. In contrast, there is no mitigation against Address Resolution Protocol (ARP) DoS attacks for IPv4. However, Microsoft does not support SEND in Windows Vista, Windows XP, Windows Server 2008, or Windows Server 2003. Microsoft is considering supporting SEND in a future version of Windows.
このように、SENDは広く普及している技術ではありません。SENDはネットワーク内のすべてのノードがサポートできてこそ、その効果を発揮します。一つのルーターだけがSENDをサポートしていても、利用者が操作するパソコンやサーバーがSENDのパケットを生成したり、検証したりできなければ、その効果はありません。
6.2 ネットワークの信頼モデル
自営ネットワークが信頼できる管理者によって運営されており、かつ利用者の全員が信頼できる人物であれば、近隣探索スプーフィングは神経質になるほど大きな脅威ではありません。この問題は攻撃者のノードが犠牲者のノードと同じネットワーク上にある場合のみ顕在化します。
システムを運用する上での対策としては、ネットワークシステムに接続するコンピュータならびにその利用者を制限することです。例えば、企業の社内ネットワークにおいて業務委託先のコンピュータ技術者が持参したコンピュータを社内ネットワークへ接続させることは許すべきではありません。
社内ネットワークを利用する正社員は信頼されるべき人物ですが、万一に備えて、社内で共有するファイルサーバーやメールサーバーは利用者端末とは別のネットワークに設置したほうが良いでしょう。これは余談ですが、サーバー群を設置する部屋が一般の執務室と隔離され、限られた人物しか入室できないように管理されていると更に良いでしょう。
7 関連する問題
RFC 3756では、DOS（サービス妨害）攻撃まで含めて12の攻撃方法について述べられています。パケットの向かう先を変える方法は、偽の近隣探索メッセージを送る方法の他にもあります。攻撃者は偽のルーター広告メッセージや偽のリダイレクトメッセージを使って、犠牲者のホストが送出するパケットを横取りすることが出来ます。
この記事の範囲から外れてしまいますので詳しくは触れませんが、これらの問題についても注意するべきでしょう。
8 おわりに
偽の近隣探索メッセージによる攻撃の実験を行うために、今回、特別にプログラムを作成しましたが、インターネットで公開されているツールを使って攻撃を実行することも出来ます。以前は、このページでも検査用プログラム(nsspf)を公開していましたが、Wiresharkなどのパケットキャプチャーツールと合わせて使用すれば悪用される可能性がありますので、現在では公開を止めています。
偽の近隣探索メッセージを使った攻撃を防ぐことは現実的には難しく、その他、偽のルーター広告メッセージを使う攻撃など、解決策が未だ研究課題として残っている問題もあります。現時点では、信頼できるネットワークでない限り、パケットが横取りされてしまう危険性は常にあると考えられます。ですから、他人に知られたくない大切な情報を扱う場合は通信内容を暗号化することを検討するべきです。そうすれば、仮に第三者にパケットが横取りされたとしても、その内容を知られることを防ぐことができます。
最後に、この記事がネットワーク管理者にとって少しでも役立つものになることを願っています。
著作権者の文書による承諾を得ずに、本記事の一部または全部を無断で複写・複製・転載することはできません。