![[LinuxFocus-icon]](../../common/images/logolftop_319x45.gif){kind=small} |
|
|
 |
|
by Eric Detoisien <valgasu(at)club-internet.fr> 著者紹介: Eric Detoisien はコンピューターセキュリティの専門家です。 セキュリティに関することなら何でも興味があり、rstack グループ (www.rstack.org) の中心メンバーの一人です。 目次: |
外部からの攻撃
要約:
この記事は Linux Magazine France のセキュリティ特集号に掲載されました。 編集者、著者、翻訳者のご好意により、この特集号の全ての記事を LinuxFocus に転載することを許可していただきました。 LinuxFocus では英語に翻訳ししだい皆さんにお届けします。 関連者の方々に深く感謝致します。 尚、同号の全ての記事にこの前文を掲載します。 この記事では、ネットワーク上のマシンに対してクラッカーが外部から行う、いろいろな種類の攻撃を紹介します。 ネットワーク攻撃のうち主だったもの、アプリケーションを使った攻撃、サービス拒否攻撃などを取り上げます。 |
ネットワーク攻撃ではプロトコルやその実装に存在する脆弱性が利用されます。 いろいろな攻撃がありますが、良く知られる 5 つのネットワーク攻撃から派生しています。
RFC (Request For Comment) 791 (IP) では、全てのインターネットノードは 68 バイトのパケットをフラグメント化することなく送受信できることが義務づけられています。 IP パケットのヘッダーの最小サイズは、オプションがない時で 20 バイト、オプションがある場合で最大 60 バイトになります。 IHL (Internet Header Length) フィールドは、32 ビットを 1 単位としてヘッダー長を保持しています。 このフィールドは 4 ビットを使いますから、可能な値は 2^4 - 1 = 15 (0000 は不可) です。 ですから、ヘッダーの最大長は 15*4 = 60 バイトということになります。 そして、フラグメントの最初のデータが元のデータグラムの相対何バイト目なのかを示すフラグメントオフセットフィールドは、8 バイト単位になっています。 つまり、データフラグメントは 8 バイト以上でないといけません。 それで、合計 68 バイトということになります。
この攻撃は TCP 接続要求を、2 つの IP パケットにフラグメント化して送ることで実現します。 68 バイトからなる最初の IP パケットは、TCP ヘッダーの先頭の 8 バイト (送信元ポート、宛先ポート、シーケンス番号) しか含んでいません。 2 つ目の IP パケットのデータには、TCP 接続要求 (SYN フラグが 1 で ACK フラグが 0) が入っています。
しかし、IP フィルターはパケットの全てのフラグメントに対して同じ規則を適用します。 最初のフラグメントのフィルター (フラグメントオフセット = 0) が適用する規則を決め、それが他のフラグメント (フラグメントオフセット = 1) にも無条件で適用されます。 よって、ターゲットとなるマシンの IP 層で組み立てを行う際、接続要求パケットが再構成され、TCP 層に渡されます。 本来であれば、経路途中にある IP フィルタがこれを防御すべきですが、コネクションが確立してしまうのです。
図 1 と 図 2 はフラグメントを、図 3 はターゲットマシンで再構成されたパケットを示します。
図 1: フラグメント 1
図 2: フラグメント 2
図 3: 再構成されたパケット
もう一度 RFC 791 (IP) に戻ると、もし 2 つのフラグメントがオーバーラップした場合には、後のほうのフラグメントが最初のフラグメントを上書きすることになっています。 この攻撃では、IP パケットを 2 つのフラグメントに分割します。 IP フィルタは 68 バイトからなる最初のフラグメントを通してしまいます (タイニーフラグメントの説明を参照)。 これは、TCP 接続要求ではない (SYN フラグ = 0、ACK フラグ = 0 となっている) からです。 ここでも、同じ規則がそのパケットの他のフラグメントにも適用されます。 実際のコネクションに関するデータを含む 2 番目のフラグメント (フラグメントオフセット = 1) が到着しても、IP フィルタはここでコネクションがオープンされるとは気づかないので、パケットを許可してしまいます。 こうして再構成の際に、最初のフラグメントの 8 バイト目以降 (フラグメントオフセット = 1 なので) のデータが、2 番目のフラグメントのデータで上書きされてしまいます。 組み立て後のパケットは、ターゲットとなるマシンにとっては接続要求として正しいものになります。 そして、経路途中に IP フィルタがあるにも拘らず、コネクションが確立してしまうのです。
図 4 と 図 5 はフラグメントを、図 6 はターゲットマシンで再構成されたパケットを示します。
図 4: フラグメント 1
図 5: フラグメント 2
図 6: 再構成されたパケット
この攻撃の目的は、あるマシンの IP アドレスを奪うことです。 それによりクラッカーが攻撃元を分からなくしたり (サービス拒否攻撃で使われる) 、2 つのマシンの信頼関係を悪用したりできることになります。 ここでは、後者について説明します。
この攻撃の原理としては、クラッカーが IP パケットを捏造し
(hping2 や nemesis といったプログラムを使って)、データだけでなく送信元 IP アドレスも変えてしまうというものです。
IP スプーフィングは、よくブラインドスプーフィングとも呼ばれます。
送信元が偽装されているため、不正パケットに対する応答がクラッカーのマシンには届かないからです。
応答パケットは偽装に使われたマシンに届くことになりますが、応答を受け取るための方法が 2 つあります。
rlogin や rsh といったサービスに対しては、ブラインドスプーフィングが使われます。 これらのサービスは、認証手段としてクライアントマシンの送信元 IP アドレスだけに頼っています。 この攻撃は比較的良く知られた攻撃で ( 1994 年にケビン・ミトニックが下村努氏のマシンに使った方法)、以下の手順を踏んでいきます。
showmount -e を実行して、ファイルシステムがエクスポートされているマシンを表示します。また、rpcinfo を使えばもっと詳しい情報を得ることができます。echo ++ >> /.rhosts を送って、より高いアクセス権を得ることも可能です。
そのためには、クラッカーは TCP PSH フラグ (Push) が立ったパケットを偽造します。
そうすることで、受信パケットは即座に上位レイヤー (この場合は rsh サービス) に送られます。
これで、クラッカーは rlogin や rsh などのサービスを使って、IP スプーフィングなしでターゲットマシンに接続することができるようになります。図 7 に IP スプーフィングの手順を示します。
図 7: rsh サービスに対する IP スプーフィング
クラッカーが使うのはマシン A で、C は信頼されたマシンを示します。
A(C) という記述は、C の IP アドレスを偽装したパケットが A から送られることを示します。
mendax というプログラムがあり、これを使うことで IP スプーフィングが可能になります。
TCP セッションハイジャックを使えば、クラッカーは TCP のデータをリダイレクトできます。 つまり、クラッカーはパスワードによる防御をくぐり抜けることができるのです (telnet や ftp 等を使って)。 ネットワークを監視 (盗聴) する必要があることから、この攻撃はターゲットと物理的に同じネットワーク上でしかうまくいきません。 この攻撃を詳しく説明する前に、TCP プロトコルの基本原理について説明しましょう。
といっても TCP プロトコルの奥深くまで立ち入ることはしません。 攻撃を理解するのに必要なポイントだけを説明します。 TCP ヘッダーには以下のフィールドがあります。
図 8 は TCP コネクションの確立の様子 (Three Way Handshake) を示します。
図 8: Three Way Handshake
上図では、マシン A が マシン B に TCP コネクションを開始しています。
図 9 は TCP のデータの送受信の様子を示します。
シーケンス番号は送られたデータのバイト数に応じて変化し、Seq で表しています。 応答確認番号は PSH フラグと ACK フラグの後に、送信されたデータのバイト数は括弧の中に示しています。
この攻撃では、TCP コネクションの両端で同期ずれの状態を作り出し、セッションをハイジャックします。 マシン A が送ったデータのシーケンス番号がマシン B が予想しているシーケンス番号と異なると、コネクションの同期ずれが起こります。 逆も同様です。
図 9 で、最初に B がパケットを受信すると、A は応答確認番号 x+60 の入ったパケットを待ちます。 このとき、もし B がこれ以外の応答確認番号が入ったパケットを送信すると、A と B は同期ずれとみなされます。
マシン C にいるクラッカーが、既に マシン A と B との間で確立された Telnet セッションをハイジャックしようとしているとします。 まずはマシン C は A と B の間の Telnet のトラフィック (TCP ポート 23) を盗聴します。 マシン B 上で A の認証が済んだと思ったら、B に対して A を同期ずれの状態にします。 それには、送信元アドレスにマシン A の IP アドレスを、TCP 応答確認番号には B が待っている番号をセットしたパケットを偽造します。 マシン B はもちろんこのパケットを受け付けます。 このパケットは同期ずれを起こすと同時に、A が確立済の Telnet セッションに対してコマンドを送りつけることもできます。 実は、このパケットを使ってデータを送ることができるのです (PSH フラグ = 1)。
図 10 に、この攻撃を示します。
図 10: TCP セッションハイジャック
マシン B は C から送られたコマンドを受け付け、A に ACK フラグが立ったパケットを送って応答確認をします。 もしその間に A が B にパケットを送っても、B が予期したシーケンス番号でないため、破棄されます。
ただし問題があります。Ack ストームです。大量の ACK が生成されるのです。 これは、A が不正なシーケンス番号を送り (A は同期ずれ状態なので)、B がそれを拒否して、自分が待っているシーケンス番号が入った ACK パケットを A に対して送ることで発生します。 A はこの ACK を受信しますが、シーケンス番号が自分の思っているものと違うので B に ACK パケットを送り、B もまたこれを繰り返します。
この Ack ストームは、クラッカーが ARP スプーフィングを使うことで発生しなくなります。
それには、マシン C は、マシン B の ARP キャッシュを汚染し、A の IP アドレスが
C の MAC アドレスに関連づけられていると思わせます。
hunt プログラムを使えばこれを実行することができます。
この攻撃は ARP リダイレクトとも呼ばれ、1 つ以上のマシンのネットワークトラフィックをクラッカーのマシンにリダイレクトします。 これは攻撃対象となるマシンが物理的につながっているネットワーク上で行われます。 まずは、ARP プロトコルがどんなもので、どのように働くのかを復習しましょう。
ARP プロトコル (Address Resolution Protocol) は IP アドレスに対応するイーサネットの MAC アドレスを知るための仕組です。 ネットワーク機器は、データリンクレイヤーでイーサネットフレーム (もちろんイーサネットネットワークでの話です) をやりとりすることで通信を行います。 情報をやりとりするためには、ネットワークカードは固有のイーサネットアドレスを持っている必要があります。 これが MAC アドレスです (MAC=Media Access Control)。
IP パケットを送る時には、送信側は受信側の MAC アドレスを知る必要があります。 そのため、ARP リクエストのブロードキャストがローカルネットワークの全マシンに送信されます。 このリクエストは、「この IP アドレスに対応する MAC アドレスは?」ということを問い合わせます。 この IP アドレスを持っているマシンは ARP パケットで応答し、要求された MAC アドレスを送信側のマシンに教えます。 これで送信側のマシンは、パケットを送ろうとしている IP アドレス に対応する MAC アドレスが分かりました。 この対応表はしばらくの間キャッシュに保持されます (IP パケットを送るたびに要求を出さなくて済むようにするためです)。
ARPスプーフィング攻撃では、ターゲットとなるマシンのキャッシュを汚染します。 クラッカーはターゲットマシンに ARP 応答を送り、たとえばゲートウェイの IP アドレスに対応する MAC アドレスはクラッカーの MAC アドレスであると伝えます。 すると、クラッカーのマシンはゲートウェイ宛のトラフィックを全て受け取ることになります。 トラフィックを盗聴 (および改竄) するにはこれで十分です。 その後、クラッカーはパケットが本当の宛先に転送して、誰もこのことに気づかないようにします。
ARP スプーフィングは、ローカルネットワークがスイッチを使っている場合に効果的です。 スイッチでは、イーサネットフレームは MAC アドレス毎に別々のポート (ケーブル) にリダイレクトされます。 そうなると、盗聴プログラムは自身の物理的な線以外のフレームをキャプチャすることができません。 そこで ARP スプーフィングを使うことで、別のポートにつながっているマシン間のトラフィックを盗聴することができるのです。
ARP スプーフィング攻撃を行うには、クラッカーは ARPSpoof や
nemesis といったパケット生成プログラムを使います。
例としてターゲットとなるマシンを 10.0.0.171、
デフォルトゲートウェイを 10.0.0.1、
クラッカーのマシンを 10.0.0.227 としましょう。
攻撃の前の traceroute の結果は次のようになります。
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.1 (10.0.0.1) 1.218 ms 1.061 ms 0.849 ms
ターゲットの ARP キャッシュは以下の通りです。
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:b0:c2:88:de:65 C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
次にクラッカーが ARPSpoof を実行します。
[root@pirate -> ~]$ arpspoof -t 10.0.0.171 10.0.0.1 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
送信されたパケットは、マシン 10.0.0.171 の ARP キャッシュを汚染するためのもので、10.0.0.1 に対応する MAC アドレスは 00:00:86:35:c9:3fであると伝えます。
すると、マシン 10.0.0.171 の ARP キャッシュは以下のようになります。
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:00:86:35:c9:3f C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
トラフィックがマシン 10.0.0.227 に流れるようになったことを確認するには、もう一度ゲートウェイ 10.0.0.1 に対して traceroute を実行すれば分かります。
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.227 (10.0.0.227) 1.712 ms 1.465 ms 1.501 ms 2 10.0.0.1 (10.0.0.1) 2.238 ms 2.121 ms 2.169 ms
これで、クラッカーはマシン 10.0.0.171 と 10.0.0.1
の間のトラフィックを盗聴できるようになりました。
クラッカーは、自分のマシン 10.0.0.227 で IP ルーティングを忘れずに動かしておく必要があります。
DNS (Domain Name System) プロトコルはドメイン名 (例えば www.test.com) を IP アドレス (たとえば 192.168.0.1) に変換したり、逆の変換を行ったりするためのプロトコルです。 この攻撃では、「犠牲者」となるマシンが送った DNS 要求に対して偽った答えを送ります。 この攻撃は主に 2 つの方法を使います。
DNS プロトコルのヘッダーには識別子のフィールドがあり、応答と要求を突き合わせるのに使われます。 DNS ID スプーフィングの目的は、本当の DNS サーバーが応答するよりも前に嘘の応答を送り返すことです。 そのためには、DNS 要求の ID を予測しないといけません。 ローカルであれば、ネットワークを盗聴することで簡単に予測できます。 リモートではもうすこし複雑になりますが、方法はいくつかあります。
いずれの場合でも、本当の DNS サーバーよりも先に答える必要があります。 例えばサービス拒否攻撃でサーバーをクラッシュさせるなどして実現します。
この攻撃が成功するには、アタッカーはドメイン attaquant.com
で権限を持っているDNSサーバー
(ns.attaquant.com) を操る必要があります。
ターゲットとなる DNS サーバー (ns.cible.com) は、予測可能なシーケンス番号
(要求毎に 1 ずつ増加させるなど) を使っているとします。
攻撃は 4 段階で行われます。
cible.com
の DNS サーバーに、www.attaquant.com の問い合わせ要求を出します。ns.cible.com に送られる
attaquant.com
の DNS サーバーへ要求を中継します。www.spoofed.com で、IPアドレスが
192.168.0.1 だとします。
アタッカーは ns.cible.com に対して、www.spoofed.com を解決するよう要求を送ります。
その直後、この要求に対し、ソース IP アドレスをドメイン spoofed.com のDNSサーバーのどれかにして、改竄された DNS 応答を大量に送ります (IP アドレスはアタッカーのサイト 10.0.0.1にします)。
各応答の ID は、手順 2 で得た ID (100) から始めて、 1 ずつ増やしていき、正しい ID に当たりやすくします。
これは、ns.cible.com が他の要求に答えて、DNS ID が変わってしまっている場合に備えてのことです。
図 12 にこの手順を示します。
www.spoofed.com の解決を要求したマシンに対しては、アタッカーのマシンの IP アドレスが送られて、アタッカーのサイトにリダイレクトされることになります。
アタッカーのサイトは本物のサイトのコピーになっていて、インターネット利用者を騙し、秘密情報を盗むといったことが可能になります。
DNS サーバーは、以前の要求に対する応答をしばらくの間ローカルに保持しておくため、キャッシュを使います。 これは、要求のあったドメインのオーソリティを持っているサーバーに対して何度も問い合わせを行って、時間を無駄にするのを防ぐためです。 ここで説明する DNS スプーフィングは、このキャッシュに偽のデータを送る方法です。 以下に例を示します。
パラメーターは前回の例と同じものを使います。 攻撃の手順は以下の通りです。
cible.com の DNSサーバーに対して、www.attaquant.com を解決する DNS 要求を送ります。www.attaquant.com
を解決するよう要求を送ります。www.attaquant.com の IP アドレスを送り返すことで、サイト www.cible.com に対する DNS レコードが書き換えられることがあります。アプリケーション攻撃はアプリケーション固有の脆弱性を利用します。 ですが、いくつかの種類に分類することができます。
アプリケーションでの最初のセキュリティ問題は、設定の誤りによるものです。 誤りには 2 種類があります。 デフォルトのインストールと設定ミスです。
ウェブサーバーのようにデフォルトでインストールされるファイルのあるソフトウェアは、サンプルサイトからクラッカーが機密情報にアクセスできてしまうことがあります。 たとえば、ダイナミックページに欠陥があって、ソースデータを取得できるようなスクリプトが入っていることがあります。 また、デフォルトのログイン名/パスワード (アプリケーションの管理者ガイドに載っている) を使ったリモートからの管理インターフェースが提供されていることもあります。 クラッカーはこれをつかってサイトを改竄することができます。
設定ミスによる脆弱性で多いのが、パラメーターが適切でないアクセスリストです。 そのため、クラッカーは個人的なページや個人的なデータベースにアクセスできることになります。
設定ミスの古典的な例として、Lotus Domino ウェブサーバーのパラメータがあります。 このサーバーをインストールする際、Lotus configuration database はアクセスコントロールリストを一切持っていません。 もし Lotus データベース names.nsf に認証なしでウェブブラウザからアクセスできると、Lotus の全ユーザー名など、大量の情報を取得することができます。
ソフトウェアのプログラミングが下手だとバグが入り込みます。 バグはとても重大な脆弱性です。 これが見つかると、認められていないコマンドを実行したり、ダイナミックページのソースを取得したり、サービス不能にしたり、マシンの制御権を取得したりと、いろいろなことができます。 バグの中でも、有名な脆弱性はバッファーオーバーフローです。
バッファーオーバーフローは、プログラミングの不具合によって引き起こされる脆弱性です。
ある関数への引数として変数が渡され、その中味をサイズをチェックせずにコピーした場合に発生します。
もし変数がバッファー用に確保されたメモリ領域よりも大きいと、バッファーオーバーフローが起きるのに十分な条件が整います。
この変数にプログラムを渡されれば、悪用されてしまいます。
クラッカーがこの攻撃に成功すると、ターゲットマシン上で、攻撃されたアプリケーションの権限で、コマンドを実行することができるようになります。
これに関しては、セキュアプログラミングに関する一連の記事に詳細が載っています。
スクリプトのプログラミング上の不具合も、システムのセキュリティに影響することがよくあります。 Perl スクリプトで見つかった脆弱性を悪用し、ウェブのルートからファイルを読み込んだり、許可されていないコマンドを実行したりすることができます。 これらプログラミング上の問題は、CGIのセキュリティについての前述の記事に掲載されています (第 6 章)。
この攻撃の主な目的は、2 つのマシン間のトラフィックを中継することです。 通信中に交わされるデータの横取り、改竄、破壊を行うためです。 この攻撃は実際の攻撃というよりは理論上のものですが、この「Man in the midele」という理論を実現した攻撃はたくさんあります。 たとえば、「DNS Man in the Midele」は、DNS スプーフィングを使ってウェブサーバーとウェブクライアント間のトラフィックを中継します。 最近では、SSH のトラフィックを中継するアプリケーションも作られました。
この攻撃は、その名のとおりサービス (特定のアプリケーション) やターゲットとなるマシンを使用不可能にします。 サービス拒否には 2 つの種類があります。 アプリケーションのバグを利用するものと、プロトコルの実装上の問題やプロトコル自身の弱点に関係するものです。
アプリケーションの脆弱性によりマシンを乗っとることができれば (バッファーオーバーフローなど)、サービス拒否攻撃を行うことも可能です。 アプリケーションはリソース不足やクラッシュにより利用不可能になります。
TCP/IP スタックの、プロトコルとしての特徴を使ったサービス拒否攻撃には、様々なものがあります。
TCP コネクションが 3 段階で確立されること (TCP Three Way Handshake) は既に説明しました。 SYN Flooding はこの仕組みを悪用します。 3 段階とはそれぞれ、SYN の送信、SYN-ACK の受信、ACK の送信です。 この攻撃の要点は、ターゲットとなるマシンで TCP コネクションを大量に待ち状態にすることです。 それには、クラッカーは大量のコネクション要求 (SYN フラグ = 1) を送ります。 ターゲットとなるマシンは、受信した SYN に対して SYN-ACK を送り返します。 しかし、クラッカーは ACK を応答しません。そのため、ターゲットは受信した SYN に対して、TCP コネクションが保留状態となるのです。 これら半分オープンされたコネクションはメモリリソースを消費しますから、しばらくするとマシンが飽和し、他のコネクションを受けつけることができなくなってしまいます。 このサービス拒否攻撃は、ターゲットマシンにだけ影響します。
クラッカーは、synk4 などの SYN Flodding プログラムを使い、ターゲットの TCP ポートを指定し、ソース IP アドレスはランダムな値を指定して、アタッカーのマシンが特定されないようにします。
このサービス拒否攻撃は、UDP プロトコルの非接続モードを使ったものです。 この攻撃では、特定のマシンもしくは 2 つのマシン間で UDP パケットストーム (大量の UDP パケット)を生成します。 マシン間でこの攻撃を行うことでネットワークが輻輳状態となり、両ホストでリソースが飽和します。 UDPのトラフィックは TCP よりも優先度が高いことから、輻輳はより重大な問題となります。 TCP プロトコルは輻輳を制御する機構を持っており、パケットに対する肯定応答が遅れて届いた場合、TCP パケットを送信する頻度を調整し、送信回数が減ります。 UDP プロトコルにはこの仕組みがなく、しばらくすると UDP トラフィックが帯域を使い果たし、TCP トラフィックはほんの少ししか帯域を利用できなくなります。
UDP Flooding で有名なのが Chargen Denial of Service Attack です。
この攻撃を実装するのは簡単です。
あるマシンの chargen サービスと、別のマシンの echo サービスをつなぐだけです。
chargen サービスは文字を生成し、echo は受信したデータを送り返します。
クラッカーはIP アドレスとソースポートを偽装して、「犠牲者」の一方のポート 19 (chargen) に UDP パケットを送ります。
その際、ソースポートは UDP ポート 7 (echo) にします。
これで UDP Flooding により 2 つのマシン間で帯域が飽和します。
そのため、ネットワーク全体が UDP Flooding の「犠牲者」となるのです。
パケットフラグメントを使ったサービス拒否攻撃では、TCP/IP スタックの IP フラグメンテーション (IP フラグメントの再構築) の弱点を利用します。
これを使った攻撃で有名なのが Teardrop です。 2 つ目のセグメントのフラグメンテーションオフセットを最初のセグメントのサイズよりも小さくし、2 つ目のセグメントのサイズにオフセットを加えたものが最初のセグメントのサイズよりも小さいようにします。 すなわち、最初のフラグメントが 2 つ目のフラグメントを含む (オーバーラップ) 状態にします。 そうすると、デフラグメンテーション時にこの例外をうまく処理できないシステムがあり、サービス拒否攻撃が起こります。 この攻撃には、bonk、boink、newtear といったバリエーションがあります。 Ping of Death というサービス拒否攻撃は、ICMP のデフラグメンテーションの不具合を突いたもので、1 つの IP パケットに収まりきらない大きさのパケットを送ります。 このサービス拒否攻撃を行うと、ターゲットマシンはクラッシュします。
この攻撃は ICMP プロトコルを使います。 ping (ICMP ECHO メッセージ) がブロードキャストアドレス (たとえば 10.255.255.255) に送られると、最後の数字が除かれてネットワーク内の全てのマシンに送られます。 この攻撃の原理は、ソース IP アドレスにターゲットを指定して ICMP ECHO リクエストを偽造することです。 クラッカーは、ネットワークのブロードキャストアドレスに対して定期的に ping を送ります。 すると、全てのマシンが ICMP ECHO REPLY メッセージで応答します。 この時、パケットはネットワーク上のマシンの数の掛け算になります。 そして、ターゲットのネットワーク全体がこのサービス拒否攻撃の影響を受けます。 攻撃により生成された大量のトラフィックが、ネットワークの輻輳を招くからです。
分散サービス拒否攻撃は攻撃対象のネットワークを飽和させます。
原理としては、多数の攻撃元 (デーモン) と、それを制御するためのマスターを使うことです。
最も有名な DDoS (Distributed Denial of Service) ツールは
Tribal Flood Network (TFN)、TFN2K、Trinoo、Stacheldraht です。
図 13 に典型的な DDoS のネットワークを示します。
図 13: DDoS ネットワーク
クラッカーは攻撃元を制御するのにマスターを使います。 もちろんクラッカーは、攻撃の設定や準備を行うのにマスターに接続 (TCP) する必要があります。 マスターは攻撃元に UDP で命令を送るだけです。 マスターがいないと、クラッカーはそれぞれの攻撃元に対して接続しないといけませんので、攻撃元は容易に発見されてしまいます。
デーモンとマスターは使用するツール毎のメッセージをやりとりします。 通信は暗号化されていたり、認証を行ったりすることあります。 デーモンやマスターをインストールするために、クラッカーは既知の脆弱性 (RPC サービスや FTP サービスのバッファーオーバーフローなど) を利用します。 攻撃自体は SYN Flooding や Smurf Attack を使います。 分散サービス拒否攻撃が行われると、ネットワークが到達不可能になります。
この頃ではリモートアタックに対するセキュリティは強化されていますが、内部のセキュリティについてはまだまだです。 これはクラッカーに対する防御の盲点であり、TCP セッションハイジャック、ARP スプーフィング、DNS スプーフィングなどのローカル攻撃が行われる余地を残しています。 また、シーケンス番号の予測 (IP スプーフィングのよりどころ) とフラグメント攻撃については、単にネットワーク機器の OS のバグが原因しています。 アプリケーション攻撃については、ウェブ関連アプリケーションがさらに複雑化し、開発者や管理者に対してはさらなる納期の短縮が求められることから、まだまだ長引くと思われます。 サービス拒否攻撃は、ユーザー各自が自分のマシンを守る必要性を認識しない限り、分散攻撃という形でまだまだ驚異であり続けることでしょう。
|
Webpages maintained by the LinuxFocus Editor team
© Eric Detoisien, FDL LinuxFocus.org |
翻訳履歴:
|
2003-05-31, generated by lfparser version 2.36