SSL LabsでA+評価をもらえるWebのTLS設定

職場で公開している、とあるWebサーバのCA証明書をようやく入手できたので、TLS対応しました。

いまどきはどんな設定するんだろうと思い検索すると、「SSL Labsで検査する」というのがひとつの指標のようです。

よい検査結果を得るためには、というか、これだけサイバー攻撃が激しくなっているいまを生き抜くために、2015年秋現在では最低でも使えるプロトコルはTLSv1以上にするのはもちろんのこと、暗号の組も現時点で弱いことが確定したものは排除しなければならず、さらに最近見つかったDHのlogjam脆弱性にも対応しなければいけません。

まず暗号の組は

Guide to Deploying Deffie-Hellman for TLS

で。とても長くなってますが、そういう時代なんでしょう。

このなかで、dhparam.pemファイル作成については

logjam対策でやったことまとめ

が日本語なのでわかりやすいと思います（といっても、opensslで1行コマンドですが）。

ここまでやって「B評価」。レポートを読むと、セッション関係の設定を改めなければならないようです。Nginxの場合ですが、ssl_session_cacheをきちんと設定するのがよいようです。ここまででひとまず「A評価」。レポートを見ると、「HSTS Preload」という項目が無効らしいことが気になります。

つまり、80番につないできたら443に飛ばす設定をして、HSTS Preloadというらしいですが、httpスキームを入れてもブラウザが80番でなく、443番に勝手につなぎにいく相手を並べたJSONファイルがネット上にあって、それに関連する設定を加えるのと、ブラウザが随時読みに行くそのJSONファイルに登録してもらう作業が必要なようです。

もろもろありますが、「とりあえずNginxならこう書いておけ」という例が

Nginx Configuration for HSTS Preload

というページにありました。ただ、resolverに8.8.8.8と4.4.4.4を設定しているのはやめるべきだと思う。

ひとまずここまでやると、「A+評価」になりました。うれしいです。

SSL LabsさんでA+評価いただきました

とはいえ、ブラウザがHSTS Preloadしないよという行は残りますので、HSTS Preloadファイルへの追加登録依頼をしなければいけないわけですが、それは

HSTS Preloadを導入しよう

というブログエントリにしたがって、Webフォームから入力することになるようです。このとき、www.ではじまるサイトが必要なようですが、当方まだできていないので、これは後日対応しようと思います。

いわゆるXcodeGhostについて

iPad AirをiOS 9にアップデートしようと久しぶりに電源を入れたら，iCloudやiMessageへのログインを繰り返し要求される事態が発生し，うんざりしておりました。公開初日だったのでAppleがとんでもなく混雑しているのは，iOS 9のダウンロード前の認証に10分ぐらいかかった時点で覚悟したわけですが，iCloudやiMessageの認証失敗もその関係かなと思っていたわけです。

日中のダウンロードを諦めて帰宅後，深夜に自宅で割と（それでもゆっくりと）ダウンロードが進むのを見ているうちに寝落ちしたので，目覚めてからは混雑解消したのか，すっきりとインストール以後は進みました。

インストールの間にもAppleの認証ステップがありますから，通信が混雑しているとインストール途中でプログレスバーがいつまでも動かない，ということが生じますが，それはなかった，ということです。

で，現象が解消して忘れていたのですがそこへXcodeGhostのニュース。各ニュースサイトで話題になっているのでご存知かと思いますが，細かいところまでよくまとまっているのが以下の記事かと思います。

• 新たなマルウェア「XCodeGhost」全てのiPhoneユーザは要チェック!! (iBitzEdgeさん）

それ以前に一般のニュースで，iCloudのパスワードを入れさせられる場合もある的な記述があり，「ゑ？」と思ったわけです。

ということで，Pangu作のチェッカを入れて確認しました。このへんは脱獄ニュースのTools4Hackさんが詳しい。Panguは脱獄ツールを作成，配布しているところですから当然でして，この界隈の修羅の様相を踏まえて，確からしい内容を選んで丁寧に解説されているのがこのサイトであります。

• [iOS] AppStoreからも感染するウイルス「XcodeGhost」の検知アプリをPanguが公開 (Tools4Hackさん）

個人的には脱獄環境でMobile Safariの穴からiOS乗っ取られた過去があるので脱獄はめんどくさいと思ってやめましたが，iOSのセキュリティについては脱獄コミュニティがいちばん詳しく知っていて，Twitterなどでかれらが漏らす話が重要だったりするので，それをうまく掬って記事にしてくださるニュースサイトは見ております。

というわけで，上記記事の手順で，Mobile Safariからアプリをインストールして，開発者証明書プロファイルを「設定」アプリから「信頼」してあげれば動きます。エンタープライズ向け，企業などで社内業務用に開発されたものなど，一般公開されないアプリをインストールして動かす手順を踏む形。

開発者証明書はAppleに申請して，Appleの署名つきのものを取得しないとアプリが動かず，証明書の偽造はまだ確認されていない，できないことになっている，のだったと思うので，このアプリを動かす間だけ「信用」すればよいし，この画面で「信用」すると赤文字で「Appを削除」にかわるわけですが，実行後，ここをタップすれば証明書とアプリの両方が消えます。

結論ですが，わたくしのところでは，コメント欄で話題になっているCamScannerは手持ちはCamScanner+だったおかげか，感染しておりませんでした。というわけで問題なし。AppStore側も感染アプリのBAN（ストアからの削除）を積極的に進めているようなので，今後インストールするアプリに同じ不正コードが含まれている可能性は少ないのかなと思っています。（AppStoreからBANされていても，いまデバイスにインストールされているアプリまで消えるわけではないので，いま動いているiOSデバイスで確認することが大事です）

それで，XcodeGhostの該当コード部分がGitHubに上がって，めきめきスターの数が上がっております。スターは，いわゆる「お気に入り」機能です。ブックマークといってもいい。

• XcodeGhostSource/XcodeGhost (GitHub)

たしかに，各種情報をとりまとめ，暗号化して情報収集サイトに送信する様子が見えます。README.mdが中国語なので読みにくいですが，英語に翻訳すればわかりやすい。文法が近いためか中国語から英語への翻訳精度は高いと思います。

Google翻訳の結果：

"XcodeGhost" Source clarification on the so-called "XcodeGhost" of

First of all, I XcodeGhost event to bring confusion apologize. XcodeGhost from my own experiments, without any threatening behavior, as detailed in the source code: https: //github.com/XcodeGhostSource/XcodeGhost

The so-called XcodeGhost is actually hard to force an unexpected iOS developers find: Modify Xcode compiler configuration text file specified code can be loaded, so I wrote the code above annex to try and upload it to your network disk.

All data in the code actually acquired basic app information: application name, application version number, system version number, language, country name, symbol developer, app installation time, device name, device type. In addition, you do not get any other data. Solemn note is required: for selfish reasons, I joined the advertising features in the code, hope can promote their applications (off the source code can be compared to the Annex do check). But in fact, from the beginning to the final shut down the server, I have not used the advertising function. And in 10 days ago, I have taken the initiative off the server and remove all data, but will not have any effect on anyone.
Willing rumors would stop the truth, the so-called "XcodeGhost", used to be a wrong experiment, after just completely dead code only.

It is emphasized that, XcodeGhost App will not affect any use, but does not obtain private data, only a dead piece of code.

Again sincerely apologize, wish you a pleasant weekend

iOS 7でのプライバシー設定（改善、か？）

iOSが行動ターゲティング広告会社にデータを売っている話が、iOS 6の頃にあった。

iOS 7でそれがどうなったのか気になっていたけれど、設定を見つけることがきょうまでできていなかった。ようやく気になるいくつかを見つけたのでこちらでご報告申し上げる次第。

まず、行動ターゲティング広告のIDについては、設定アプリの「プライバシー」の、いちばん下にずばり「広告」というのがあった。内容をみるに、これが以前問題になったものと共通する項目のようだ。明瞭な名前になったのは非常によろしい。

そして、デフォルト設定だが、「追跡型広告を制限」が「オン」になっている状態。以前のことがあるのでどちらの意味か迷ったが、いったんオフにして再びオンに戻すことに気づいた次第。したがって、「デフォルトで行動ターゲティング広告のIDは出さない」。デフォルトのままでよいということになる。これもよろしい。

というわけで、他社への販売業はやめたようだが、iOSには、iAdというアプリ組み込みの広告表示機能がある。iAdのライブラリを使ったアプリが出す広告を 妨げるにはそれこそ脱獄でもして機能を無効にするTweakでもあてるしかないのだが、広告の精度を向上させるには位置情報（GPSのデータ）を使うというのが流行らしく、Twitterアプリは位置情報を要求するときに、「広告の精度を高めます」と告白してくれる。Facebookは黙っているが、まぁ、位置情報をとったらそれを何かに使おうとはしているだろう。広告も含めて。

iAdももちろん、位置情報を利用する。これは例によって深いところに隠れていて、「プライバシー」→「位置情報サービス」→「システムサービス」のなかにある。上から4番目の「位置情報に基づくiAd」がそれだ。「かまわないでくれ」と思う人はこれを「オフ」に設定変更すべきだろう。

ほかにAppleがiOSで仕掛けたものといえば、Wi-FiアクセスポイントのIPアドレスとGPS位置情報との連動で、Androidでもそうだが「位置情報を正確にするためにWi-Fiをオンにします」というのは、屋内でGPSの衛星が使えないときにマップで自分の位置をより妥当な位置に表示するために集めているデータの組み合わせだ。未知の場所、特に海外で勝手がわからないときなどにマップアプリは必須なので、これを嫌うかどうかは趣味の問題になってしまったような気がするところ。こうした「安価な」手段を許さない人が以前からたくさんいれば別のイノベーションが起きただろうが（屋内位置情報に関する研究が、もっと以前から促進されていただろう）、もはや手遅れなのかなと僕は思っている。

この、「システムサービス」内にある「Wi-Fiネットワーキング」と「携帯電話通信網検索」というのは、要するにそういうもの。一見、「使えるWi-Fiスポットを教えてくれるのかな」とか「携帯の電波が届く場所を教えてくれるのかな」とか、サービスを受けるほうで想像してしまいがちだが、実は自分が情報提供者になるという意味なのでお間違えなきよう。マップアプリにエンドユーザーが課金されないのは、エンドユーザーが位置情報という貴重な資金源を無償提供しているからという視点は忘れないほうがいい。「無料サービスの資金源は、あなた自身だ」というネットサービスの格言がある。

それから、以前裁判所だったか司法省だったかからAppleが大目玉を食ったGPSデータ垂れ流しの件だが、それに関係するのは「診断/使用情報」だろう。トップに戻って「情報」のなかに入ると、下のほうにあり、iOS 7のデフォルトでは「送信しない」となっている。

送信しないのだから気にする必要もないのかもしれないが、ここにはデフォルトでGPSなど位置情報が入っている。これを停止したければ、再び「プライバシー」→「位置情報サービス」→「システムサービス」で、「診断/使用状況」をオフにすべきかと思う。

ひとまず気がついたのは、こんなところ。

Androidアプリで「アカウントの取得」させることの危険性

しばらく前に中古のGalaxy Nexsusを購入し、Androidの世界に身を投入しました。

GoogleがAndroidを買収して自己のプラットフォームにしていく過程で、Jobsと同じように「盗んだもの」（僕の感覚では、Sunから盗んだものが多い―実際の裁判では、争点がAPIに限定されて、Sunとは無関係という判決となりましたが）ということで、またマルウェアやガワだけ替えた偽アプリなどストアの品質などにも懸念があり避けていたのですが、Jelly Beanを入れてみると、ICS以後ようやく本気で取り組まれたfluid（表示の滑らかさ）のおかげで、「使える」プラットフォームに育ったということがわかりました。

Nexusプランドを選ぶのは、やはりカスタマイズされていない生のAndroidに触れて評価したかったためでしたが、邪悪そうに見えても自分の目と手で評価しなければわからないことは多いと実感しました。

ただ、懸念されたストアの品質ですが、たしかにiOSのApp Storeと比べれば身元不明な怪しげなアプリが目立つ印象はありましたが、iPhoneを誰もが持つようになって以後のApp Storeとどれだけ違うかというと、それはなんとも言えないように感じられました。

とはいうものの、Google Playはアプリが要求する権限を明示しており、これがアプリ内の設定ファイルから自動生成されているならば嘘ではないと思われるので、クリーンなアプリかそうでないかの判断がしやすいのはApp Storeにないよさと思うようになりました。App StoreではAppleの審査のみが唯一の基準で、ストアに出ているものを信用するしかありません。しかし、Appleは端末固有番号であるUDIDを取得するアプリは審査しないといいつつ何年も放置しています。少し前の表明でも、UDIDを取得するアプリは「新たに審査対象になる場合（バージョンアップを含む）」に審査から落とすということで、現在ストアに出ているアプリで放置されているものは、いつまでもUDID取得機能が残ったままインストールされてしまうという体たらくです。

UDID取得が嫌われるのはもちろん端末が追跡されること、UDIDをキーにして、様々なプライベートなデータを集約できてしまうことにあります。とはいえ、以前の記事にも書いたように、Apple自身が端末追跡IDをOSの機能に載せており、それを広告屋に売っているという共犯関係にあるのですから徹底することは期待できません。また、連絡先などをごっそりもっていくアプリも堂々と審査を通っています。TwitterやFacebookもそうですが、これはあとから同期をオフにできるので、いちいち連絡先を空にしてからインストールし起動するなどしていれば被害は防げるという逃げ道はありそうです。

さて本題。Androidアプリの場合、Google Playに載っているほとんどのアプリが、「アカウント情報へのアクセス」要求をします。好意的に考えるなら、「アプリが固有のアカウントを作成すること」であろう、これはAndroidアプリすべてに共通の仕様であり、Androidの下にあるLinuxのレベルで、アプリごとに違うアカウントで動くようにし、他のアカウントで動作するアプリとはデータ共用できないようにしてセキュリティを保っていることを指しているはずだ、といえるかもしれません。単にそれを言っているだけなら問題はないかもしれません。しかし、アクセスに「読み取り」があった場合、これは端末にどのアプリがインストールされているかをどこかに送信するという意味になります。これはプライベートな情報であり、嫌がる人は多いのではないでしょうか。

Androidアプリの解析結果を確認できるサイトsecroidは、内部で使用されているライブラリやフレームワークについても検証し、危険性のあるライブラリやフレームワークあった場合、どんな理由でそれが危険なのかという情報提供がなされることで、スキルは必要なものの、より深い安全性判断ができます。iOSでは危険かどうかの判断はAppleにすべて委ねられており、ストア利用者はそれを知るすべはありません。

まとめると、Google Playでアプリのインストール時に表示される、「要求される権限」には必ず目を通しておきたい（自己責任ですが）ということ、ただし表示されている内容には、わかりにくいプライバシ侵害が含まれている、ということになります。

ところで、iOSで自由なカスタマイズをしたい、Appleの審査を通らなかったアプリを入れたいという理由で「脱獄」（Jailbreak）をしたがる人は多いのですが、iOSにおいてjailはほぼ唯一の安全弁であり、これを外せば単なるパソコンと同等かそれ以下のセキュリティ状態に置かれるということは覚悟しておくべきです。jailはFreeBSDが最初に導入したかと思われるのですが、Unixに少々古くから含まれていたchroot()機能、すなわち、アプリ側から見えるトップディレクトリを、特定のディレクトリに設定することに加え、プロセス間通信やシステムコールなどを完全に分離し、そこでセキュリティ上の問題が生じてもOS全体には影響が及ばないようにする技術でした。iOSはこれを取り入れ、アプリがアクセスできる範囲全体を「サンドボックス」（お砂場）と呼んでいますが、AndroidとiOSの大きな違いは、iOSアプリが利用するObjective-Cランタイムの驚くほどの柔軟性にあります。オブジェクト指向技術の言葉でいえば、mixinが簡単にできてしまう作りです。たとえそれがOSのオブジェクトであっても、アプリ側から簡単にメソッドの追加や置き換えができてしまう強力な自由度が諸刃の剣となるのです。脱獄後にはいろいろなtweakを組み込むことが楽しくなりますが、これこそが、OSの機能を柔軟に変更している具体例です。

よくあることですが、SafariのエンジンであるWebKitには、いくつもの脆弱性がつねにあります（少ない、といってもゼロにはならない）。したがって、それほどたいした脆弱性でなくても、うまくexploitを作ればSafariをアクセスするだけでSafariが触れる範囲内で何かコトを起こされてしまう可能性はあります。サンドボックスが機能していればSafariだけの問題で済みますが、脱獄していた場合を想定したexploitの場合、OSごと乗っ取られる可能性を考慮しなければなりません。

とはいえ、UDIDや連絡先の保護、またファイアウォール設定や広告ブロックなどをしたい場合には、現状では脱獄が不可欠というジレンマがあります。Androidでrootをとるというのは実はたいしたことはなく、/bin/suという管理者権限に移行するコマンドが削除されているので、それを入れてやるというだけのことです。rootにはパスワードがついていませんから、root権限を使って便利になるよ的な説明で釣ってLinuxを乗っ取るトロイを仕込むということはあるかもしれません。報道によれば中国にはAndroid携帯による巨大なボットネットができているといいます。

iOSについては、脱獄以外の手段での何らかのカスタマイズ手法の開発、Androidを含めるならば、素性の分からない人物の作成したアプリケーションに気をつけ（ストアの評価はステマもどきがほとんどです）、甘言には乗らない心構えが必要かと思います。

Exynos騒動に関連して一言

Exynos 4210と4412の設計ミスか？　と、ちょっとワクテカしたのだがいまひとつ残念だったというのが率直なところ。

とはいえ世の中に出ているAndroid機器の台数では相当なものだろうから、CPU依存コードの修正版が配布されるまでは利用者にしてみればドキドキもんだろう。

今回の騒動は要するに、Androidの下にいるLinuxのCPU依存コード（カーネルコードの共有ライブラリ）をミスってユーザランドからカーネルメモリも自由に読み書きできるようになってました、という間抜けな話。Linuxカーネルのなかみはよくわからないけれども、メモリセグメントのrwx権限をもつテーブルかなにかのフラグ管理を間違えたんだろう。この手のミスは、複数箇所でフラグをいじるようなコードを書くと生じやすいので、ぶっちゃけスキル不十分なプログラマを投入した上に、きちんとしたコードレビューができるチームでなかったというところではないだろうか。

仕事上、韓国のIT技術者や研究者と接する機会が多いのだけれども、こういうところの品質が担保できる人材は少ないんだろうなと思うことが多い。日本メーカーもソフトウェア開発は苦手だけれども、そしてそれが組織作りや運営の問題ということが多いのだけれども、韓国人は日本人より大陸的というか、現場で失敗しながらスキルを身に着けることをよしとする傾向が強いので、上司（儒教社会なので目上や上の立場の人は絶対）が無能だとろくでもないものがあっさりと世の中に出てしまう感じだったりする。

で、一部にはAppleのiOSデバイス用CPUもサムソンの設計だからと怖がっている人が一部にいるみたいだけれど、AppleのAシリーズ開発はカリフォルニアでがっちり管理しているし、あのうるさいジョブズがこういう基幹技術の流出をよしとしたはずがないので、関わるエンジニアは完全に隔離されているというAppleとサムソン両者の説明はあながち嘘ではないと思う。

とはいえ、A4にはLimera1n exploit、A5にはデュアルコアの間の一貫性管理のミスというCPUロジックの致命的欠陥が脱獄に利用されているので、AppleのCPUだから安心というのはあまりに楽観的にすぎるといえる。iOSデバイスの場合、脱獄への強い動機があるので妙にトガッたティーンエージャーやそれ上がりの大人が寝食惜しんで脆弱性探しをしていることで発見されやすいのだけれど、おそらくどのメーカーのCPUにもexploitにまで組み上げられる何らかの欠陥のひとつやふたつは抱えているのだろうと思う。

知人の論理検証専門家が自社のCPUを対象に自分の研究成果を適用したらぼろぼろエラーが見つかって、上司に報告したらその検証ツールはお蔵入りにされたという話もきいているから、納期やコストなどの都合で、仕様書通りの動きさえすれば品質管理部門はOKを出しているのが実際のところではないかと思う。

つまるところ、ITに限らず製品やサービスに絶対の安心はないということ。人がやることなので、想定外とか手抜かりを見逃すとかいうことは必ずあるということを前提に付き合わざるをえない。「面白いなー」「便利だなー」で無邪気にアプリ収集に邁進したり、どっかの紹介やランキング上位を真に受けて突進するのは危ういと心がけるべきだ。

特に、なにかの記事や本での紹介は実質広告に過ぎないケースは多いし、ランキングというのは噂を流したり人海戦術でダウンロードしたりすることで簡単に上位に上がってくるものだ。ランキング操作も広い意味では「ステマ」の一種といえるだろう。詐欺の片棒担いだ「ステマ」有名人をあげつらう前に、「それは本当に必要なのか」と自分に問う習慣をつけるほうが、人生のいろいろな場面で余計なトラブルを避ける上でも役に立つはずだと言っておきたい。

Saurikが集めている情報

Cydiaには、「Manage Account」という機能があり、Cydia経由で購入した有料アプリやTweak等を、あとからGoogleアカウントもしくはFacebookアカウントを使ってCydiaにログインすることでいつでも「購入済み」としてダウンロード&インストールできるようになっている。

この機能はとても便利だ。同じアカウントからならば、複数のiOSデバイスに、どのバージョンのiOSからでも同じ有料アプリやTweaksを追加の費用なく入れることができるからだ。

もちろんこれは、AppleのApp StoreやGoogle Play、Microsoft Storeなどとも同じで、それぞれのアカウントにアプリがひもづけられ、ひとつ購入すれば同じアカウントで使う限りどのマシンやデバイスにもインストールできる。Cydiaがこれらと違うのは、Apple, Google, Microsoftがそれぞれにアカウントを作らせて、それぞれが独自にアカウント情報とアプリ情報を管理しているけれども、CydiaはGoogleアカウントやFacebookアカウントでログインするので、Cydia用のアカウントは不要ということだ。

少しネットの事情に詳しい人なら、他にもWebサイトで独自のアカウントを作らせずにGoogleやTwitter、Facebookのアカウントなどでログインできるように作っているところが結構あることをご存知だろう。そして、Open IDやOAuthなどといったしくみについてもご存知の識者もおられることだろう。

ここから類推するならば、CydiaのバックエンドであるAmazon AWSサービス側にはアカウント管理のしくみはなく、いわゆる（広い意味での）Open IDで利用者管理を行っていると考えるところだろう。つまり、Cydiaは利用者識別情報とそれに関する購入情報の対応を持っているだけで、それ以外の情報は一切持っていないはずだと。

ところが、あるときGoogleアカウントのダッシュボードで、関連付けられているアプリ及びアクセスされる情報を確かめる必要があったとき（2要素認証を設定すれば必ず目にすることになる）、Cydiaが3つのアクセスをかけていることを知ってしまった。ひとつは、個人のプロフィールなどアカウントへのフルアクセス、次に連絡帳、そしてGMailだ。ここに魚拓を貼ろうと思ってダッシュボードを開いてみたが、いったん2要素認証を外して再設定したのち、一度もCydiaを使っていないため、すべてがクリアされており、魚拓がとれなかった。もしこれを読まれた方で、心当たりのある方は、ご自身のダッシュボードを確かめてみていただきたい。「Googleアカウントに許可された項目」、英語なら「Websites authorized to access the account」となる。

Facebookの場合、僕はFacebookには詳しいプロフィールを入れているため警戒してCydiaには使っていないので、どのようになるかはわからないけれども、おそらく同程度の内容にアクセスしている可能性がなくはない。心当たりがおありの方は、FacebookサイトでCydiaが何にアクセスしているか確かめてみていただきたい。

Saurikが集めた情報を何に使っているのかはわからない。また、それを示唆する調査が行われたという話もきいたことがない。けれども、瞬間風速で世界中から同時に莫大なアクセスがかかってもびくともしないCydiaのことだから、おそらくAmazon EC2で無制限にスケールアウトするような契約になっていても不思議ではない。そして、そのために支払っている費用は膨大な金額だろう。CydiaはWebアクセスするほぼすべてのページに広告が入っているけれども、果たしてその広告収入だけでどこまで費用を賄うことができるのか、あるいはそれ以外の資金が投入されているのか、もちろん誰にもわからない。

もうひとつ、Cydiaで購入したアプリやTweaks等はすべてSaurik名義での請求になる。たとえそれが$0.99のものであっても、数$のものであっても、いったんSaurikの口座を経由して作者に支払いがなされているのは間違いない。実際にファイルが置かれているリポジトリは外部にあることが多いけれども、それでもPayPalからの請求書には必ずSaurikIT, LCCと書かれている。これまで疑問には思わなかったけれども、Cydiaで「購入済み」と表示できるようにするためにはCydiaのバックエンドで購入行為を管理するというのはわかるものの、Saurik名義ですべて請求する必要が絶対にあるかどうかには議論の余地があるように思われなくもない。

Cydiaはapt-getをコマンドラインで行わなくてもよく、登録したリポジトリの更新情報も管理してくれる、よくできたアプリだ。そして、Cydiaそのものが死ぬときはCydiaがデプロイされているAmazonクラウドのリージョンが死んだときだけで、瞬間風速で困ったことになるのは、外部のリポジトリが負荷に耐えられなくなって死ぬとかストールしているときに、更新情報が得られなくてCydiaの画面のなかでタイムアウトするだけだ。Saurikはそのためのバックエンドの改良や維持管理の責任を十分に果たしているとは思う。ただ、それと、ログインに使ったアカウントに対するほぼ無制限のアクセスを登録することとは話が少し違うのではないかと思うのだが、勘違いなのだろうか。

iOSデバイスへの無制限のアクセスを可能にする自由への対価として、個人情報をSaurikに渡すことが妥当かどうかは考えてもよいことだろう。早い話、Cydiaでログインに使うアカウントは普段のGoogleアカウントとは別のものを使えばよいのだが、その場合、もしそれまでに購入した有料アプリやTweaksがあったとしても、それらは（必要ならば）買い直しになる。もしくは、無料のものを取得するためだけに使っているならば（CydiaがiOSのなかを探っているのではない限り）懸念することはないだろう。ただし、Cydiaが動いているということは、Sandbox機能が外されているということだから、任意のアプリがiOSのあらゆる場所をアクセスできるということは考慮すべきとは思う。

iOS 6はTwitterのみならずFacebookとの統合が進み、どこからでもツイートやポストができるし、両方を登録したデバイスでツイートすればFacebookにも勝手にポストされる。

自分のFacebookアカウントで確認してみたところ、TwitterアプリはFacebook上のありとあらゆる個人情報にアクセスするような表示が出た。TwitterアプリはFacebookサイトから削除ができたけれども、Facebook公式アプリはサイトに現れないので、どうなっているかは全くわからない。ただ、Facebookのありとあらゆるところ（設定変更など）が触れなければ欠陥アプリとなるおそれが大だから、すべて許可なのだろう。iOSとFacebookの「深い統合（deep integration）」の意味するところについて、そろそろよく検討してみたほうがいいかもしれない。

問題だったWebKitのバグはiOS 6.0.1で修正されたそうだ

先日やられたWebKitのバグは、きちんとAppleに伝えられ、iOS 6.0.1で対策されたようだ。threatpostが伝えている。

Apple Patches Kernel, Passcode Lock and WebKit Flaws in iOS 6.0.1

https://threatpost.com/en_us/blogs/apple-patches-kernel-passcode-lock-and-webkit-flaws-ios-601-110212

そもそもカーネル内部に入り込める脆弱性があったというのは驚き。kext用に用意してあったOSBundleMachOHeadersというキーでカーネル内部のアドレスを取得でき、そこはADSRしてあっても直接アクセスできるから便利という話のようだ。

Passcode LockとPassbookの関係は各地で既報の通り。デザインの問題と思う。

最後のWebKitの問題で、僕がやられたのはおそらく前者のJavaScriptの配列の扱いに関するものだと思われる。どうやらここに何らかの脆弱性があって、細工したJavaScriptを食べさせれば任意のコードが実行可能だったらしい。

後者はSVGに関するコードに、ダングリングポインタを放置しているところがあるらしく、当然戻り先がおかしくなるのでSVGを含むページをうまく細工して任意のコードを実行させるという話。

とりあえず、すでに攻撃コードが配布されている脅威は対策されたということなのだろう。

ただ、iOS 6.0.1もまだWi-Fiに問題があるような気がしている。6.0は問題外だったが、アンテナ立ってるのに通信しないケースが、まだ6.0.1にも残っている感じがする。そこで、Apple税を払っているので6.1 beta 1にしてみたら、結構いい感じ。iOSに関してはいつものことだが、6.0より軽くなっている感じがする。

いい気になってiPod Touch 4GだけでなくiPad 3までiOS 6.1 beta 1にしたのだが、WOWOWのオンデマンドアプリがiOSバージョンチェックで動かなくなってしまったというオチ。いやはや。

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

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

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に開示されると明示されている。
----