Linux/CGP作業メモ

■Appleの使用IPアドレスはClass A（スパムチェック手法）
　Apple名義でiTunes Storeのアンケートが送られてきたのだが、クリックで誘導される先がhttpsではあったものの、www.itunespulse.comという聞慣れないドメインでwhoisによるとApple所有のドメインにも関わらず、証明書の名義がSocratic Technologies, Inc.になっていたのでちょっと気になって調べてみたメモ。ちゃんとアンケート自体に「アップルの調査の実施は、独立マーケティングリサーチ会社であるSocraticによって行われています。」という一文があるので適切な説明はされているのだけど、やはりSSL証明書が別企業になっていてデザインがアップルっぽいのものになっているとちょっと気にしてしまう。で、フィッシングを警戒して調べてみたらAppleってClass A のIPアドレスレンジを所有してるんだなと言うことがわかってちょっと驚いた。

■調べた手順
０）URLやSSL証明書の所有者を確認
　ANSI Whoisなどで所有者検索
　SSL証明書はブラウザから詳細を確認
１）メールヘッダを解析
　Recievedヘッダにあるサーバ名とIPアドレスをチェック
　Return-Pathの確認
２）SPFの確認
　Return-PathのアドレスにあるドメインのTXTレコードをdigで確認
３）TXTに書かれたIPアドレスを確認
　ANSI Whoisなどで所有者検索

　結果どれもAppleの正当な所有のもと発送されたメールであると判断できるものであったが、それであればなおのことSSL証明書だけが別会社名義というのが残念な感じ。apple.com名義のSSL証明書の不正利用を懸念してこうした構成にしているとするなら、本来はアップルが取得した上で自管理サーバ上にインストールし、Webアプリと集計データのみをSocratic社のコントロール範囲とすべきと思う。

　で、この経緯の中digの結果が以下であったことから、「え？流石にAppleがClass Aの17.0.0.0全体を所有してるとかないんじゃね？相当適当にSPF書いちゃってるのかなぁ？」と思ってWhoisで所有者を確認したところ、以下にあるように正当な所有者でしたと…（滝汗　一体いつの間に…Sunに買収されるかもという時期にオンタイムでApple関連企業で仕事していた身としては今の企業成長度合には常々びっくりしてはいたものの、このIPv4が枯渇しようかという時期にClass Aを所有できるようになっていたとは…とか思ったけどwhoisでは初回登録が1990-04-16になってるから、ほんとネット草創期からAppleが保有したままだったのね。17とか早い番号を所有しているのも納得。先駆者メリットだったんだなぁ…

■digのTXTレコード取得結果
　;; ANSWER SECTION:
　apple.com. 3600 IN TXT “v=spf1 ip4:17.0.0.0/8 ~all”

■Whoisの結果
　NetRange: 17.0.0.0 – 17.255.255.255
　CIDR: 17.0.0.0/8
　OriginAS:
　NetName: APPLE-WWNET
　NetHandle: NET-17-0-0-0-1
　Parent:
　NetType: Direct Assignment
　RegDate: 1990-04-16
　Updated: 2010-04-09
　Ref: http://whois.arin.net/rest/net/NET-17-0-0-0-1

　OrgName: Apple Inc.
　OrgId: APPLEC-1-Z
　Address: 20400 Stevens Creek Blvd., City Center Bldg 3
　City: Cupertino
　StateProv: CA
　PostalCode: 95014
　Country: US
　RegDate: 2009-12-14
　Updated: 2010-04-06
　Ref: http://whois.arin.net/rest/org/APPLEC-1-Z

(2 投票, 平均値/最大値: 3.50 / 5)

Loading...

■WhisperCore 0.4アップデートメモ
　以前インストールしたWhisperCoreが0.3から0.4にアップデートして機能も追加されたということでアップデートしてみたメモ。改良点はなかなか気が利いていると思った。

　WhisperCore
　http://www.whispersys.com/whispercore.html
　WhisperCore 0.5アップデートメモ
　http://blog.isnext.net/issy/archives/1272
　NexusOneにWhisperCoreをインストールしたメモ
　http://blog.isnext.net/issy/archives/1094

■WhisperCore 0.4改良点
・ロック画面で皮脂跡によるクラックを防止する機構を搭載
・システムのバックアップをクラウドにセキュア保存するFlashBackの搭載
・Android2.3.4へのアップデート
・kernel 2.6.35を採用

■アップデート
　既に0.3をインストールしている場合は アプリ一覧から
　WhisperCoreUpdaterを開き、Check for Updatesボタンを押すだけ

　…だけだったはずが、なぜかリリース後1日経ってるのにnot found…
　仕方ないので、0.4のインストーラをダウンロードしてインストールした
　※端末が完全に初期化されるので注意（アップデートはなく新規のみ可）

■Smudge resistant screen unlock
　Andoridではスクリーンのロック画面で指の軌跡を利用するパターンロックや、パスコードロックの設定が可能になっている。しかし利用状況によっては、皮脂により操作の跡が画面に残ってしまい、クラックする際のヒントになってしまう可能性がある。そこでWhisperCoreでは独自のPINコードパターンを追加したり、パターンロック解除後ワイプ操作を強制することで皮脂跡を残しにくい工夫を追加している。

　１）独自PINコードパターン
　　設定＞位置情報とセキュリティの設定＞画面ロックの設定＞SecurePINで設定
　　画面中央に１〜５の数字ボタンが縦に並ぶので、６ケタの数字を設定する
　　画面のロック解除の項目にForce screen wipeという項目が出るのでチェックする
　　ロック画面にして解除しようとすると同じく１〜５の数字ボタンが縦に並ぶ
　　PINコードを入力すると、スライダが表示される
　　１〜５のボタン位置をワイプするように縦に引き下ろす動作でロック解除
　　ボタンのどこを押したかワイプしてしまうため、特定されにくい状況が作られる

　２）パターンロックワイプ
　　設定＞位置情報とセキュリティの設定＞画面ロックの設定＞パターンで設定
　　画面でパターンロック設定を行う
　　画面のロック解除の項目にForce screen wipeという項目が出るのでチェックする
　　ロック画面にしてパターンを入力して解除する
　　次の画面でパターンのあった位置に☆マークが並ぶので全てワイプして★に変更する
　　全て★になったところでロックが解除される
　　パターンのあった位置を全てワイプするのでパターン自体が特定されにくくなる

■FlashBack
　端末の内容やSDCardの内容までセキュアにクラウド上にバックアップを作成してくれるサービス。要アカウント登録。クラウドはAmazon S3を利用しており、アカウント登録時にamazon.comのアカウントも必要になるので注意。FlashBackは無料だが、amazonのストレージは有料？のように見える…微妙な感じなのでアカウントまでは作成していない。詳細はこちらを確認。暗号化部分の詳細についても公開されておりこちらで確認ができる。現状ではストレージがamazon S3限定なので、任意のWebDAVに保存させてくれると使い勝手がいいと思うのだが、WhisperSystemsはここで利用料金を取ろうと思っているようなので、ちょっと期待できないかもしれない。

■WhisperCore0.4の使用感
　起動時の立ち上がり（電源ON時のパスフレーズ入力からホームが出るまで）は0.3より体感で速くなったように感じる。ちゃんと測定していないので正確ではないが５〜１０秒ほど短くなっているように思う。ROMとしての安定感は変わらず。非常に興味深いパーソナルファイアウォール実装であるWhisperMonitorも0.3と変わらずしっかりとポートチェックをしてくれるので安心感はある。Android2.3.4になったことでの大きな動作変化（タッチレスポンスが劇的に速く変わったとか）はないが、短時間なりに使ってみた印象では安定ROMとして使うには十分と思われる。

　個人的にはWhisperMonitorとそれに必要な部分だけでも他のROMで使えるようにして欲しいなぁと思う。端末自体を暗号化してデータを守る専用ROMというスタンスはわからなくはないが、むしろそちらのニーズよりはパーソナルファイアウォールとしてのアプリへのニーズの方が多いと思うので、今後WhisperMonitorが他ROMで利用できるよういくらか技術公開をしてもらいたいと願う。WhisperSystemsの提供しようとしているセキュアなAndroid端末環境は非常に興味深いので、今後もWhisperCoreをウォッチしていく予定。次のバージョンアップが楽しみ。

(まだ評価されていません)

Loading...

■「99.7%のAndroid端末に不正アクセスの危険」検証メモ
　一応気になったので検証してみたメモ。と検証記事を書く前に、18日時点で既にGoogleから修正が提供されているという記事が。

　99.7%のAndroid端末に不正アクセスの危険 – Googleがセキュリティ修正
　http://journal.mycom.co.jp/news/2011/05/19/034/
　Google、Androidアプリの情報流出問題で対応を表明
　http://www.itmedia.co.jp/news/articles/1105/19/news020.html

■やったこと
　iMacのインターネット共有設定でAirMac経由のアクセスをAndroid端末に共有し、該当I/FをCocoaPacketAnalyzerでキャプチャする。その後端末上のアカウントの同期を行う。同期を行って確認した設定アカウントは以下。
　・Exchange ActiveSync（自サーバ設定）
　・Google Account
　・HTC Sense用 Twitter
　・Twitter（Twitterオリジナルアプリ）
　・Google Market（マーケットアプリを起動）

■検証結果（001HT 2.3.3で実験）
　18日から提供されているGoogleの修正はサイレントフィックスということで適用されているかどうか明示的に判断する術がわからない。が、今回キャプチャした中でオリジナルの指摘にあるauthTokenに当る「Authorization: GoogleLogin auth=」から始まる行は確かに平文で確認することができたので、適用されていないということだろう。

１）Exchange ActiveSync
　自前のCommuniGate Proサーバに設定しているため、直接サーバとHTTPSで通信。全ての通信がHTTPSで行われる。

２）Google Account
　User-Agent: Android-GData-Contacts/1.3 (ace GRI40) がGETのURLでGoogleアカウントのメールアドレスを含み、Authorizationヘッダを付けてandroid.clients.google.comへリクエストを送信している。Android-GData-Calendar/1.4 (ace GRI40) も同様。Google Account同期中にHTTPSのセッションも存在するがこれがおそらくメールの同期。メール以外は通信がHTTP平文だった。

３）HTC T Sense用 Twitter
　User-Agent: HTC-Android/1.0 がGETのURLでapi.twitter.com宛てに Authorization: OAuth oauth_consumer_key=から始まるトークンを送出し、その後のデータも全てトークン付きHTTP平文でやり取りしている。

４）Twitter
　３と同じapi.twitter.comにアクセスするが全てHTTPSで通信されている。

５）Google Market
　User-Agent: Android-Market/2 (ace GRI40) がHTTP平文でPOSTデータ中にrequest=から始まるコードを送信。送信毎に微妙に異なる内容だが、先頭から493文字が同一なので何らかの認証の役割が含まれているように思われる。

　このようにGoogle謹製アプリはメールを除いてマーケットまでもが平文通信かつauthTokenが確かに見えていた。またどうもHTC製Twitterアプリも平文通信でありオススメできない。AndroidでTwitterを利用するならTwitter謹製アプリにする方が安全なためオススメ。ちなみにGoogleはThawte、TwitterはRapidSSLのSSL証明書を利用しているようだ。

　WhisperCoreをインストールした際にGoogleアプリの多くが80番を指定して通信しているのが気になったが、こういうことだったのかと納得した。こうして見ると実はアプリが平文通信してるという例はかなり多いのかもしれない。まだまだ調べるといろいろ出てきそうで恐い。Android端末では、少なくとも以下のことは守った方が安心できそうだ。

・オープンWiFiは使わない
・SSIDとkeyが公知になっているWiFiは使わない
・どちらも利用せざるを得ない場合には同期オフにしてから利用するかVPN設定で利用する

　※一応HTCにはホームページの問合せフォームから通知しておきました。
　※5/20 19時ごろHTCから受領とチケット発行のメールが届きました。
　※6/3 19時ごろHTC日本サポートセンターからメールにて「電話で連絡してよいか？」と問合せあり。
　　メールにて返信をとのことだが、no-reply@htc.comからのメールで返信先指定なくわからず。
　　仕方がないので一応メール返信はして、合わせてチケットページと問合せページから返信をしておいた。
　※6/4 12時ごろHTC日本サポートセンターからメール。今回はno-replyからじゃなかった。
　　お詫びと担当者から連絡する旨の内容。電話連絡待ちということに。
　※6/9 18時過ぎHTC日本サポートセンターからやっと電話が来た。これは別記事に。

　→新しい記事にまとめました
　続「99.7%のAndroid端末に不正アクセスの危険」検証メモ
　http://blog.isnext.net/issy/archives/1207

(1 投票, 平均値/最大値: 5.00 / 5)

Loading...

■CommuniGate ProにStartSSLの証明書を複数使うメモ
　さっと覚書程度。無償SSL証明書の入手 【5/11追記】 で追記したのは、こちらの確認をしていたため。最後にTLS接続のブラウザ挙動の試験結果も軽く記載。

■試験前提
　ドメイン：example.com
　サーバ名：mail.example.com
　a) user01はuser01@mail.example.comとuser01@example.comの両方を受信可能にする
　b) user02はuser02@sub.example.comで利用する
　c) user01はsub.example.comでは受信しない
　d) user02はmail.example.comでもexample.comでも受信しない
　e) CommuniGate Proで利用するプロトコルは以下
　　SMTP/SMTPS/POP/POPS/IMAP/IMAPS/HTTP/HTTPS
　f) example.com, mail.example.com, sub.example.comのIPアドレスは同一

■CommuniGate Proの設定
　ここでは過去にCentOS5向けに高パフォーマンス環境のインストール記事があるので、そのリンクを紹介しておく。こちらの記事のプロセス１〜６までがおよそのインストール手順となる。

　カスタム版MyNETSとCentOS5で１万人規模のSNSを構築する
　http://blog.isnext.net/issy/archives/384

　ここではCommuniGate Proの管理画面で
[code]　　Mail Domain Name : mail.example.com
　　Langage : Japanese
　　Preferred Charactor Set : UTF8
　　Time Zone : (+0900) Japan_Koria
　　interface : expert[/code]
　としてスタートする

１）user01の設定を行う
　管理画面＞アカウント＞ドメイン＞mail.example.com＞オブジェクトにて
　アカウント作成　に　user01　と入力してアカウント作成ボタンを押す
　管理画面＞アカウント＞ドメイン＞mail.example.com＞ドメイン設定にて
　画面一番下、ドメインエイリアスに　example.com　と入力して更新ボタン

２）user02の設定を行う
　管理画面＞アカウント＞ドメインにて
　ドメインを作成　に　sub.example.com　と入力してドメインを作成ボタンを押す
　一覧に作成されたsub.example.comのリンクをクリック
　アカウント作成　に　user02　と入力してアカウント作成ボタンを押す

　ここまででa-dの条件は完了

■SSL証明書をインストールする
　StartSSLの証明書に関してはこちら参照。ここでは別途作成済みの秘密鍵と証明書をインストールする手順を紹介。

３）mail.example.comの証明書をインストール
　管理画面＞アカウント＞ドメイン＞mail.example.com＞セキュリティ＞SSL/TLSにて
　鍵のサイズでインポートを選択して、鍵の生成ボタンを押す
　カスタムPEM符号化鍵の入力の入力フィールドが表示される
　そこにmail.example.comの秘密鍵をペーストして鍵の生成ボタンを押す
　PEM符号化証明書の入力フィールドが表示される
　そこにmail.example.comの証明書をペーストして証明書の組み込みボタンを押す
　StartSSLから中間証明sub.class1.server.ca.pemを取得する
　認証局チェーン (オプション)にsub.class1.server.ca.pemの値をペーストして
　認証チェーンの組み込みボタンを押す
　StartSSLのCA証明はCommuniGate Pro標準で組み込み済みなので不要
　最後にSSL/TLSタブ下のPKIサービスをオンにする

　StartSSLの証明書はドメインのみ＋指定ホスト名の２つのURLを証明してくれるので、これでexample.comとmail.example.comの２つ分の証明書が組み込まれたことになる。

４）sub.example.comの証明書をインストール（３とほぼ同じ）
　管理画面＞アカウント＞ドメイン＞sub.example.com＞セキュリティ＞SSL/TLSにて
　鍵のサイズでインポートを選択して、鍵の生成ボタンを押す
　カスタムPEM符号化鍵の入力の入力フィールドが表示される
　そこにsub.example.comの秘密鍵をペーストして鍵の生成ボタンを押す
　PEM符号化証明書の入力フィールドが表示される
　そこにsub.example.comの証明書をペーストして証明書の組み込みボタンを押す
　認証局チェーン (オプション)にsub.class1.server.ca.pemの値をペーストして
　認証チェーンの組み込みボタンを押す
　最後にSSL/TLSタブ下のPKIサービスをオンにする

　これでsub.example.comの証明書も組み込み完了。

５）ユーザがアクセスするHTTPポートを変更する
　管理画面＞設定＞サービス＞HTTPUから画面右側のリスナーのリンクをクリック
　以下の設定を追加して更新ボタンを押す（1行1回）
　　80, 全てのアドレス, オフ, なし
　　443, 全てのアドレス, オン, なし

　これでHTTP:80とHTTPS:443でユーザがサーバにアクセスできるようになる。証明書の組み込み手順はここまで。

■ブラウザ毎のTLSの動作結果
　CommuniGate ProサーバにHTTPSでアクセスした場合に、TLS1.0の接続が正しく行われて同一IPでmail.example.comとsub.example.comの証明書が適切に選択されるブラウザはGoogle Chrome11とFireFox4だけで、IE8やSafari5はメインドメインになっているmail.example.comの証明書が優先的に適用され、sub.example.comにアクセスした場合証明書が正しくない旨のダイアログが表示されてしまう。ブラウザの仕様によって動作に差があることが確認できた。
　CommuniGate Pro本体で複数の証明書を取り扱う場合には上記に配慮し、ブラウザの選択に注意する必要がある。

…５ユーザまで無償のCommuniGate Proと無償のStartSSL証明書の組み合わせって個人で運用できる最強にセキュアなメッセージングサーバになるんじゃないかという気がする。

(まだ評価されていません)

Loading...

■NexusOneにWhisperCoreをインストールしたメモ
　以前にAndroidでの個人情報漏えい対策(DroidWall)の記事に「WindowsのZoneAlarmやMacOSXのLittle Snitchのように、通信時にアラームをあげてくれるタイプの製品が登場することを期待したい」と書いたのだが、その通りのパーソナルファイアウォール実装がWhisperMonitorとしてリリースされたので試してみたメモ。

　WhisperCore
　http://www.whispersys.com/whispercore.html
　WhisperCore 0.4アップデートメモ
　http://blog.isnext.net/issy/archives/1173
　WhisperCore 0.5アップデートメモ
　http://blog.isnext.net/issy/archives/1272

■WhisperCoreをインストールする
　WhisperMonitorはWhisper SystemsからWhisperCoreというカスタムROMに含まれるアプリとして提供されているため、以下のページからNexusOne用のインストーラをダウンロードして端末にカスタムROMとしてインストールを行う。（カスタムROMをインストールしたことない人、ROM Manager以外で標準ROMに戻す方法を知らない人はインストールしない方が賢明です、きっと。）

　WhisperMonitor説明
　http://www.whispersys.com/whispermonitor.html
　WhisperCoreインストーラダウンロード
　http://www.whispersys.com/whispercore.html

　今回はMacOSX版をダウンロードして実験。CyanogenMod 7.0.2.1がインストール済み（oem unlock済み、root化済み、CWM Recovery導入済み）のNexusOneを書き換え。Whisper Core Installerは端末のoem unlockを実行するので、保証を無くしたくない人は実行してはいけない（現時点でWhisperCoreが対応しているNexusOneやNexusSを使っている人でそういう人は少数だと思うが）。

１）USBデバッグをonの状態でMacにUSB接続する。
２）MacにダウンロードしたWhisper Core Installerを起動する
３）ダイアログに沿って進める
４）完了　とっても簡単w
５）端末の起動時にパスフレーズを設定する（毎回起動時に入力するため）

　WhisperCoreはセキュリティ強化？したカスタムROMのため、標準で内蔵ストレージが初期化＆暗号化される。SDcardの暗号化はオプションとなっていてインストール過程では勝手に暗号化されることはないが、念のためインストール前にROMのバックアップとSDcardに保存されたバックアップデータをPCのストレージに退避させておくことをオススメ。WhisperCoreとして元のROMに戻す機能も用意されていないので、元に戻すためには自分で準備をしておくことが必要になる。

■WhisperCoreのレビュー
　インストール再起動後のアンドロイドバージョンは2.3.3、モデル番号が Full Android on Passion、カーネルバージョン 2.6.35.7-59427-ga04760d-dirty moxie@searching #70、ベースバンドバージョン 32.36.00.28H_4.06.00.12_7、ビルド番号 full_passion-userdebug 2.3.3 WS0.3 eng. moxie.20110502.221518 test-keysとなっている。カスタムROMの内容自体はほぼ標準のAndroid2.3.xでレスポンスも悪くない感じ。アプリケーションとして WhisperCore Updater と WhisperMonitor が独自にインストールされている。また日本語環境にも対応しており、言語設定で日本語に設定することが可能で、日本語入力プログラムとしてオムロンソフトウェア社のJapanese IME Ver.1.3.5が導入されているのですぐに利用が可能。

　インストール直後にはWhisperMonitorはdisableの設定になっているが、アプリを起動してメニューを出してEnableしてあげれば即座に有効になる。その後ブラウザなどを利用するとダイアログが出て、宛先のホスト名 or IPと通信ポートが表示され、どのように許可を出すのか求められるようになる。許可の方法は以下の２つの項目の組み合わせ。
　１）宛先
　・ホストとポートをセットで限定した許可（To this address and port）
　・ホストのみ限定した許可（To this address）
　・ポートのみ限定した許可（To this port）
　・限定なしで許可（Anywhere）
　２）許可期間
　・一度だけ許可（Once）
　・再起動するまで許可（Until reboot）
　・常に許可（Always）
サンプルで許可（Allow）前提で書いているが、もちろん拒否（Deny）することも可能。条件を選んで許可か拒否のいずれかを選ぶことになる。ダイアログ上はアクセスしようとしているアプリ名 or システム名が宛先とポート番号とセットで提示されるので表示項目としては必要最低限ではないかと思われる。実際のところIPアドレスで表示される場合も多くどこが所有しているアドレスなのかわからないので微妙だなぁと思う。ある程度判断材料を提示しようとするならIP表示の場合は可能な限りwhoisなどで所有者まで表示してほしいと思う。

　一度設定した許可/拒否の条件は、WhisperMonitorアプリのFilter Rulrsタブでアプリ単位に確認できる。アプリをクリックすると設定された条件がリストされるので、変更したい条件を長押しするとPOPメニューからルールの削除やテンポラリ化ができる。アプリ毎の許可条件をわかりやすく確認できるのでこれは嬉しい。表示される条件は許可/拒否共に、再起動するまで or 常に の条件に設定されているもののみで、一度だけのものは表示されないので注意。Connection Historyタブには一度だけ条件も含めて許可/拒否した履歴がアプリのアイコンと共にリストされるため確認には非常に便利になっている。

　実際にこれらを使用してみると、如何にアプリがたくさんのアクセスをバックグラウンドでしようとしているか（広告表示のアクセスを含め）実感することができる。残念ながらこちらで記事にしていたTaintDroidのように通信パケットの内容までは表示してくれないのだが、いずれそうした中身も確認＆フィルタリングできるようになってくれると嬉しいなぁと思う。久しぶりにTaintDroidもその後をさらりと調べてみたが、まだ実装したROMについての言及は無いようで見つけることはできなかった。ディスカッションフォーラムもあまり活気無くやや残念な感じ。どこかでひっそり着々と開発実装が進んでいることを期待したい。

　とりあえずまだ改善の余地はあるものの、アプリ単位宛先単位で通信が制御できるようになるこの実装は非常に素晴らしい試みであると思われる。

■WhisperCoreのroot
　仕組み的にrootが有効になっていないと実現できないはずと思ったので、WhisperCoreのroot状況について確認してみた。MacのTerminalからadb shellで接続してsuしてみると、実にあっさりとrootになることができた。これはフォントの入れ替えもできるかな？と思い、日本語フォントの入れ替え手順を実行してみると、SDCardにインストールされたbusyboxを使って当然のように入れ替え可能。フォント自体は端末再起動しないとちゃんと反映されなかったが、adb shellからはroot権限でいろいろ実行することが可能。

　じゃあ要rootアプリはどうだろうと言うことでROM Managerをインストールしてみたところ、「特権コマンドを実行中にエラーが発生しました」ということでやはりNG。superuserアプリをインストールすればいいかな？と思ったが、インストール後、suのupdateインストールまでは再起動込みでなんとかできたところ、ROM Managerからはやはりエラーになりroot権限が利用できない状況は変わらず…。これについてはまた時間のある時に確認したい。

　とりあえずコマンドラインではrootでいろいろできそうなので、しばらくこの環境上で常用するアプリの動作など試してみようと思う。TaintDroidも言及していたが、こうしたレベルのセキュリティを実装するためにはAndroidではカスタムROMという手法を取らざるを得ないというのが残念に思う。むしろAndroidに標準で組み込んで欲しい機能だと思うだが…携帯として利用するエンドユーザ層を考えるといろんな意味で標準で搭載というのは難しいんだろうなぁ…と思ってしまう。せめて標準の範囲内で利用可否の選択肢を提供してもらえるといいんだが…iOSとの差別化の観点からも実現してもらいたいと切に願う。

(1 投票, 平均値/最大値: 5.00 / 5)

Loading...

■Viber for Androidを試したメモ
　やっとViber for Androidがベータテストに入ったので、登録して001HT(Desire HD)でインストール試験を行ってみた。001HTではデバイスに完全に対応していないという旨は表示されるものの、ほぼiPhoneアプリと同様のGUIと手順でViberを利用することができる。以下は例によってキャプチャしたりして判明した5/7時点の内容をメモしておく。

　最新の記事
　Viber 2.1遂に連絡先平文送信を変更
　http://blog.isnext.net/issy/archives/1610

■気付いたこと
　5/7時点のバージョンは 2.0.105930 beta
　Moreメニューの中にbetaらしくsend log項目がある
　ユーザからサーバへの送信XMLのデータが平文だけどURLエンコードされてる
　ベータテスター登録した番号以外受付されない
　アクティベートのアクセスは相変わらず平文
　GoogleAnalyticsにもRefererが平文のため電話番号が送信されている
　連絡先送信もTCP4244宛てやはり平文
　電話番号が入力されている連絡先以外は送信していない（iPhoneも同様と推測）
　今回は登録手順のどこにもHTTPSは利用されていないように見える
　Viberアプリを明示的に終了させる方法（メニュー）が用意されていない？

　今回電話として常用していない端末だったため、メールアドレスしか入れていない連絡先が多く、連絡先送信内容がいわゆる全件ではなく電話番号が入っているものを全件ということが明確にわかった。iPhoneの時には電話番号がほとんどに入っていたので見逃していたような気がする。

　先行したiPhoneアプリでも暗号化については限定的だったのであまり期待はしていなかったが、やはりAndroid版は非対応だった。一応登録まで行った時点でキャプチャを停止したので、それ以降通話などの試験は行っていない。Androidでは連絡先アプリなどの実装がメーカーカスタマイズによって異なる可能性があるため、互換性を維持するのはいろんな意味で大変だと思うが、とりあえずベータテストに漕ぎ着けたことは嬉しく思う。ただやはり個人情報の通信が暗号化されていないことは残念に思う。ログを適切に取得するための非暗号化ということであれば理解はできるのだがそのような説明は明示されていないし、ベータ版として選択的にSSL利用することもできないので、暗号化対応にはまだまだ相当長い道のりがあるのかもしれない…。ベータだからこそ暗号化実装を試して欲しかったなぁと個人的には思ってしまう。

　Viber社のプライバシーポリシーはよく検討されていると思うし、データ保持の仕組みなどの情報開示の取り組みには関心するものはあるが、肝心のViberアプリによって送信されるのは自端末の連絡先にある他人の情報であるからこそ、安全安心のために経路暗号化を行いプライバシーポリシーを守って適切にサービス運営をしてもらいたいと願う。

(4 投票, 平均値/最大値: 3.25 / 5)

Loading...

■endian UTM のアップデート方法メモ
　endian UTM (endian Firewall) Communityバージョンのアップデート方法メモ。残念ながらGUIの管理画面からは自動アップデートできず、手順を踏む必要がある。

■Endian Communityにレジストする
　以下のURLからEndian Communityにレジストする
　http://www.endian.com/en/community/efw-updates/

　登録すると確認メールが送信されてくるので、URLをクリックしてActivateする
　Welcomeメールに書いてある手順に従う

　メール記載の手順は以下。対訳（意訳）で紹介。

■アップデート手順
１）Enable SSH access on your firewall
　　使用中のUTMでsshサービスを有効にする

２）Open your favorite SSH terminal and connect to the firewall (On Windows you may use putty)
　　任意のsshクライアントで接続する

３）If your Endian Firewall Community is older than version 2.2 please run
　　root@efw-2:~ # rpm -ivh http://updates.endian.org/upgrade.rpm
　　version2.2以前を使用中の場合は上記rpmコマンドを実行する

４）Run the efw-upgrade script
　　root@efw-2:~ # efw-upgrade
　　efw-upgrateスクリプトを実行する

　　Please choose the appropriate channel for your environment and hit [ENTER]:
　　1) Production (stable releases)
　　2) Development (bleeding edge)
　　安定版か開発版か選択肢が出るので１の安定版を選択する

　　Please enter your username and hit [ENTER]:
　　usenameとして登録したメールアドレスを入力する

５）Life is too short to be serious! Become our fan on Facebook and have some fun!
　　Facebookでファン登録して楽しんでねw

5番の手順はともかく、シンプルにアップデートできる。１と２についてはsshを開けなくてもコンソールからログインすることでアップデートが可能。管理画面からもできていいんじゃないかと思われるが、UTMのadminとマシンのrootは違う人間が担当するという前提での設計なのかも。

(まだ評価されていません)

Loading...

■CommuniGate ProでAndroid端末をリモートワイプ
　Microsoft Exchangeの代替ソリューションのひとつであるCommuniGate ProでAndroid端末のリモートワイプ実験をしたメモ。CommuniGate Proはキャリアグレードのスケーラビリティと安定性を誇るソフトウェアにも関わらず５ユーザまで無償で利用可能で、ExchangeサーバのActiveSyncと近似した機能をAirSyncという名前で提供しており、これも無償ライセンス内で利用できる。このActiveSync互換のAirSyncを利用して、メッセージの同期とリモートワイプの実験を行う。試したのは手持ちのNexusOne (CyanogenMod7 Android 2.3.3)、GalaxyTab (Froyo XXJK5 Android 2.2)、Desire HD 001HT (標準 Android 2.2)の３つ。Android1.x系はそもそもExchange連携未対応なので対象外。CommuniGate Proのバージョンは5.3.11。

　設定は簡単。インストール済みのCommuniGate Proを用意してアカウントを作成、Android側ではExchange同期アカウントを利用して、CommuniGate Proのアカウントを設定してやればいい。注意点は以下。

・CommuniGate Pro側でHTTPの待ち受けをTCP80/443に設定すること（※追記参照）
　AirSyncはこれらのポート以外では動作しない
・Android側でアカウントを指定する時には＠以下も記述すること

■実験結果
１）NexusOne
　メッセージとアドレス帳の同期はOK。カレンダー同期はNG。
　リモートワイプは信号受信するものの無視。

２）GalaxyTab
　メッセージとアドレス帳の同期はOK。カレンダー同期はNG。
　リモートワイプは信号受信するものの無視。

３）Desire HD 001HT
　メッセージとアドレス帳の同期はOK。カレンダー同期はNG。
　リモートワイプは信号受信し即端末全体を初期化。

　メッセージとアドレス帳はどれも問題なく同期できたが、カレンダーがエラーとなり同期できなかった。リモートワイプが実行できたのは001HTのみ。Exchangeサーバだと端末側でアカウント作成時にデバイス管理者の追加設定許可を求められるはずのところを、CommuniGate Proではそのダイアログが出てこないことから、ActiveSyncとAirSyncで一部動作が異なっていることが確認できた。また端末側でもHTCのカスタマイズにより001HTでは本来Android2.2以降にあるはずのデバイス管理者設定項目が消失していることから、どうやらデバイス管理者設定の状態によりリモートワイプが実行できるかどうかが判断されているようだ。HTCの端末では2.1の頃から独自にExchange対応をしていたり、HTC Senceサービスで独自のリモートワイプサービスを提供していたりするので、その辺りの影響が出ているものと思われる。

　ちなみにCommuniGate ProではiPhone/iPadについては問題なくリモートワイプできている。CommuniGate Proは5.4系でAndroidに正式対応するということなので、今後修正がされる可能性はあるが、現在のところCommuniGate ProでリモートワイプによりAndroid端末のデータ消去を実行しようと思ったら、Android2.2以降を搭載したHTC製端末（HTC Sence 2.x以降）を選択する必要がある。（同端末はHTC SenceのWebサイトに登録することで、Webからデータ消去操作を行うことも可能だが、システム管理者が一括で管理したいというようなケースでは、Communigate Proを利用するメリットがある）

■追記
　AirSyncの待ち受けについては80/443のどちらか一方だけでも問題ない。httpは平文でデータ参照できてしまうことから、実運用する場合には443で設定する方が望ましい。またApache等と同居している場合など、CommuniGate Pro自体の80/443を有効にできない時には、proxy設定を利用して80/443への接続をCommuniGate Proの標準待ち受けポートTCP8100へ繋いでやることでAirSyncを行うことが可能。以下Apacheで443接続をproxy設定するサンプル。
[code]

ServerName cgp.exsample.com:443
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/httpd/cert/cgp.crt
SSLCertificateKeyFile /etc/httpd/cert/cgp.key

ProxyRequests Off
ProxyPass / http://localhost:8100/

ProxyPassReverse http://localhost:8100/
ProxyPassReverseCookieDomain localhost cgp.exsample.com
ProxyPassReverseCookiePath / /
Order allow,deny
Allow from all

[/code]

(まだ評価されていません)

Loading...

■Viber 2.0の暗号化対応は限定的
　待望のViber 2.0がリリースされたので、暗号化対応について確認してみました。検証方法はここと同じです。動作を確認したViberのバージョンは2.0.1です。結論から言うと確かに一部通信はHTTPSに対応しており暗号化対応されているものの、肝心の連絡先の情報を送信するプロセスはこれまで通りで平文のまま、掛電時の相手先番号及び新機能のテキストメッセージも平文であることが確認されました。
　また登録時にSMSが受け取れない場合「no code」ボタンから遷移するブラウザ画面へ引き渡されるURL中に電話番号がそのまま引数として設定されており、結果的に同ページで設定されているGoogleAnalyticsのURLにまでrefererとして電話番号が表示されている状況が確認されました。こちらもWebアプリの造り的にあまり望ましいものではないと思いました。現状を整理すると以下のようになります。

　最新の記事
　Viber 2.1遂に連絡先平文送信を変更
　http://blog.isnext.net/issy/archives/1610

■暗号化されたことが確認できたもの（https://secure.viber.com: Thawteの証明書を利用）
・登録プロセスの一部（暗号化しないこともあり？）
・Deactivate accountのリンク（登録情報削除の機能）

■暗号化されていなかったもの
・連絡先情報の送信内容
・掛電時の電話番号
・テキストメッセージの内容
・no codeボタンで開くURLの画面

　確かに2.0のリリース文には新機能としても変更点としても、暗号化について触れられていません。重要な部分が暗号化されていないことから、一部対応してはいるものの誤解を招かないよう表記しなかったのかもしれません。念のためキャプチャしながら複数回登録をやり直してみたのですが、同じ登録方法は短時間に繰り返せない仕様になっているようで、SMSが届かなかったり電話がかかってこなかったりとテスト状況が完全に同じプロセスを踏んでいないため、実際に動作が一部異なっているように見えたりと十分な検証とはいいにくいところはありますが、期待とは異なる結果になってしまったことは間違いないと思われます。

　正式にViber社より暗号化対応の発表があるまでは、個人利用者の方については「Viberは通信時の暗号化対応が適切になされていない状態なので手放しでオススメはできないが、連絡先の情報を最小限にしてViber利用者に絞るなどリスクを覚悟して使う必要がある」と言うことになると思われます。ちなみに暗号化対応がされたとしても、もしＰマーク等の個人情報保護体制認定プログラムの適用事業者に勤務している場合には、業務上利用しているiPhoneにViberはインストールしてはいけないということに変わりはありません。アドレス帳に取引先や従業員情報が入っていた場合、法人としてViber社と適切な契約状況になければ情報漏えいに該当すると判断される可能性が否定できないからです。

　残念ながらQ1末までに期待した暗号化対応は果たされなかったわけですが、暗号化に対応する姿勢は実装にも現れているので、もうしばらく動勢を見てみようと思います。

　※一部に誤解があるようですが、Viber社の掲示するプライバシーポリシーに記載されている第3者提供の条項はとても全うなものです。過去の記事にもあるようにViber社は現時点において説明通りであれば事業に必要な第3者と情報を共有しているに過ぎません。日本国内のＰマーク事業者でもここまでまともなポリシーの記載と情報開示をしている企業はあまり例がないと思います。このblogで現在取り上げているリスクは、通信が暗号化されていないこと＆クラウド環境にサーバがあることから、Viber利用者及びViber社以外の第3者が通信を盗聴することにより、何らかの被害が起きうる可能性に対しての問題提起であるとご理解いただければと思います。

(3 投票, 平均値/最大値: 4.67 / 5)

Loading...

■CodenameでAndroid端末をリモートワイプ
　前記事で紹介した無料のExchangeサービスCodenameを使ってNexusOneをリモートワイプしてみるテスト。

■Codenameアカウントの作成
　以下のリンクからアカウントを作成する
　チェックはOutlook Web Access & Exchange ActiveSync(25MB)につける
　http://codename.win1.jp/account/default.aspx

　今回はサンプルとして アカウント名を「astest」で設定する
　登録後指定したメールアドレスにcodename@win1.jpから通知が来る
　通知されたOWAのURLにアクセスしてアカウントの有効確認をする
　（ADへの登録に時間がかかることがあるので気長に待つ）
　https://ex.codename.win1.jp/owa/

■Codenameアカウントの設定（ActiveSync設定）
　OWAでアカウント有効確認ができたらAndroid端末に設定を追加する
　※¥マークは実際にはバックスラッシュで入力

　設定＞アカウントの同期＞アカウントを追加＞コーポレート
　メールアドレス：codename¥astest@codename.win1.jp
　パスワード：登録パスワード
　次へ

　ドメイン¥ユーザー名：codename¥astest
　パスワード：登録パスワード
　サーバー：ex.codename.win1.jp
　安全な接続（SSL）を使用する　にチェック
　次へ

　セキュリティのリモート管理　ダイアログにOK
　アカウントのオプションを適宜設定して次へ

　メールアカウントの登録で名前を付けて完了
　デバイス管理者を有効にしますか？で内容確認の上「有効にする」

■OWAからリモートワイプを実行する
　OWAのURLへアクセスしてログインする
　右上の「オプション」をクリック
　左メニューの「モバイル機器」をクリック
　ActiveSync設定のされているデバイスのリストが表示されるので
　「最終同期時刻」の表示されているデバイスからワイプ対象を選択
　「デバイス上のすべてのデータの消去を実行…」をクリック

　ワイプ完了後OWAに完了通知が届くので確認する
　確認したらモバイル機器からワイプされたデバイスを選択して
　「デバイスを一覧から削除… 」をクリック
　※この削除を行わないと同じ機器を再接続できないので注意

■リモートワイプ実行結果
　NexusOne（CyanogenMod7 RC2）ではデバイス管理者の権限がメールと
　なっていたが、リモートワイプ実行で端末が初期化された。
　ワイプコマンド受信後再起動し、起動後は初期アカウントの設定画面になる
　ただしSDカードの中身は初期化されずそのままだった

　おそらく端末実装等によりAndroid端末によりどこまで初期化されるかが
　異なると推測されるので要実機検証。

(まだ評価されていません)

Loading...