■「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=」から始まる行は確かに平文で確認することができたので、適用されていないということだろう。

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

2)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平文だった。

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

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

5)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...

■SPFレコードとスパムパターンのメモ
 最近思うことあってCommuniGate Pro本体でのSPFレコードの判定を有効していろいろなルールを書いてスパムのパターン解析をしたメモ。

■SPFレコード
 囮アドレスに来るスパムの傾向を見てみると90%以上はSPFはPassになっている。そこでdigで該当ドメインのTXTレコードを引いてみると、かなりの確率で “v=spf1 +all” が帰ってくる。”v=spf1 +all” でない場合でも100%末尾に “+all” が指定されていることで、全てのIPアドレスから送信されることを許容した設定になっている。

■Recievedヘッダ
 こちらも90%近い確率でRecievedヘッダが一行しかない。botから直接メールサーバに送信しているパターンだと想定される。

■X-Mailerヘッダ
 上記2条件の当てはまるパターンのメールは手元では100%X-Mailerヘッダがなかった。

 これらのことから、少なくとも自メールサーバ宛てでは、SPFレコードに+allが付いていて(2011年時点で+allとか付けてる時点でスパム認定でいいような気もする)、Recievedヘッダが1行、X-Mailer無しのパターンはほぼスパムでFAということに。

ちなみにCommuniGate ProのSPFチェックを有効にするのは以下の設定。
 管理画面>設定>メール>SMTP>受信>処理
 SPFレコードチェック を有効にする

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...