Cisco Japan Blog / 脅威リサーチ / UPnP を利用して IPv6 アドレスを明らかにする

エグゼクティブ サマリー

ZMap や Masscan などのツールが利用可能になったことや、一般的に使用可能な帯域幅が拡大していることから、かつては実行が難しかったインターネット上の IPv4 の全アドレス空間のスキャンが当たり前に行われるようになっています。Shodan や Scans.io のようなプロジェクトでは、最新のスキャン結果のデータセットを集計して公的な分析用に頻繁に公開しているため、研究者はインターネットの現状についての詳しい洞察を得ることができます。

一般的には IPv4 が使用されていますが、IPv6 の使用が増加しています。しかし、アドレス空間のサイズを考えると、この最新のインターネット プロトコルは包括的なスキャンの実行が不可能であるため、ほとんど分析がなされていません。アクティブな IPv6 ホストを列挙するには、今までにない手法を導入する必要があります。

この記事では、ユニバーサル プラグ アンド プレイ（UPnP）プロトコルのプロパティを使用して特定の IPv4 ホストを取得し、その IPv6 アドレスを明らかにする手法を紹介します。この手法を使用すると、アクティブな IPv6 ホストの特定のサブセットを列挙し、スキャンすることができます。また、IPv4 と IPv6 両方で検出されたホストの比較スキャンを実行した結果と分析について説明します。この調査結果は、UPnP を使用するこの手法が有効であること、そしてこれらのホストの IPv4 インターフェイスと IPv6 インターフェイスのセキュリティ フィルタリングには大きな差異があり、意図しない IPv6 接続が今後大きな問題になることを示しています。

はじめに：動機と以前の調査

注目を浴びた多くの脆弱性の発見を受け、IPv4 アドレス空間の完全なスキャンが最新のネットワーク セキュリティ調査で不可欠になるほどに、インターネット全体を包括的にスキャンして脆弱性の具体的な影響を測定し、修復する動きが見られています。OpenSSL 暗号化ソフトウェア ライブラリのバグである Heartbleed の脆弱性が発見された際には、この脆弱性がどれ位広まっているかや時系列のパッチ適用状況の広域な分析が行われました。

一部の研究出版物は、公的にアクセス可能な MongoDB および Redis インスタンスに広まるデータベースの不適切な設定の問題への認識向上に乗り出しました。

Talos でも、以前にインターネット全体でアクセス可能な Memcached サーバのスキャンを実施し、複数の脆弱性のリスクを評価しました。具体的には、脆弱性 TALOS-2016-0219、TALOS-2016-0220、および TALOS-2016-0221 に影響を受けるソフトウェアをスキャンし、パッチ適用率と攻撃の影響を受けるかどうかを調査しました。

Mirai botnet などの分散型サービス妨害（DDoS）攻撃は、IPv4 スキャンとデフォルトのクレデンシャルを活用して、数百万台のデバイスに感染を広げています。

目的の良し悪しに関わらず、これらはすべて、比較的少ないリソースだけで数時間のうちに完全な IPv4 ポート スキャンを実施できるために実行可能になったことです。

現在 IPv6 は、IPv4 アドレス枯渇の問題を長期的に解決できる唯一のソリューションであるため、IPv6 対応ネットワークとアクティブな IPv6 ホストは着実に増加しています。

IPv4 枯渇の問題を軽減するために、IPv6 は 128 ビット アドレスを使用しています。したがって、論理的な最大ホスト数は IPv4 よりも桁違いに大きくなります。使用可能なアドレス数がこのように膨大であるため、現在 IPv6 アドレス空間は非常にまばらです。実際に使用中の IPv6 アドレスは比較的少なく、使用されるアドレスはランダムに決定されるため、アドレスは散在しています。このアドレス空間全体をスキャンしてすべてのアクティブ ホストを列挙することは、理論的には実行不可能です。しかし IPv6 の使用は増加しているため、IPv6 空間をスキャンできないと、今後のインターネット調査で発見できないホストがさらに増加する恐れがあります。ますます多くの IoT デバイスが未保護のままオンラインに接続されている現在、このことは特に重大な問題です。

この問題を解決するために、複数の研究者がインターネットに接続されているアクティブな IPv6 ホストを発見する新しい手法を開発しています。ネットワーク上の特権のある地位を使用してアクティブなホストのリストを作成する研究者も、悪用可能なさまざまなプロトコルの正当な機能を使用する研究者もいます。Shodan プロジェクトでは、ホストを取得してその IPv6 アドレスを露呈させるために Network Time Protocol の機能が使用されています。IPv6Hitlist プロジェクト では、複数のソースと技法を活用して、正引き DNS ルックアップ、証明書の透過性ログ、RIPE Atlas などのアクティブな IPv6 ホスト/ネットワークのリストを毎日更新しています。IPv6 Farm プロジェクトでは、DNS と DNSSEC のプロパティを使用してアクティブなホストを発見し、IPv4 アドレスのアクティブなホストとの比較スキャンを実行しています。

Talos では、UPnP の NOTIFY パケットを使用してデュアルホーム ホストの IPv4 および IPv6 アドレスのペアを発見する手法を利用して、公的な IPv6 研究に貢献したいと考えています。Talos のデータセットは、規模は比較的小さめですが、以前に公開したデータセットではほとんどカバーされていなかったエンドユーザ デバイス、クライアント側デバイス、コンシューマ デバイスでほぼ構成されています。

UPnP とインターネット

ユニバーサル プラグ アンド プレイは、元々はネットワーク検出のために設計されたネットワーク プロトコルです。基本的には、ローカル ネットワーク上のさまざまなデバイスが、自身のプレゼンスと機能を他のデバイスにアナウンスすることができます。UPnP のもう 1 つの一般的な用途は、デバイスがインターネット ゲートウェイ デバイス プロトコルを使用してポート フォワーディングを行える NAT（ネットワーク アドレス変換）トラバーサルです。

UPnP は、設計上はローカル ネットワークの外部で使用されるものではありませんが、多くのデバイスがインターネットに公然と UPnP ポートを露出しています。そのため、長年にわたって悪用や攻撃が行われています。UPnP は、悪意を持って NAT に穴を開ける、機密性の高いネットワーク構成情報をリモートに公開する、DDoS 攻撃を実行するといった目的で悪用されてきました。かつて Talos では、UPnP クライアント側攻撃と侵害の可能性に関する調査を公開したことがあります。この調査をもとに、UPnP を使用して IPv6 アドレスを明らかにする方法のアイデアを思い付きました。

新しいデバイスはネットワークに接続すると、マルチキャスト アドレスに UPnP NOTIFY パケットを送信することによって、自身のプレゼンスと機能をアナウンスします。このパケットは、通常は次のようになります。

NOTIFY * HTTP/1.1
Host:239.255.255.250:1900
Cache-control:max-age=1800
Location:?http://host/description.xml
Nt:upnp:rootdevice
Nts:ssdp:alive
Usn:uuid:de5d6118-bfcb-918e-0000-00001eccef34::upnp:rootdevice

このパケットで最も重要な要素は「Location」ヘッダーで、デバイスの機能を説明する XML ファイルをポイントする説明 URL が指定されています。このパケットが UDP を介して特別なアドレス「239.255.255.250」に送信されると、UPnP と Simple Service Discovery Protocol（SSDP）をサポートするすべてのデバイスが、その URL にアクセスし、その XML を取得して解析することになります。偶然にも、この機能は Talos が 2015 年に公開した MiniUPnP vulnerability の中核で使用されていました（TALOS-2015-0035）。

UPnP 実装では、NOTIFY パケットの送信元（ローカル ネットワークからマルチキャスト IP アドレスに送信されているか、エンドポイントに直接送信されているか）は管理されません。そのため、この特定の UPnP パケットを送信することにより、ターゲット UPnP エンドポイントを、私たちが選択した URL に接続させることができます。前述のように、インターネット上の多くのデバイスは、UPnP ポート（デフォルトは UDP 1900 番）をフィルタリングせずに露出しています。

つまり、私たちは IPv6 アドレスを含む URL が指定された NOTIFY パケットを使用することができます。UPnP ポートが開かれている IPv4 アドレスにこの NOTIFY パケットを送信し、そのホストに IPv6 接続性もある場合、このホストは指定された URL に接続するため、その IPv6 アドレスが露呈されます。この操作をすべての IPv4 アドレスに実行すれば、さまざまな IPv6 ホストからの接続が見込めます。この方法によって、IPv4 アドレスと対応する IPv6 アドレスのペアを作成し、両方のスキャンを実行してセキュリティの差異を確認できるはずです。

スキャンの実行

スキャンは次の 2 つの手順で実行します。まず、すべての IPv4 アドレスに特定の UPnP NOTIFY パケットを送信し、IPv6/IPv4 のペアを収集します。次に、発見したペアの完全なポート スキャンを実行し、IPv4 側と IPv6 側のオープン ポートの状態を比較します。

最初の手順では、Masscan の修正済みパケット テンプレートを使用して NOTIFY パケットを送信することにしました。説明 URL の取得を試みるホストからの HTTP 要求を記録するために、Web サーバを実行し、完全なログを取りました。さまざまなホストからの HTTP 要求を区別できるようにするには、すべての要求を一意にする方法が必要でした。その最適な手段は、ターゲット IPv4 アドレスを「Location」URL にエンコードすることでした。Talos で使用した NOTIFY パケットは次のようになります。

NOTIFY * HTTP/1.1
Host:239.255.255.250:1900
Cache-control:max-age=1800
Location:http://[IPv6_address_of_our_server]/?IPv4_ADDR_OF_TARGET
Nt:upnp:rootdevice
Nts:ssdp:alive
Usn:uuid:de5d6118-bfcb-918e-0000-00001eccef34::upnp:rootdevice

このパケットを受信した ターゲットの UPnP IPv4 ホストは、IPv6 接続性も持つ場合、この URL で自身の IPv4 アドレスを使用して Talos の IPv6 サーバに HTTP GET 要求を送信します。Talos の HTTP サーバ ログ ファイルには、次のような情報が記録されます。

上記の出力では、ターゲット ホストの IPv6 アドレス、GET 要求内の対応する IPv4 アドレス、UPnP の実装とバージョンを示すユーザ エージェント文字列を確認できます。また、Talos のデータが誰かに意図的に汚染されることがないように、シンプルな暗号化スキームを使用して URL 内の IPv4 アドレスを暗号化しました。この方法によって、ログを解析する際に、得られた要求が私たちが送信した NOTIFY パケットに応答する正当な要求であることを証明できました。

この結果を記録した後、スキャンの 2 番目の手順を開始できました。私たちは結果のデータセット内の 各 IPv4 および IPv6 アドレスに対して 1 つずつ、2 つの詳細なスキャンを実施しました。応答したホスト数は膨大ではなかったため、NMap を使用して一般的な上位 100 ポートをスキャンしました。

結果

インターネット ホストを Talos のサーバに接続させ、その IPv6 アドレスを露呈させるには、いくつかの条件が満たされる必要があります。まず、ホストの UDP 1900 番ポートが開かれていること、ホストが Talos の UPnP パケットを受け付けて解析すること、ホストが指定された URL を要求することです。この URL 要求を成功させるには、ホストがデュアルホーム接続（IPv4 と IPv6 の両方に接続）されている必要があり、Talos の HTTP ポートへの送信トラフィックが許可される必要があります。私たちは、2 ヵ月間にわたって、何度もこれらのスキャンを実施しました。毎回、約 12,000 個の一意の IPv6 アドレスがログに記録されました。これらの要件を考えると、私たちは発見できるホストの大半がコンシューマ デバイスであると予想しましたが、その予想は正しいことが実証されました。従って、発見されたホストの大半では時折変更される動的 IPv4 アドレスが使用されていました。これはデータセットの有効性が時間の経過とともに低下することを意味します。

ホストに IPv6 アドレスを割り当てる手法は多く存在しており、移行技術もいくつか使用されています。たとえば、データセット内のホストの 8% は、リレー経由で IPv4 ネットワーク上に IPv6 トラフィックを流せるようにする移行メカニズムである「6to4」メカニズムを使用して IPv6 アドレスが割り当てられていました。同様に、Teredo トンネリングも一部の Windows バージョンでデフォルトで採用されている移行メカニズムです。Teredo アドレスを使用していたホストは、Talos のスキャンに応答したホストの 1% 未満でした。

データセット内のデバイスの一部は、デフォルト IPv6 アドレッシング スキームを使用しています。このスキームでは、インターフェイス識別子を表す 64 ビットは、ホストの MAC アドレスに基づいています。MAC アドレスはそれぞれ独自のグループに属するため、知識に基づいてデバイス タイプを推測できます。ユーザ エージェント文字列によって、この推測がさらに裏付けられました。

デバイス製造業者 トップ 10

1. Huawei Technologies 社
2. Zhejiang Uniview Technologies 社
3. Amazon Technologies 社
4. Swann Communications 社
5. LT Security 社
6. Trendnet 社
7. Netgem 社
8. Shenzhen Giec Electronics 社
9. Synology Incorporated 社
10. Panasonic AVC Networks Company 社

報告されたユーザ エージェント文字列に基づくと、ホストの 98% は、セキュリティ カメラ、メディア/NAS サーバなどの組み込み型 Linux デバイスと、スマート TV やメディア ドングルなどの Android デバイスです。応答した Windows ホストのほとんどは、Azureus などの BitTorrent クライアントでした。

最も一般的な UPnP 実装は現在も LibUPNP で、最も使用されているバージョンは 2013 年にリリースされた可能性が高い 1.6.18 です。2 番目に普及しているのは MiniUPNPですが、そのホストの割合は 1% 未満です。最も一般的なバージョンは MiniUPnP 1.9 で、2014 年にリリースされました。これらのバージョン両方に、公開されている複数の脆弱性が含まれています。

• その他の一般的なユーザ エージェント文字列
• Android/4.4.2 UPnP/1.0 Cling/2.0
• Android/5.0 UPnP/1.0 Cling/2.0
• Android/5.0.2 UPnP/1.0 Cling/2.0
• Android/7.1.2 UPnP/1.0 Cling/2.0
• Android/8.0.0 UPnP/1.0 Cling/2.0
• Android/8.1.0 UPnP/1.0 Cling/2.0
• Azureus 4.3.0.6
• Azureus 4.9.0.0
• Azureus 5.7.5.0;Mac OS X;Java 1.8.0_66
• Azureus 5.7.5.0;Windows 10;Java 1.8.0_121
• Azureus 5.7.5.0;Windows Server 2012 R2;Java 1.8.0_121
• Azureus 5.7.5.0;Windows Server 2012;Java 1.8.0_121
• Dalvik/2.1.0 (Linux; U; Android 6.0; vivo Y67L Build/MRA58K)
• Dalvik/2.1.0 (Linux; U; Android 7.0; JMM-AL00 Build/HONORJMM-AL00)
• Dalvik/2.1.0 (Linux; U; Android 8.0.0; DUK-AL20 Build/HUAWEIDUK-AL20)
• Dalvik/2.1.0 (Linux; U; Android 8.0.0; SM-A720F Build/R16NW)
• Dalvik/2.1.0 (Linux; U; Android 8.1.0; EML-AL00 Build/HUAWEIEML-AL00)
• Debian/8 UPnP/1.0 MiniUPnPc/
• Linux/2.6.32-042stab128.2 UPnP/1.0 Cling/2.0
• Linux/3.0.35 UPnP/1.0 Portable SDK for UPnP devices/1.6.21
• Linux/3.10.0_s40 UPnP/1.0 Portable SDK for UPnP devices/1.6.19
• Linux/3.18.22+ UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
• Linux/3.4.67_s40 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
• Linux/4.14.79 UPnP/1.0 jUPnP/2.0
• Linux/4.9.97 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
• Ubuntu/12.04 UPnP/1.1 MiniUPnPc/1.9
• WindowsNTunknown/6.2 UPnP/1.0 Teleal-Cling/1.0

最も一般的な実装である LibUPNP では、ユーザ エージェント文字列に Linux カーネル名とバージョンが埋め込まれます。最も一般的な Linux カーネル バージョンは 3.0（10,390 ホスト中 4,248 ホストが使用）、次いで 3.10（3,950 ホストが使用）でした。Linux カーネル バージョン 4.x を使用しているのは、196 ホストのみでした。応答したうち、Linux カーネル バージョン 2.6 を使用していたのは 660 ホストでした。このバージョンは、現在も非常に多くのコンシューマ クラスのワイヤレス ルータで使用されています。自身の Android バージョンを明示的に示した 523 ホストのうち、293 ホストは バージョン 5.1.1 でした。次いで多かったのは Android 8 の各種リリースで 102 ホストでした。

私たちはこの調査の開始時に、IPv4 側のホストは適切なフィルタリングを実施し、重要なすべてのポートがファイアウォールで保護されており、IPv6 側のホストはフィルタリングが緩めまたはまったく行われていないという仮説を立てました。そして実際、対応する IPv6 アドレスと IPv4 アドレスの上位 100 TCP ポート スキャン結果を比較すると、IPv6 側の 3% のホストでより多くのポートが開かれていることを発見しました。この結果は、SMB ネットワーク共有、FTP および HTTP サーバなどの機密性の高いデータおよびサービスの意図せぬ露出につながります。

前述のように、IPv6 Hitlist プロジェクトは、多くのソースから収集した既知のアクティブな IPv6 ホストを集計し、毎日更新したリストを維持しています。Talos のスキャンで得られたアクティブなホストと Hitlist のリストを比較すると、重複するホストは 0.1% 未満でした。つまり、Talos の調査結果のデータセットは小規模ながら、まだ調査されていなかった一意のアクティブな IPv6 デバイスのサブセットを表しています。

まとめ

このデータからいくつかのことを推測できます。まず、インターネット上のオープンな UPnP の問題はなくならないということです。また、所有者が IPv6 接続性があることを認識していない数千台のデバイスがインターネット上に存在していることは確かです。Talos のテストでのホストの要件は、公的にアクセスできる IPv4 アドレスと IPv6 アドレスを持っていることでしたが、プライベート IPv4 アドレスは持たず、所有者に知られずにパブリック IPv6 アドレスを持っているホスト数はさらに高い可能性があります。スキャンされたホストのうち IPv4 側よりも IPv6 側の方でのフィルタリングが少ないホストが非常に多いという事実も考慮すると、この意図しない IPv6 接続性によって、これらのデバイスとその接続先ネットワークの露出が増加することになります。さらに、Talos のデータセットは比較的小規模ですが、これらのホストが非常に古くなったソフトウェアとオペレーティング システムを実行していることが判明しため、インターネットへの意図しない露出の影響は大きくなります。

インターネット接続された IPv6 ホスト数は増加しています。これらのホストは直接完全に列挙することはできませんが、パブリック アドレスを通じて露出される可能性が高いため、プライベート IPv4 空間の NAT の背後で通常は隠されているデバイスの構成や保守を適切に行わなければ、こうしたホストを積極的に発見する技法によって悪用される可能性があります。

ユーザは、自分のデバイスに意図しない IPv6 接続性がないかを確認してください。意図的な接続性がある場合は、適切にファイアウォールを設定してください。

本稿は 2019年3月18日に Talos Group のブログに投稿された「IPv6 unmasking via UPnP」の抄訳です。

Authors

TALOS Japan