2011年7月アーカイブ

アメーバのログインを盗聴されると、暗号化パスワードが盗まれただけで、アカウントにログインされてしまうことがわかりました。
この状態で、アメーバでのほとんどのサービスを利用できるようになります。

では、ここで、登録情報の書換を行って、パスワードやメールアドレスを書き換えてしまうことで、完全にアカウントを乗っ取ってしまうという考えが浮かびます。

さっそく実験してみましょう。

セッションハイジャックを行いログインします。
その状態で、マイページの右上にある「パーソナルセキュリティ研究所さんの登録情報」のボタンをクリックします。

すると、ここで再度ログイン画面が表れました。

ところが、今度のログインはSSLのログインです。
ログイン情報を、WebTasterでフックしてみましたが

amebaId=psec-net
&password=1234

このように、MD5でハッシュ化されない、そのままのパスワードが送信されています。

ということは、ここでは元のパスワードが無ければ先にすすむことができません。
そして、通信はSSLの暗号化なので、盗聴によって元のパスワードを盗むこともできません。

これは、これで良いことです。
ある意味、正しいログインのさせ方でしょう。

しかし、ふと思います。ひょっとして、こうなっているということは、

アメーバ運営サイドは、ログインが盗聴によって簡単にセッションハイジャックされることを知っている。
その上で、アカウントの完全乗っ取りの対策だけを施してある。

ということでしょうか。

アメーバのハッシュパスワードによるハイジャックが面白かったので、他にもSSLを使わずにログインさせるサービスを探してみました。

SNS大手のmixiのログイン画面をみると、

ありました、ありました！

"ＳＳＬ（ｈｔｔｐｓ）はこちら"　と書いてあるということは、
何も考えずに普通にログインすると、ＳＳＬではなく暗号化されない状態でデータが飛びそうです。

アメーバは、この場合にパスワード自体をＭＤ５で暗号化して送信していましたが、mixiはどんな処理をしているかなっと．．．．．

なんと、mixiのログインは、暗号化しないパスワードをそのまま送信することが標準になっています

mixiのパスワードは丸見え！　なのです。

確かに、ＳＳＬでのログインが用意されてはいますが、一般の人は、その意味もよく分からず、デフォルトのログインを使うことでしょう。

大変危険なログインだと言えそうです。

mixiユーザのみなさん、必ずＳＳＬログインを使いましょう。

そうしないと、アメーバのケースとは違い、完全にアカウントを乗っ取られます。

管理人がいろいろなサービスのログインパスワードを見てきた結果、アメーバやmixiなど、日本の急成長したＩＴサービスのログインにおいて、ＳＳＬを使わないのではないか、という疑問が出てきます。

我々は、ＳＳＬも用意してますよ。
もし、セキュリティが気になるなら、ＳＳＬをお使いください。
選択すればＳＳＬが使えるんだから、これでいいでしょ。

とうスタンスに見えるのです。

これに対して、

海外の有名サービス、facebook、youtube、twitter、googleなどなどは、標準でＳＳＬを使っており、ユーザが特に意識をしなくても、そのパスワードは保護されています。

管理人の予想では、ＳＳＬのサイト構築の方がトータルコストがはるかに高く掛かるため、ユーザー数が爆発的に増えていっているmixiやアメーバなどは、まずは、ユーザーのセキュリティを犠牲にしてでもキャパを増やし、金儲けをする、こんなとこなのでしょうか。

みなさん、日本の新しいサービスを利用するときには、充分注意し、意識してＳＳＬを使いましょう。
無線LANが多用される現代では、盗聴やセッションハイジャックは身近な問題なのです。

こうなると、次ぎに気になるのが大ブレイク中のGREEのログインですが．．．．

明日は、GREEを調査してみましょう。

イケイケＩＴベンチャーのサービスはＳＳＬを標準で使わず、サーバのコスト削減および負荷軽減を図っているのではないかと、疑惑が湧いたので、最近、話題のGREEをWebTasterで調査してみます。

まず、GREEのログイン画面です。

おおお、入力枠のタイトルが"ログイン（ＳＳＬを利用する）"となっています。
さすがGREEのログインは、ＳＳＬ標準のようです．．．

と、思って、（ＳＳＬを利用する）にマウスを持って行くと．．．アンダーバーが表れました。

"ログイン（ＳＳＬを利用する）"

なんと、一見わかりませんが「ＳＳＬを利用する」というリンクボタンになっているのです。

通常、リンクなら色を変え、アンダーバーを表示しますし、ＳＳＬをユーザに促すなら、「ＳＳＬの利用はこちら」等の表記の方が親切です。さらに、これが"（　）"の中に書かれて、ログイン方法を補足しているように見せていることも不自然です。

この画面の表記は、管理人には、"ＳＳＬを利用したログインですよ"と読み取れます。
ＳＳＬを予想させるものを装っていて、ほぼ詐欺に近い状況ではないでしょうか。
実際にＳＳＬを利用するには、「ＳＳＬを利用する」をクリックして、別のＳＳＬログイン画面に移動しなければなりません。

管理人の推測では、確信犯ではないでしょうか！
やっぱりイケイケＩＴベンチャーは、ＳＳＬを標準にしないようです。
それどころか、それを装っているとは、何と恐ろしい。

GREEを利用しているみなさん、ＳＳＬログインだと思っていると、パスワードが丸見えで飛んで行くのです。

実際に、WireSharkで盗聴したパケットがこちらです。

リンクだとは分かりにくいですが、ログイン（ＳＳＬを利用する）の「ＳＳＬを利用する」をクリックしてからログインすることをお忘れなく。

GREEのＳＳＬ詐欺にかなり衝撃を受けたので、もうちょっとGREEを調査してることにしました。

パスワード観察の範囲を若干逸脱してはいますが、GREEのユーザーの新規登録を行ってみます。

必要な項目は、名前、携帯メールアドレス、パスワード、生年月日、性別などのいわゆる個人情報です。

何気に、下にある「登録を確認（無料）」ボタンにカーソルを持っていくと、ステータスバーに"http:gree.jp/"と表示されました。

まさかの"http"です。暗号化のＳＳＬ通信なら"https"になってなければなりません。

このリンク表示だけが、httpになっているのかもしれないので、WireSharkで、盗聴しながら、登録を行ってみました。

なんと、個人情報の送信がＳＳＬでなく平文で、パスワードまでが丸見えです。

近年になって、個人情報の送信にＳＳＬでない暗号化なしの通信を使っているところがあるとは絶句です。

正直言って、この会社のＣＳＲ経営自体に疑問が残ります。
GREEの新規登録には、なんとＳＳＬのオプションも発見できませんでした。

GREEへの新規登録は、どうしたら安全なのか。。。

GREEさん教えてください。

GREEの暗号化なしの個人情報登録には、かなり度肝を抜かれました。
しかし、イケイケＩＴ企業が、こぞってＳＳＬを標準で使わないということは、相当の費用負担が発生することを表しているのでしょうか。
思い出してみれば、YAHOO!だってamazonだって、少し前までＳＳＬが標準では無かったという記憶があります。
GREEのような個人情報登録でＳＳＬを使わない例は、見たことがありませんが、ログインの標準がＳＳＬでないというのはよくあることです。

本来、すべての通信をＳＳＬ（暗号化）にすれば、ずっとセキュアなのですが、これはやはりサーバ側のコスト（負荷）がかかり過ぎます。

最近の主流としては、

• 会員登録　　ＳＳＬ（暗号化）
• ログイン　　　ＳＳＬ（暗号化）　←イケイケＩＴはここがＳＳＬ標準ではない
• ログイン後　　平文
• 支払い　　　　ＳＳＬ（暗号化）

概ね、こんな具合に使い分けられています。

もし、あなたの通信を誰かが盗聴していたとすると、ログインまでは見えませんが、その後のサービス利用は、覗かれてしまうことになります。

一般に、ユーザーがログインしたあとは"クッキー"という仕組みを使って、アクセスしているユーザーが誰かという識別を行っています。
前述のように、サービスの利用は暗号化されていないことが多いので、この"クッキー"というデータも盗聴されることがあります。
というより、サービス提供側は、これが盗聴される可能性があること知っていて、その上でシステムを設計しなければなりません。

次回からは、このクッキー盗聴によるセッションハイジャックの実験を行っていきます。

実験を行うに当たって、他人の識別符号を使ったり、サーバのセキュリティホールを利用したりすると、不正アクセス禁止法に抵触し、逮捕されてしまいますので、あくまでも自分のアカウントの範囲で実験を行います。

当研究会の実験では、ブラウザとしてGoogle ChromeとWebTaster、パケット盗聴用としてWireSharkを使ってみます。

実験で調べるポイントは大きくは２つです。

1. クッキー盗聴で他人がログインできてしまうか
2. その他人が、買い物だできたり、パスワードの変更ができたりと重要な操作が可能かどうか

※クッキーによるセッションハイジャックは、想定外の不正アクセスではありません。ですから、システム設計側は、ユーザを保護する意味でも、セッションハイジャックされた場合でも、ユーザの重要な情報にアクセスさせない仕組みが作られているかが肝になります。

＜方法＞

1. まず、Chromeを使って、会員制のホームページにログインします。
2. ログイン後に、ホームページ内のサービスを利用してみます。
3. その時のパケットをWireSharkで盗聴し、クッキー情報を取得します。
4. WebTasterを起動し、同じホームページに行きます（ログインしていません）
5. WebTasterのクッキー情報を盗聴したクッキー情報で改竄します。
6. この状態でログイン状態になってしまうか？
7. ログインできてしまったなら、Webメールの読み書き、パスワード変更、買い物などユーザーにとって操作されるとても困るであろう操作が、できてしまうかをテストします。
   

まず、Chromeを使って、ＳＳＬを利用しmixiにログインします。
これにより、ログインのパスワードは盗聴されません。

mixi利用中の通信パケットをWireSharkで盗聴し、クッキーを取り出します。

WebTasterでmixiにアクセスします（ログインしていない状態）

WebTasterでクッキーを盗聴したものに改竄します。

再度、mixiのトップページにアクセスすると、

見事にセッションハイジャック成功です！

次ぎにメッセージを読めてしまうか

これも見事に成功です。
セッションハイジャックで、メッセージが読めました。

それでは、パスワード変更ができてしまうか。これは重要です。もし、セッションハイジャックされて、パスワードを変更されてしまえば、本当のユーザーがログインできなくなります。

早速、設定変更から、パスワード変更へ

おっと、さすがにここでは、オリジナルパスワードによる認証が表示されました。
しかも、この部分はＳＳＬで暗号化されているようです。

その他、ユーザーの情報へのアクセスはほとんどできるようですが、設定変更に関してプロテクしてありました。いずれにせよ、完全に本人として振る舞うことができてしまうということが分かります。

このクッキー盗聴によるセッションハイジャックは、ほぼ防ぐことができません。

今日は、クッキー盗聴によるセッションハイジャックで、アメーバピグができてしまうかを実験してみます。
セッションハイジャックの方法は、前回とほぼ同じです。

1. まず、Google Chromeで、アメーバにログインし、アメーバを使います。
2. その状態の通信パケットをWireSharkでパケット盗聴し、そこからクッキーの情報を取得します。
   

3. WebTasterでアメーバのサイトにアクセスします。この状態では、当然ですがログインしていません。
4. WebTasterのクッキー改竄機能で、盗聴し取得したクッキーデータを書き込みます。
   

5. そのままWebTasterでアメーバを使ってみます。
6. さらに、アメーバピグも使ってみます。

結果は．．．．

見事、アメーバピグを自由自在に扱うことができました。
パスワードが取得できなくても、利用しているネットワークパケットが盗聴されると、完全にセッションハイジャックできるのです。

アメーバの場合、登録情報の確認や修正にアクセスするには、再度パスワードが求められる仕組みになっていて、そこをセッションハイジャック対策の砦にしているようです。

セッションハイジャックされたアメーバピグは、アメＧの利用から、何から何までフルアクセス可能でした。
アメーバを利用しているパケットを取得されると、自由自在に他人に利用されてしまうのです。

防衛方法は．．．．これなら大丈夫というものはありません。少なくとも自宅以外の公共の場でアメーバを使ったり、無線（暗号設定の甘い）を使っていると、セッションハイジャックができてしまいます。

クッキーによるセッションハイジャックの説明をしてきましたが、いまひとつクッキーとか、セッションハイジャックの意味が分からないという問い合わせが何通も着ましたので、分かりやすい例えで、イメージを説明したいと思います。

＜イメージ例＞
会員制の遊園地があることを想像してみてください。

1. 会員登録（個人情報登録）
   あなたがその遊園地に行くためには、まずメンバー登録をしなければなりません。
   申込書に、住所、氏名、年齢、職業、電話番号などの個人情報を書き込み、申込みをします。そして、あなたの会員証（会員番号：ＩＤが書いてある）と、利用する為のパスワードを発行してもらいます。
2. ログイン
   さて、遊園地に遊びに行く日です。
   まず、入場受付に行き、会員証を見せ、パスワードを書き込み本人確認をしてもらいます。
3. クッキー受け取り
   そして、入場料を支払い、手首に巻き付けるワンデーパスを受け取ります。
4. クッキー利用
   そのワンデーパスを手首に巻いて、１日自由に遊園地で遊びます。

ここで言う、ワンデーパスがクッキーに相当するものなのです。
ワンデーパスは、パスワードや個人情報とは違って、隠すものではありません。見せるものです。
つまり、クッキーによるセッションハイジャックというのは、「他人のワンデーパスを盗み見して、そっくりなものを作って、遊園地に入場する」という行為に当たるでしょう。この方法なら、他人の会員番号やパスワード知らなくても、遊園地に入場ができるわけです。

クッキーによるセッションハイジャックの対策として、とてもシンプルで重要なことがあるのを忘れていました。

サービスを使い終わったら必ず「ログオフ」する

このことがとても重要です。
正しく設計されているシステムでは、ログオフをクリックすることで、今まで使われていたクッキー情報が無効化されますので、盗聴されたクッキーによるセッションハイジャックの心配がなくなります。

しかし、システム運用会社や設計会社により異なります。
手短にテストしてみた結果では（詳細テストは未だです）
mixiはログオフすると、クッキーが無効になりましたが、アメーバはなりませんでした。
しかし、使い終わったらログオフするという習慣は重要です。

みなさんがネット買い物をするサイトの定番にアマゾンがあります。
日常的に使うショッピングサイトなので、アマゾンのハイジャックについて実験してみましょう。
環境は、これまでの実験と同じです。

まず、Google Chromeでアマゾンにアクセスし、アカウントにログインします。
この時、アマゾンはＳＳＬが標準になっていますので、盗聴される心配はいりません。

ログインが完了したら、アマゾンで商品を検索し、カートに入れます。
残念ながら、この時は他のネットサービスと同様にＳＳＬを使っていません。
つまり、クッキーがネットワークや無線ＬＡＮの盗聴によって盗まれる可能性があります。

ハイジャック対策として、念の為に、Google Chromeでアマゾンからサインオフして終了します。

ここまでが、ユーザーの行動です

－－－－－－－－－－－－－－－－－

ここからがハッキングの実験です。

ハッカーがWire Sharkを使い、ネットワーク盗聴して盗み取ったクッキーはこれです。

次ぎに、WebTasterを使って、アマゾンにアクセスします。
サインインする代わりに、先ほど盗聴したクッキーで改竄をおこないます。

さあ．．．どうか

セッションハイジャック成功です。

商品をカートに入れて、買い物に行ってみます。

ここでパスワード認証の画面が出てきました。
アマゾンの場合には住所やクレジットカード情報を登録していることが多いサービスなので、少し心配しましたが、個人情報の表示の前で、認証がかかっていました。

どうやらこのように、セッションハイジャックは黙認で、個人情報アクセスが行われる前で、再認証するというのが標準的に行われている手法のようです。

日本のＩＴベンチャーには、パスワードにＳＳＬを掛けないところが見られました。
やはり最終の防衛手段はパスワードになりますので、かならずＳＳＬログインを使うようにしましょう。

昨日、アマゾンのセッションハイジャック実験をしました。
個人情報へのアクセスや購入においては、ＩＤとパスワードを求める画面ができるので、それほど重大な被害はなさそうです。

しかし、その後の実験でセッションハイジャックしたアカウントで、「アカウントサービ」へ移動してみると、

なんとサインインボックスにメールアドレスが表示されています。

パスワードはブランクでサインインはできませんが、そのアカウントのメールアドレスは盗まれる可能性があります。

メールアドレスだけなら良いのか、悪いのか．．．
できれば、メールアドレスも隠して欲しいものです。

アマゾンを利用するときは、捨てメールアドレスの方が良さそうです。

クッキーによるセッションハイジャック実験をする時に、WireSharkで盗聴するパケットが多すぎるので、クッキー盗聴専用のフィルターを作ってみました。
これだと、GETとPOSTのパケットだけが収集できます。

tcp[tcpflags] & (tcp-push) != 0 and tcp dst port 80
  and (tcp[20:4]=0x47455420 or tcp[20:4]=0x504f5354)

WireSharkで取得したデータのCookies:の行を選択し、右クリックでCopy→Byte(Printable Text Only)とすると、テキストデータでクッキーを取り出せます。

後は、このデータをセミコロン（；）区切りに改行すると、WebTasterのクッキー書換ダイアログで利用することができます。

管理人が利用しているYahoo!メール、これをクッキー盗聴でセッションハイジャックする実験を試みてみます。

Yahoo!メールのログインは、ＳＳＬになっていますから、パスワードが盗聴されることはありません。

いつものように、Google Chromeで、Yahoo!メールにログインし、これを使っているところをWireSharkで盗聴します。
次ぎに、WebTasterで、Yahoo!メールのページに行って、そこで盗聴したクッキーを使って、クッキーを改竄します。ただし、Yahoo!メールの場合は、予めログインしておかないと、Yahoo!メールのサーバにアクセスできません。まず、WebTasterを使って、Yahoo!に行き、まずは、自分のアカウントでYahoo!メールにログインします。

その状態で、盗聴したクッキーで改竄を行う実験をしました。

結果は、

セッションは切断されました。
ハイジャックはできません、失敗です。
しかし、アカウント名およびメールアドレスは、表示されているのが分かります。

Yahoo!メールも盗聴によって、アカウントIDおよび、メールアドレスの漏洩は防げないようです。
また、Yahoo!メールは、ＳＳＬを使っていませんから、読み出したメールの本文、内容などは、盗み見される可能性がありますから、盗聴の危険性がある場所(無線ＬＡＮ、学校、会社など）では、利用しない方が無難です。

今日は、GMailのクッキーによるセッションハイジャックをテストしてみます。
WireSharkでHTTPをネットワーク盗聴しながら、Google ChromeでGMailを操作してみます。

何も盗聴できません。
GMailのアドレスバーを見てみると、

HTTPS（SSL）になっています。
GMailは、メールアクセスの全てが暗号化されて通信されているのです。

今まで見てきた日本のイケイケITベンチャーとは違いますね。
この状態を見る限り、無線LANが標準になってきた今のネット環境では、ＧＭａｉｌを使うのが安全そうです。

下記のようなネットバンクの不正利用に対する注意喚起のメールが横浜銀行から着ました。

どうしても、パスワードの盗み出しはキーロガーで行われると決めつけたいのでしょうか。

管理人が何度も説明しているように、
PCの中に不正なプログラムが浸入してしまった場合、ソフトウエアキーボードは対策になりません。キーロガーよりも簡単に、正確にパスワードは盗み出されます。

当研究会のデモプログラム、「パスチラ」を試してみれば、パスワードがすぐに盗み見できることがわかります。

大手SIさん（NTTDATAかな）、銀行さん、古い手法への対策だけをユーザーに教えて、やみくもに安心を与えるのは、罪だと思いますが。

（以下メール）

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

◆◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◆
　【重要なお知らせ】
　　インターネットバンキングの不正利用にご注意ください

　　　　平成23年7月21日　　株式会社横浜銀行 http://www.boy.co.jp/
◆◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◆

　最近、不正なサイトへのアクセスによりウィルスに感染する等、お客さまの
　パスワードや暗証番号が不正に取得され、不正な振り込みがおこなわれる
　事件が発生し、問題となっています。

　お客さまにおかれましては、以下のセキュリティ対策のご確認とご対応を
　あらためてお願い申し上げます。


　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　セキュリティソフトは導入されていますか？
　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

　●インターネットバンキングをご利用のパソコンには必ずセキュリティソフト
　　の導入と、最新版へのアップデートをお願いします。
　　また、定期的に正常に動作していることをご確認ください。

　●セキュリティソフトを導入されていない場合は、不正に利用されるリスクが
　　高いため、パスワードを変更するか、都度指定振込利用停止機能等を
　　利用して振込取引を制限してください。

　●パスワード入力時には入力欄への直接入力を避け、ソフトウェアキーボード
　　を利用してください。

　●セキュリティソフトを導入されている場合も、ワンタイムパスワード等の
　　複数のセキュリティ機能を組み合わせてご利用ください。

今日は、Twitterをクッキー盗聴によりセッションハイジャックする実験です。
いつものように、Google Chrome、WireShark、WebTasterを使って実験を来ないます。

WireSharkで、ネットワークを盗聴している状態で、Google Chromeを使ってTwiterにログインし、いろいろと操作をします。
次ぎに、WebTasterでTwitterに行き（ログイン前）この状態で、クッキーデータをWireSharkで盗聴し収集したTwitterのクッキーデータに改竄します。

され、ログイン画面が表示されました。
セッションハイジャック失敗です。
Twitterは、クッキーでは、セッションハイジャックできないのか．．．

もう一度実験します。
そういえば、前の実験では、ログインのときに
□保存する
のチェックボックスにチェックを入れていなかったので、保存をチェックします。

再度、クッキーを取得し、WebTasterでクッキーを改竄すると、

おおお、大成功！
つぶやきもできてしまいました。

ちなみに、Twitterの場合は、設定の中に

「HTTPSを常時使用する」

というのがあります。少し重くなりますが、これをチェックして利用すると、盗聴問題は回避できます。

いままで、いくつかのＩＴサービスのログインやセッションハイジャックなどのセキュリティをテストしてきました。
これらをユーザーの安全性の視点で、まとめて行きたいと思います。

こんな項目でランキングをつくってみようと思います。
[ ] 内の数字は、管理人の独断と偏見による得点。

１.ログイン

標準でＳＳＬ[2]
オプションでＳＳＬ[0]
ＳＳＬなし[-3]

２．個人情報送信

標準でＳＳＬ[2]
オプションでＳＳＬ[0]
ＳＳＬなし[-3]

３．サービス利用時

標準でＳＳＬ[3]
オプションでＳＳＬ[2]
ＳＳＬなし[0]

４．個人情報アクセスで再認証要求

求める[2]
求めない[-1]

５.クッキー盗聴、セッションハイジャック（SSLでない場合）

ログインできない[3]
ログインできてしまう[0]
サービスなりすましで利用できてしまう[-3]

さあ、どうなるでしょうか。
お楽しみに。

当研究会が、GREEはSSL詐欺であると指摘したからなのかどうか分かりませんが、早速、GREEのログインのシステムが変更されました。

　←変更前

←変更後

変更後は、SSL詐欺表示もなくなり、標準でSSLログインになっています。

当研究会の指摘なんて見ていただいたのでしょうか？

いずれにせよ、GREEさん、早速の対応ありがとうございます。

標準ログインがＳＳＬになったGREE、
ユーザーセキュリティが大幅に改善されたことを期待して、再チェックしてみます。

１．ログイン　（２点）

標準でSSL

２．個人情報送信　（－３点）

なんと、いまだにＳＳＬなしで、携帯メアド等が送信されます

３．サービス利用時　（０点）

ＳＳＬなし

４．個人情報アクセスで再認証要求　（－１点）

求めない

５．クッキー盗聴、セッションハイジャック　（－３点）

サービスを成りすましで利用できる

総得点は、－５点

GREEさん、個人情報保護の見直しを是非お願いします。

今まで調査をしてきた、インターネット上のサービスのユーザー保護の視点に立ったセキュリティレベルにポイントをつけて、P-SEC管理人の独断と偏見でランキングをしてみました。

予想通り、日本のイケイケベンチャー企業のランキングが低いのが気になります。
もっと、ユーザーの安全について配慮してくれることを期待しています。

サービスプロバイダの皆様へ
ランキングに誤りがある場合や、その後に修正をした場合などは、P-SEC管理人宛にメールをいただければ、確認後にランキングを修正いたします。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－