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

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

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

UPnP (2) セキュリティ (62) 脆弱性 (4)

「UPnPに脆弱性が見つかり、危険だ」というニュースがいろいろなWebサイトに掲載されていますが、例によってまた何言ってるかよく分からない部分が多かったので、調べたことを書いておきます。

概要

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

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

日本語サイトの情報源

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

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

「libupnpの脆弱性」は「UPnPパケットを使ったバッファオーバフロー」

まず真っ先に理解できることは、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参照。

「WANから攻撃可能」というニュースの意味

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

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

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

「WANからのSSDPリクエストを受け付ける」ルーターとは?

ここで、重要なのは「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」をチェックしてみます。

「libupnp」と「SSDPリクエストを受け付けてしまう脆弱性」の関係について

リンク先も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を受け取ること」自体の問題

さて、今回のニュースでは「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」が、1年以上前(2011年10月)のページであるということです。

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

何があったからニュースになった?

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

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

1月29日にあったこと

実は、一番重要なのは、「Rapid7が発表したホワイトペーパー」だったのです。この発表が1月29日(現地時間)にあったから、ニュースになったようなのです。

しかし、US-CERTの「Overview」には、先ほどの「バッファオーバーフローの話(去年以前)」と、「WAN側からのUPnPのメッセージを受け取る脆弱性(1年以上前)」が関連づけられていて、ホワイトペーパーはサブ扱いに見えてしまいます。実際に@ITでも

US-CERTは1月29日、Portable SDK for UPnP Devices(libupnp)の脆弱性情報を公開した。それによると、libupnpでSSDPリクエストを処理する際に問題があり、バッファオーバーフローの脆弱性が複数存在する。libupnpを使ったデバイスは、WANインタフェース経由でUPnPを受け入れることもあり、インターネットから脆弱性を悪用される恐れがあるという。

のように、US-CERTの文章を引きずってこの2点に注目しており、Rapid7のホワイトペーパーについてはサブ扱いです。

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

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

本当のニュースは「Rapid7のホワイトペーパー」の公開

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

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

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

ホワイトペーパーの中身

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

libupnpのバッファオーバーフローを新しく発見したわけではない(全て2012年に発見済みの物)

がポイントで、さらに

脆弱性は「libupnp」「MiniUPNP」「SOAP API Exposure」の3つを紹介していて、libupnpだけの話ではない

というのもポイントです。この文章の「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インターフェースを外部ネットワークに公開してしまっていなければたぶん大丈夫だよ」

バッファローとかNECとかの家庭用ルータはどうなの?

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

ちなみにcnet JAPANに載っていた記事は

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

ひとこと

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

確認

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

追記A(2013-01-31 11:00頃)

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

追記B(2013-01-31 09:00頃)

今回の「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)

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

libupnpのバグ関連

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

コメント(0)

新しいコメントを投稿




  • カテゴリ ナビ
  • 著者紹介

    ブログが趣味で、 月間1,000万PV を達成しました。

    自分が困ったことをブログに書けば、次に困る人の参考になって、みんながみんな同じ苦労をせずに済む、というのが原点です。

    最近の関心は、スマホやパソコンに詳しくない人の行動や思考、 そしてそんな人を手助けする方法や枠組み。 また、それに関連するような、"身近な"セキュリティ。

    ※SNS(特にTwitter)でシェアされた記事は、内容の追加・更新を行っています。 必ず、ではありませんが、気に入った記事は積極的にシェアしてみてください。

    RSS | Facebook | Twitter | About