Googleアカウントの2要素認証

Apple IDはなんとか復活させてもらった。クレジットカードの不正利用の疑いも、Visaに確認したところ、Google Driveの有料サービス（25GBで$2.45）を8月に使用し始めたのだけれども、その返金が、10月分の請求の翌日にあったということだった。簡単に言うと、勘違いだった。

Appleはクレジットカードの破棄を薦めるが（当然だと思う）、こちらは家庭の事情があって不可能なので、詳しく様々な事情を説明し、不正利用ではなかったことも合わせて説明して、特例として認めてもらうことができた。社のポリシーとしては疑わしければ（顧客の金銭被害を助長する可能性があるめ）ブラックリストに入れ、そこから外すことはないとのことなので、読まれた方は、説明すればカードを再度有効にしてもらえるのだとは期待されないでください。

というわけで、やはりネットのアカウントを狙う様々な手口があることを身をもって体験したので（まさかiPadにマルウェアが入るとは思わなかった）、Googleアカウントのセキュリティ向上のため、2要素認証を有効にすることにした。

やりかたは、

https://accounts.google.com

にアクセスし、そこから左側の縦のメニューで上から3番目の「セキュリティ」を選択し、中央列に現れる項目のうち、2番目の「2段階認証プロセス」の「ステータス」をONにする。

このとき、たしか携帯電話の電話番号の確認があったように思う。これはどういうことかというと、普通にメールアドレスとパスワードで認証をかけたのち、そのサービスとひもづいた一時パスワード（数字6桁）が、ここに登録された携帯電話に通知されるという、2番目の認証があるから。

これは、サービスごと、Googleサービスを参照する個別のアプリごとに電話がかかってくるので、不正なアクセスがあればすぐにわかるという仕掛け。逆に、いったん電話で合成音声で言われた数字を入れてしまえば、自分（同じPCまたはデバイスの同じアプリ）が使う分には電話はかかってこない。

なので、ログインする際には携帯電話を近くに置いておき、ガラケーで折りたたみ型の場合は開いた状態にしておくという準備をしておくべきだ。なぜなら、電話は遅くても3秒以内にかかってきて、数字は2度言われるが、決してゆっくりした話し方ではないからだ。周囲がうるさい場所では諦めたほうがいい。携帯を片手に、数字キーに指を置いて、言われるままにそのまま入力し、2度目はそれを確認するだけ、というのが望ましい。

失敗した場合は、再度電話をかけさせることができるので、落胆することはない。もういちどログイン画面に戻って入力すれば、別の番号で電話がかかってくる。

なお、最初に使うときは英語のメッセージでかかってくることがあるので、英語が苦手な人でも慌てないように。最初に、「Google認証システムをご利用いただきありがとうございます」という言葉が述べられ、いったん少し間があったあと、「番号は」と続き、あとは数字を6つ、2回言うだけだからだ。ワン、ツー、スリーがわかる人なら大丈夫だと思う。英語では、最後に「サンキュー」と言って切れるが、日本語の場合はもうすこし丁寧な挨拶で切れる。言語の違いは、認証画面の表示が英語か日本語かで区別されているようだ。言語に関係なく、すべてアメリカからの国際電話。

さて、Googleの認証を、ブラウザ画面で行っているとか、アプリ内でブラウザを起動している場合にはこれでよいのだが、アプリが独自のログイン画面を用意している場合は、数字の画面に遷移しないので、電話がかかってこなくて、「アカウントの設定を確認してください」のようなエラーが出るだけだ。このような場合は、ブラウザから一時パスワード（英字16文字）を作成させ、それを自分で決めたパスワードのかわりに入力すればよい。

やりかたは、さきほどの「セキュリティ」画面の3番目の項目、「アプリケーションとサイトを認証する」の[編集]をクリックし、再びGoogleアカウントのパスワード（自分で決めたもの）を入力すると現れる画面の、下半分に注目してほしい。箱で囲まれた、入力欄があるはずだ。ここに、アプリやマシンなどを区別する自分で決めた名前を入力し、隣のボタンを押す。すると、画面が切り替わって、4文字ごとに空白が入った16文字の英文字が表示された、背景つきの大きな枠の画面に切り替わる。この16文字（空白は省略してもしなくても、どちらでもよい）が、アプリに入力する一時パスワードだ。

独自のアカウント設定画面をもつアプリすべては、こちらを使えば解決する。電話の場合と同じように、アプリごとに違うものを入力しなければならないので、さきほどの入力欄には、アプリ名とコンピュータ名を必ず入れるようにしておくと、次に同じ画面にきたときに、画面最下部に一覧されたときに区別がつくので、よいと思う。

こうした、アカウントのパスワードが盗まれた場合の次の防御は、考え方としては比較的よいことだと思われる。Googleアカウントのみですべてがいっぺんに奪われることを防ぎ、アプリ、サービスごとに区別された、次の防御があるからだ。

もちろん、この画面がフィッシングだったら意味はないが、アカウントを作らせるサービスの場合、参考にしてよいものではないかと思う。特定のサービスがやられたとしても、個別に「無効にする」ことができるので、パスワードを変更したあとには、いったんすべて無効にして再度2段階認証をやるべきだと思う。

なお、スマホなどの場合には、認証パスワード生成アプリがあるらしい。

http://support.google.com/accounts/bin/answer.py?hl=ja&answer=1066447&topic=2784804&ctx=topic

ここに、機種ごとの説明がある。

Apple ID乗っ取り

いまのところ金銭的な被害はなさそうなのだけれど、Appleがかけたロックを外すための入力事項がどれも使えない状態。登録情報を書き換えられてしまったら、何らかの問題報告（僕はiCloudに関してのその他の自由入力を使った）をサポートページから伝えなければならなさそうな感じ。

リテールストアのGeniusが対応してくれるのかどうかはわからない。

ただ、PayPalにも変な金銭の出入りがあるし、まぁ、いろいろとやられているような気配。ちなみにPayPal IDはApple IDとは何の関係もないので、前回のマルウェアでなにか履歴でも抜かれたのかもしれない。

JavaからKinectを使うプログラム例をお探しの方へ

とある経緯があって、PrimeSense社のKinect用無償配布ミドルウェア「NiTE」のJavaインタフェースについての解説を探して見つけ出したので、こちらにリンク。

ひとつ前置きしておくと、NITEは骨格座標だけでなく、もっと高度なモーションに関する処理を担当してくれるライブラリで、マイクロソフトのKinect for Windows SDKに近い機能が実現されています。OpenNIはオープンソースなので、C++, C#, JavaなどのAPIが公開されているのですが、NITEに関しては、PrimeSenseのカタログではJavaにも対応していると書かれているものの、どうやって使ったらいいかはどこにも書かれていませんし、ソースもドキュメントも非公開なので、PrimeSenseと契約して魔法少女…もとい、ライセンスかなにかを買わない限り、誰かが使った例を読む以外に具体的なプログラムを作る方法を知ることができません。

それを解説した本が、現在タイで教鞭をとっていらっしゃるらしいAndrew Davison氏の著書「Kinect Open Source Programming Secrets: Hacking the Kinect with OpenNI, NITE, and Java」です。Kindle版は$15ぐらいで結構お安いのですが、どうも地域制限がかかっていて、USでしか買えないようです。

ただ、著者がこの本のドラフト版＋最新情報の追加をしたPDFをご自身のサイトで公開されています。

http://fivedots.coe.psu.ac.th/~ad/kinect/index.html

ちゃんとJavaでサンプルが書かれており、NITEを使ってモーション認識する例が記述されています。

ご自身のプロジェクトがJavaで作られており、Kinectに対応させたいとお考えでしたら、参照されるとよいかと思います。

WebKitのセキュリティホールにやられたorz

YahooメールのspamをiPadの「メール」から削除しようとしたら、プレビューが表示されて、以後3分ぐらいに一度、「Macのメールウイルス対策には...comへ」の日本語アラートが数分おきに現れるようになった。iOS4まで標準だったアラートなので、[OK]を押すまで他のことは何もできない。とりあえずこのアラートは、「設定」の「通知」で空白アイコン、無名のエントリを「オフ」設定にすることで出なくすることはできたが、たいへん気分が悪い。

おそらくプレビューでWebKitが呼び出されて、WebKitのセキュリティホールを使って何らかのトロイの木馬が仕込まれたのだと思う。メールを開いたつもりもなく、「編集」で削除しようとしただけでプレビューが出たように記憶するのだが、もしかしたらタップして踏んでしまったのかもしれない。

iOSは5.1.1。6には事情があってまだしていない。

きょうのthreatpostの投稿に、iOS 6にも存在するWebKitのexploitの説明があったので、例によって超訳することで鬱憤を晴らすことにする。なお、WebKitなのでAndroidのChromeでも踏めるらしい。もしかしたら、少し前にMac OSのSafariがアップデートされたがそれに関係があるかもしれない（アラートの文面からしても、Mac OS X Mountain Lionの「通知」でこれを表示させたほうが効果的な気がする）。

（2012年11月12日追記：このexploitとPOCはApple側で認識され、iOS 6.0.1で対策されたようだ。僕は早速アップデートした。事情があって上げられない人とかいるかもしれないが、乗っ取られるのとどっちをとるかよく考えたほうがいいと思う）

原文はこちら：

https://threatpost.com/en_us/blogs/iphone-5-launches-hackers-explain-journey-working-exploit-ios-6-092112

----

iPhone 5出荷開始、iOS 6でも生きているexploitへの旅についてハッカーが語る

threatpost - Apple

Michael mimoso
2012年9月21日

AppleのiPhone 5を待ちわびて今日まで行列を作って泊まりこんだ数万人と同じ時間、ハッカーたちはすでにそのコアであるiOS 6オペレーティングシステムを配下に置いていた。2人のオランダ人ハッカーたちはAppleの頑丈な防壁をうまくやりすごし、今週アムステルダムで行われたEUSecWest会議で「iPhone 4Sにパッチを当てるハック」に最初に成功したことをプレゼンした。このexploitは、いままさに登場する新しいデバイスについても有効なものだ。

Joost PolとDaan Keuperは数多くの賞賛と、$30,000を、このmobile Pwn2Ownコンテスト（注：Pwnはオンラインゲームでの勝利、Wonをチャットでミスタイプしたことから広まったもの。ここでの勝利はクラック成功を意味していて、Pwn2Ownとは、クラック成功者に商品授与するイベントを指す）勝者にその努力を報うものとして授与された。この2人は、オランダのセキュリティ会社Certified Secure社の研究員で、WebKit、つまりAppleのSafariブラウザの下敷きになっているブラウザエンジンの脆弱性を利用した。3週間の価値ある労働を経て、このペアは携帯からデータを盗み出すことのできる、生きているexploitを見つけ出した。本ブログはPolとKeuperに、どうやって彼らがiPhoneを首尾よくクラックしたのか尋ねてみた。

Threatpost: iPhone 4S（とiOS 6）をターゲットにした動機は？

Pol and Keuper: iPhoneには考えられる最善のセキュリティ機能（例えばASLR - アプリのメモリ割り当て空間をランダムにする, DEP, サンドボックス、コード署名など）を備えていて、なにより僕たちにとって最も興味深いターゲットだったから。iOS 6のリリースについては、WebKitの新しいバージョンが使われていて、以前の脆弱性やexploit経路はふさがれていると思っていたから、おまけでついてきた関心といったところ。

Threatpost: 君たちが発見した「WebKit脆弱性」（注：今年8月末の同ブログ記事で、WebKit脆弱性を嘆くコラム）はどの程度深刻で、それをどうやって見つけたのか説明してくれないか。

Pol and Keuper: 脆弱性を発見したのは、WebKitのコードの検査をする過程からだった。脆弱性の程度は極めて深刻で、（若干の罠を仕掛けておけば）任意のコード実行が（Safariのサンドボックス内で）可能だ。僕たちがPwn2Ownで実演したように。これを活用すれば、（例えば）誰かの個人的な写真やアドレス帳やブラウザの履歴に直接アクセスすることができてしまう。

Threatpost: 「WebKitのセキュリティ」（注：今年2月にRSAカンファレンスで講演されたAndroid携帯のWebKitが持つゼロデイ脆弱性の悪夢についての記事）の話について、君たちはどんな意見を持っている？

Pol and Keuper: 不完全だと思う。現時点で、僕たちが見つけた脆弱性の詳細について話すことはよいことではないと思うし、WebKitのセキュリティ全般（そして競技のルール全体やその他すべて）についてもそう思う。でも、僕たちがexploitできる脆弱性を3週間以内に見つけられたという点で、この「不完全な」話は極めて強い意味を持つことになったと思う。

Threatpost: 脆弱性を発見してから、君たちはいくばくかのコードを継ぎ合わせて、生きているexploitに仕上げてしまった。それはどんなもので、なぜそんなことをしなければならなかったのか話してくれないか。

Pol and Keuper: 脆弱性があったからといって、それが「直接」コード実行に結びつくことは極めてまれだ。ほとんどのexploitは、コード実行を可能にするために、あなたが言う「追加の作業」がある程度必要なんだ。僕たちのケースでは、iOSの機能であるコード署名（Appleが付与する署名なしではいかなるコードも実行できない機能）に対するワークアラウンドも必要だった。

Threatpost: Appleのコード署名に対して、どんな細工をしたのかな？　難しかった？

Pol and Keuper: 普通、iOSではコード空間のあるページに対して、実行可能か書き込み可能かのどちらかしか許可していない。両方の権限がつくことはありえない。また、対象となるページは実メモリにロードされる前に署名されている必要もある。これはとても厳密な規則で、（注：セキュリティにとって）非常によい働きをする。iOS 4.3以後、Appleはこのポリシーを導入した。

iOS 4.3以後、Appleがそれを決めたのは、Mobile Safariブラウザのパフォーマンス向上のためにJust In Time (JIT)コンパイラを導入したからだった。だから、いまではMobile SafariはページにRWX（注：読み書き実行）をマップできる。この例外はMobile Safariだけのために与えられた（つまり特権を持っている）。僕たちのexploitでは、JITページのロケーションを見つけ出して自作のシェルコードを上書きし、そこへジャンプする。

もしJITページがなかったら、ROP [return-oriented programming]を使って全く同じ結果（つまりコード実行）が得られるようにしてやる。けれど、ROPのペイロードを作るのは実にまったくしんどい作業だ。

どちらも既知のテクニックで、以前にも利用されたことがあるものだ。

Threatpost: そのexploitを働かせるためには、利用者をうまく釣って携帯から悪意あるサイトを観るように仕掛けるの必要があると思うんだけれども、それはどうやるの？

Pol and Keuper: exploitはバックグラウンドで動いて、ひそかに利用者の個人データ（アドレス帳、カメラで撮った写真、ブラウザ履歴など）を携帯から外部のサーバに、攻撃者の指示で送信することになるだろう。

Threatpost: 君たちの仕事では、iPhoneからemailやSMSメッセージを取り出すことはできなかったようだけれど、それはどうして？

Pol and Keuper: Safariのサンドボックス（つまり僕たちのコードが動くところ）からはSMSやemailのデータベースにアクセスできないんだ。

Threatpost: 今回のexploitはiOS 6にもそのまま残っていて、iOS 6でも同じexploitが働くという理解でいいのかな？

Pol and Keuper: 今回の脆弱性はiOS 6にそのまま残っている。exploitに対する一般的なアイディアも同じだ。けれど、iOS 6では少し異なった中間作業が必要になる。

Threatpost: 君たちはexploitを破壊した、ということだけれどそれは本当なの？　どうして？

Pol and Keuper: 本当だ。そんなものは、もはや不要だろう？　競技のルールのなかに、脆弱性の説明と簡単なPOC（コンセプトを証明する）プログラムをZDI [TippingPoint's Zero Day Initiative program]へ送る必要があった、それだけのこと。

Threatpost: その詳細はAppleと共有している？　やりとりはどんな感じだったの？

Pol and Keuper: 競技の規則の一部に、脆弱性はZDIからAppleに開示されると明示されている。
----

イオシスがまたやってくれた

昨日は久々の東京出張だったので、秋葉原を散策。本当は、分解して取り出した古いVAIOの液晶ディスプレイを再利用したかったので、Aitendoさんの店舗で相談するつもりだったのだが、ピンポイントで木曜定休にはまり、シャッター越しに暗い店内を覗きこむような形になった。残念。めったに東京出張できる身分でないので、通販で相談するしかないか。

しかし、末広町駅西側があんなことになっているとは思いもよらなかった。公には書けないが、要するに中国のテクノロジーやそういった2ch的なもろもろが微妙な感じで、あっさりいえば商売になっているということ。世の中がなんでもクリーンならばよいとは全く思わないので、とりあえず見逃してもらえていることはよいことだと思う。また、価格的にもネットの裏商売のようなひどいものではなく、適正な利益水準と感じられたので、当局の方々におかれましては、今後ともお目こぼしいただきたいと願う次第。

そんなこんなで魔境を延々と彷徨っていたため、いつもの共立・秋月の通りに到着するまでかなり時間がかかったのだが、秋月の隣にあるイオシスは例によって一応みておくことにした。

ioBook Airについては以前にも書いたが、場所を微妙に裏側に変更して販売継続中のようだ。しかし、10月26日のWindows 8販売開始以後、あの価格で勝負ができるとは思えないのでそれまでになんとか売り切ったほうがいいような気がした。

今回目にしたのは、キーボード。ひとつはApple Bluetooth Keyboardのなんちゃって版と、驚いたことにHappy Hacking Keyboard風のなにか、であった。

前者は、ioBook Airよりはましだが五十歩百歩な感じの品物だ。アルミ素材も似ている。金型の精度も似たり寄ったりな感じだ。1,980円だったように思うのだが、その程度のものということ。特に、チルト用の脚はあまりにもひどいので、Apple製品と較べてはいけない。それなら、末広町魔境にある別の同価格のものを検討すべきと思われる。

で、Happy Hacking Keyboard風のなにか、であるが、これも大変に残念なものと思われる。キータッチは普通のメンブレンで、まぁどうということはない。配列は一応USなのだが、なぜか106キーボードの風情が漂う。スペースキーが短いのだ。で、英数キーのところはMacのコマンドキーのマーク、かなキーのところはイオシスのロゴが入っている。

1000円台でコンパクトなUS配列のキーボードはなかなか入手困難なので、そんな要望にはひとつの解決になるかもしれないが、スペースキーが日本語キーボード並に短いのは耐えられない人が多いと思う。これは各自、実物を触って確かめてもらいたい。

ついでなので中華Padもいくつかの店舗に並んでいるのを見たのだが、中華Padもちゃんとしたものが主流となりつつあるようで、1万円台ではせいぜいAndroidも3.0程度、ICSやJerry Beanを動かすなら2万、3万といったところで、それならNexus 7買っちゃえばと感じられた。Nexus 7を初めて触ったのだが、Androidマシンの無駄にハイスペックなSoCとJerry Beanになってようやくまともになったなめらかな表示で、正直、驚愕してしまった。これなら使ってみたいと、Androidなのに初めて思った。予算が余るなら、買ってしまうかもしれない。安いし。ええ、間違っても自腹では買いません。Androidなんで。

SONY DCR-TRV900 mini DVカメラをiMovieで認識させる

Mini DVで持っていたテープの内容を発掘するために、手持ちのSONY DCR-TRV900をMac mini mid 2011に「Thunderbolt to Firewire Adapter」に接続してみた。

ところが、この機種は昔VAIOでもうまく認識されず、ケーブルを選ぶところがあった。案の定、Macはカメラを認識してくれない。こういうときは検索ということで、Appleのサポートフォーラムがひっかかったが、理由はよくわからないがうまくいったりいかなかったりするようだ。

困ったなと思い、接続したままカメラの電源を入れたり、VTR側に切り替えたり（テープを再生したいのだから、VTR側が正しい）するのだが、どうもうまくいかなかった。

システムの詳細をみても、カメラは見あたらない。

そこで思い立って、VTRでオンにしたままi-Link端子のケーブルを抜いて挿しなおしてみたところ、いきなりiMovieにDVカメラのウインドウが開いた。要するに成功したということ。

何にせよ、理由がわからないのは確か。お困りの方のご参考になればとここに記しておく。

なお、iMovieでの「自動」取り込みは、無録画からはじまるテープではうまくいかないようだ。僕はテープの先頭部分は信用していなかったので、少し送ってから使うようにしていた。この場合は、「手動」で録画されているところの頭まで巻き戻してから、おもむろに「取り込む...」を押すとよいようだ。

Emacs 24.2をMac用にコンパイルする

いままで使ってきたEmacs23、ふと思うところがあり、思い切ってGit Headをもってくることにした。きょうのバージョンは24.2.50だった。

そのまま./automake.sh && ./configure --with-ns && make bootstrap installでもよいのだが、おなじみinlineパッチとLion Full Screenパッチをあてることにした。

どちらもEmacs24ではあるが、inlineパッチは24.50、Full Screenパッチは24.1を対象にしたもの。結論からいうと、あまり問題にはならなかった。

先にFull Screenパッチをあてるといいと思う。こちらは行が若干前後するだけで、パッチはきれいにあたる。一方、inlineパッチは、最初がconfigure.inに対するパッチで、これはGit Headには存在しないので、./automake.shしてconfigureを生成してからpatchコマンドを実行することになる。すると最初にファイル名を問われるので、そこで「configure」を入れてやればよい。1つだけrejectが出るが、inlineパッチで追加したmacim.mのオブジェクトを追加するところ。rejファイルを見て、その前にある"nsfont.o"を検索して、そのあとにmacim.oを追記してやればよい。

なお、sourceforgeに置かれているinlineパッチは、インストール時のOSのLocaleを見ているので、英語設定でインストールして、システム環境設定で言語を日本語に切り替えた場合、ことえりなど日本語IMEを見つけてくれない。MacEmacs JPメーリングリストの記事にある、現在選択されているLocaleが日本語なら日本語IMEを探すようにしておくほうがいいかもしれない。

make installまでやると、nextstepディレクトリの下にEmacs.appとして一式揃っているので、/Applicationにでもmvしてやればよいと思う。というか、そうした。

最後にいちばん苦労したのは、.emacsが結構違うということだった。さまざまな議論があちこちにあるけれども、Mac Wikiの説明がいちばん有用だと思う。あまり詳しいコメントはついていないが、Emacs Lispを少々かじっていれば何をやっているかはわかるはず。個人的にはSection 6の、文字の拡大縮小（\C-+,-,0）に対応したフォントの設定がたいへんありがたかった。いままで12ptで、さすがにThunderbolt Displayの27inchには文字が小さかったので、14ptになって助かっている。また、ここのブログエントリでも苦労が明かされているが、「(setq default-input-method "MacOSX")」の行は、画面の各種設定をやった後に置かないとinlineパッチで期待される動き（toggle-input-methodがIMEのオンオフと連動する）をしないようだ。ここはEmacs23までとは大きく違う、おそらくパッチで何らかの手立てが必要と思われる部分と思われるところなので、当面注意しておくことをおすすめする。

（2012年9月7日追記：Emacs23以後はUnicodeのIVSに対応しているような話があったが、どうもこれはLinux上での話のようだ。つまり、--with-nsでCocoaを使った場合とは違うようだ。そこで--with-Xをつけてコンパイルしようとするが、libotfを組み込んでくれない。理由はpkg-infoでまずlibXftを調べ、そのあとpkg-infoでfreetype2の存在を調べてからpkg-infoでlibotfを調べるからのようだった。作ろうとしたのがHomebrewを使っているMacだったので、Xquartzに入っているものは普通にはインストールしない。強引に作るにはconfigureを書き換えることになるが、面倒なのでやめた。）