web-dev-qa-db-ja.com

攻撃者が到着前に私の送信メールの内容を変更することは可能ですか？

パスワードを変更したいユーザーに「パスワード変更リンク」を送信するWebアプリケーションがあります。

リンクは次のようなものです：

http：// www.my-domain。com/changepass？uid = username＆secretkey = some-hardly-encoded-secure-key

到着前にメールの内容を変更することはできますか？頭の中にシナリオがありますが、その可能性については何も知りません。

  1. 攻撃者は受信者より先に私の送信メールを受け取ります
  2. 攻撃者は私のメール内のリンクを次のように変更します。

http：// www.attackers-domain。com/changepass？uid = username＆secretkey = some-hardly-encoded-secure-key

  1. 攻撃者は受信者（元のユーザー）に電子メールを送信します
  2. ユーザーがメール内の間違ったリンクをクリックし、パスワードを変更するために間違った場所に移動する
  3. ユーザーが攻撃者のサイトに新しいパスワードを入力する
  4. 攻撃者サイトは正しいプロトコルを使用して新しいパスワードを私に送信し、ユーザーのパスワードを変更します

そして今：

  1. ユーザーは攻撃について何も知らない
  2. 攻撃者はユーザーに新しいパスワードを持っています
emailattacksman-in-the-middle
2
S.Yavari

それは可能ですが、比較的高度な攻撃が必要です。電子メールは一般的に安全ではありません。安全なプロトコルは電子メールを交換するために存在しますが、実際にそれを使用するサーバーはほとんどありません。

攻撃者が中間者攻撃として知られているものを実行できる場合、電子メールについて必要なすべてを変更する可能性があります。中間者攻撃では、送信者から受信者への電子メールのルートの一部を制御する必要があります。これは、送信または受信メールサーバー、ユーザーの電子メールクライアント、または電子メールがたまたま通過するインターネットルーターのいずれかです。

攻撃者が中間に入ることができる場合、調整するのは簡単ですが、比較的確立されたハッカーであり、ある程度のリソースを利用できる場合を除いて、中間に入るのは比較的困難です。

あなたの場合、最も簡単な対策はHTTPSベースのリンクの使用です。 SSLを使用していて、ユーザーがそのURLがサイトに対応していることを確認する必要がある場合、攻撃シナリオは機能しません。また、パスワードをリセットすることを選択したときにリンクが移動することをドメインに伝えることもできます。そうすることで、パスワードが有効かどうかを確認できます。これがおそらく最も簡単な解決策です。

6
AJ Henderson

あなたが説明する可能性は存在します。他の人が指摘したように、それは「中間者攻撃」です。

それを阻止するには、クッキーキー（そのままでは不十分なシークレット）など、電子メールで送信される追加のシークレットnotが必要になります。 同じコンピュータとブラウザを使用して、「パスワードをリセットしたい」コマンドを送信するために使用するパスワードをユーザーに要求することができます。

その後、攻撃者は適切なCookieを送信できなくなります。彼のドメインが元のドメインと異なるため、ブラウザは適切なCookieの値を使用するように指示していません。

より厳密な可能性は、ユーザーに「パスワードのリセット」ページに挿入することを要求することですそれを閉じずに、電子メールで送信されるコード。その時点のメールにはリンクも含まれていません。攻撃者はコードを知っていますが、開いているブラウザウィンドウを制御できません。ウィンドウには、サーバーがそれ自体に「通知」している非表示の秘密、またはCookie（基本的に同じもの）が含まれている場合があります。永続的な情報の使用を回避するために、サーバーはページにランダムな文字列を保存し、秘密のソルトでハッシュされたランダムな文字列を送信する場合があります。次に、ユーザーは両方の値を持つフォームに入力します（1つは非表示、1つはメールからコピー）。サーバーは秘密のソルトでコードをハッシュします。 2つの文字列が等しい場合、変更は承認されます。この場合の「繰り返し攻撃」（つまり、既知のチャレンジ/ハッシュペアの再利用）を回避するには、チェックにユーザー名とタイムスタンプを含めることができます。

form
    username    hidden (e.g. "lserni")
    timestamp   hidden (e.g. 20140108131005)
    hash        hidden (e.g. "e2961ca083b4393690ec74b93d3c4b32")
    code        input

ユーザーは、コード「123456」をランダムに100000から999999で受け取ります。約90万件のコードが正常に推測される可能性が1つあります。サーバーはSERVERSECRETPASSWORD.lserni.20140108131005.123456を連結し、e2961ca083b4393690ec74b93d3c4b32へのハッシュであることを確認します。

攻撃者はタイムスタンプを推測できますが、ハッシュにアクセスできません。ハッシュとそれに対応するコードを知ることは、正当なユーザー名でのみ機能し、保存されているタイムスタンプ間の違いは変更できず、壁時計は大きくなりすぎず、その時点でサーバーが提供します別のメールを送信します。

起こり得る（避けられない）問題

一方、攻撃者が電子メールを制御できる場合は、自分でパスワードの回復を開始し、リソースへのフルアクセスを少なくとも1回許可することができます。これを防ぐには、パスワードのリセットを開始するために、その他の情報（「秘密の質問」など）を提供する必要があります。また、nsuccessful認証の場合の警告をユーザーに発行して、問題を認識させる必要があります（「パスワードが間違っています。昨日17:23にパスワードを変更したことを忘れないでくださいIP 1.2.3.4。これを行わなかった場合は、次の点に注意してください... "）;

別の考えられる問題

一部のシステムでは、サーバーに "remember yo"を要求することが許可されます。サーバーは、あらゆる点で弱い認証であるmightがパスワードに接続されていないCookieを発行することにより、これを行います。

パスワードの変更はそのようなすべてのCookieを無効にするである必要があります。そうでない場合、攻撃者は次のことができます。パスワード-サーバーに「Remember me」と尋ねて「Get Home Free」Cookieを取得-利益-ユーザーは自分がログインできないことに気づく-パスワードを変更して再度ログインする-攻撃者はstill =彼のクッキーでログインできる。

これを行う1つの方法は、Cookieをランダム文字列に設定することですplusサーバーシークレットのハッシュ、ランダム文字列、ユーザー名、およびデータベース内のユーザーのパスワードハッシュ。パスワードを変更すると、そのユーザーの既存のすべての認証Cookieが自動的に廃止されます。

2
LSerni

TL; DR：はい。標準の暗号化されていない電子メールは、はがきの裏側に書き出されたメッセージとほぼ同じくらい安全です。

より長い回答：これは、攻撃者が次の少なくとも1つに対する管理者権限を持っている場合に完全に可能です。

  1. メッセージが通過するメールサーバー（メールメッセージを開き、使用しているメールクライアントで「完全なヘッダー」を選択します。各Received: from [foo] by [bar]行は、このメッセージが通過したメールサーバーを示します）。メールサーバーの管理者権限がある場合は、メールサーバーのキューにアクセスし、キュー内のメッセージを一時停止して、メッセージを編集してから送信することができます。

  2. メッセージが通過した任意のTCP/IPルーター。この場合、攻撃者は理論的にはすべてのSMTPトラフィックを透過プロキシとして機能するローカルリレーサーバーにルーティングしますが、特定のメッセージにタグを付けてキューに保持し、攻撃者が送信する前に変更できるようにします。トリッキーですが、実行可能です。

[〜＃〜] note [〜＃〜]：2番目の方法は、smtp-over-を使用することでときどき防止できますsslですが、この方法は一般的ではありません。smtpsまたはsmtp/tlsは、bothside *がサポートしている場合にのみ機能します。攻撃は正当な（破壊された場合）チェックポイントで発生するため、最初の方法は送信を暗号化することで防止できません。

両方の攻撃ベクトルに対してどのようなが機能するかは、公開鍵/秘密鍵のペアを使用してメッセージに署名しますが、受信者はあなたのコピーを持っている必要があります鶏と卵の問題の可能性がある公開鍵。

0
Shadur

メールが平文で送信された場合、攻撃者は理論的にはメールの内容を正確に変更し、正確な結果を得ることができます。

この電子メールを傍受して変更するには、攻撃者は、送信中の電子メールを処理する電子メールサーバーを制御するか、電子メールを変更する機能を持つルーティングデバイスを制御する必要があります。これは簡単なことではありません。攻撃者が何かにアクセスしようとする場合、発信元の電子メールサーバー以外の電子メールが通過する正確なパスを知る必要があります。つまり、顧客ベースを知る必要があります。顧客ベースを知るための最良の方法は、システムをハッキングすることです。ハッキングできる場合は、とにかくユーザーのパスワードを入手します。また、パスワード変更をキャプチャするためのスクリーンスクレイパーソフトウェアとWebサイトを作成することは、かなりの労力となります。

一部のフィッシング攻撃は、非常によく似た攻撃方法をすでに使用しています。ただし、電子メールを傍受して変更するのではなく、巧妙に細工されたスパムメールを送信するだけで、はるかに簡単です。銀行はかなりの時間を費やしてサイトをスクリーンスクレイパー攻撃に耐えさせています。懸念がある場合は、サイトのデザインについて調査を行い、これらの攻撃をより困難にするためにサイトにいくつかの対策を組み込むことをお勧めします。

電子メールを傍受して変更することのメリットは、スパムフィルタリングの可能性がはるかに低くなること、およびユーザーがパスワードの変更を要求したときに電子メールのリンクを信頼する可能性が高くなることからわかります。それでも、攻撃の複雑さを考えると、サイトはだれもがそのために時間と労力を費やすことをいとわない前に、かなり高い値でなければなりません。サイトがターゲットになるかどうかは、自分で決める必要があります。

0
GdD

SMIMEまたはDKIMを使用して、このタイプの攻撃から保護できます。どちらのテクノロジーもメッセージヘッダーを検証し、DKIMはオプションでメッセージ本文（またはその中の最初のX文字）を保護します。

DKIMはDNSに格納されている公開鍵であり、メール管理者がメッセージに「署名」し、ヘッダーにスタンプします。 DKIMの詳細については、こちらをご覧ください： http://en.wikipedia.org/wiki/DKIM

DKIMに依存するということは、エンドユーザーがメッセージを変更しないように自分のメール管理者を信頼する必要があることを意味します。 DKIMを検証するDKIMクライアント側ソフトウェアパッケージがありますが、広く使用されていません（AFAIK）。

0
goodguys_activate