5月 13

無料の Private VPN「ZenMate」メモ

9ヶ月前にサービス開始し、今や利用者は300万人と言われている無料のVPNソフト「ZenMate」をインストールしてみました。VPNというと多くの方は、どこにいてもネットにさえ繋がれば会社や自宅にいるように作業を行える環境を提供してくれるものというイメージをお持ちなのではないでしょうか。
今回、インストールしたものはそれとは少し違うものでボクは区別するために「Private VPN」と呼ぶようにしています。
どういうものかを簡単に説明すると目的のサーバにアクセスする前に1つサーバを経由してからアクセスを行い、自身とその経由するサーバとの間の通信は暗号化されるというものです。また、アクセスされる側の目的のサーバから見ると元々のアクセス元、つまり、あなたは見えないわけです。

pvpn01

上図でいうと①がPrivate VPNを使用しない通常のアクセスで、②と③がPrivate VPNを利用したアクセスです。
②の通信は、暗号化されているためフリーのWiFiなどの安全ではないネットワークでhttpアクセスを行ったとしてもネットワーク盗聴が行われていたとしても一切の通信の中身を覗き見することはできません。③の通信は使用されているプロトコルに依存する形になります。httpであれば非暗号ですし、httpsであれば暗号化されます。アクセスされる側の目的のサーバから見ると元々のアクセス元(図では[クライアント])が見えないと前述しましたが、この図でいうと[目的サーバ]から見た場合、Private VPNサーバからのアクセスに見えるためです。
Private VPNを利用することで通信の秘匿と通信の匿名性をある程度保つことが可能になるわけです。
(ただし、これらのサービスを利用し犯罪を行った場合、法執行機関による捜査によって身元が判明する可能性はゼロではありません。過去にそういった事例もあります。)
また、国によってネット検閲が厳しく、自由に自国外のサーバとの通信が許可されていない場合があります。
そういった場合にもPrivate VPNは下図のように効果を発揮します。

pvpn02

[A国]はネット検閲が厳しく、何かしらの理由で[C国]への通信が許可されていないとします。
しかし、[A国]は[B国]との通信は許可されており、[B国]は[C国]と自由に通信ができるとします。
その場合、[A国]から[B国]にある[Private VPNサーバ]を経由することで結果[C国]にある[目的サーバ]と通信できるというわけです。また、こちらも前述した通り[クライアント]と[Private VPNサーバ]との間の通信は暗号化されているため通信内容を見ることができず[A国]による検閲も回避できるということになります。

これをブラウザでの閲覧に絞って実現するサービスが「ZenMate」です。
(対応ブラウザはこのエントリ作成現在ChromeとOperaのみです。)

前置きが長くなりました。

それでは「ZenMate」のインストールです。今回はChromeにインストールします。

まずは、公式サイト(https://zenmate.com/)にアクセスします。
トップページにある[Add ZenMate]をクリックします。
toppage

するとアクセス権限の確認のポップアップが表示されるので確認の上、問題ないと判断したら[追加]ボタンをクリックします。
permit

追加が完了すると画面が変わり、メールアドレスの登録画面になります。
01_zenmate_welcome

メールアドレスを入力し、[Get secured now]ボタンをクリックすると画面が切り替わり、自動で生成されたパスワードが表示されます。これはユーザ情報の変更などの際に必要になるのでメモするなりパスワード管理ソフトに記憶させておいてください。
02_zenmate_password

これでインストールは完了です。と同時に「ZenMate」が有効化されています。
先程まで青色だった盾のアイコンが緑色になっていると思います。
ためしに自身のIPアドレスなどを確認できるサイトにアクセスしてみるといいでしょう。(例えばココとか)

オフにしたい場合は、盾のアイコンをクリックしてポップアップしたウインドウの右下にある[ON]を[OFF]にするだけです。
03_zenmate_popup

またロケーション(経由する[Private VPNサーバ]の物理的場所)を変更することも可能です。
同じく盾のアイコンから表示されたポップアップの中央にある盾の部分をクリックするか、左下にある[Change location]をクリックしてください。
03_2_zenmate_popup

するとポップアップしたウインドウの表示が切り替わりロケーションを選択することができます。
04_zenmate_location_change
選択できるロケーションはこのエントリ作成現在「香港 – 九龍」「ドイツ – フランクフルト」「イギリス – ロンドン」「スイス – チューリッヒ」「アメリカ – ニューヨーク」の5つです。
変更して自身のアドレスがどのように見えるのかの結果を確認してみてはいかがでしょうか。

今後、対応ブラウザや経由ロケーションが増えたり、サービスが拡張されれば有料のサービスも出てくることでしょう。この先が楽しみなサービスです。

Category: memo | 無料の Private VPN「ZenMate」メモ はコメントを受け付けていません
3月 23

KADOKAWAが不正アクセスされフィッシングメールに悪用された可能性について考えてみました。

kadokawa_sorry
KADOKAWAオフィシャルサイト( http://www.kadokawa.co.jp/ )が不正アクセスの被害に遭い、フィッシングメール送信の踏み台にされていた可能性があるそうです。
このブログを書いている 2014年3月23日3:00 現在、サイトの一部のサービスをサーバーの安全性確保と調査のため停止しているようです。
マイナビの記事によると

不正アクセスを受けた期間は公表していないが、これによりフィッシングメールを送信する”踏み台”にされた可能性がある。現在同社は、KADOKAWAオフィシャルサイトを閉鎖して調査を行なっているという。

なお、個人情報の流出や、マルウェアのダウンロードへの誘導といったWeb改ざんを仕組まれた痕跡は現時点で「一切見つかっていない」としている。

とのことです。

上記、報道内容が正しいと仮定してボクが推測したことは以下の通りです。

・KADOKAWAの正規のメールアドレスを利用してKADOKAWAのユーザへKADOKAWAのフィッシングサイトへ誘導するメールを送信したのではないか?

・そうすることによりフィッシングサイトがテイクダウン(停止)されるまでフィッシングメールに引っかかった人のユーザID、パスワード(平文)で盗み出すことが可能となる。

・KADOKAWAのサイト自体を改ざんして情報を盗む方法を取らなかったのは改ざんに気付かれた時点でユーザの情報を盗めなくなってしまう。しかし、フィッシングメールでのフィッシングサイトへの誘導であればサイト上での異変に気付いてもメールは既に送信されているためサイト側では対策を講じることができず、フィッシングサイトをテイクダウンされるのを待つのみとなり、ユーザの情報を盗むための時間稼ぎができる。

・今回侵害を受けたKADOKAWAのサーバからアクセスできる範囲にユーザのID、パスワードが存在した場合、そちらも盗んでいる可能性がある。その盗んだ情報はパスワードが暗号化、ハッシュ化されている可能性があるためにそちらは現在、別のサイトへのリスト型攻撃などのために平文に戻す作業をしている可能性がある。

・上記によって攻撃者はユーザID、パスワード(暗号化、ハッシュ化されている可能性あり)に加えて、フィッシングサイトからユーザID、パスワード(平文)も入手できるというメリットがあると考えられる。また、フィッシングサイトによるパスワードの入手は平文に戻すには時間がかかる複雑なパスワードも平文で入手できる可能性があるということもメリットである。

もちろん、以上は推測ですので当たっているかもしれませんし、外れているかもしれません。
あくまで攻撃者が考えそうなことを推測してみました。
今後、詳細が公表されることを待とうと思います。

【2014年3月24日 22:50追記】
[続報]KADOKAWAへの不正アクセス、大手銀行を装うフィッシングが目的
続報が出ていました。

出版大手のKADOKAWAのサーバーが不正アクセスを受けた問題において、同社サーバーを経由して大手銀行を装うフィッシングメールが送られていることが判明した

とのことです。
良いのか悪いか分かりませんが予想ははずれました。

【2014年3月23日 14:40追記】
このエントリについてご意見をいただきました。
頂いた意見を要約したものは以下の通りです。

自社サービスのIDを盗むフィッシングメールの送信に使われたのなら、トップページでもっと具体的に注意喚起をすると考えられる。具体的な注意喚起ができない理由として自社ではなく他社のサービスを騙ったフィッシングメールに使われたかということも考えられる。また、メールの送信や中継に使われたのではなく、フィッシング画像などのコンテンツのホスティングに使われたという可能性も考えられる。

KADOKAWAのドメインのメールで同サイトのフィッシングサイトへの誘導をすると怪しまれる率、スパムフィルタを抜ける率が高まり、結果的に平文パスワードを入手できる率が高まると考えたので今回ボクは、KADOKAWAに閉じた攻撃で推測してみました。頂いた意見のような可能性は充分に考えられると思います。
また、実際のメール送信や中継ではなくコンテンツのホスティングに使うという可能性はボクには考えついていませんでした。


Category: memo | KADOKAWAが不正アクセスされフィッシングメールに悪用された可能性について考えてみました。 はコメントを受け付けていません
2月 13

Active Directoryを利用したEMETの制御

Active Directoryの機能である「グループポリシー管理」を用いて、Active Directory配下のクライアントに対するEMETの自動インストールと、ポリシーを用いた制御を目的とします。本文書では、「グループポリシー管理」を利用してEMETを自動配信する方法と、「グループポリシー管理」へEMETのテンプレートを追加する方法を記載します。

■EMETとは
Enhanced Mitigation Experience Toolkitの略称で、Windows上で動作する様々なアプリケーションに対し、脆弱性を利用した攻撃の発生を防ぐツールです。以下にEMETの動作イメージを挙げます。

01_EMETの動作イメージ3

EMETの役割は、ユーザが細工されたアプリケーションを操作した際に、クライアント上で細工されたアプリケーションが実行されるのを防止する、というものです。

 

■EMETの導入方法
最新版のEMET(バージョン4.1)は以下のサイトからダウンロードが可能です。

Enhanced Mitigation Experience Toolkit

クライアントに対して個別にEMETのインストールを行う場合は、ダウンロードしたファイルをそれぞれのクライアント上で実行しインストールを行います。
一方で、Active Directoryのグループポリシー機能を利用し、配下のクライアントに対してEMETの配信を行うことが可能です。Active Directory内の共有ファイルサーバを利用して、EMETをクライアントに自動的にインストールさせます。

【配信の準備】
バージョン4以降のEMETのインストールには、.NET Framework4.0の導入が必要です。予めEMETを配信したいクライアントに、.NET Frameworkをインストールしておきます。また、配信用のEMETインストーラを、UNC表記で接続可能なネットワーク上の共有ファイルサーバへ配置します。

【クライアントへの配信】
①「グループポリシーの管理」より、EMETを配信するためのポリシーオブジェクトを作成します
(例:下図では、[EMET Test]という名前のポリシーオブジェクトを作成)

02_オブジェクトの作成

②配信用のポリシーオブジェクトにEMETを追加します
[コンピューターの構成]→[ポリシー]→[ソフトウェアの設定]→[ソフトウェアインストール]を右クリックし、「新規作成」を選択

03_EMETの追加

③UNCパス表記でEMETを登録します
ネットワークサーバ上のEMETを、UNCパス(\\サーバ名\ファイルパス)で登録

04_UNC表記

④EMETがポリシーオブジェクトに追加されていることを確認します

05_オブジェクトの確認

⑤「グループポリシーの管理」から、先ほど作成したポリシーオブジェクトをコンテナへリンクさせます

06_オブジェクトの設置

⑥クライアント上でインストールされたことを確認します
クライアントの通知領域にEMETが存在していれば完了

07_EMETインストールの確認

 

■グループポリシー管理を用いた制御
Active Directoryのポリシーを管理しているサーバの、ポリシーを格納しているフォルダに、EMETを制御するためのポリシーテンプレートをコピーします。

①EMETのインストールフォルダ内にadmlファイルとadmxファイルが存在するので、この二つのファイルをコピーします

08_EMETテンプレートの場所

②ポリシーを格納しているフォルダにペーストします
ポリシーの格納フォルダは、デフォルトでは%SystemRoot%\PolicyDefinitions

09_ポリシーを格納する場所

③「グループポリシー管理」のポリシーオブジェクトからEMETのテンプレートが追加されていることを確認します
[コンピューターの構成]→[ポリシー]→[管理用テンプレート]配下に[EMET]が追加されていれば完了

10_EMETテンプレートの確認

Category: memo | Active Directoryを利用したEMETの制御 はコメントを受け付けていません
2月 4

JALマイレージバンクについて個人的まとめと雑感

oriduru1r

このようなニュースがありました。
「JALマイレージバンク」に不正ログイン、マイル盗む 数字のみパスワードの強化策は「検討していない」
以下は記事の引用です。

同社はメールとWebサイトを通じ、全ユーザー2700万人にパスワードの変更を依頼。JALマイレージバンクのパスワードは数字6ケタだが、数字だけのパスワードが脆弱という認識は「ない」(同社広報部)としており、ケタ数を増やしたりアルファベットを加えるなどの強化策は「検討していない」という。

割と衝撃的な回答ですね。

ちなみに各社のポリシーは以下の通りでした。

・JAL
半角数字6桁

・ANA
半角数字4桁

・ソラシドエアー
6文字以上12文字以内で、半角英数のみ

・スターフライヤー
半角数字4〜8桁
*全て同じ数字は利用できない。

・AIR DO
数字のみの場合8文字以上20文字以下、英数字の場合6文字以上20文字以下

・スカイマーク
サービスなし?

Splash Dataというところが発表した2013年のよく使われる脆弱なパスワードランキングによると「123456」が1位のようですのでこれでリバース攻撃を行なわれたらJALは6桁数字パスワードだし… と思っていたのですが実際にパスワード変更にて確認してみたところ「123456」は設定できませんでした。改めて別ページにあった「パスワードに使用できない組み合わせ」を確認したら以下のような制限があるようです。

(1) 生年月日(西暦・元号とも)
(2) 電話番号
(3) 住所の数字部分
(4) 111111などの連続する同じ数字
(5) 123456などの連続する数字
(注)(4)以外は、順序を逆にしたパターンも使用できません。

しかし、よく使われる脆弱なパスワード11位の「123123」は設定可能でした。
連続する数字に関しても確認してみたところ「111112」というものは設定可能であったため連続する数字というのは6桁すべてが同じものという意味のようです。ちなみに「123451」も可能でした。
このルールを事前に調べておけばそもそも使えないパスワードが分かりますので、攻撃者はその他の弱そうなパスワードを試そうという思考になり実際に試す候補が絞り込めとも考えられなくもないですね。

また、JALはパスワードについてこのようなページも用意しています。
以下は引用です。

パスワードは、個人情報および積算マイルの保護のため、定期的に変更することをお勧めいたします。またパスワード変更時には、生年月日、電話番号、連続する同じ番号等、推測されやすい番号はご使用にならないようご注意ください。

少し拡大解釈しすぎかもしれませんが、今回のパスワードの強化策を講じないということ、数字のパスワードは脆弱という認識は無いということから考えると、あくまで責任はユーザにあると言っているようにも取れます。
もちろん、弱いパスワードを設定しまうことに関しては一部ユーザの責任であると考えることもできますが、その前に設定できるパスワードの自由度を上げることがサービス提供側の責任でもあるのではないでしょうか。数字6桁のみとなると脆弱なパスワードを設定することを誘発していると考えることもできます。

ただ、数字のみのパスワードというのには理由があるだと思います。
例えば電話での予約や確認サービスの利用などでしょうか。
ただ、電話予約やその確認のためなどに数字6桁のみのパスワードというものを残さないといけないというのであれば、Webログインやその先にできるものは別のものにするか、二要素(段階)を導入して欲しいと思います、

とはいえ、今すぐシステムをどうにかということは現実的に無理だとは思います。
だから、「数字だけのパスワードが脆弱という認識は「ない」」などと言わず、10年以上前から多くの方が指摘されてきたことであるということを受け止めて、これをよい機会とし、今後のセキュリティ強化に努めていく一歩を踏出していただきたいと強く思います。もちろん、JALだけではなくです。

【おまけ】
Wikipedia – JALマイレージバンク の 概要の項目を見るとお得意様番号にはある程度の規則性のようなものがあるようですね。

【2014/02/05追記】
紹介したITmediaの記事に追記がありました。

2月4日午後8時50分追記

 その後の取材に対してJAL広報部は、「パスワードの方法を含めて今後の対応を検討していきたい」と話した。

とのことで新たに記事も追加されていますね。
JALマイレージバンクの不正ログイン、セキュリティと利便性のバランスが問題に?

今後、各社安心、安全に繋がる対応に期待です。

Category: memo | JALマイレージバンクについて個人的まとめと雑感 はコメントを受け付けていません
1月 29

リモートデスクトップにPass-the-Hashしてみました。

rd_cut
Kali Linuxのblogを見て試してみました。

Pass-the-Hashって何?という方もいらっしゃると思いますので(かなり)簡単に説明します。
WIndowsはログオン(最近はサインインと言うようですね。)パスワードは平文ではなく、ハッシュ関数を用いてハッシュ化して保存されています。

ntsujiというユーザ名でntsujiというパスワード設定した場合は以下のように保存されました。

ntsuji:1001:NO PASSWORD*********************:622BB9FF06C09173842E03C47E49F33F:::

「622BB9FF06C09173842E03C47E49F33F」の部分が「ntsuji」というパスワードをハッシュ化したものです。

通常ログオンする際には、「ntsuji」と設定したパスワードを入力しなければログオンできません。
これはリモートデスクトップでも同じことです。
しかし、このハッシュ化された文字列を用いてログオンする手法があります。
それがPass-the-Hashです。

それの何が便利なの?ということなのですが、何も便利ではありません。
通常使っている分には。
しかし、攻撃者からするととても便利な手法なのです。

例えば、1台のコンピュータへの侵入に成功し、そのコンピュータからパスワードハッシュを入手したとします。その情報を使って他のコンピュータに侵入を試みるには、通常のログオン同様、ハッシュ化されたパスワードではなく、元のパスワード、つまり、平文のパスワードが必要になるわけです。
そのためには一旦、そのパスワードハッシュを平文の戻す作業が必要となり、一手間多くかかってしまいます。パスワードの強度次第では平文に戻すための作業にかける時間が膨大になる、もしくは、現実的な時間では戻せない場合もあります。そこで、Pass-the-Hashを用いることでパスワードハッシュさえあれば、それを使って侵入を試みるということが実現可能となるわけです。
もちろん、手元にあるパスワードハッシュが他のホストで使用されているものと異なる場合は侵入には成功しません。逆にいうとパスワードの使い回しが行なわれていれば一網打尽にできてしまうということになります。
ここまで書いて思い出したのですが過去に@ITの「セキュリティ・ダークナイト」でも触れていましたのでそちらも参考にしていただければ幸いです。

パスワードの定期変更という“不自然なルール” (4/4)

そろそろ本題です。

今までは、リモートデスクトップではPass-the-Hashを行なうことはできませんでした。
しかし、RDP 8.1からは、Restricted Admin Modeがサポートされたことにより可能となったようです。

ということで試してみました。
利用するツールは「FreeRDP」なのですが、公式のものにパッチを適用するか、こちらを利用する必要があります。

Kali Linuxを利用している場合は

apt-get update
apt-get install freerdp-x11

とすればPass-the-Hashに対応した「FreeRDP」を利用することができます。

シンタックスは以下の通りです。

xfreerdp /u:ユーザ名 /pth:パスワードハッシュ /v:ターゲットのアドレス

以下が、Windows 8.1への実行結果です。
8.1

特に問題なくパスワードハッシュを用いてリモートでスクトップを利用することが可能でした。

ちなみに、RDP 8.1は、Windows 8.1、Windows 2012 R2からですので、それ以前のOSではこの手法は使用できません。
念の為、Windows 8とWindows 7にも試してみました。

【WIndows 8 の場合】
8

【WIndows 7 の場合】
7

また、ターゲットとする権限は「Administrators」に属している必要があり「Remote Desktop Users」ではこの手法は利用できないようです。以下は、Windows 8.1上に作成した「Remote Desktop Users」に属する「rdp-user」へPass-the-Hashを行なった結果です。
8.1rdpuser

RDP 8.1 で「Administrators」に属さないないユーザではもPass-the-Hashによるログオンができないということがお分かりいただけたかと思います。

【2014/01/30追記】
Restricted Admin modeについて北河拓士さんからコメントをいただきました。
以下はその内容をまとめたものです。

Restricted Admin modeの導入の理由としては、既に侵入されてしまっているマシンに対して、ヘルプデスクがメンテナンスを行なうためにリモートデスクトップでDomain Adminsに属するユーザででログオンした際「mimikatz」などを利用してメモリ上からそのDomain Adminsに属するユーザのパスワードを平文で取得されないように制限を付けるというメリットのためです。
Restricted Admin modeについての説明をした資料はこちら[PDF]が詳しいかと思います。

セキュリティ強化を行なうために導入された機能が新たな攻撃方法の成功を生んでしまうことはなんとも皮肉なことかもしれませんが、攻撃者が既にハッシュを持っているという状態で行なう攻撃ですとリモートデスクトップとは別の経路でPass-the-Hashも可能です。それらを考慮すると以前よりもセキュリティ機能としては+αされたと言えるのではないかと思います。

Restricted Admin modeが導入されている環境下での「mimikatz」実行結果に関してのエントリーはまた別の機会に。

Category: exploit, memo | リモートデスクトップにPass-the-Hashしてみました。 はコメントを受け付けていません
1月 20

Raspberry Pi をTorルータにするメモ

tor_on_raspberrypi

onion pi」や「SafePlug」など海外ではお手軽にTorを使うことのできるTorルータが販売されているようですが日本では、送料や到着までの時間など購入のハードルが高いので自作をしてみました。そのときのメモです。
今回は「RPi – Raspberry Pi で Tor ルーター ( Onion Pi )を構築する方法」をかなり参考にさせていただきました。netbuffaloさんありがとうございます。
Raspberry Pi初心者!という方には同じく、netbuffaloさんの「RPi – Raspberry Pi ファースト・インプレッション + 押さえておきたい初期設定」を参考にされるといいと思います。

ネットワーク環境は下記の通りです。
自宅ネットワーク 192.168.0.0/24
Torルータネットワーク 10.0.0.0/24

まずはupdateとupgradeを済ませておきます。

sudo apt-get update
sudo apt-get upgrade

次にRaspberry Piの無線LANインターフェイスにIPアドレスとネットマスクの設定

sudo ifconfig wlan0 10.0.0.1 netmask 255.255.255.0 up

ここで設定したアドレスがクライアントとして接続したコンピュータのゲートウェイとなります。

/etc/network/interfacesを編集。

sudo vi /etc/network/interfaces

下記のようにアドレスを設定

iface wlan0 inet static
address 10.0.0.1
netmask 255.255.0.0

この際に先に記述されている箇所を下記のようにコメントアウトしておきます。

#iface wlan0 inet manual
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
#iface default inet dhcp

【DHCPのインストール】
接続してきたクライアントにIPアドレスを貸し出す為にDHCPサーバをインストールして、自動起動を停止させます。

sudo apt-get install isc-dhcp-server
sudo update-rc.d isc-dhcp-server disable

DHCPでIPアドレスを貸し出す側のインターフェイスの指定するために下記ファイルを編集。

sudo vi /etc/default/isc-dhcp-server

インターフェイスにwlanを指定するため下記記述へと編集。

INTERFACES=”wlan0″

次に設定ファイルを編集します。

sudo vi /etc/dhcp/dhcpd.conf

設定ファイル内に下記の記述を追加します。
ここは自身の環境に合わせて設定値を変更してください。

ping-check true;

subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.1;
option subnet-mask 255.255.255.0;
option domain-name “local”;
option domain-name-servers 8.8.8.8,8.8.4.4;
default-lease-time 600;
max-lease-time 7200;
range 10.0.0.2 10.0.0.254;
}

「option routers」は、無線LANインターフェイス(wlan0)のIPアドレスを設定。
「option subnet-mask」は、同じくサブネットマスクを設定。
「options domain-name」は、自身の好きなドメイン名を設定。
「option domain-name-servers」は、使用するDNSのアドレス。
ここではGoogle DNSを設定しています。
「default-lease-time」は、標準のIPアドレスの割り当て時間。クライアントがDHCPREQUESTを出さない場合はこの貸し出し時間となります。
「max-lease-time」は、最大のIPアドレスの割り当て時間。クライアントがDHCPREQUESTを出した場合でもこの時間を超えることはできません。
「range」は、クライアントにIPアドレスを貸し出す際の範囲。

以上、準備ができたらDHCPサーバを起動します。

sudo /etc/init.d/isc-dhcp-server start

【hostapdのインストール】
次に、無線LANインターフェイスをアクセスポイント化するためにhostapdをインストールして、自動起動を無効化します。

sudo apt-get install hostapd
sudo update-rc.d hostapd disable

次に設定ファイルの作成です。

sudo vi /etc/hostapd/hostapd.conf

下記、記述を追加します。

interface=wlan0
ssid=好きなSSIDを指定
hw_mode=g
channel=3
wpa=2
wpa_passphrase=接続の際のパスフレーズを指定
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP

WN-G300UA(Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter)では、hostapdを動作させることができないので「Realtek Semiconductor」社のサイトから最新のドライバをダウンロードしインストールします。ファイル名は「RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911」です。
(WLI-UC-GNMではapt-getで入るhostapdで問題なく動作させることができました。)

ダウンロードしたファイルを展開し、make、既存の物との置き換えをします。

unzip RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip
cd RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911/
cd wpa_supplicant_hostapd/
tar zxvf wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz
cd wpa_supplicant_hostapd-0.8_rtw_r7475.20130812/
cd hostapd/
make
sudo cp ./hostapd /usr/sbin/
sudo cp ./hostapd_cli /usr/sbin/

これで無線LANインターフェイスがアクセスポイントとして動作するようになります。

sudo hostapd /etc/hostapd/hostapd.conf

上記コマンドを実行した後に「hostapd.conf」のSSIDで設定したものがWiFiネットワークを検索したときに表示されれば問題なく動作しています。
(上記コマンドではフォアグラウンドで動作するので同じターミナルで作業を続ける場合はバックグラウンドで動作させてください。もしくは別のターミナルで作業を続けてください。)

【Torのインストール】
次にTorのインストールして、自動起動を停止します。

sudo apt-get install tor
sudo update-rc.d tor disable

インストールが完了したら、設定ファイルを編集します。

sudo vi /etc/tor/torrc

設定ファイル内に下記の記述を追加します。
ここは自身の環境に合わせて設定値を変更してください。
「TransListenAddress」と「DNSListenAddress」をwlan0のアドレスに設定してください。「TransPort」は任意のものでも問題ありません。

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 9090
TransListenAddress 10.0.0.1
DNSPort 53
DNSListenAddress 10.0.0.1

次にTorのログファイルを作成します。

sudo touch /var/log/tor/notices.log
sudo chown debian-tor /var/log/tor/notices.log
sudo chmod 644 /var/log/tor/notices.log

上記設定ができたら設定を反映させるためTorサービスを再起動します。

sudo /etc/init.d/tor restart

【iptablesの設定】
次にiptabelsを使って無線LANインターフェイスで受信したDNS通信をwlan0のUDP 53番ポートへ、TCP通信をwlan0のTCP 9090へリダイレクトするように設定します。

sudo iptables -t nat -A PREROUTING -i wlan0 -p udp –dport 53 -j REDIRECT –to-ports 53
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp –syn -j REDIRECT –to-ports 9090
sudo iptables -A FORWARD -i eth0 -o wlan0 -m state –state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

これでRaspberry Pi を Torルータにすること自体は完了です。
試しに接続をしてみてTor経由の通信が行なわれているかを「確認くん」などで確認してみるといいでしょう。

最後の仕上げとして各種の自動起動設定などを行ないます。

【自動起動などの設定】
iptablesの設定を起動時に読み込むようにするため行なった設定をファイルに出力します。

sudo sh -c “iptables-save > /etc/iptables.tor.ap”

hostapdの起動スクリプトを編集します。

sudo vi /etc/init.d/hostapd

設定を行なった設定ファイルのパスを「DAEMON_CONF」に追加します。

DAEMON_CONF=/etc/hostapd/hostapd.conf

最後に「rc.local」を編集します。

sudo vi /etc/rc.local

下記内容を追加します。

service isc-dhcp-server start
service hostapd start
service tor start
iptables-restore < /etc/iptables.tor.ap

これで再起動をしてもRaspberry piがTorルータとして動作するはずです。

myonionpi

Category: memo | Raspberry Pi をTorルータにするメモ はコメントを受け付けていません
1月 16

JICS2014に参加してきました。

jics2014

JICS(JAPAN IENTITY & CLOUD SUMMIT)2014でお話をしてきました。

ボクが出させていただいたトラックはこういう感じのものだったのですが構成としては
根岸さん、ボク、徳丸さんの順番にそれぞれの視点(ボクは攻撃者視点)でお話をしてから
その3名に楠さんを加えてパネルディスカッションを行なうというものでした。

ボクがお話したときの資料はコチラ
(ただ、これを見ながら聴いていただくための資料で、持ち帰りを前提とした配布資料的なものではないのであしからず。)

全体的にいつも参加しているイベントと違い、自分としてはとても新鮮な雰囲気でした。
このイベント自体がセキュリティオンリーなものではないので、そこがそもそも新鮮さを誘発する要因だったのかもしれませんね。ふと思ったのですがセキュリティって色々なものに関連するにも関わらず、切り離してセキュリティだけで独立したものが多いような気もします。
例えば、Webアプリを開発されている方はデータベースやWebサーバなどなど関連する方々と割と繋がっているイメージがあります。自戒として色々なところに話を聴きにいかないといけないな。などとぼんやり思いました。

パネルディスカッションのときには色々なお話をしたと記憶してるのですが、自分的に今回のボクは些か控えめだったように思います。その分、自分の話した内容を割としっかりと覚えています。折角なので自分が振り返ることができるという意味でも2点ほどメモしておきます。

【パスワードを覚えられない方はこちら】

パスワードって色々なところにあります。
ネットワーク上のサービス、銀行ATM、各種デバイスなどなど。
1つも使っていないって人を探す方が難しいのではないでしょうか。
そんな状況の中で
「複雑なパスワードを設定して、サービスごとに別々のものを設定して使い回しをしない。」
という人力のみでは割とハードルの高いものを要求されます。
ボク自身はパスワード管理ソフトを使っているのでそれほど苦ではないのですが、これをすべての人が使いこなせる、使おうと思うかどうかというと答えは絶対に「No」だと思います。
ボクの実家の家族のコンピュータにはアンチウイルスをインストールしてありますし、Windows Updateなどの各種アップデートもするように伝え、その方法も覚えてもらいました。
これだけでもやっとだったのに、これに加えてパスワード管理ソフトの使い方を覚えるとなると相当ハードルが高くなるとボクは思います。
コンピュータに明るい方は、簡単だと思ってしまうのだと思いますが、それと同じ事を自分のお父さん、お母さん、さらには、おじいちゃん、おばあちゃんができるか?ということを考えればおそらく多くの方はボクと同じような答えになるのではないでしょうか。

そんな中、1つの方法としてサービス提供側がユーザ登録時に強固なパスワードを発行して、それを使ってユーザはログインし、自分の好きなものに変更することはせず、再度ログインするときには再発行/リセットするといった「なんちゃってワンタイム」(実際には再発行/リセットするまで同じパスワードなのでワンタイムとは呼べませんが)的な運用を行なうという選択肢もあってもいいのかも?と思いました。
もちろん、再発行/リセットを行うためのメールアカウントなどは死守する必要はありますが、記憶/記録しておかなければならないものが減りますし、サービス提供側が毎回強固でランダムなものを発行すれば
「複雑なパスワードを設定して、サービスごとに別々のものを設定して使い回しをしない。」
ということは満たされますし、リスト型攻撃などによる被害状況は改善されるのではないかと思います。
(追記:再発行とすると平文でパスワードがメールで届くことがイメージされるため、再発行から再発行/リセットとしました。)

そんな事をパネル中に考え

「こういう運用をしたい人には
パスワードを忘れた方はこちら
みたいに
パスワードを覚えられない方はこちら
みたいなリンクがあってもいいんじゃないでしょうか。」

という発言をしました。

【続きを読むには…】

記事の続きを読みたいけど…
資料をダウンロードして読みたいけど…

その為にはユーザ登録しなければならない。
多くの方が出会ったことがある状況でしょう。
登録を求める側も個人情報が欲しいので、その気持ちは分かるのですが
本当に面倒ですよね。アレ。

そのためだけに登録するのは…うーん… と思いますし
頑張って「続きを読む」にしても表示してみたら2行ぐらいしか続きがなかった…
なんてことに遭遇し、どっと疲れたこともあります。

パスワード管理の観点からすると管理しなければいけないアカウントが増え
これも簡単なパスワード、使い回しを誘発する要因となると考えられます。

そこで、言い方は悪いですが

「ユーザにとって価値の低いと考えられるアカウントだけを
ID連携でまとめてしまうというのもあってもいいのではないでしょうか?」

という発言をしました。
実現するかどうかは別にして以外と楽になるんじゃないかなって思います。

上記、2点はあくまでアイデアレベルですので、実現するには様々な課題もあるのだとは思います。
そして、もっともっとセキュアでスマートな方法はあると思いますが、前述した通り、すべてのテクノロジーをすべてのユーザが使いこなせるわけではありません。また、金銭をはじめとする様々な事情があり、すべてのサービス提供側がそのテクノロジーを導入できるわけでもありません。
できる方はどんどん前に進みますが、そうではない方はどんどん取り残されるばかりです。
しかし、本当に守ってあげなければいけないのはそういう方々なのではないかなと一人のエンジニアとして思いました。弱きを守るのがセキュリティだと思うのです。

0か100のどちらか。
ではなく「よりよい程度と選択」なのだろうな。
ということを考えたパネルディスカッション、イベントでした。

ntsuji_jics2014

セッションを聴講された方々のツイートを
novさんが
まとめてくださっているのでご興味あるかたはお読みいただければと思います。

Category: memo | JICS2014に参加してきました。 はコメントを受け付けていません
1月 6

MacでRaspberry Pi用のOSをSDにインストールするメモ

Windowsでのメモは多いのですがMac用のメモをあまり見かけないのでメモしておきます。

【準備】
ここから好きなディストリビューションをダウンロード。
(今回、ボクはRaspbianをダウンロードしました。)

ここからRPi-sd card builder をダウンロードします。

それぞれダウンロードしたら展開を行なってください。
01

【作業】
MacにSDカードを挿入してRPi-sd card builderを起動します。
起動するとイメージファイルを指定するようにとのメッセージが出るので予めダウンロードしておいたイメージファイルを指定し「選択」をクリックします。
02

SDカードが接続されているかの確認メッセージが表示されるので問題なければ
「Continue」をクリックします。
03

次にオプション画面に移りますので使用するSDカードにチェックを入れて「OK」をクリックします。このとき挿入されているSDカードが1枚の場合は始めからチェックが入っていると思います。複数表示されている場合は目的のSDカードにのみチェックをしてくください。
04

次に管理者パスワード(使用しているMacのパスワードです。)が
要求されるので入力し「OK」をクリックします。
05

SDカードが取り外されたかどうかの確認メッセージが表示されます。
ここではSDカードを物理的に取り外さず「Finder」でアンマウントされているかどうかのみを確認し、問題なくアンマウントされていれば「Continue」をクリックしてください。
06

これでSDカードにOSがインストールが開始されます。
(書き込み中はメニューバーで確認ができます。)
07

後は放っておくだけで暫くするとインストールが終わります。
08

これで作業は完了です。

SDカードをRaspberry Piに挿入し、使える状態になりました。

Category: memo | MacでRaspberry Pi用のOSをSDにインストールするメモ はコメントを受け付けていません
12月 24

パスワードの有効期間設定及び、パスワードの定期変更についてボクなりに再考してみましたよ。

総務省から「リスト型アカウントハッキングによる 不正ログインへの対応方策について(サイト管理者などインターネットサービス提供事業者向け対策集) 」がリリースされました。思うところがったので以前メモしたのですが、先日、その文書に関わった方と「パスワードの定期変更」についてTwitterでやり取りさせていただきました(やり取り内容はこちら)ので再度「パスワードの定期変更」について総務省からリリースされた文書(以下、文書)を参考に自分なりに考えてみようと思います。

ちなみにボクは、この策に対しては懐疑的、否定的で、リスト型攻撃を含む攻撃(辞書攻撃などを含む)に対抗する場合は、「パスワードの使い回しをやめる」ことと「容易に推測可能なパスワードは設定しない」という対策を行うべきだと考えており、定期変更は必要がないというスタンスです。(もちろん、自ら定期変更を行いたいという方は行っていただいても文句はありません。そこは自由だと思いますので。)

考えるポイントとしては
パスワードの有効期間設定及び、パスワードの定期変更の効果はあるか。
というものです。
また、関連する対策として
「パスワード履歴の保存」というものがあります。
こちらには以下のような記述があります。

パスワードの変更時期が来た際に、利用者が前回まで使用していたパスワードに戻してしまうなど、更新時期が来るたびに2つのパスワードが使い回しされては、攻撃者が保有するリストが再度有効なものになってしまい、意味がありません。そのため、上記(2)のパスワードの定期的な変更と合わせて、パスワードの更新履歴を保存し、変更時に過去のパスワードと照合して、数世代前に使用したパスワードへの変更を認めないようにすることも考えられます。

こちらも整理する際の考慮にいれます。

まずは、文書から読み取れる前提条件などの自分なりの整理。

【前提条件】
 ・ リスト型攻撃への対応。
 ・ 対象はオンライン上のサービスである。
 ・ サービスのユーザID、パスワードは利用者が設定できるサービスである。
 ・ サービス提供側が行える対策である。
 ・ ローカルネットワーク上のサービスやスタンドアロンコンピュータは対象外。

【リスト型攻撃の特徴】
 ・ ある程度の期間に渡り、検知に時間を要する。
 ・ 数万単位の不正ログインが行われる。
 ・ 利用者の通報、大量のエラーの発生、特定IPアドレスからの不正ログインの検知、社内の調査によって検知されている。
 ・ 指名、性別、生年月日、住所などの個人情報が閲覧されている可能性がある。

【定期変更関連以外に文書内で言及されている策】

 [予防策]
  ・ ID・パスワードの使い回しに関する注意喚起の実施
  ・ 二要素認証の導入
  ・ ID・パスワードの適切な保存
  ・ 休眠アカウントの廃止
  ・ 推測が容易なパスワードの利用拒否

 [被害の拡大を防ぐ対策]
  ・ アカウントロックアウト
  ・ 特定IのIPアドレスからの通信の遮断
  ・ 普段とは異なるIPアドレスからの通信の遮断
  ・ ログイン履歴の表示

整理は以上です。

さて、上記の整理を踏まえて

パスワードの有効期間設定及び、パスワードの定期変更の効果はあるか。

ということですが、効果があるとする主張される方の理由としては以下のものが挙げられるかと思います。

① どこかから漏えいしたリストの無効化を行うことができる。
② 万が一、ログインに成功されたとしても被害の拡大を防止できる。

それぞれ効果があるのかどうかということを考えてみます。

① どこかから漏えいしたリストの無効化を行うことができる。

こちらは、そもそもになるかと思いますが文書のP4で言及されている「ID・パスワードの使い回しなどの関する注意喚起」内にある

サービスごとに異なるパスワードを設定することが本質的な対策となります。

の部分ができていればパスワードの定期変更タイミングまで待つということを行う必要はないと思います。

また、Twitterでのやりとりで出てきたもので
「複数のサービスで定期変更のタイミングが異なるため、その異なるタイミングで各サービスで異なるパスワードを設定することを促すこととなるのではないか?」という意見がありました。
これに関してはあるかもしれませんし、ないかもしれません。
数字的な根拠はありませんが個人的な感覚としては、同じものを設定する、もしくは可能性が高いのではないかと思っています。仮に別のパスワードを設定されることがあったとしても許可されている世代数でパスワードを変更していく(3世代なら3つのパスワードをループさせる)という運用をユーザが行った場合、定期変更のタイミングのズレで一旦異なるパスワードとなったものが同じものになるタイミングを生んでしまう可能性もあるではないかと思います。ですので、必ずしも定期変更が使い回し減らすことには繋がらないのではないかと思います。

リスト型攻撃の特徴とは少し逸れますが、定期変更を繰り返すことで生まれるものはパスワードが容易に推測されるような文字列になり、それが複数のサービスで使い回されることの発生を誘発すると考えています。トレンドマイクロの調べによるとパスワードでログインが必要なWebの利用状況として、1ユーザあたり13.95サイト(標準偏差)を利用しているとのことです。使い回しをしない前提ですと、1人当たり約14のパスワードを覚えることになります。これに対し定期変更を行うとそれぞれのパスワードをその都度、覚えなおしになります。(パスワード管理ソフトやメモしている方は除く。)そうなれば、やはり、覚えやすいパスワード(つまりは攻撃者にも推測されやすい)を設定し、複数サービスで共通のものを設定してしまいがちとなるのではないでしょうか。

また、「どこからか漏れたリスト」と考えた場合、他から漏れたリストだけではなく、漏れた元とリスト型攻撃が行われる対象が同じという場合もあると思います。
漏れたリスト(攻撃者からすると盗んだリスト)のパスワードが平文ではなかった場合(多くの場合そうであってほしいのですが)攻撃者は平文に戻す処理を行う必要があります。いわゆるオフラインクラックですね。この平文に戻す処理を行っている間に定期変更のタイミングがやってくれば、攻撃者のオフラインパスワードクラッキングを振り出しに戻すことが可能と言えるでしょう。
しかし、ここではリスト型攻撃の特徴として文書にも挙げられている

・ 数万単位の不正ログインが行われる。
・ 利用者の通報、大量のエラーの発生、特定IPアドレスからの不正ログインの検知、社内の調査によって検知されている。

といった特徴を利用してサービス提供側が早期発見し、リセットなどの対策を取ってほしいとボクは思います。

また、定期変更が招くと考えらえれる「容易に推測可能な文字列」を設定した場合は、パスワードの保存の方法にもよりますが、オフラインクラックに耐性のないものとなってしまう可能性があると考えられます。

② 万が一、ログインに成功されたとしても被害の拡大を防止できる。

こちらは、不正ログインされたタイミングからほど近く、うまい具合に定期変更のタイミングが来た時には効果はあると思います。ただ、文書中P3で言及されている「これまでのリスト型攻撃による被害の特徴」にある

氏名、性別、生年月日、住所などの個人情報が閲覧されている可能性があ
ること

これが仮に目的であった場合は不正ログインを行われてすぐにでもアクセス可能な情報であると考えられるためうまい具合に定期変更のタイミングで守られるとは考えにくく、守れることはかなりのレアケースなのではないかと考えられます。

それ以外の目的であった場合を考えてみます。

不正ログインを行った後、オンラインバンキングで送金処理を行う、ポイントサービスを用いてポイントを不正利用するなどが考えられると思います。前者の場合は、殆どの場合において新規の送金先に送金する場合は何かしらの追加認証が用意されていますので、実際に送金することはパスワードのみでは行うことができません。(住所変更などを行う場合も別の認証が設けられている場合もありますね。)後者の場合は残念ながら追加の認証がない場合が殆どです。では、これが定期変更のタイミングで守りきれるのか?と考えるとやはり疑問が残ります。

先日こんな事件がありました。

楽天ポイント盗み、電子マネーに=不正アクセス容疑で中国人逮捕-岐阜県警

IDとパスワードが流出! キミの楽天ポイントも知らずに盗まれる?

記事を読む限り、どこからか漏れたリスト(楽天でのログインができるできないの確認はしているかどうかは不明)を買い取ったとされる容疑者が犯行に及んだと考えられます。このケースの場合は、どこかからリストが漏れてから実際の被害が発生するまで、前に例で挙げた目的である個人情報を閲覧されるよりもタイムラグがあると考えられます。これであれば定期変更のタイミングでユーザがパスワードを変更すれば不正ログインすることを防ぐのに間に合うタイミングは多少あると思います。しかし、これもタイミングという曖昧なものに頼るのではなく、どこかから漏れたリストを使われたとしてログインできないよう使い回しをやめるというところに力を注ぐべきではないでしょうか。

また、サービス提供側でできる対策としては賛否が分かれるところではあると思いますが

Adobeの個人情報流出のお知らせ、なぜかEvernoteから

一部のYahoo! JAPAN IDに対するパスワードリセット措置について

といったことを実施しているところもあります。

【まとめ的なもの】

ボクの中では、やはり、どうしても「定期変更」によって得られる恩恵はかける労力に見合わなさすぎるという結論です。
ボクは前述した通り、、「パスワードの使い回しをやめる」ことと「容易に推測可能なパスワードは設定しない」に注力することが先決であるという考えは変わりません。
これら2つの対策は単体でも相当の効果が得られる(前者はリスト型攻撃に対して、後者は辞書攻撃などの推測でのログイン試行に対して)のに対して、定期変更は単体での効果も薄く曖昧で、かつ、この2つの阻害要因ともなりえると思っています。

ユーザにはユーザに委ねられる部分である

・パスワードの使い回しをやめる
・容易に推測可能なパスワードは設定しない

を行ってもらうようにし、サービス提供側が行えることについては定期変更に関するもの以外を運用との兼ね合いを考慮した上で行ってもらうというのが現状の現実解なのではないでしょうか。

もちろん、定期変更をやめることで、この2つの対策が必ず行われ、すべてがクリアになるのかというとそういうわけではありませんが、ユーザに対しては必要最低限の労力をかけてもらうようにし、何を行うべきかを示し、それに注力してもらうべきなのではないかとボクは思います。
対策としては、パスワード管理ソフトの使い方を覚えるか(場合によっては有料のソフトもあるのでお金が必要なケースもあります。)、メモというアナログな方法での運用でカバーかというところですね。どちらでもよいと思いますし工夫次第かと思います。ボクとしてはボクが便利と感じるパスワード管理ソフトをおすすめしたいところですが、すべての人が使いこなせるわけではないのでパスワード管理ソフト1択とはできないと思っています。
また、パスワード管理ソフトって言っても全てが有料というわけではありません。複雑なパスワードを設定して、使い回さず、定期変更が必要なのでパスワード管理ソフトを買わないといけませんよ!なんて言ってくる人がいたらそれは「セキュリティ詐欺」だと思っていいと思います。

「パスワードが長期間変更されていません。」
「パスワードは定期的に変更してください。」

といったようなことが書かれているところが消え
パスワードを設定する際に

「容易に推測可能なパスワードを設定していませんか?」
「他のサイトでのパスワードの使い回しをしていませんか?」

に対するチェックボックスなんかが表示されたり、そこを「はい」にしないと
それらの脅威を説明するページに飛ばされたりする日がくればいいなって思いました。
ちょっと鬱陶しいですかね?

Category: memo | パスワードの有効期間設定及び、パスワードの定期変更についてボクなりに再考してみましたよ。 はコメントを受け付けていません
12月 19

リスト型アカウントハッキングによる不正ログインへの対応方策について メモ

総務省から「リスト型アカウントハッキングによる 不正ログインへの対応方策について(サイト管理者などインターネットサービス提供事業者向け対策集) 」がリリースされました。そちらについての思うところメモ。

【P2】

このようなリスト型攻撃から個人情報や信用情報などを守るためには、利用者において、自身のID・パスワードの管理に際して対策を実施していただく必要があることは言うまでもありません。しかし、リスト型攻撃による不正アクセスの発生やそれに伴う個人情報の漏洩は、企業のコンプライアンス上問題となり、企業の信用を損ねる恐れがある他、内部調査及び復旧のためにサービスを停止する事態になれば、多くの機会損失が発生することになるなど、サービスを提供する事業者自身の問題とも言えます。

ユーザが設定するパスワードが推測可能なものか、使い回しているかということは最終的にユーザの責任において行われるべきものだと思います。
そこでユーザにきちんと注意喚起や保護する仕組みを提供することはサービス提供側が行ってほしいことではあると思います。しかし、おんぶに抱っこをしないからといって、それが企業コンプライアンスに関わるのかというとそれは違うと思います。
この類の話をするときにボクは自動車メーカーとドライバー(運転手)の話をします。自動車メーカーはサービス提供側、ドライバーはユーザです。
調べてみると分かるのですが(たとえばこのあたりとか)自動車メーカーは安全に対して様々な技術を取り入れています。エアバッグ、歩行者障害低減ボディ、アクティブセーフティ技術などなど。
こういった安全技術が取り入れられていたとしても、ドライバーが飲酒、スピード超過など危険運転を行ってしまっては元も子もありません。

これと同じでサービス提供側とユーザで各々が担う部分があり、双方の努力と歩み寄りを行うような空気や理解を広めていかなければならないのだと思います。サービス提供側が一方的に攻められ負担を強いられるようなセキュリティではあってはならないと思うのです。

【P4】

② パスワードを定期的に更新し、リストを陳腐化する

とありますが、複数のサイトで同一のパスワードを使い回していなければ「定期的」に変更し続ける必要はないと思います。サービスから漏えいが発生してしまったのであれば、ユーザへは漏洩が発覚したときに利用されていたパスワードを使って不正ログインできないようにするために一度変更してもらえばよいはずです。もしくは、サービス提供者の側でリセットを行い、以前使っていたパスワードとは別のものを再設定してもらうよう注意を促すほうがよいのではないでしょうか。もう少し踏み込んだサービス提供側のアクションとしては、他のサービス提供者で漏えいが発覚した際には、そちらの情報を元に注意を促したり、自サービスでパスワードのリセットなどを行うといったことも最近はちらほら行われてきているようです。

【P5】

(2)パスワードの有効期間設定

これに関しては同意できません。
パスワードの定期変更の理由として、定期変更のタイミングで被害を食い止めて、被害の拡大を防止するというものが挙げられますが、これは「情報は盗まれる。不正利用はされる。でも、され続けない。」という些細な効果しかないと思っています。ここの項目では有効期間を設定する理由として、どこからか漏えいしたID、パスワードのリストを陳腐化させるというものが挙げられているのですが、文末には

また、有効期間も一年、半年にするなど、事業者で管理している情報の価値に応じて設定することも一案です。

とあります。
仮に半年とした場合、最長で半年間は不正ログインされ続けることになりますのでリストを陳腐化することができる有効な対策とは言えないと思います。
数時間から数日で攻撃者は欲しい情報を手に入れていくことでしょう。
だからといって変更の感覚を短くすることはユーザへの負荷を高めるだけで利便性を大きく損ない、まさに本文に書いてある通り

ただし、パスワードの有効期限を短くして利用者に頻繁に変更を求めすぎると、利用者が、他人に推測されやすい簡単なパスワードを設定する傾向に陥りやすく、窃取される危険性を高めることもあるので注意を要します。

を招いてしまうことになると思います。

リストを陳腐化させることに対して敢えて、定期変更が有効であるという理由を挙げるとするならば、リスト型攻撃を行った攻撃者がリスト内の有効なアカウント(不正利用可能なアカウント)を確認した上で自分ではそれ以上のことを行わず、他者に売り渡すというパターンでしょうか。それでもやはり半年というのは悪用することにおいて十分な期間とも考えられますし、そもそも、リスト型攻撃のような分かりやすい攻撃が発生していることをサービス提供側がいち早く検知し、対処を行う仕組みを用意することのほうが必要で有効であると言えると思います。
(これについてはP11で触れられていますね。)

【P11】

② 攻撃が行われているIPアドレスからの通信を遮断する

これは有効だとは思います。
しかし、11月に起きた「GitHub」への攻撃では4万あまりにIPアドレスを使った攻撃(リスト型攻撃ではなくブルートフォース攻撃と言われている。)であるとのことですので、そういった場合は、有効性が低くなるということは理解しておく必要があると思います。巷には、リスト型攻撃対策として閾値を超えるログイン試行があった場合はその攻撃元のIPアドレスをブロックするという製品がありますが、リスト型攻撃を行われた場合、そのリストの質によっては、はその閾値以下のログイン試行は成功/失敗確認が取れるということになります。5回を閾値として6回目以降をブロックというものであればIP数 x 5回の確認は行えるということになります。また、閾値が外部から挙動をチェックすることで分かればその閾値以下ギリギリの試行を行って、別のIPに切り替えるということをすればブロックされたことを通知するようなアラートがあった場合、そのアラートは上げさせないということもできそうですね。
IPアドレスを頻繁に変えつつ試行を行っても短時間に行われれば通常よりも集中したアクセスであると検知しやすい側面があるのかもしれませんが、今後はもしかすると時間をかけたものも現れるのかもしれませんね。この辺りは攻撃者のトレードオフに対する考え方にもよるのだとは思いますが。

【さいごに】
リスト型攻撃って本当に厄介なものだなと思うわけですが、冒頭にも書いたようにサービス提供側とユーザ双方の努力と理解による歩み寄りが必要性が顕著に表れているものだなと思います。
過去にセキュリティって誰のためのものなのか?ということを考えたことがあるのですが、セキュリティって一部の専門家のためのものではなくて、脆弱性から保護することよろしく、弱い者(あるいは物、箇所)を守るためにあると思いました。とすれば、守る者と守られる者がいるわけで、つまるところ、みんなのものだと思います。みんなのものであればみんなで役割分担、当事者意識を持っていけるようなものにしていかないといけないなって心底思います。

地道でも頑張っていかないといけないなって改めて思います。

Category: memo | リスト型アカウントハッキングによる不正ログインへの対応方策について メモ はコメントを受け付けていません