Google、Androidアプリのセキュリティスキャン実行へ 47
ストーリー by headless
監視 部門より
監視 部門より
Googleは2月2日、Androidマーケットで公開するアプリを自動でセキュリティスキャンするサービスを発表した(Google Mobile Blogの記事、
TechCrunch Japanの記事、
本家/.)。
「Bouncer」というコードネームで呼ばれるこのサービスでは、Androidマーケットで新規に公開されるアプリと、既に公開されているアプリの両方がスキャン対象となる。アプリがアップロードされると、パターンを使用して既知のマルウェアやスパイウェア、トロイの木馬などが含まれていないか分析する。また、すべてのアプリをクラウド上で実行して挙動を監視し、不正な挙動の見られるアプリについては、過去に発見された危険性のあるアプリとの比較も行われるという。さらに、新規登録される開発者アカウントについては、過去に別アカウントで不正アプリを公開していないかどうかといったチェックも行われるとのことだ。
「Bouncer」というコードネームで呼ばれるこのサービスでは、Androidマーケットで新規に公開されるアプリと、既に公開されているアプリの両方がスキャン対象となる。アプリがアップロードされると、パターンを使用して既知のマルウェアやスパイウェア、トロイの木馬などが含まれていないか分析する。また、すべてのアプリをクラウド上で実行して挙動を監視し、不正な挙動の見られるアプリについては、過去に発見された危険性のあるアプリとの比較も行われるという。さらに、新規登録される開発者アカウントについては、過去に別アカウントで不正アプリを公開していないかどうかといったチェックも行われるとのことだ。
パターンマッチは以前からやってましたが (スコア:5, 参考になる)
root取得につながる既知のexploitを突くようなアプリは1年くらい前からリジェクトされるようになっています。
これでAndroidマーケットから消えたアプリの代表例はたとえばz4root。
DroidDream(や、その既知の亜種)なども既知になった以降は
新規追加しようとしてもリジェクトされていますので、
今回の報道の件ではじめて導入されるような表現は本当は正しくないですね。
今まで名無しでやってことをさらに強化したからじゃあ名前付けるか、って感じでしょうか。
Re:パターンマッチは以前からやってましたが (スコア:3, 興味深い)
名無しというより、コードネームがBouncerでやってたという話では？
Symantecが「マルウェア入りのアプリを最大500万人がダウンロードした」というようなFUDを発表するに至って、Googleとしても放置しておけなくなったのではないかと思う。
放置していない、既知のマルウェアに関してはスキャンをかけて調べているし、動作パターンも調べているということを発表して、Symantecが煽るほど危機的な状態ではないとするのは必要だったのだろう。
結局マルウェアであるといったのはSymantecくらいで、ほかのベンダーは「アグレッシブなアドウェア」という判定だったし、挙げられたアプリの中ではマーケットから削除されなかったものもあるので、調べたうえで削除するほど悪質ではないと判断されたということだと思う。
Re: (スコア:0)
ついでにボコボコ落ちるアプリが公開されないような仕組みも入れてほしい。
ちょっと前のGoogle Map の updateはちょっとズームアップするとガンガン落ちまくったりしたし。
某電子書籍リーダも数冊読むとアプリ再起動しやがるし。
Re: (スコア:0)
Samsung製端末つかってるんじゃないの？
Googleマップが落ちるのはGALAXYシリーズの伝統だという認識だけど。
というかGALAXYシリーズはGoogleマップに限らず不具合多すぎなイメージ。
Re: (スコア:0)
今回の発表は単なる静的スキャンだけではなく、動的解析をしているという発言の方が大きいんじゃないかな？
より完璧なスキャンをするためにはセキュリティの専門家を雇うとか、どこかのベンダーと手を組むはずですが、少なくても後者に関してはだんまりですよね。
ICSの説明会でもスキャンをやってますと言ってたけど………
Re:パターンマッチは以前からやってましたが (スコア:2)
ネイティブコードでの開発を可能にしてるのが厄介な感じなんですかねぇ・・・
実際問題どの程度まで防げるんでしょうね。
Exploitもメーカーや機種固有の物があったりしますし、メーカーやアプリ開発者が見つけたor見つかった場合はブラックリストに乗っけてもらえるフローとか有るんですかね？
それとも、有名になったら初めて対策されるのかしら？
また、誤検知したらどのようにフローが流れるかも気になります。
有名アプリが誤検知で引っかかっても即座にマーケットから引っ込ませる？
それとも、マークするだけで人間が確認してから引っ込ませる？
いったいどうなるのやら。
公開側はある日突然誤検知で引っ込ませられた挙句、AdSenseのように支払い拒否されて裁判へ [srad.jp]では困るし。
後は、Google廃業 [srad.jp]と同じ、著名開発者の氏名住所で登録後にワザと引っかかる悪戯にどの程度耐性が有るか気になります。
最近のGoogle Checkoutで個人情報漏れ [srad.jp]って話もありましたし。
ある日突然どこそこの公式アプリを公開してたアカウントが消えました。では困りますけど。
# その方式である日突然Googleのアプリが消えたら笑うしかないわ。
Re: (スコア:0)
>ネイティブコードでの開発を可能にしてるのが厄介な感じなんですかねぇ・・・
>実際問題どの程度まで防げるんでしょうね。
>Exploitもメーカーや機種固有の物があったりしますし
逆説的な話ですが、たとえばAndroid端末の特定モデルの特定バージョン、せいぜい10万台、
そのうち引っかかるところまで来てくれるのが1000台程度(もあるわけないですが)、
さらにアンチマルウェアなどでガードされてなおさら対象は減り、
Google側の対処ですぐに撤去もされる、では
苦労してアプリ作ってAndroidマーケットに展開して犯罪取締りリスクや訴訟リスクを負ってまで、
とならな
Re:パターンマッチは以前からやってましたが (スコア:1)
現状のアカウント作成の容易さは言うほど犯罪取締りリスクや訴訟リスクが高いとも思えません。
それに関しては、
＞Google側の対処ですぐに撤去もされる
見つかれば・・・ですよね。
また、ターゲットが絞られるならそれはそれで有意だと思うのですが。
例えば自分が使っているSHARP機に共通のExploitが有るとか特定企業の制式採用されている特定モデルといった可能性が有ったりする訳ですが、そのようなスピア攻撃はどうなるの？という点に触れないのは酷な話です。
例えば上記のSHARP機共通Exploitであれば、日本語アプリにしてしまえば大半の海外モデルユーザーを対象にする必要がない訳で多様性はそこまで高くないです。。
ソーシャル的な要素(SHARP機向け！とか、特定企業の興味を持ちそうなジャンル、メールによる誘い込みとか）も使えば更に多様性は意味が無くなります。
極端な話、既にマーケットで公開されてるアプリをダウンロードして、毒を追加してリパックされた時、「本物」はどちらかなんて余りのアプリの多さにエンドユーザは大抵判るわけも無く、
上記手法で適当に拾ってきて特定機種用の罠を仕掛けたアカウントを1個づつ用意なんて攻撃に対処出来るのでしょうか？
なんとなく、その多様性による防御というモデル、言うほど機能するのでしょうか？と疑問符が付きます。
最終的に多様性は有るけど攻撃を受けるWindowsとそのWindows上で動くアプリレベルのような気がします。
その点、書類審査等によって安全性を担保しようというキャリア囲い込みのマーケットの存在意義は有るとは思います。
ソースコードまで提出を義務付けてコード・データのレビューを実施、その後そのソースからビルドし、提供といったセキュリティソフト屋のマーケットとかも登場しても面白いと思うのですけどね。
Re:パターンマッチは以前からやってましたが (スコア:3, 参考になる)
>現状のアカウント作成の容易さは言うほど犯罪取締りリスクや訴訟リスクが高いとも思えません。
AppleのAppStoreもGoogleのAndroidマーケットも同じですが
アカウント作成には本人名義のクレジットカードの登録が必要です。
※ 勘違いしている人が多いですがAndroidマーケットでも必須です。
クレジットカードまで用意する輩を前提にするならAppStoreもAndroidマーケットも変わりません。
クレジットカード作成に必要な書類一式揃えてるわけですからね。
>例えば自分が使っているSHARP機に共通のExploitが有るとか
>特定企業の制式採用されている特定モデルといった可能性が有ったりする訳ですが、
>そのようなスピア攻撃はどうなるの？という点に触れないのは酷な話です。
企業ユースでマーケットから勝手アプリを好き放題入れていればそりゃ危険でしょうね。
root奪取以外の通常のマルウェアも山ほどあります。
たとえば以前話題になったiOS向けのDolphin Browserとかね。
防衛策はiOSもAndroidも関係なく、勝手アプリをインストールしないことです。業務端末なんですから。
ちなみに、スピアアタックをしかけるならAndroidマーケットなんて使いません。
その会社の社員メアドにapkを添付して送信しまくるほうが1000倍早いです。
>ソーシャル的な要素(SHARP機向け！とか、特定企業の興味を持ちそうなジャンル、メールによる誘い込みとか）も使えば
>更に多様性は意味が無くなります。
それは前述「1000台かそこいら」に絞り込まれるのがより早くなるだけですね。
悪意ある者の最大の興味である分母は増えませんよ。
>なんとなく、その多様性による防御というモデル、言うほど機能するのでしょうか？と疑問符が付きます。
>最終的に多様性は有るけど攻撃を受けるWindowsとそのWindows上で動くアプリレベルのような気がします。
あなたの論点は「新しく発見された未知のExploit」にありますので話がずれています。
その前提ではiOS端末だって危険ですよね。「未知」なんですから。
自分の論点は既知のExploitで、端末固有の観点で
いろいろ塞がれてたり塞がれてなかったりそもそもOSバージョンすら違ったりする場合はどうなんだろう？です。
クレジットカード番号は「1ドル」で買える (スコア:1)
http://gigazine.net/news/20070322_underground_economy/
Re:パターンマッチは以前からやってましたが (スコア:1)
クレカの件はほかのツリーで出てるのでバッサリカットします。
「管理者を騙ったインストール指示メール」とかだったらどうなりますかね。
単にapk添付じゃメールGWで落とされるとか、apkからの導入には別途Androidの設定変更が必要ですから。
其れよりは、エンドユーザーが使い慣れてるマーケットを踏み台にする方が都合ヨサゲだなと。
もちろん、社内アプリを配布する際にapkで直にといった事をしていたなんて情報があればそちらの方がより効果的だとは思いますが。
なんとなく、貴方は「広く浅く」タイプの攻撃を想定されてるのかな？と思いますがどうでしょう。
なんでiOSが出てくるのか解りません。
未知のExploitが危険なのは全てのOS、アプリケーションに共通の話です。
そんなの当たり前ですよね。
私の論点というか、主張としては、そのような多様性が有ったとしても、ソーシャル的な物を利用することで有効に攻撃可能では？といった形です。
例えば「003SH専用ライブ壁紙」やら、「本アプリは003SH、005SHでしか動作しません」やら明記しておけばよいのです。
そもそも、普通にマーケット公開時にマーケットフィルター [android.com]を設定しとけばその機種使ってる人しか普通の手順では動かせませんし。
また機知というのは、Googleが知っていればというのが恐らく前提ですよね？
「特定界隈で幅広く機知」だが、「Googleは知らない」機知のExploitはどうするんでしょうって話です。
Androidの場合、メーカーがAndroid自身のセキュリティホールを発見して修正する場合があります。
その場合、メーカーから情報が上がってこなければ「Googleだけが未知のExploit」が生まれる素養となります。
またコア部分がOSSな都合上、ユーザーコミュニティ等オープンな環境で発見される事も有ります。
また、アプリケーション。例えば暗号化していないで個人情報を保管していた。
故に旧バージョンを利用しているユーザーにとって、そのアクセスするコードは重大なリスクになります。
当然アップデートやデータを削除し、使用中止が正攻法ですが必ずしも行われるとは限りません。
その際、そのセキュリティホールを利用しようとする可能性があるとして、例えば特定ファイルにアクセスしようとするという挙動を好ましくない物としてアプリ開発者がGoogleへ「悪意ある物がこのファイルへアクセスしようとするかもしれない」といったシグネチャを作るための情報を提供可能なのか？
また、Googleが情報提供を受けたとしても、何時間～何ヶ月後に実施されるのか、そもそも対応されない等、そもそもGoogleはどうするつもりなのか。
そういう体制・制度がどうなってるかといった物が気になったわけです。
一行で書けば、更新されないパターンファイルでウィルススキャンをしても意味が無いように、そのパターンを更新するための「ネタ」をGoogleはどっから引っ張ってくるつもりなのか。
それが気になっています。
検出される機知のExploitが増えないんじゃ有りもしない幻想に騙されるしかないのですから。
Re: (スコア:0)
勘違いしている人がいると思いますが、App Store も、カードレスでのアカウント作成が可能です（あまりその情報が表に出てないないので、何も考えていないとそのようなアカウントは作れませんが。特定の作り方をするとカードがなくてもアカウントを作れます。）
よく知らないけど、Android Market でもおそらく同等のことは出来るはずです。全面に情報が出てないだけかと思います。その意味では、クレジットカード番号を入力するメソッドはそれほどバリヤーにはならないのではないかと思いますが。
もっとも、アプリをアップロードする人がカードレスのアカウントでアップロードできるかどうか（申請できるかどうか）は知りませんが。
クレジットカードでなくてもいいやん (スコア:0)
デビットとか、チャージ式のカードでもイケたはず。
実際、vプリカでアプリ買ってます。その後JNBのワンタイムデビットでも買ってます。
アメリカだとその辺のスーパーとかコンビニでもチャージ式のカード売ってますね(SSNが必要って話もあるけど………)。
Re: (スコア:0)
カード番号だけ（ただの表面上の番号のみ）では
アカウント登録はできませんよ。
アカウント登録には、それこそ
「そのカードで好き放題買い物しキャッシングしちゃえる」
くらいの情報が必要で、
これは一円云々の話ではありません。
そして、そこまでお膳立てされたなら
スマホ向けマーケットでのんびり登録なんてしません。
まっさきにカード枠すべて使い切って現金資産に換金されますよ。
わからないなら本当の意味で勉強してきてください。
Re:クレジットカード番号は「1ドル」で買える (スコア:1)
ちょっとお高いね。
Re:クレジットカード番号は「1ドル」で買える (スコア:1)
「現金で買えないもの(情報)に価値がある。」とは考えないのですか？
Re: (スコア:0)
管理者を装ったメール程度で
わざわざAndroidマーケットからマルウェアをダウンロードするような輩は、
管理者を装ったメール程度で
社内パスワードなりなんなりをどんどんまき散らすようなレベルですから
そもそもスマホインフラからいったん隔離して情操教育からやり直すしかないですね。
これが理解できないほど妄想が強いなら病院行ってください。
Re:パターンマッチは以前からやってましたが (スコア:1)
パスワード程度に価値は無いですからねぇ。
第三者にとって価値があるのはパスワードを利用した先で得られる何かです。
真に守るべきはパスワードなんかではなく、「パスワードで守りたい何か」でしょう？
まぁ、そんな事はどうでも良くて、
スマホは最近出た新しい機材で、どのような注意が必要か教育が行き届いてるんでしょうかね。
例えば、悪い学習としてこういうツール [android.com]を、管理者が面倒だからとエンドユーザーにやらせてれば、「やった事がある操作の繰り返し」になるんですよね。
まぁ、妄想癖があるのかもしれませんね。
Re: (スコア:0)
自分で読み返してみるとわかると思うけどさ、
そういうのを「心配しすぎ」って言うんだぜ。
特定の更に特定の条件下でうんぬんなんて言い出したら、
多分死ぬしか選択肢がなくなるよ。
Re: (スコア:0)
>現状のアカウント作成の容易さは言うほど犯罪取締りリスクや訴訟リスクが高いとも思えません。
そうですね。
iTunesStoreなどでも、悪意のコンテンツ配布業者による不正アクセスで
勝手に購入されるという被害が多発したにもかかわらず、Appleが犯人を
探したり告発したりしたという話は一度も聞いたことがありませんしね。
App Storeでも同じでしょうね。
>＞Google側の対処ですぐに撤去もされる
>見つかれば・・・ですよね。
App Storeでも、アプリをダウンロードして改造して再公開した偽アプリが
見つかったら取り下げ食らってましたね。
愉快犯なので、なかなか見つからないから自ら「贋物
Re:パターンマッチは以前からやってましたが (スコア:1)
au one Marketの場合 [kddi.com]ですが、クレジットカードだけで開設出来る物のと異なり、お役所の謄本が必要となります。
もちろん偽造リスクは依然残りますし、堂々と悪意あるコードを組み込む可能性もありますが、現状のお手軽に開設出来るAndroid Marketと比較した場合は、よりはマシといった程度です。
Re:Androidはオワコン (スコア:4, 興味深い)
iOSは見て見ぬふりをしているだけな気が・・・・
つかMacの頃からそういう傾向がありますよ、Appleは。
アンチウイルスの類が開発しにくい結果でしょ。
Re:Androidはオワコン (スコア:2, 興味深い)
電話帳がノーガード、
勝手インターネット通信がノーガードのiOSは
どこをどうしようともユーザーに優しくなんてなりようがないですよ。
もちろん信仰心厚い信者の方々に関しては別問題ですが。
Re:Androidはオワコン (スコア:2, すばらしい洞察)
標的型マルウエアがここまで出回っているのによくもまぁそんなのんきなことを…。
Re:Androidはオワコン (スコア:5, 興味深い)
>その根拠は？
>Googleが認めないとマルウェアの存在が明らかにならないわけでも無し
Appleはセキュリティベンダーに対して
「iOS向けアンチウイルス/アンチマルウェアアプリの提供を禁止」しています
(注：ガチ。ちなみにiOS端末上で動作するMACOSX向けアンチウイルスアプリとは違う話なので注意)
提供したらベンダーごとBANされます。
さらに言えば、マルウェアの話題を発表するときにはAppleに伺いを立て、
Appleの気分を損ねるようなことをしないよう釘を刺されます。
結果として「iOSにはマルウェアなんてない」としか発表できません(さもなくばベンダーごとBAN)。
そのくらいAppleの独裁は歪んだものです。
どこぞのたとえ話では「中国の新幹線と同じ」と表現されてましたね。
Re: (スコア:0)
AppStoreで実際にマルウェアを公開してみせた専門家がBANされて
他のセキュリティベンダは口をそろえて「今期もAppStoreのマルウェアはゼロでした」って言うんだから
茶番もいいとこだよな
Re: (スコア:0)
＞結果として「iOSにはマルウェアなんてない」としか発表できません(さもなくばベンダーごとBAN)。
ここでの「ベンダーごとBAN」ってどういう意味？
前段のAppStoreの話なら登録が必要だから分かるけど、
発表するのにBANも何もないと思うけど。
Re:Androidはオワコン (スコア:2, 参考になる)
>前段のAppStoreの話なら登録が必要だから分かるけど、
>発表するのにBANも何もないと思うけど。
Appleの見解と異なる報道をしたらBANです。
すなわち「AppStoreでマルウェアを発見」とベンダーが発表したあと、
Appleが「あれはマルウェアではない」とした時点でベンダーがBANされます。
ですのでベンダーはまずAppleに伺いを立て、
いつもどおり「マルウェアではない」と返答されて黙るというループ。
致命的な穴などであればAppleが黙ってコッソリ修正します。
その間に被害者が出ても誰も助けてくれません。
中国の新幹線事故の被害者のように土に埋められてしまうだけです。
Re: (スコア:0)
> 「iOS向けアンチウイルス/アンチマルウェアアプリの提供を禁止」しています
iOSのウィルス情報がでてこないのは、ここが全てですね。
セキュリティーベンダーにとっては、アンチウィルスソフトを売りたいから危険性を声高に発信するわけだから。
販売するアンチウィルスソフトがないのに危険だと発信しても、「当社では解決できる製品はありません」では何の意味もない。
もしAndroidでもアンチウィルスソフトを作れなかったら、Androidの危険性なんてセキュリティーベンダーは発信しないでしょう。
Re: (スコア:0)
ある意味あの手法は「イノベーション」ですよねぇ……
道義的に良いか悪いかはともかく画期的な発想の転換だと思う
Re: (スコア:0)
信仰心を問題にするならAppleが最強でしょうね。
お布施の額もね。
Re: (スコア:0)
送信時に認証の仕組みを取り入れてなかったSMTPや、認証なしにTrackbackを受信するBLOGシステムなどの失敗から学べるのは、
プラットフォームを設計する際には開発者の良心や知性なんて期待しちゃ駄目って事ですわ。
プログラミング言語も、Cのような自由度の高すぎる言語は認定有資格者のみが使うべきです。
無資格者は、PascalやJavaのような「自分流は許さない、略さず全て俺に報告しろ」系の軍隊型言語が適してるような。
Re:Androidはオワコン (スコア:1)
軍隊型言語と言うならAdaを外したらいけないと思う.
Re: (スコア:0)
サンドボックスのようなものがあるJava はともかく Pascal と C を区別する理由はあるのか?
自由度の話なら、それらのどれもが自由度が高すぎる。Cはポインター関連でバグを生み出しやすいくらいの違いしかない
。
さらに、例に挙げたSMTPやBLOGの処理系がJavaで作られている例がたくさんある事とも矛盾しているよね。
Re: (スコア:0)
ここがfj.comp.lang.*じゃなくてよかった。
Re: (スコア:0)
fj.news.usageなのですね、わかります。
Re: (スコア:0)
junk.testだとばかり思っていました。
持ってない人には，関係ありません．
--
なーんて書いたら，resがつかんかったりして．
Re:Androidはオワコン (スコア:1)
thcomp [thcomp.org]ですか。懐かしい。
あの頃のjunk.testは「○○してみるテスト」と銘打てば何でもあり [2ch.net]なすごい場所だったなぁ…
でもやっぱり、junk.testの流れをくむのは2chで、
/.-Jは、fjの流れをくんでると思う。
#端から見ると、どっちも似たようなものに見えるかもしれません。特にvoid的に…
Re: (スコア:0)
ACでのお約束ギャグお疲れ様です。
Re: (スコア:0)
ここまで自演テンプレ
Re: (スコア:0)
Apple信者の被害妄想が止まりませんね。