iCloudハック事件の手口はガードできる
相変わらずはてブしている人達はやべーやべー言ってて、件の記事「iCloudハック事件の手口がガード不能すぎてヤバイ」を書いた人は的外れな続きの記事「ソーシャルエンジニアリングは他人事じゃない」を書いているわ…
英語が正しく理解できない人か、原文をちゃんと読んでいないかのどっちか。
この方に限らず、原文を読んでいない人が多すぎ。しょうがないからかわりにじっくり読んで時系列を沿って今回の事件の手順をちゃんと整理して書きます。自分自身の整理がなっていないので、自分のメモとして（当ブログの趣旨）ですが。
１．@matという三文字ツイッターアカウントに目をつける
２．ツイッターアカウントに出ているHPにアクセスしてみた
３．HPにgmailのアドレスを発見し、ツイッターアカウントのメアドじゃないかと推測("Holla"のとこ)。
４．グーグルでログインできねーページからアカウントパスワード忘れたって手順に進む。
----
※ ここでグーグルアカウントの２段階認証を有効にしていたら以下の一連の流れは防げた。正確に言えばハッカー達は２段階認証が有効であったなら諦めていたと言っている。
２段階認証が有効な場合「このアカウントに対して 2 段階認証プロセスが有効になっているようです。 パスワードを再設定するには、電話で取得した確認コードを入力する必要があります。電話がない場合は、アカウント再設定の完了までに 3～5 営業日かかることがあります。」と出る。有効でない場合は「次の予備メール アドレスにパスワード再設定リンクを送信: ho••••••••••••••••••@hogehoge.com」みたいに予備のメールアドレスが出る。
----
５．予備のメールアドレス「m••••n@me.com」が出たぜ！あれ？＠の前の文字数がgmailのと一緒じゃね？そして始まりと終わりも一緒じゃね？なるほど、me.comのアカウントたぶんわかった！
６．me.com(アップル)はメールアドレス・請求先住所(billing address)・クレジットカードの下四桁番号があれば新しくパスワードを発行してくれるのは周知の事実。
７．メールアドレスはわかっている。請求先住所はさっきのHPのリンクにあるドメイン(honan.net)のwhoisかけてみたらjoker.comが出てくる…joker.comで検索してみると、おお、Billing contact: って出てくるじゃないか。CNET-から始まる識別番号みたいなのになっているけどリンク付き！リンクをクリックして無事請求先住所を入手できました。
----
※ ここで登録している住所を非公開とかにしていれば、正確な請求先住所は入手できなかったでしょう。もっともhonan.net上に、請求先住所と同じ住所を自ら公開していたので今回の件では無意味だったのでしょうけど…
ちなみに( ﾟÅﾟ)んーはnnnnn.meとnnnnn.coを利用していますが両方とも、個人情報は非公開にしています（厳密に言うと代理公開を利用しています）。
ドメイン情報を非公開にしていれば請求書先住所を入手されるような事はありません。しかし、自分で非公開設定・デタラメな内容を入力する事は禁止されています。非公開にする場合はちゃんとした手続きを踏んで代理公開を利用して下さい。
----
８．次にクレジットカード番号の下四桁を知りたいわけですが、ここでアマゾンが活躍登場します。アマゾンへ電話し、新規クレジットカード番号を追加したいと言えば、名前・メールアドレス・請求先住所があれば行える。全部情報が揃っているので新しいクレジットカード番号を追加できました。
９．アマゾンに再度電話をし、今度は「アカウント情報忘れちまったわー」って言う。名前・請求先住所・クレジットカード番号の下四桁の情報を提供する事により、アカウントに対してメールアドレスの新規に追加が行える。名前・請求先住所は判っていてクレジットカード番号の下四桁は先程登録した新クレジットカード番号のを言えば、ここはパス！
１０．次にアマゾンのウェブ上でパスワード再発行手続きを行う。新しく登録したメールアドレスに再発行メールが届きます。これでパスワードをリセットしてアクセスできました。アマゾンの" アカウントサービス >クレジットカード情報を編集・削除する"を見て、先ほど登録したものでない方の、クレジットカードの下四桁を確認する。
----
※ はてブとかではこのアマゾンの対応がかなり非難されているが、元記事ではこのアマゾンの対応自体はそこまで問題視していない。理由としてはピザハットでの注文を例に、このあと書くアップルの対応の原因がある限り（アップルIDを持っている限り）ピザ配達員とか誰でもできるからであるとしている。これは「ソーシャルエンジニアリングは他人事じゃない」で言っている佐川急便の配達員（またはそれを装った人が）の例と同じ感じである（物理ハッキングうんぬんは別として）。
----
１１．（６．に書いてある）必要な情報が出揃いました。これであとはアップルに電話すればiCloudにもアクセス可能な、AppleIDへの新しいパスワードを発行してくれます。
１２．me.comに入り込めればあとは簡単。グーグルアカウントのパスワード再発行を要求して、そしてグーグルアカウントに入り込みます。そしてツイッターアカウントのパスワード再発行を行なってツイッターアカウントを乗っ取ります。
１３．奪還阻止、途中で邪魔されないようにiCloudのリモート削除機能(Find My Mac)で削除を実行！
( ﾟÅﾟ)おわりでｓ
---
結論として、ハッキング被害にあった方はhoge@gmail.com・hoge@me.com・hoge@wired.comのように＠の前を統一してメールアドレスを使いまわしていたこと、Macbookのバックアップを取っていなかった事等を今回の反省として捉えているようです（それ以上にFind My Macを有効にしていなければよかったと言っているが、私はApple製品を持っていないのでここでは言及しません）。
この記事の結論として、ソーシャルエンジニアリングのキモはこの言葉に集約されているような気もします。
The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.
（訳）アマゾンが表示するのに問題ないと考えていた４桁の数字と、Appleが個人認証として使うのに適切であると考えていた４桁の数字は全く同じであった。
一方では重要でなくても一方では重要視されている、組み合わせによっては色々破る事ができるという事なのだろう。
iCloudアカウントハッキングに対して
iCloudハック事件の手口がガード不能すぎてヤバイという記事からガード不能過ぎてってあるが別に不能過ぎるわけではない。
そもそもソーシャルハッキングはそう新しいものではない。ここ10年ぐらいの話しで言えばだけどね。
さて、肝心のガード方法（？）だが、まずメールアドレスを使い分けるという事がキーとなる。
Tumblr、facebook、amazon、はてブとか様々なサービスを利用している人が多いと思いますが全てに共通して言えることがアカウントのログインはメールアドレスベースであるものが多い。これらのサービスを全て一つのメールアドレスで管理すると、一箇所から漏れた場合、アカウントに使われているメールアドレスの推察がかなり簡単になる。ってか、この連絡先を普通にウェブ上に公開している人も多いだろう。
メールアドレスじゃなくてアカウント名でログイン処理を行うサービスも沢山あったが、アカウント名を忘れるという人が非常に多いという理由で廃れた気がする。いや、まだそういうサービスもあるけど、アカウント管理がずさんだと、すぐ「あれ？ログインできねぇ…」って状態に陥る。実際自分の何度か経験している。
そして、アカウント名を忘れた場合メールアドレスを使って、アカウント名をメールで送ってもらったりその場で表示したりするのだけど結局はメールアドレスに紐付いて管理されているんですよね。
っという前置きで本筋に戻すと、今回の件は以下の問題点にあると自分は思う。
１．ウェブに公開しているメールアドレス(もしくはme.com)でamazonを使っていた
Amazonは基本的にメールアドレスがアカウント名となっている。上記の記事だけ読んでいるとAmazonテックサポートがだいぶ雑で問題だが、そこは自衛できる範囲外なので省略。
２．サービスに登録するアカウントを全てme.comで行なっていた
me.comが破られて、あとはアカウントのパスワード再発行メールが全てここに一括して行くのが問題。
３．簡単に推察可能なメールアドレスを主要アカウントとして使わない。
googleのパスワード再発行のメールアドレスに推察可能なメールアドレスが入っていたのも致命傷です。はっきり言って、”m••••n@me.com”って情報と、ツイッターアカウントが乗っ取られた後に臨時で使っていたツイッターID@mathonan（ようするに彼がよく使うID、ってか彼の名前）から誰しもme.comのメアドに想像がつくと思います。
（ここでは明記しませんがmathonan@me.comではありません。でも充分連想できます。ちなみにwired.comの記事中にはメアドが明記されています。）
っというわけでガード方法としては、推察可能なメールアドレスは使わない、メールアドレスは使わけてを複数運用すれば問題ないってのが判ります。
主要アカウントは推察が出来ないメールアドレスを使えばおｋ。それがgmailである場合は、二段階認証をしっかり付ける。複数管理めんどいワロタって人はThunderbirdにアカウント全部入れればおｋ。１アカウント追加なんて5分も掛からない。もしくは、webで転送設定をして、主要gmail.comにパスワード再発行宛先として指定する。充分に推測ができないメールアドレスにしておけば特定もされないだろう。
補足：
住所の特定はwhoisで行われています。ドメイン管理している人なら、ここで個人情報を公開している人も多いでしょう（私はプロテクションをかけてます）。
Amazonにクレジットカードを追加する際に「住所」・「名前」・「Eメールアドレス」だけで済み、この「住所」はWhoisで特定されたのが使われています。メールアドレスが特定されていなければ…っと考えるとやはりメールアドレスが推察可能かどうか、他のサービスに紐付けられているかどうか？がキーだと私は思います。
( ﾟÅﾟ)うｍ
LINEからの脱却方法
色々問題点が指摘されている中、LINEは着々とユーザ数を増やしています。
先日リア繋がりの人とLINEの今後の予測をしたのですが、( ﾟÅﾟ)んーはLINEはいずれ炎上して消えて行くだろうと予測しました。
理由としては以下の２点、
１．LINEの優位性はユーザ数の多さしかない
通常サービスやデザイン、何かしらの優位性が競合他サービスと比べてあります。この市場に至っては差別化が難しいというのもありますが、国内ユーザ数が極端に多い事を除けば特に優位と言える物が何も無いです。強いて言えばかわいいスタンプが豊富という点でしょうか。
（他の類似アプリを使ってみた感じ、LINEが特別かわいいと思える訳では無いのですが、女子高生・OL受けするデザインってのは良く判らないのでもしかしたらものすごく特別かわいいのかもしれません）
２．電話番号認証型のメリットを生かしきれていない
端末を変えること・電話番号を変えることが多い市場の中で、結局引き継ぎをするのにメールアドレスを登録しなければならないという手間が存在する。他の方々がLINEの仕組みや移行手順に関して言及しているので省きますが、結局この手間はしょうがないと思う。だったら別に電話番号と紐付ける必要ない。総当りできる電話番号と登録写真・HNを結びつける必要性がない。数億通りしかないアカウント名(数字のみ)を有していてしかも相手からの承認なしである程度の情報を参照可能と考えてもらえればリスクでしかないと感じない。こういうのは機能をもっと限定して、利便性のみ追求して電話番号を知っていれば話しかけたりする機能を削れば、色々メリットは出るかもしれないが、今後機能をどんどん追加していくようで電話番号紐付け型から脱却しないと、これはいずれ大きな問題となるだろう。
んじゃ、代替アプリとしてなにがいいんだよ、っていう話ですよね。
脱却ってか移行ってか、まぁ”脱却方法”とかいいつつ競合他アプリを紹介するだけなんですけどね。
kik messengerが良いと思います。理由は２点
１．電話番号紐付け型でない
メアド型なので、余計な心配をしなくてすむ。
２．拡張機能が利用・開発できる
拡張アプリを適宜入れることができる。同時にこれらのアプリを開発する事もできる。
あまりメリットに聞こえないかもしれませんが説明するのがめんどくさいのでメリットってことで。
逆にデメリットをあげますか。
１．電池の減りが早い（気がする）
気のせいかもしれません。ちゃんと調べていないので気のせいかもしれません。
自分は充電できない環境にあまり遭遇しないので気にしたことないです。Androidの携帯(Docomo F-12C)を使っていますが、電池は丸１日持ちます。電池が持たなくなってから検証するかもしれません。
２．たまに届かない（気がする）
友人と検証したところレスポンスはかなり早いと思うのですが、たまーに不着？お知らせがない？みたいな現象があるかもしれません。友人が少ないので、色々試せていないのが残念です。端末の買い増しも検討しているので、なんとか検証を考えています。
NaverBot(YetiBot)の件で苦しめられた人からすると、そもそもNaverに良いイメージを持っていないでしょう。自分もそのうちの一人ですが、LINEはPRとか上手だと思いますし、それが成功要因だとも思っていますが、やっぱりどうも信用おけないんですよね。まわりが使っていても僕は使わない。かわりにkik messengerを使う。そして周囲に広めたい。
広める際に「LINEは韓国製だから危ない！」とか「NAVERだから危ない！」とか「個人情報ガー！！」って言っても一般人は( ﾟДﾟ)ﾊｧ?って状態なので( ﾟÅﾟ)んーは「kik messengerの方が反応早い」「機種変問題がない！」とか「かわいいスタンプを自前で無料で作ったり使えたりできるよ！」とか「写真の転送とか早い！」とかまぁ本当か嘘か、嘘でない範囲で言って薦めています。
こうして利用する人を地道に増やして母数を増やさないと、一般人に普及しづらいんですよね。
「LINEでいいじゃん。」
いやいや、これからは「kikでいこうよ。」
CloudCoreVPSへ移転
nnnnn.meとredmine.nnnnn.meの移転を行いました。
先ほどDNSの更新を行ったので1～2時間程度で新しいサーバにちゃんと行くようになると思うのです。
redmineは最新バージョンにして、ひどい管理状態だったのを一新するために思い切って古いデータは捨てて作り直しました。
ゆーても捨てるデータも新しいデータもクソもねぇんですけどのぉ
新しいサイトはトップページが超しょぼしょぼのindex.htmlを置いています。drupalのコンテンツはnnnnn.me/drupal7に移しました。そういうわけでかっちょいいトップページを作りたいのですが、なんかいい、トップページのみ作るかっちょいい何かねぇですかね。
CloudCore VPSで仮想化(kvm) 運用編(opensuse)
( ﾟÅﾟ)めんどくさいのでコピペでｓ
例によってCloud Berryさんのを参考に…iptablesを設定します
NATとDNATのコメントアウトされているところを有効にｓｍｓ
( ﾟÅﾟ)そしてIPアドレスを先ほど設定した192.168.122.2にしまｓ（適宜変更）
あとはOpenSuseでアレしてアレすれば使えます。
OpenSuseはapache入れてウェブサーバにでもします。
自分の場合はiFolderを使いたかったのでとりあえずアレしてアレです。
参考：
http://www.nofolder.com/documentation/installation/server/opensuse/opensuse_12-1/
http://yourlinuxguy.com/?p=916&cpage=1
http://yourlinuxguy.com/?p=358
特に問題なくできました。おわり
CloudCore VPSで仮想化(kvm) インストール編(opensuse)
( ﾟÅﾟ)忘備録なのか覚書なのかわかりませｎ
( ﾟÅﾟ)基本的にCloud berryさんの（KVM on KVM）CloudCoreVPSにKVMをインストールを参考にしてまｓ
( ﾟÅﾟ)OpenSuseをいれてみまｓｔ。インスココマンドｄｓ
# virt-install --connect qemu:///system --name vm1 --ram 512 --vcpus 1 --os-type Linux --disk path=/var/kvm/images/vm1.img size=80, bus=ide --network network=default --keymap ja --nographics --location ftp://ftp.kddilabs.jp/Linux/packages/opensuse/distribution/12.1/repo/oss/ --extra-args=' console=tty0 console=ttyS0, 115200n8'
容量はsizeで指定されている80GBにしています。もしかしたらうまくとれないので--promptをつけてインスコするといいです。
インストールはネットワークを選んでFTPを選びます。途中でIPとか聞かれますが、これはブリッジのをいれてあげます。
IP:192.168.122.2/24
GATEWAY:192.168.122.1
DNS:27.34.160.11
IP:ftp.kddilabs.jp
dir:/Linux/packages/opensuse/distribution/12.1/repo/oss/
あとは勝手にインストールしてくれます。
作成されたvm1の仮想OSの扱いとかは次回
英語から日本語へ翻訳：標準欲しいねー的なメモ
翻訳がちゃんと標準化されればいいんじゃないかなーって思ったり。
色々議論はあるようだけど、ちゃんと手順とか方法までつっこんで標準化されれば、
色々不毛な論争や摩擦を起こさずOSSは翻訳がすすみ、かつOSS外の翻訳に関しても、翻訳者にかかわらずきちんと統一された用語の使用が行われるのではないかなっと…
まぁそれが１００％よしではないだろうが、読み手を考えるとせめて使う語句ぐらい統一されていたりしたほうが良いでしょう。もっといえばせめて本の中で統一してほしい。なんだかんだぐちゃぐちゃ…その理由としては以下の項目があるだろう。
０．英語力不足
内容によるけど、TOEFLiBTベースで100点もない人が翻訳するのはやめてほしい…原文の解釈間違っている事に気づけないでしょ…え、何故TOEFLかって？書物って日常会話じゃないでしょ…電子媒体においても読み物であることは変わりないです…
100点ってラインはアメリカの大学で学ぶとしたら最低必要な点数のラインがこのあたり。(留学考えている人とかは110点前後あったほうが良いです)
１．翻訳ルールを知らない
俺ルールとか私ルールが多数存在する。明確な規格とかないけどこれ統一しようよ。
文体・漢字とかローマ字とか記述記号とか…
２．翻訳プロセスをきちんと考えていない
ワークフローとしてはGNOMEのDamned Liesの図が参考になります。
これをもっと落としこんで標準化できたら楽じゃね？
３．翻訳プロセスを実行する方法を知らない
ツールを知らないとか、いつまでEXCELで照らしあわせてやっているとか…
翻訳メモリとか知らない人が技術書を書いていたりするのが現状です。翻訳に必要なのは英語力や、プロセスの把握だけでなく適切なツールを使って実行する必要があります。
ちなみに多くの場合はOmegaTで充分です。
４．翻訳レビューの仕方を知らない
レビューを行う者は自身の与えられている役割を正確に把握していないと行けません。
ここでまた俺ルールが発動すると摩擦を生んだり、レビューのやり直しを永遠とやるはめになります。
これね、なんかJISとかにできたらかなり多くの人が救われるのにね。プロセスの部分も含んでやるべきだと思う。
てけとーに考えるかなぁ…暇ができたらですｇｋｄｎ( ﾟÅﾟ)
