母のGmailアカウントがどのようにハッキングされたか理解できない
私の母（Gmail、Chromeを使用）は、友達のHotmailアドレスからメールを受け取りました。彼女はメール（明らかにフィッシングメール）を開き、その中のリンクをクリックしました。これにより、多数の医療広告が掲載されたWebページが開きました。彼女はページを閉じてメールを削除しました。
彼女はリンクをクリックしても他に何も起こらないことに気づきませんでした。たとえば、ダウンロードの開始が表示されず、開いたページで何もクリックしませんでした。
彼女がクリックしたリンクのURIはhxxp://23.88.82.34/d/?sururopo=duti&bugenugamaxo=aGViZTFzaGViZUBob3RtYWlsLmNvLnVr&id=anVuYWx4QGdvb2dsZW1haWwuY29t&dokofeyo=anVuYWx4 [そのアドレスにアクセスしないでください！]
すぐに（当時は知りませんでしたが）、Gmailアドレスから選択した連絡先に約75通のメールが送信されました。 Gmailアカウントの送信済みメールリストに表示されます。これは17:08と17:10 GMTの間に起こりました。ここで1つのソース：
Return-Path: <[email protected]>
Received: from localhost (Host86-152-149-189.range86-152.btcentralplus.com. [86.152.149.189])
by mx.google.com with ESMTPSA id r1sm16019263wia.5.2014.02.23.09.10.15
for <[email protected]>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 23 Feb 2014 09:10:16 -0800 (PST)
Message-ID: <[email protected]>
Date: Sun, 23 Feb 2014 09:10:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
From: [email protected]
Return-Path: [email protected]
Subject: Bar gain
<span style=3D"VISIBILITY:hidden;display:none">Mount your brooms said Madam=
Hooch Three two one =20
</span><br /><u>[email protected] has sent you 3 offline broadcast</u><=
br /><a href=3D"hxxp://23.88.82.8/d/?ba=3Djurofaxovu&maremiditigehavuve=3Da=
nVuYWx4QGdvb2dsZW1haWwuY29t&id=3DaGVsZW5fY19odWdoZXNAaG90bWFpbC5jb20=3D&guv=
iwafaloco=3DaGVsZW5fY19odWdoZXM=3D" >Locate Full Email Content</a>
Gmailの[アクティビティ情報]ウィンドウは次のとおりです： 
このリストのIPアドレス86.152.149.189は、その電子メールのヘッダーと同じであることに注意してください。
私の母の友人の1人は、彼女が電子メールの1つを受信し、その中のリンクをクリックしたと報告しています。その後、自分のメールアカウントから大量のメールが送信されたと彼女は言います。
これが起こったとき、母のIPアドレスはわかりませんでした。つまり、86.152.149.189でした。
どうしてこうなったのか分かりません。彼女は他に何も使用しない非常に強力なパスワード（私はこれを変更しました）を持っていて、開いたページにこのパスワードを入力しませんでした。
いったいどうすればメールのリンクをクリックして、攻撃者がGmail SMTPサーバーを自分の母親として認証し、大量のメールを彼女の連絡先に送信することができますか？そして、どうすれば彼女の連絡先のアドレスを取得できたのでしょうか。
イゼルニの答えに続く更新：
私の母は、医療広告のページが閉じられた後に「Gmail」がパスワードを要求したときに、彼女が本当に彼女のGmailパスワードを入力したことを確認しました。彼女の叔母はメールの1つを受信し、Gmailのログイン詳細の入力も求められました。彼女が言ったのは、元のメールが私の母から来たからです。巧妙な攻撃
[〜＃〜]重要[〜＃〜]：これは私があなたのリンクから取得したデータに基づいていますが、サーバーは何らかの保護を実装している場合があります。たとえば、被害者に対して「銀の弾丸」を送信すると、同じリクエストに対してfaked「銀の弾丸」で応答する可能性があるため、調査している人は誰もが迷子になります。 cHVwcGFtZWxvの偽のパラメーターを送信して、別の動作をトリガーするかどうかを確認しましたが、トリガーしませんでした。それでも、それは大きな保証ではありません。
[〜＃〜] update [〜＃〜]-上記はまだ成立しますが、メインに追跡できないランダムなIPからテストを行っていますセッション-攻撃サーバーは区別せず、ブラウザー、リファラー、JS/Flash/Javaのサポートに関係なく、クエリに快く応答します。
受け取ったリンクには、URLに既に埋め込まれている次のパラメーターが含まれています-少し変更して、正しい形式がStack ExchangeのGoogle検索に表示されないようにしました（最初の文字を入れ替えました）。
[email protected]
[email protected]
リンクはJavascriptを挿入します。まず、Geotrack API呼び出しを通じて現在地を取得し、次に別のスクリプトをロードします。 （私は最初にこれをGMailコマンドと間違えていました;私の悪い）。
2番目のスクリプトはWebページをロードしますbut alsoは、受信メールに応じて、人気のあるアカウント（Hotmail、GMailなど）のログインページのレプリカをいくつか表示します。GMailアカウントは偽のGMailページを取得します。これらすべてのページには、「セッションが終了しました！もう一度ログインしていただけますか？」と表示されます。
たとえば、ここをクリックします（しないでください万が一に備えて、GMailにログインしているときに行います）
hxxp://23.88.82.8/d/[email protected]&jq=SVQ7RmxvcmVuY2U=
偽のGoogleアカウントのログインが表示されます（存在しないユーザー 'puppa'の場合）。
実際のログインページは
http://ww168.scvctlogin.com/login.srf?w...
http://ww837.https2-fb757a431bea02d1bef1fd12d814248dsessiongo4182-en.msgsecure128.com
ファイアアンドフォーゲットドメインです。
盗まれたユーザー名とパスワードを受信するサーバーは、明らかに常に同じです。31.204.154.125のShineServersマシンは、 忙しい小さなビーバー です。これらのURLのほとんどは さまざまなサービスに送信されています であり、1月までさかのぼって表示されていました。
フィッシングと二要素認証
thisシナリオにおけるTFAの有用性について、私は2つの考えを持っています。私がそれを見ると、私は間違いや何かを見落としているかもしれませんが、
- 被害者がリンクをクリックする
- 「切断」され、フィッシング画面によって「再接続」するように促される
- [ユーザー名と]パスワードを入力
- 攻撃者はログインを試み、「Enter Secure Code」にリダイレクトされます
- 安全なコードが被害者に送信されます
- 攻撃者は被害者に「安全なコードを入力」画面を送信します
- （ほとんど？）被害者も安全なコードを入力する
- 被害者のアカウントが危険にさらされています
何ができるか
- アドレスバーに表示されるURLを確認してください。 SSL証明書を確認します。
- anythingにログインしないでください。ブックマークまたは手動で入力したリンクからのものでない限り、一般的なスペルミスに注意してください。ナビゲーション中にログイン画面が表示された場合は、ブラウザを閉じて、再度開きます。
- 常に最初に間違ったパスワードを挿入するという偏執的な癖に入り、最初は使用しないパスワードを、次に「ログイン失敗」画面で正しいパスワードを挿入します。間違ったパスワードが受け入れられた場合...（もちろん、攻撃者は最初の試行に対して常にWRONG！と応答する可能性があります。攻撃者は、被害者を怖がらせるコストと、他の被害者を獲得する潜在的な利益とのバランスを取る必要があります。 2人の攻撃者は無視でき、2人の攻撃者は彼らにとっての勝利の戦略です。
- @Subinによって指摘された、またはブラウザ自体に埋め込まれたOpenDNSなどのサービスは、着信サイトを分散リストと照合して検証し、既知フィッシングサイトへの接続を拒否します。
開発者ができること
多分、たぶん、多分、「このページはこの他のページのように見える」アプリケーションを開発することは可能でしょう。おそらくそれはシステム上でひどく重いでしょう。その最も基本的で防御可能な形式のHTMLコードに「Enter Google password」が含まれ、URLがnotgmailの場合、大きい血の赤いバナーが表示されます。
もう1つの可能性としては（再び反抗的）、honey-tokenアプローチを採用し、パスワードを含むフォーム送信を拒否することです。
Googleができること
これは私のちょっとした不満です。フィッシング画面はピートのためにGoogleサーバー上のデータを使用しているため、これらのサーバーは、フィッシング詐欺師のドットコム。それらのサーバーは何をしますか？彼らはロゴをそのまま提供します！ [〜＃〜] i [〜＃〜]がこのようなサーバーを管理する場合、任意のページからのアバター画像（または任意の画像）のリクエストnotサイトは確かに画像を取得します。選んだ画像で困ることはないでしょう。しかし、誰かがそのような画面で進んで自分のパスワードを入力することはほとんどありません。
もちろん、攻撃者はWebサイトに画像をミラーリングするだけです。しかし、私は他の多くのトリックを考えることができます。たとえば、1.2.3.4のブラウザからログインアバターを要求された場合、特に数秒後にアドレス9.8.7.6から送信されるパスワードの確認に注意する必要があります（特にother accountの他のパスワードの場合）。過去数分間に同じ住所から同様の状況で来ていました。
ひねり：コメンターが示唆したように（私はまだ洞察に感謝しなければなりません）、Googleは実際に着信リクエストを監視していますGMail表示メッセージと同様に。少しのデータ分析で、フィッシングサイトをほぼリアルタイムで確実に知ることができ、フィッシングサイトをミラーリングしても、この種の分析はそれほど妨げられません（ほとんどの場合、被害者から収集したデータに基づいています）。その後、Googleは既知のサイトのアドレスをブラウザ拡張機能に提供できます（例Chromeサイト保護））。
私はまだ彼らができると思います両方-ログイン画面を守りますandフィッシング詐欺師が誰であるかを知るためにデータマイニングを使用します-しかし、私は正当化されていないことを受け入れますグーグルが実際にやっていると言ってnothing。
より複雑なトリック
また、ブラウザのフィンガープリントに基づいて、攻撃者が照合する必要があるユーザーには見えないチャレンジ/レスポンスでログイン画面を複雑にする可能性があります。ログインしたい場合は、プロンプトが表示されたのと同じログイン画面からパスワードを送信します。これも簡単に阻止できます。
しかし、アカウントを危険にさらすために20の簡単なことをしなければならない難しい。また、あなたが17問正解した場合、私（サーバー）はあなたのアドレスにマークを付け、次の時間にログインに成功した場合は偽のサンドボックスアカウントにリダイレクトする可能性があります。そして、私はあなたが何をしているかを見るだけです。あなたはほとんど何もしません、私は本当のアカウントで複製します、そしてあなたが正直であれば、あなたは決して知ることさえないでしょう。 X以上の類似したメール、または速すぎる送信、そして私は知っているでしょう。もちろん、アカウントは開いたままであり、すべてのスパムを快く受け入れます。何故なの。 送信それですか？さて...それは別の問題ですが、今ではありませんか？
この正確な方法でハッキングされた顧客がいました（Gmailのアクティビティ情報を見ると、まったく同じUKベースのIPアドレスが表示されていました）が、母親がそれを受け取った後のことです。
彼女は私に会う前に1時間だけフィッシングされていたので、プロンプトが出された後、すべてのステップを思い出すことができました。
フィッシングリンクをクリックした後、彼女は複数のポップアップウィンドウが開いた広告がいっぱいのページに移動しました。彼女はポップアップウィンドウの1つを閉じ、自分がいた場所に「戻った」と考え、Gmailのログオンのように見えるウィンドウに移動しました。
資格情報が入力されたのはここで、それから間もなく、アカウントを使用してフィッシングメールを連絡先リストの全員に送信しました。
彼女のGmailのパスワードはリセットされていましたが、幸い、SMS確認を使用すると、古いパスワードを使用して新しいものにリセットできました。
さて、ここでは私の推測です。
おそらく起こったのは、Webページにブラウザーに影響を与えるエクスプロイトがあり、Gmailセッションにアクセスするために管理され、そこから電子メールを送信するために使用されるブラウザー自体を単に制御したことです。
おそらく、このエクスプロイトはパスワードをまったく解読しませんでした。