(n)

ＫＡＤＯＫＡＷＡオフィシャルサイト( 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に閉じた攻撃で推測してみました。頂いた意見のような可能性は充分に考えられると思います。
また、実際のメール送信や中継ではなくコンテンツのホスティングに使うという可能性はボクには考えついていませんでした。

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

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

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]という名前のポリシーオブジェクトを作成）

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

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

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

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

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

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

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

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

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

このようなニュースがありました。
「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桁のみのパスワードというものを残さないといけないというのであれば、Webログインやその先にできるものは別のものにするか、二要素（段階）を導入して欲しいと思います、

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

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

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

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

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

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

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

「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ルータとして動作するはずです。

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

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

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

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

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

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

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

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

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

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

という発言をしました。

【続きを読むには…】

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

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

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

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

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

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

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

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

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

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