カテゴリー: セキュリティ

スマホのメアドにアカウントを乗っ取ったというメールが届いたのだけど。

僕のスマホのメールアドレスにアカウントを乗っ取ったという怪しい？メールが届きました。面白かったのでブログネタにしてみました。まずは実際に届いたメールを見てください。

===== ここから =====
[メールの件名]
（※僕のメールアドレスが記載※）ハッキングされています！すぐにパスワードを変更してください！

[メールの本文]
こんにちは！

私はあなたに悪い知らせがあります。
2019年7月23日 – この日、私はあなたのオペレーティングシステムをハッキングし、あなたのアカウント（※僕のメールアドレスが記載※）にフルアクセスできました。

それはどうだった：
その日接続していたルータのソフトウェアには、脆弱性が存在しました。
私は最初にこのルータをハックし、その上に悪質なコードを置いた。
インターネットに接続すると、私のトロイの木馬はあなたのデバイスのオペレーティングシステムにインストールされました。

その後、私はあなたのディスクの完全なデータを保存しました（私はすべてあなたのアドレス帳、サイトの閲覧履歴、すべてのファイル、電話番号、あなたのすべての連絡先のアドレス）を持っています。

あなたのデバイスをロックしたかったのです。ロックを解除するために、私はお金がほしいと思った。
しかし、私はあなたが定期的に訪れるサイトを見ました, そしてあなたのお気に入りのリソースから大きなショックを受けました。
私は大人のためのサイトについて話しています。

私は言う – あなたは大きな変態です。 無限のファンタジー！

その後、アイデアが私の頭に浮かんだ。
私はあなたが楽しんでいる親密なウェブサイトのスクリーンショットを作った (私はあなたの喜びについて話しています、あなたは理解していますか？).
その後、私はあなたの喜びの写真を作った (あなたのデバイスのカメラを使って). すべてが素晴らしくなった！

あなたの親戚、友人、同僚にこの写真を見せたくないと強く信じています。
私は$856が私の沈黙のために非常に小さいと思う。
それに、私はあなたに多くの時間を費やしました！

私はBitcoinsだけを受け入れる。
私のBTCウォレット： 1PLSGCFxYW186T956vomoBvFn3NCTvponm

Bitcoinウォレットを補充する方法がわからないのですか？
どの検索エンジンでも、「btc walletにお金を送る方法」と書いてください。
クレジットカードに送金するよりも簡単です！

お支払いの場合は、ちょうど2日以上（正確には50時間）をご提供します。
心配しないで、タイマーはこの手紙を開いた瞬間に始まります。はい、はい。それはすでに始まっています！

支払い後、私のウイルスと汚れた写真は自動的に自己破壊されます。
私はあなたから指定された金額を受け取っていない場合、あなたのデバイスはブロックされ、あなたのすべての連絡先は、あなたの “喜び”と写真を受信します。

私はあなたが賢明であることを望みます。
– 私のウイルスを見つけて破壊しようとしないでください！ （すべてのデータはすでにリモートサーバーにアップロードされています） – 私に連絡しようとしないでください（これは実現可能ではありません、私はあなたのアカウントからメールを送りました）
– 様々なセキュリティサービスはあなたを助けません。 あなたのデータは既にリモートサーバー上にあるので、ディスクのフォーマットやデバイスの破壊は役に立ちません。

P.S. 私は支払い後にあなたに再び邪魔をしないことを保証します。
これはハッカーの名誉のコードです。

これからは、良いアンチウィルスを使用し、定期的に更新することをお勧めします（1日に数回）！

私に怒らないでください、誰もが自分の仕事をしています。
お別れ。

===== ここまで =====

まずメールが届いたのは2019年10月5日の午前中なので、メール本文にある2019年7月23日から随分と間が開いてました。

OS（オペレーティングシステム）をハッキングしてアカウントを乗っ取ったと書かれているけれど、僕が使っているパソコンではメアドをアカウントにしてなんかしてないぞ？と思って、詐欺メールだなと思いました。

メールにはハッキングした手法だとか、大人の事情に絡む嗜好が書いてあったりするけれど、なかなか面白い。読んでいて笑ってしまった。。件名に「パスワードを変更してください！」と書いてある割には、本文ではパスワード変更については触れられていないのもおかしいですが。そもそも日本語が変だから、もともとは英語の詐欺メールを日本向けに訳したんだろうと思います。

で、ちょっとメールの送信元アドレスを見てみたら、僕のメールアドレスになっていました。メールの宛先(To)も送信元(From)も同じです。送信元はバレないように詐称しているようです。メールヘッダを見てどこのメールサーバーから転送されたのか見ようと思ったのだけど、スマホのメールアプリではメールヘッダの表示ができませんでした（表示させる方法がわかりませんでした）。メールヘッダを見れば転送元のメールサーバーがわかるのでIPアドレスもわかり、どこの国、ISPからのものかわかるんじゃないかなぁ、、と思ったのですが。

メール受信したときは、その程度のことしかしなかったのですが、後日、スマホでもメールヘッダを見る方法を見つけました！！

Eメールヘッダ情報の確認方法

これを見つけたのはメール受信してから3日後で、早速、メールヘッダを確認してみたのだけど携帯電話会社で保存しているメールヘッダの保存期間が2日（48時間）までだったみたいで表示されなかった。かなりガッカリです。。もう少し早く見つけていれば確認できたので残念です。

それにしても、この詐欺メールにせよ迷惑メールにせよスマホのメアドにはいろんなメールが届いていて、おそらくどこかで僕のメールアドレスの情報が流出してしまっているんだろうな、と思う次第です。

Wiresharkに秘密鍵を登録しても解読できないのにSSLKEYLOGFILEを使えば解読できる理由

秘密鍵をWiresharkに登録してもTLSの通信を復号できなかったのに、SSLKEYLOGFILEを使えば復号できる理由を考えてみました。Wiresharkを使ってTLS通信を復号しようとした記事は以下です。

秘密鍵をWiresharkに登録してもTLS通信を解読できない？
ubuntuでFirefoxのTLS通信をキャプチャする。

TLSのネゴシエーションの中で「鍵交換」に関するやり取りに注目して必要な部分を抜き出したものが以下のシーケンス図です。
※TLSのネゴシエーションのすべてではありません、省略しているものもあります。

図の中にある各やり取りの説明をします。

Client Hello
クライアントからサーバーに対してWEBブラウザが対応しているいくつかの暗号スイートを提示します。

Server Hello
クライアントから提示された暗号スイートの中からクライアント／サーバーの双方で使える一番強い暗号スイートをサーバーが選び、クライアントに通知します。ここで決められた暗号スイートに従い、以降の通信を行います。

Server Certificate
サーバー証明書をクライアントに通知します。サーバー証明書には公開鍵が含まれています。

Server Key Exchange
必要に応じて一時的な鍵をクライアントに通知します。Server Key Exchange は省略される場合があります。

Client Key Exchange
共通鍵を生成する鍵の元を先ほど受け取った公開鍵で暗号化してサーバーに通知します。

Change Cipher Spec（クライアント→サーバー）
鍵の元から共通鍵の生成ができたことをサーバーに通知します。

Change Cipher Spec（サーバー→クライアント）
鍵の元から共通鍵の生成ができたことをクライアントに通知します。

Application Data
やり取りしたいデータを共通鍵で暗号化して双方で通信を行います。データの復号にも共通鍵を使います。

[広告]

それでは、本題に入ります。

鍵交換方式がRSAでは解読できるのにECDHEだと解読できないのはなぜか？
SSLKEYLOGFILEを使った場合、鍵交換方式がECDHEでも解読できるのはなぜか？

まずRSAの鍵交換の方式から見ていきます。鍵交換にRSAを使った場合はクライアント／サーバーの双方で同じ鍵の元を共有します。鍵の元はClient Key Exchangeでクライアントからサーバーに送られています。そのためWiresharkで鍵の元のデータを盗み見することができれば共通鍵を得ることができます。鍵の元からクライアントやサーバーがやっているのと同じアルゴリズムで共通鍵を作るのです。

次にECDHEの方式です。ECDHEは Ephemeral Eliptic Curve Diffie-Helman の略です。ECDHEの最後の「E」がEphemeral（一時的）を意味します。ECDHEの場合は鍵の元をクライアントとサーバーの双方で生成し、鍵の元を使って計算した値をクライアントとサーバーで送り合います。つまり、クライアントとサーバーは別々に違う鍵の元を持ち、それを使った計算結果を相互に交換するので鍵の元自体はネットワークに流れません。計算結果は Server Key Exchange と Client Key Exchange で交換してします。（厳密にはもっと複雑なのかもしれませんが交換しあっているということです）。鍵の元を交換せず計算結果だけを交換しあったところで同じ共通鍵を作れるのか？という疑問もありますができるようです（前提としてクライアントとサーバーで共有しておく数値があらかじめある）。そのへんのアルゴリズムは難しいので書くことはできないのですが、大事なところは、通信を盗み見したところで鍵の元はわからない、ということです。盗聴をして「前提としてクライアントとサーバーで共有していた数値」および「計算結果」を取得し、アルゴリズムがわかったとしても、鍵の元を逆算で導き出すのは至難の業（ほとんど不可能）というわけです。

と言うことで、1点目の「鍵交換方式がRSAでは解読できるのにECDHEだと解読できないのはなぜか？」については、ECDHEだとWiresharkでパケットを盗み見しても共通鍵を導き出せないから、というのが理由になります。今は鍵交換にRSAを使おうとするサーバーはほとんどないです。古いクライアント端末ではRSAしか対応していない場合があり、そのような端末でも利用できるようにするためサーバー側もRSAを使用している、というケースはあるでしょう。一応、RSAは鍵の元をずっと使い続けるわけではなく、随時再作成はしているようです（一時的な鍵として使用している）。なお、ECDHEのような鍵交換方式はPFS(Perfect Forward Secrecy)と呼ばれていて、PFSは秘密鍵がわかってもそれだけでは暗号を解読できない性質のものを指しています。

では、2点目のSSLKEYLOGFILEを使った場合を考えてみます。秘密鍵をWiresharkに登録してECDHEの鍵交換のやりとりを盗み見しようとしたのと違って、2点目の場合はWEBブラウザが「クライアントの鍵の元」と「サーバーからの計算結果」を知っています。ですのでブラウザは共通鍵を生成できます。つまり、SSLKEYLOGFILEを環境変数として設定することでブラウザが共通鍵そのものをファイルに書き出してくれます。ファイルの出力先はSSLKEYLOGFILEで指定した場所になります。そのためWiresharkはそのファイルを取り込むことで共通鍵を手に入れることができ、それをもとにTLS通信を復号することができるのです。ただブラウザに共通鍵を出力する機能があれば良いのですが、そういう機能がない場合はこの手は使えません。ChromeとFirefoxでは対応しているみたいですね。