「UPnP（libupnp）に脆弱性・WANから攻撃可能」という話の中身を調査してみた

ニュースの情報源であるUS-CERTのページを見ると「libupnpの脆弱性」も「WANからSSDPメッセージを受け取ってしまう問題」も、昨年以前から指摘されていた問題のように読めました。すると、じゃぁどうして今日ニュースになって「脆弱性が見つかった」とか言われているんだろう、と気になってしまいました。

というわけで、そのUS-CERTのページを読んだところから、最終的にどうして記事になったんだろう的な部分までを、だらだらと書いておきます。正直細かいところは知識不足でわからないのですが、文章から読めたことから、いろいろ解釈していきました。詳しい人は、アドバイスお願いします。

複数の日本語サイト（ITmedia、INTERNET Watch、@IT）の情報源（直接的な翻訳元）は、「Vulnerability Note VU#922681 - Portable SDK for UPnP Devices (libupnp) contains multiple buffer overflows in SSDP」

この情報源の言ってることが分かりにくいのです。

まず真っ先に理解できることは、libupnp（1.6.18未満）にある脆弱性がバッファオーバーフローである、ということです。

multiple buffer overflow vulnerabilities in the libupnp implementation of the Simple Service Discovery Protocol (SSDP) （引用元）

この脆弱性については、「CVE-2012-5958」 「CVE-2012-5959」 「CVE-2012-5960」 「CVE-2012-5961」 「CVE-2012-5962」 「CVE-2012-5963」 「CVE-2012-5964」 「CVE-2012-5965」

しかし、これらの脆弱性はすべて「去年」発見されたものです。今さらニュースになる理由はなさそうに思えます。←末尾の追記A参照。

さて、この「libupnpの脆弱性」を使って攻撃するためには、UPnPの「SSDPリクエスト」をlibupnpを使用したルーターに「送りつけて」、libupnpに読み取らせる必要があります。

つまり、「SSDPリクエスト」を送りつけることができないなら、攻撃はできないわけです。

ですから、「WANから攻撃可能」というのはつまり、「SSDPリクエストをWAN側からルータに読み込ませることが可能」という状況が無いと発動しないわけです。

ここで、重要なのは「WAN側からのSSDPリクエストを受け付けるかどうか」という話です。「Vulnerability Note VU#922681」では、次に引用するOverviewの「accept UPnP queries over the WAN interface」から「Vulnerability Note VU#357851」へリンクされています。

Overview
The Portable SDK for UPnP Devices libupnp library contains multiple buffer overflow vulnerabilities(=脆弱性). Devices that use libupnp may also accept UPnP queries over the WAN interface, therefore exposing the vulnerabilities to the internet. （引用元）

この文章が、例えば@ITでは次のように翻訳されています。

libupnpを使ったデバイスは、WANインタフェース経由でUPnPを受け入れることもあり （引用元）

ITmediaの場合はこうです。

libupnpを使っているデバイスはWANインタフェース経由でUPnPクエリーを受け入れてしまう可能性があり （引用元）

「受け入れることもある」「受け入れてしまう可能性がある」→どういうこと？？？？？。

「libupnpを使っていたら、受け入れてしまうかも」と読めるわけで、「受け入れてしまう」原因が「libupnpにある」ように思えます。さらに、「こともある・可能性」という表現もよく分かりません。

さて、「libupnpの利用」と「SSDPを受け入れてしまうこと」に関連あるのでしょうか。それともこの読みは誤解なのでしょうか。まずここを確かめます。

というわけで、さきほどのCE-CERTが提示しているリンク先である「Vulnerability Note VU#357851」をチェックしてみます。

リンク先もUS-CERTのページなのですが、こちらのOverviewにはこう書いてあります。

Some Internet router devices incorrectly accept UPnP requests over the WAN interface. （引用元）

このページ全体を検索しても、「libupnp」という文字は出てきません。

説明にはこう書いてあります。

Some UPnP enabled router devices incorrectly accept UPnP requests over the WAN interface. "AddPortMapping" and "DeletePortMapping" actions are accepted on these devices. （引用元）

やはり「libupnp」の問題ではなく、「特定のルータ」の問題のようで、（libupnpに起因しない）ルータのファームウェアの問題のようです（Vendor Informationにこの脆弱性があるルータを扱っているベンダが書いてありますが、これがちょっと少なめ←あとでポイントになります）。

やはり、「libupnp」と「SSDPリクエストを受け取ってしまうこと」は無関係のようなのです。ここでは「受け取ってしまうこと」の原因を「特定のルータ」としているわけです。先ほどの「libupnpを使っているルータだからこそSSDPリクエストを受け取ってしまう」という解釈は「誤解」となります。

さて、今回のニュースでは「WANからのSSDPを受け取る」+「libupnpのバッファオーバーフロー」のセットで「危険」とされているのですが、実は、「WANからのSSDPを受け取る」ことだけで「危険」という話が書かれています。

さきほどの「Vulnerability Note VU#357851」のオリジナルの情報源として掲げてあるDaniel Garcla氏のホワイトペーパー「"Universal plug and play (UPnP) mapping attacks"」を読んでみました（全部読んだ）。ここに、その「危険性」の詳細が書かれています。

重要なのは「AddPortMapping」と「DeletePortMapping」というUPnPの機能を自由に使われてしまうことであり、これによってどこからどこへ転送するかの対応付け（port map）を書き換えられてしまうかもしれない、ということです。これを利用すると、特定のWAN側から来たパケットを特定のLAN内に転送する設定ができて、内部のネットワークを解析されてしまったり、WANからWANへの転送設定ができてしまったりすることで、攻撃の踏み台（プロキシ）にされてしまう危険性がある、としています。

allowing attackers to add a port map from the external WAN IP to any host desired.
The attacker can map a port on the external IP and forward that traffic to another external host. The attacker can also map external ports on the WAN IP to internal hosts behind the NAT of the device. This allows the attackers to scan for hosts inside the NAT, forward traffic to external hosts and forward traffic to internal hosts.

じゃぁ、そもそも「なんでWAN側から来たUPnPリクエストを受け取ってしまうのか」という話ですが、これについてはこのように書かれています。

Some routers, have an open control point by default. In fact, some routers keep accepting UPnP requests after disabling UPnP WAN requests.

つまり、「初期設定」だったり、「無効にしても受け取ってしまったり」を原因としています。また、このPDFのAbstractにはこんなことも書かれています。

Devices with WAN ports allowing UPnP actions are the minority, but still a big threat.

「WAN側からのUPnPメッセージを受け取るデバイスは少数派」としています。

ここまでで、WAN側からUPnPのメッセージを受け取ることの危険性や、WAN側からUPnPのメッセージを受け取ってしまう原因が分かったかと思います（詳細については疑問点もあり）。

しかし今回大事なのは、今回ニュースで取り上げられている「Vulnerability Note VU#922681」の冒頭で紹介されていた「Vulnerability Note VU#357851」が、１年以上前（2011年10月）のページであるということです。

やはりこの点についても、新しい情報はないので、ニュースになるきっかけにならないのです。

一番印象的な「UPnP（libupnp）の脆弱性」は前からいくつもあった、という話でした。そして、WANから攻撃可能である"根拠らしき"「WAN側から接続可能」というのも前から問題になっていました。

ここまで調べて「ではなぜ今回取り上げられたのか」、ちょっと分からなくなってしまったのです。

追記A：このRAPID7のホワイトペーパーにlibupnpの脆弱性の発表が含まれていた説が自分の中に表れたので、訂正しておきます。1/29にあったことは、「RAPID7のホワイトペーパーの公開（脆弱性の発表を含む）」「libupnpのセキュリティアップデートの公開」だと思われます。ただし、このホワイトペーパーが最大の情報源であり、重要性は変わりません。また、脆弱性についての説明が置き換わることではありません。（末尾にも追記しました）

追記Aにより、以下も打ち消し線を付けておきます。

なので、「脆弱性が見つかった！」というニュースの見出しだと、US-CERTのページを見る限り、「それって、だいぶ前の話じゃない？」ってなるのですが、実際にニュースの見出しがそうなっているので、ややこしいというか、ここまで理解するのに時間がかかりました。

１月２９日に起こったことは、「Rapid7のホワイトペーパーの公開」なのです。

ではそこに何が書いてあるのか。

このホワイトペーパーはやたら詳しいのですが、まず

がポイントで、さらに

というのもポイントです。この文章の「Research Result」にはこう書いてあります。

This paper is the result of a research project spanning the second half of 2012. The goal of this research was to quantify the number of UPnP-enabled systems that expose the SSDP service to the internet, determine how many of those also exposed the SOAP service, and identify security weaknesses in the most commonly used UPnP implementations.

つまり、今回のニュースでは、これらの発表の内、特に「quantify the number of UPnP-enabled systems that expose the SSDP service to the internet（インターネット側（WAN側）からのSSDPリクエストを受け入れてしまうように設定されたUPnPデバイスの数を測定してみた）」の部分に特化したタイトルとOverviewがUS-CERTの「Vulnerability Note VU#922681」に掲載され、それを元にニュースが書かれたようなのです。

ホワイトペーパーのSummaryにこんな段落があります。

The UPnP protocol suffers from a number of basic security problems, many of which have been highlighted over the last twelve years. Authentication is rarely implemented by device manufacturers, privileged capabilities are often exposed to untrusted networks, and common programming flaws plague common UPnP software implementations. These issues are endemic across UPnP-enabled applications and network devices.

やはり、「UPnPライブラリの脆弱性や、WAN（のような信頼できないネットワーク）からのSSDPを受け付けてしまう問題は前々から知られていた」のであって、「脆弱性発見！」というより、「脆弱性の危険がこれだけ大きいことが発覚！」という話のようです。

ここからがちょっと難しいのですが、おそらくこの調査によって、いろいろなベンダーのいろいろなルーターが、SSDPリクエストのパースに脆弱性のあるlibupnpを使っており、実際にSSDPを受け取る状態でインターネットに公開されっぱなしになっていたよ！というのが分かったため、一斉に「Vendor Information」に（脆弱性情報として）それらが発表された、ということのようです。

おそらく、「libupnpの問題は分かっていたけれど、実際にその問題があるバージョンを使っている製品がこんなにたくさんあったの見つけちゃったよ」→「脆弱性情報」という流れのように読めます。

つまり、「libupnpの脆弱性」が見つかったのではなく、「脆弱性のあるバージョンのlibupnpを使っている製品が、危険な状態で、しかも大量に公開されていること」が見つかった、というのが実際にニュースっぽいです。

あまり詳細にRapid 7のホワイトペーパーを読めていませんが、これを読むのが一番今回のニュースに詳しくなる手段のような気がします。

ここまでいろいろ調べて、一番問題なのは「WAN側からのUPnPメッセージを受け取るように設定されていること」だとわかりました（もちろんlibupnpのバッファオーバーフローも危険なのですが、RAPID7の調査的にも）。一見libupnpを最新版にすればいいような気もしましたが、そうでなくても、LANの情報が読み取られてしまう問題などもあり、UPnP、特にSSDPのポート(1900/UDP)を信頼できるネットワーク以外に公開してはいけないということがわかりました。

なので、WAN側にUPnP用のポートを公開していなければ、問題はないということがわかります。そうすると、「家庭用の、市販のルータはどうなの？」と思うのですが、たいていの場合、UPnPを使っていても、WAN側にSSDPを受け取るポートを公開していたりはしないんじゃないかなぁ？と思います。

※ホワイトペーパーで家庭のユーザは、UPnPを無効にしましょうと書いていたりします。

Home and mobile PC users should ensure that the UPnP function on their home routers and mobile broadband devices has been disabled.

※※一方で、RAPID7のブログのコメント欄には、こんなことも書かれています。

So long as the UPnP interface is not exposed to the external network, you are probably fine. （引用元）

↑「UPnPインターフェースを外部ネットワークに公開してしまっていなければたぶん大丈夫だよ」

私も気になったBUFFALOに電話してみたのですが、いつまでたっても「大変混雑しております」状態から抜け出せず、携帯電話からかけて料金がばかばかしいと思ったので、途中で諦めてしまいました。

この点CNET JAPANの記事（CBS Interactiveの記事を朝日インタラクティブが日本向けに編集したもの）は、しっかりと「１月２９日」に発表されたRapid7のホワイトペーパーを中心に記事を書いています。「何があったのか」分かりやすいと思いました（いろいろ調べてから分かりやすさが分かった的な）。

SSDPとかUPnPに詳しかったりはしないので、とりあえず引用を多めにして、資料をたくさん載せてみることにしました。解釈が間違っているかもしれません、気になったら情報元を読んでみてください。

確認のためにもう一度書いておきます。「WANから攻撃可能」というのは、結局WAN側にUPnP（SSDP）が使うポートを公開した場合（当然設定ミスも含む）、「libupnpの脆弱性が使われてしまって危険」という意味のようです。ただ、Vulnerability Note VU#357851のように、本当にルータの不具合で公開されてしまう場合もあるっぽい。

libupnpのバッファオーバーフロー脆弱性に対応するCVEの情報ページ（cve.mitre.org）を見たところ、内容の掲載がありませんでした。このことから、libupnpの脆弱性は昨年発見されていて、報告されてCVEの番号が割り当てられていたものの内容は発表されておらず、今回libupnpのアップデート公開を機に「脆弱性の情報」を含んだ「RAPID7のホワイトペーパー」を公開した、ということのようです（脆弱性の扱いに詳しいわけではありませんが、そういうことではないかと）。ですので、「脆弱性が発見された」というニュースの見出しは間違っていないと思われます。

今回の「WANから攻撃される」という脆弱性については、WAN側に公開しなければいいという話でしたが、じゃぁUPnPを使って大丈夫なのか、といえば、以前から指摘されている脆弱性を検討する必要があるようでした。それについて書きました。

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

参考：

The security company (←RAPID7のこと) examined the source code of these two tools and found eight vulnerabilities （引用元）

Rapid7 worked with CERT/CC to coordinate the disclosure process (←脆弱性公開の手続き、という意味かな). CERT/CC reached out to the libupnp project along with other regional CERT teams to notify affected vendors. Version 1.6.18 of libupnp has been released and corrects the vulnerabilities identified in this paper. （RAPID7のWhite Paperより）

ここがメインコンテンツっぽい。

事の発端（VU#922681）

• Vulnerability Note VU#922681 - Portable SDK for UPnP Devices (libupnp) contains multiple buffer overflows in SSDP
• Ciscoのページ：Article

RAPID7のホワイトペーパー関連

• ホワイトペーパーの公開ページ：Whitepaper: Security Flaws in Universal Plug an... | SecurityStreet
• RAPID7のブログ記事：Information Security: Security Flaws in Univers... | SecurityStreet（ブログ記事）
• ScanNow for UPnP：自分の環境にUPnPの脆弱性に関する問題がないかチェックするツール（Windows専用）：ScanNow for Universal Plug and Play (UPnP) | Rapid7
• Millions of devices vulnerable via UPnP - The H Security: News and Features

libupnpのバグ関連

• CVE-2012-5958
• CVE-2012-5959
• CVE-2012-5960
• CVE-2012-5961
• CVE-2012-5962
• CVE-2012-5963
• CVE-2012-5964
• CVE-2012-5965

UPnPのポートを外部に公開する危険性について

• Vulnerability Note VU#357851 - UPnP requests accepted over router WAN interfaces
• Universal plug and play (UPnP) mapping attacks
• A Fox in the Hen House UPnP IGD http://www.blackhat.com/presentations/bh-usa-08/Squire/BH-08-Squire--A_Fox_in_the_Hen_House_UPnP_IGD_v1.1.0.pdf
• UPnP Hacks: IGD hacking
• UPnP Info Q&Aが詳しい