情報科学屋さんを目指す人のメモ

方法・手順・解説を書き残すブログ。私と同じことを繰り返さずに済むように。

やっぱりUPnPは「無効」に設定すべき？という話について調査してみた

UPnP (2) セキュリティ (78)

スポンサーリンク

「「UPnP（libupnp）に脆弱性・WANから攻撃可能」という話の中身を調査してみた」とう記事を書きました。ここでは、ニュースで騒がれている脆弱性は、「WAN側にUPnPのサービスを公開しなければ防げる」という話になりました。しかし、実は今回のニュース以前から、「WAN側にUPnPのサービスを公開していなくてもUPnPを悪用される危険性がある」脆弱性が指摘されていました。つまり、「WAN側のUPnPのサービスを公開しないようにする」のは今回のニュースの問題（WANからの攻撃）を防ぐためには有効であっても、そもそも別の脆弱性があるため「UPnPを無効にすべき」、なようなのです。しかし、この危険性が公開されたのは2008年1月で丸４年前（そもそも度が高すぎる）。「もしかしたら今は大丈夫かも」という可能性もあるため、追跡調査してみました。

※謝辞：この脆弱性の存在については @hamano さんにご指摘頂きました。ありがとうございます。

スポンサーリンク

UPnPの特徴

UPnPには認証機能がないので、「UPnPを有効」にした状態は、簡単に言えば「ルータの設定を書き換え可能」な状態といえます。

ですから、昨日の記事に書いたように、libupnpの脆弱性が無くても、外部（WAN側）にUPnPのサービスを公開している時点で危険だったわけです。

LAN側からならもちろん悪用可能

もちろん、内部（LAN側）からなら、どんどん設定を変更できる、ということになります。つまり、LAN内のコンピュータは全て信頼することが前提なのです。

The UPnP protocol, as default, does not implement any authentication,

Unfortunately, many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy （引用元）

したがって、昨日の記事で言う「WWAN側でUPnPのSSDPメッセージを受け付けなければいい」というのは、あくまで「WANから攻撃されないためには」という話であって、LAN側からの攻撃は当然気を付けなければなりません。そしてそれはlibupnpの脆弱性が無かったとしても、です。

簡単な例では、不特定多数が使うカフェなどでは確実にUPnPをOFFにすべきでしょう。

では、誰も悪さをする家族が居ない家庭内のUPnPデバイスなら、そのままで大丈夫なのでしょうか。

もし悪意のあるWebサイトにアクセスしてしまったら

実は、悪意のあるサイトのFlashを実行してしまうことによってUPnPにアクセスされてしまい、設定を書き換えられてしまう危険性があるのです。

つまり、端末の利用者（家族など）に悪意が無くても、悪意のあるWebサイトにアクセスするだけで、ルーターの（UPnPで設定可能な）設定項目が書き換えられてしまう脆弱性があるようなのです。

どんな問題が起こるの？

例えば、DNSを書き換えられてしまう危険性があります（※UPnPのプロトコルを叩けるデバイスだからといって、必ずしもDNSの設定を変更できるとは限らないようです→追記D参照）。

the attacker can change the primary DNS server of the target router （引用元）

DNSが書き換えられてしまうと、例えば「www.google.co.jpという安全そうなWebサイトにアクセスしたと思ったら、実は全く別の悪質なサイトにアクセスしていた」ということがあり得ます（接続先を変更されてしまう - 参考：DNS偽装 - Wikipedia）。わかりやすい例だと、銀行のホームページだと思っていたら実は偽物だった、アドレスは間違ってないのに＞＜ということが発生し得ます。

また、WAN側IPアドレスを取得され、ポートマップを書き換えられてしまうと、外部から内部のPCの好きなポートにアクセスできるようになってしまいます（この話は後で出てきます）。つまり、LANのコンピュータにポートスキャンすることも可能、というわけです。

その他UPnPの仕様的に具体的にできることとして、例のFAQにはこんなことが書かれています。

  • portforward internal services (ports) to the router external facing side (a.k.a poking holes into your firewall and/or network)
  • portforward the router web administration interface to the external facing side.
  • port forwarding to any external server located on the Internet, effectively turning your router into a zombie: the attacker can attack an Internet host via your router, thus hiding their IP address (not all routers are affected by this, but most are)
  • change the DNS server settings so that next time when the victim visits bank.com, they actually end up on evil.com mascaraed as bank.com（←追記D参照）
  • change the DNS server settings so that the next time when the victim updates theirs favorite Firefox extensions, they will end up downloading evil code from evil.com which will root their system.（←追記D参照）
  • reset/change the administrative credentials
  • reset/change the PPP settings
  • reset/change the IP settings for all interfaces
  • reset/change the WiFi settings
  • terminate the connection etc.

（引用元）

UPnPの「プロトコル自体」の問題

さて、今回はUPnPのどんな実装の問題なのでしょうか、それとも、ブラウザの問題なのでしょうか。実はどちらでもありません。

「「UPnP（libupnp）に脆弱性・WANから攻撃可能」という話の中身を調査してみた」で紹介したRAPID7のホワイトペーパーにも、この脆弱性が触れられていました。

In 2008, GNU Citizen/PDP wrote three blog posts detailing some of the security issues with UPnP as a protocol. These were followed by an FAQ on the ability to report maps via IGD using a Flash application within the victim’s web browser.

これはまさしく「issue with UPnP as a protocol」つまり、実装ではなくプロトコル自体の問題なのです。そして、仕様そのもの問題であるから、特に厄介なようなのです（この「プロトコルの問題」こそが先ほど紹介した「認証機能がない」ことです）。

この脆弱性の厄介さについて

ここでリンクされている「GNUCITIZEN » Hacking The Interwebs」が、この脆弱性を最初に報告した GNUCITIZEN のページです。

どれだけ厄介なのかについては、この脆弱性を発見した GNUCITIZEN の書いたFAQにいろいろと質問形式で書かれています。

  • なにかフラッシュの脆弱性を利用しているの？→いいえ。←実質Flashの脆弱性だったようなもの（←詳細は追記Bへ）
  • 特定ブラウザの特定バージョンが必要な攻撃なの？→いいえ
  • 特定のOSじゃないと攻撃できないの？→いいえ
  • 認証画面とかあるでしょ？→UPnPの仕様的にないよ
  • FLASHをアンインストールすれば！→FLASH使わない方法も出てきそうだよ（←これについても追記Bへ）

とても怖いことが書かれています。

発見当時（2008年1月）の記事

実際調べてみると、この問題が明らかになった2008年当時の記事が見つかります。

シマンテックでは、同攻撃について解析。その結果、この攻撃手法は強力で、かつ広く知られているとして、影響が非常に大きいと判断。今回、改めて警告した。

シマンテックでは、この手法を使った実際の攻撃は確認していないとしながらも、もしこの攻撃が出回るようになったら、深刻な事態を招くだろうと結んでいる。 （引用元）

Flash悪用のルータ攻撃、影響は「極めて甚大」の可能性 - ITmedia エンタープライズ

いかにも危険な感じですね。他にも、いろいろな記事が見つかります。

その他の記事

（なんだかなぜか最近見慣れてきた）脆弱性情報もあります。

ここまでの情報を読むと、UPnPは危険すぎて無効が必須！である気がしてきます。

特に、「Vulnerability Note VU#347812」のサブタイトルが印象的です

UPnP enabled by default in multiple devices

適当に勢いを付ければ「やばい！UPnPがデフォルトでONのルーターが複数あるんだってよ！！」といった具合です。

発覚当時の対策法

実際に脆弱性情報のページ（US-CERT）には、こんな対策が書かれています（Workaraound・ユーザ向け）。

  • ネットワーク機器のUPnPを無効化する
  • コンピュータのUPnP機能を無効化する
  • FirefoxのNoScriptで脆弱性を避けられるかも（→こんなのあり？そしてFirefox強制）
  • Firewallを使って1900/udpと2869/tcpを塞ぐ（→ノード毎にUPnPを無効化しているに近い。WAN側のポートを閉じるのとはわけが違う）

このように、結果としてUPnPの機能を利用しない（無効化する）ことが解決策となっています。また、先ほど紹介した、脆弱性発覚直後に公開されたの多くのサイトでも、「UPnPの無効化」を第一に掲げていました。

結局のところ、2008年1月時点で「UPnPは無効化すべき」状況でした。

そしてこれをlibupnpのニュースがあった昨日から４年前を振り返ってみれば「UPnPを有効にしておくのは危険！というそもそも論」になるわけです。

結論１

この後もこのブログエントリは続くのですが、とりあえずここまでの情報を見ただけで、「UPnP自体の仕様の問題だし、FAQにもいろいろ書いてあったし、これは問答無用でUPnPは無効化するべきだ」と結論づけてもよい気がします。

でも、その後どうなったのか

しかし、もしかしたらひょっとするとこんなに状況が変わらなそうな雰囲気でも、状況が突如改善された「かも」しれないので、調査してみます。

Flashの対策情報（2008年4月）

実は先ほどのUS-CERTのページに、発覚から３カ月後のAdobe Flash Player 9のUpdateにより、対策がされたことが書いてあります（しかしリンクが切れてる。。。ので、探してきました→「2008年４月のFlash Player 9のセキュリティアップデートについて | デベロッパーセンター」）

The April 2008 Flash Player update adds a new security feature to perform a cross-domain policy file check before allowing SWFs to send headers to another domain. This change helps improve web site security by helping to defend against malicious HTTP headers sent by content from other domains. The feature will also help to mitigate a potential UPnP issue (VU#347812) in which routers fail to correctly handle unexpected header values. （引用元）

ちょっともともとの攻撃について詳しく理解していないので、この対策の効果のほどを説明できないのですが、ろくに他のサイトに書かれていないものの、何かしらの対策になったのは確かだと思います。（Flashによる攻撃はこの変更でふさがれたようです→追記Bへ）

しかし、この後紹介しますが、この対策以降もベンダーが対応情報を公開するものの、Flashアップデートの話題に触れないことから、やはり解決になっていない、もしくは、Flashを対策するだけではダメ、という先ほど紹介したFAQの意見が有力なのではないかと想像できます。

ルーターベンダーの対策情報

この脆弱性の発覚から２カ月から１年弱の間に、複数のルーターベンダーが発表していることが調べると分かってきました（つまり、発覚直後のニュースでは分からない）。

対策の結果、どうなのか、見てみます。

ヤマハ（2008年2月←早い）

RTシリーズのUPnP機能ではUPnP Forumで規定されているすべての機能のうちの一部しか有していないため、ルーターの一部の情報や状態が参照されたり任意のポート番号に対するポートマッピング（UPnP NATトラバーサル）が意図せず行われる可能性はありますが、設定が変更されることはありません。 （FAQ for YAMAHA RT Series / Security）

そもそもUPnPの仕様をフルセットでは実装していない（※追記Aへ）という意外なことが書いてありました。「WAN側IPアドレス・WAN側のインターフェースの状態・ポートマッピングのエントリ・IPマスカレードの有効or無効」が読み取り可能なだけで、設定変更はできないようです。ただし、ポートマッピングは設定されてしまう恐れがあるため、デフォルトでUPnPがオフのファームウェアが新しく配布されたようです。

先ほど述べたように、やはりこの能力（WAN側IPアドレス取得・ポートマッピング変更）だけでも十分危険であることがわかります。ですから、やはりUPnP無効化が推奨です（ポートマップまで変更不能にしてしまうとUPnPとして使いものにならなくなっちゃう？）。

※これがきっかけでUPnPがヤマハではデフォルトでOFFになったようですね。↓このTweetがつい昨日のTweetであり、最新の内容であることに注意。

NEC（2008年6月）

「ネットワーク機器におけるUPnP機能の脆弱性」にいろいろ書かれており、こちらもヤマハと同様、設定情報が参照される恐れはあるものの、設定の変更はできない、ということになっています。

IP38XシリーズにおけるUPnP機能は一部の機能のみ有効であるため、ルータの設定情報などが参照される恐れはありますが、設定の変更を行うことはできません。 （引用元）

ただ、なぜか「対策済みファームウェア」が配布されており、その効果が書いてないため、よく分かりません。しかし、ファームウェアのリンクが、なんとあのヤマハのページになっているのです。仕組みがヤマハに似ている・・・ということで、このページには書いてないものの、実は「ポートマップは変更可能」で「デフォルトでUPnPがオフになるファームウェアを配布」だと思われます。というか、このページ後半の「意図しないポートマッピングの存在を調べる方法」がまるっきりヤマハのページと同じです。

やはり「UPnPの有効化は危険」だと言えるでしょう。

BUFFALO（2008年8月）

対応FWに関しましては、UPNPの通信に使用するパラメータを個体毎・起動毎個別の値を持つ事により、セキュリティを強化します。 （ルータ関連製品におけるUPnP機能のセキュリティー強化のお知らせ）

「UPnPの無効化」という対策以外に、「対策FW（=ファームウェア）」を入れて対策してください、ということになっています。ちょっとUPnPについて詳しくないので、詳しくどういう仕組みだか分かりませんが、セキュリティが強化されているようです。

いちよ、「MSN Messenger／Windows Messengerの音声チャットやIP電話機器など、UPnP機能によるネットワーク機器の操作を前提としているアプリケーション・機器は動作しなくなる可能性があります」と書かれており、「※どれを実施すればよいか解らない場合は 対策FWのアップデートを推奨致します。」とも書いてあるので、やはり困らないのなら「無効化が一番」ということだと思われます（Messengerが使えなくなった！などの混乱を避けるためかと）。

Allied Telesis（2008年10月）

本脆弱性はUPnPの仕様上の問題です。特定の実装に依存した問題ではありません。

第三者からの攻撃を受けるような環境下では、UPnP機能を無効にして下さい。

下記製品はUPnP機能をサポートしております。UPnP機能を有効にした場合、当該脆弱性に該当致します。尚、弊社製品の場合、UPnP機能はDefault(初期状態)で無効になっております。

第三者からの攻撃を受けるような環境下では、UPnP機能を無効にして下さい。

（サポート｜セキュリティ・脆弱性について）

いろいろ書かれていますが、「デフォルトで無効」「有効にしたら危険」ということのようです（第三者からの攻撃を受けるような環境←Flashを利用した攻撃もこれに含まれるかと）。

その他ベンダー

とりあえず見つけられたのはこのあたりです。これを見る限り、UPnPを無効化せずに攻撃をシャットアウトするような対策はなく、引き続きUPnPを有効にするのは危険であるといえそうです。

最近この話題に触れているサイト

最後に、最近この脆弱性に触れたサイトを探してみました。

HTG Explains: Is UPnP a Security Risk? : How-To Geek （2012年8月24日）

「HTG Explains: Is UPnP a Security Risk? - How-To Geek」

I can’t find any sort of indication that this was ever fixed. Even if it was fixed (this would be difficult, as this is a problem with the UPnP protocol itself), many older routers still in use would be vulnerable. （引用元）

やはり厳しそうです。

RAPID7 ホワイトペーパー

冒頭で紹介したホワイトペーパーですが、ここに特に注意書きもなくこの脆弱性が紹介されていたため、ちょっと未修正度UPです。

ただ、まぁそれはあまり参考にならないとして、このホワイトペーパーには、今回注目した脆弱性以外にも、UPnPの脆弱性発見の歴史が掲載されています。

結論2

以上のように2008年1月に発覚したFlashを使ったUPnPの脆弱性は、（Flashからの攻撃は防げた可能性があるものの、FAQにあったように仕様自体の問題で実装の脆弱性を突いた攻撃ではないため）未だに注意すべきものであると推測されます。

昨日のニュースの話からしたら本当にそもそも論なのですが、「結論1」でも述べたように、やはり「UPnPは無効化した方が良さそう」です。

それにしても、「あの脆弱性は今」みたいな感じで詳しい人のの話は公開されないのかなぁ。でも公開されたとして、「Flashの脆弱性はふさがれていました、以上。だから大丈夫」、とかだとまたややこしいことになりますが。

補足

前の記事の感想に「WAN側にUPnPを公開していなければ大丈夫そう」「大したことじゃなさそう」というのが見受けられましたが、それについては、「今回のニュースで取り上げられたWANから攻撃、というのは防げる。しかし、そもそもUPnPをLAN側から攻撃できる脆弱性があり、（調べた範囲では）解決したのかはっきりしていないので、それも含めると大丈夫じゃない可能性がある。だから、本当にUPnPが必要か考えて利用するべきかも。」とコメントしたいと思います。

追記A

というリプライをいただきました。このリプライによれば「ヤマハのルータがUPnPの一部のみ実装」というのは、「IGD (Internet Gateway Device） 用の仕様を実装した」ということを意味しているようです。

この仕様はUPnP IGDと呼ばれ、「Internet Gateway:2 » UPnP Forum」に仕様が掲載されています。

追記B（「この脆弱性の厄介さについて」の文章と「Flashの対策情報（2008年4月）」の文章からリンク）

「UPnPの設定変更をFlashから行うやつって今でも出来んのかという話」に、「Flashの対策情報（2008年4月）」の章で紹介したセキュリティアップデートについて書いてあります。やはり、このアップデートで、Flash経由での攻撃は塞がれたようです。

また、じゃぁ他の手段ならどうなのか、ということについても紹介されています。

なので、そういう穴があるんなら塞いだほうがいいし、UPnPに関してはブラウザで悪意のあるURLを開いただけ、では無理で
「もうちょい強い権限を持つアプリケーションからじゃないと変更できない」と考えてよさそうだ。 （引用元）

とりあえず重要そうなところを引用しましたが、詳細は引用元へどうぞ。

追記C

ちょっと思い出したので、ついでにひとつ記事を紹介しておきます。「Zlob.P - 身近に存在する DNS ポイズニングの脅威 | Symantec Connect Community」こちらはWebブラウザ経由の話ではなく（重要・誤解しないで）、Zlob.Pというトロイの木馬の挙動を紹介しており、途中でUPnPの機能を利用しています。手順が細かく書いてあって、雰囲気がつかめてなんだか勉強になりました。

追記D

GNUCITIZENのページを参考に、本文中に「例えば、DNSを書き換えられてしまう危険性があります」と記述しました。これは「UPnPのプロトコルを叩ける、ならば、DNSの設定を変更できる」と解釈できます。しかし実際には「UPnP対応デバイスだからといって、必ずしもDNSの設定を変更できるとは限らない」という理解が正しく、その詳細は「デバイスの実装次第」である、という解釈が正しいようです（参考：UPnP Hacks: IGD hacking）。ですので、例えば「ルーターがUPnPに対応しているから、DNS設定が書き換えられてしまう」という文があるとすれば、それは間違い、となります。

以下に、「実装次第」という話についての詳細を書いておきます。

UPnP Hacks: IGD hacking によれば、「UPnP」というプロトコルには複数のプロファイルが定義されていて、ルーターのようなInternet Gateway Device用に「UPnP IGD」というプロファイルが定義されています。そして、さらに UPnP IGD の中に、サブプロファイルがいくつか定義されており、そのひとつに「LANHostConfigManagement」というプロファイルがあるようです。このプロファイルに、DNSの設定を書き換えられる「SetDNSServer」「DeleteDNSServer」「SetIPRouter」「DeleteIPRouter」などのメソッドが定義されており、これを使うことで、DNSの設定が書き換えられるようです。

すると「UPnP IGDを実装しているルーターは、DNSの設定を変更できてしまうんじゃない？」となりますが、この件については、 UPnP Hacks: IGD hacking の該当箇所の最後にこのように記述されています。

However, in practice these methods are either not implemented, return an error when they are invoked or UPnP and DNS/DHCP/routing are not coupled to the UPnP system. It never hurts to check though. （引用元）

訳すと、「しかし実地では（実際のデバイスでは）、これらのメソッドは実装されていない（エラーを返す）か、もしくは、そもそも UPnPの機能 と DNS/DHCPなどのルーティングの機能 が分離されています。ただ、確認しておくに越したことはありません。（it never hurts to）」って感じになると思います。つまり、「DNSの設定をUPnPの機能から変更できるのか」は、「このプロファイルを実装しているかどうかという実装次第」のようです(サブプロファイルが定義されていることと、そのサブプロファイルが実装されていることとは別々に考えないといけない) 。

※この「実装による」という部分ついては、追記Bで紹介した文章中でも

もっとも「UPnPで出来ちゃう設定変更がどこまでなのか」とか「使ってるルーターの脆弱性」によっては、 （引用元）

と記述されていました。

参考


スポンサーリンク


「UPnP（libupnp）に脆弱性・WANから攻撃可能」という話の中身を調査してみた
Javaインストールを求める怪しいページの例
QRコードログイン機能を悪用したLINEアカウント乗っ取りの危険性とその成功可能性・ユーザー像について
家庭の無線LANが「WEP（ウェップ）」方式の暗号化を使っているか確認する方法

コメント（3）

  1. 通りすがり
    2014年6月7日(土) 17:10

    初めまして。
    某社製ルーターとセットになっていた安いプランでインターネット接続をしています。
    直結しているため無線機能を切るべく設定を確認していたところ、
    貴ブログのこの記事に書かれていた製品でファームウェアアップデート済ですが
    UPnPは有効になっていました。
    使用しているのは2012か2013頃から出ているもので、
    現在でもプロバイダによってはセット販売されています。
    周囲の使用状況を見るに、初期パスワード自体はセキュリティ度の高いものが設定されているため
    初期設定のまま他は設定画面すら見ずに使っている方の方が多そうです。
    会社名を書いてしまうのがどうかと思いますので伏せますが、
    会社側が対策していると書いていても結構対策されていないのでは…と思いました。

    余談ですが、説明書を分厚くしても読まない人が多いからか
    如何に簡単に設定するか、だけに重きが置かれていて
    詳細を確認するためにはネット接続必要、用語を見るにはネット接続必要、
    で本当にセキュリティというのは個々の勉強と判断なんだなあと思わされる次第です。
    一度は設定画面を見てみるよう促すのは会社側には面倒くさいんですかね…

  2. いやいやいやいや
    2014年7月28日(月) 03:37

    そもそも、FLASHが本当にUPNPなルータと通信できるかについて検証した形跡が無いんですが。
    できないでしょ。

  3. いやいやいやいや
    2014年7月28日(月) 03:40

    と思ったら追記Bに書いてあった。やっぱりもう安全なんじゃん。全然無効にすべきじゃないじゃん。

新しいコメントを投稿




スポンサーリンク