ブログとストーリー

SpiderLabsブログ

年間50万人以上の読者を魅了しているブログがセキュリティ コミュニティの主要目的地になっているのは、最新の脅威の技術的な分析、重要な脆弱性に関する開示、最先端の研究が掲載されているからです。

セキュリティ回避のために IPv6 を使用する

イントロダクション

私たちがクライアント組織に対してペネトレーションテストを実施した際に、IPv4 インフラストラ クチャに対する堅牢な警戒体制を目の当たりにすることがあります。彼らはサービスを厳重に 固め、ホストベースのファイアウォールを使用し、一般的にはセキュリティガイドラインのベスト プラクティスに従っています。しかしこのような組織でも、時折 IPv6 を認識していないことがあ ります。IPv6 を明示的には使用していないものの、ほとんど全ての現代的なシステムでは IPv6 はデフォルトで有効になっており、興味深い攻撃方法を攻撃者に提供してしまうケースが あります。

このブログの目的は、実際の例を通して、すべてのエンドポイントをテストしないことに対する 危険性と影響を強調することです。すべてをテストすることは、私たちが日常的にやっているこ とですが、堅牢な警戒態勢を確保するために、皆様に実施するようにお勧めしています。

一例:

ここに、同じ物理ネットワーク上のホストからスキャンされた 192.168.9.19 のアドレスを持つ Linux システムのポートスキャン結果があります。

Nmap scan report for 192.168.9.19
Host is up, received arp-response (0.0021s latency).
Scanned at 2018-04-04 10:28:36 +0630 for 105s
Not shown: 65532 filtered ports
Reason: 65532 no-responses
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
25/tcp open smtp syn-ack ttl 64 Postfix smtpd
5666/tcp open tcpwrapped syn-ack ttl 64
MAC Address: 00:80:10:22:38:66 (Commodore International)

ここで、現代のオペレーティングシステムは通常、デフォルトでは、自動的に設定されたアドレ スで IPv6 を有効にします。IPv4 とは対照的に、IPv4 における ARP のような別プロトコルを使 用する代わりに、IPv6 では実際に OSI モデルのレイヤ 2 で IP を動作させます。これにより、 IPv6 が有効になったシステムがネットワークに接続されると、MAC アドレスに基づいて、 fe80::10 アドレスレンジ内で、レイヤ 2 アドレスで自分自身を設定し、ルーターの存在を広告す るためのデフォルト IPv6 マルチキャストアドレス (ff02::/10) を待ち受けます。

1 つの特別なマルチキャストアドレスに ff02::1 があります。これはローカルネットワークセグメ ントに接続されたすべての IPv6 対応ノード用です。このアドレスに ICMP echo requests を送 信すると、たとえ IPv6 アドレスが明示的に指定されていなくても、理論的にはローカルネットワ ーク上のすべての IPv6 マシンがそれに応答する必要があります。

# ping6 ff02::1%eth0

PING ff02::1%eth0(ff02::1%eth0) 56 data bytes
64 bytes from fe80::280:10ff:fe22:3866%eth0: icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from fe80::250:56ff:fe8c:3172%eth0: icmp_seq=1 ttl=64 time=1.82 ms (DUP!)
64 bytes from fe80::250:56ff:fe8c:478c%eth0: icmp_seq=1 ttl=64 time=3.03 ms (DUP!)
64 bytes from fe80::80b1:c330:51b8:5a22%eth0: icmp_seq=1 ttl=64 time=3.08 ms (DUP!)
64 bytes from fe80::ec4:7aff:fe42:2b90%eth0: icmp_seq=1 ttl=64 time=3.63 ms (DUP!)

この ping6 の出力によると、ローカルネットワーク上には、5 つの IPv6 対応デバイスがあるこ とが分かります。これには、ping を実行したデバイスも含まれています。IPv6 アドレス fe80::280:10ff:fe22:3866 のデバイスもあります。これは以前スキャンした IPv4 アドレスに関連 付けられた MAC アドレス 00:80:10:22:38:66 に対応しています。次に、この IPv6 アドレスに対 してポートスキャンを実行して、何を待ち受けているかを確認します。

Nmap scan report for fe80::280:10ff:fe22:3866
Host is up, received echo-reply ttl 64 (0.0033s latency)
Scanned at 2018-04-04 10:32:47 +0630 for 22s
Not shown: 65530 closed ports
Reason: 65530 resets
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
25/tcp open smtp syn-ack ttl 64 Postfix smtpd
5666/tcp open tcpwrapped syn-ack ttl 64
3128/tcp open http-proxy syn-ack ttl 64 Squid http proxy 3.4.8
6379/tcp open redis syn-ack ttl 64 Redis key-value store
MAC Address: 00:80:10:22:38:66 (Commodore International)

IPv4 アドレスでのポートスキャンで見たのと同じポート 22/25/5666 はオープンで、まったく同じ サービスを実行しているようです。しかし、IPv4 アドレスは他のポートを filtered していますが、 IPv6 アドレスの場合は、未使用ポートはすべて closed として表示されています。これは、シス テムが接続試行を無視するのではなく積極的に拒否していることを意味します。ほとんどのオ ペレーティングシステムは未使用ポートへの接続を拒否しますが、ほとんどのホストおよびネッ トワークベースのファイアウォールはそのような試みを無視するように設定されています。拒否 された接続試行と、静かに無視された接続試行とを比較すると、初期偵察に役立つことがよく あります。

もう一つの興味深い結果としては、IPv6 スキャンでは、IPv4 アドレスには存在しなかった 2 つ の追加ポート、ポート 3128 上の Squid プロキシ、およびポート 6379 上の Redis インスタンスが 表示されたことです。その Redis インスタンスを詳しく見ていきましょう。

https://redis.io/topics/securityの Redis セキュリティ文書は、Redis はセキュリティではなくパフ ォーマンスのために最適化され、ファイアウォールルールを使用してネットワークサービスへの アクセスを制限する必要があると述べています。今回のケースでは、このホストの管理者は正 確にこれを実行しました。ホスト上の IPTables ルールは、ポート 22, 25, 5666 へのアクセスを 許可し、複数の特定のアドレスからポート 6379 へのアクセスを許可し、他のすべてのトラフィッ クをドロップするように設定されています。しかし、これは IPv6 対応の IP6Tables ではなく、 IPTables を使用して行われただけなので、これらのアクセスコントロールルールは IPv6 にまで は拡張されません。

したがって、認証なしで、IPv6 経由で Redis インスタンスに接続することが可能でした。

# redis-cli -h fe80::280:10ff:fe22:3866%eth0 -p 6379
[fe80::280:10ff:fe22:3866%eth0]:6379> echo test
"test"

[fe80::280:10ff:fe22:3866%eth0]:6379>

結論

このブログの鍵は、このシステムを設定した人はセキュリティを意識しているということです。 Redis などの潜在的に脆弱なサービスへのアクセスを制限するために、ローカルのファイアウ ォールルールを設定する作業を行いました。しかし彼らは、おそらくは意識の欠如のために、 システム上に IPv6 が存在するかどうかを考慮していませんでした。多くのシステム管理者や ネットワーク管理者は IPv6 に関する経験がなく、完全に無視してしまう傾向があります。

自動設定用に IPv6 または IPv4 のいずれかが設定されているが、ネットワーク上に設定サー バーが存在しない場合、これらの設定要求に答える不正なサーバーを入れることによって、他 の攻撃が可能になります。今日のオペレーティングシステムでは、従来の IPv4 よりも IPv6 を 優先し、利用可能な場合はデフォルトで不正な IPv6 接続を使用します。これにより、攻撃者は DNS ルックアップなどのトラフィックを乗っ取ることができます。この設定攻撃を利用するため のツールや記事については、https://github.com/fox-it/mitm6 などで既にカバーされているの で、この記事では詳しい説明は行いません。

このような問題の迅速な修正は、IPv6 を無効にすることですが、これはいくつかの理由で推奨 されません。IPv6 は未来であり、今日の多くのシステムとソフトウェアがそれを念頭に置いて 設計されています。IPv6 が無効になっていると、一部のアプリケーションが正常に動作しなくな る場合があります。同様に、組織がまだ IPv6 を正式に使用していない場合でも、必要となるま Trustwave SpiderLabs Blog – April 18, 2018 Copyright © 2018 Trustwave Holdings, Inc. All rights reserved. 4 でには時間がかかりますので、できるだけ早く準備して経験を積むことは理にかなっていま す。

IPv6 を無効にする代わりに、IPv6 が存在するかどうかを検討し、IPv4 で使用されているセキ ュリティルールが IPv6 にも適用されていることを確認してください。IPv6 の経験を得るため に、IPv6 をネットワーク上に展開して使用することも検討してください。IPv6 サービスは IPv4 と同じ方法で監視する必要があり、不正なサーバーの存在を特定して対応する必要がありま す。