あるAnonymous Coward 曰く、Mac OS Xに標準搭載されているパスワード管理基盤「Keychain」では、アプリケーションがパスワードリストにアクセスする際に確認のためのダイアログが表示されるのだが、このダイアログが表示された瞬間に「許可」を自動的にクリックするというマルウェアが発見されたそうだ（GIGAZINE）。マウスポインタを操作して勝手に「許可」をクリックさせるという力技だが、有効性は高い。画面を見ていれば何かが起きたことは確認できるが、Keychainへのアクセス許可が勝手に設定されるというのは判断できないかもしれない。
OS の設計が脆弱ですね (スコア:2, 興味深い)
OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは、Mac OS というものは設計からして脆弱なんですね。
Windows の場合、Windows Vista 以降ならOSが出す権限昇格などを求めるダイアログ（UAC）は、ダイアログが表示された時点で内部的に隔離された仮想スクリーンに切り替わるので、アプリケーションがマウスやキーボードを操作して承認させることはできません。
どうしてもやりたかったら、マウスやキーボードのドライバを書き換える必要がありますが、署名の無いドライバは最近のWindowsでは原則としてインストールできなくなっています。また、当然ながらドライバのインストールには管理者権限が必要です。
Re:OS の設計が脆弱ですね (スコア:3)
なにか根本的に勘違いしているような。Keychain は資格情報を管理しているが権限昇格を管理しているわけではないし。元記事もわかりにくい。Macへアドウェアをインストールするだけでなく、自動的にキーチェーンへのアクセス許可をクリックさせるインストーラーが発見される。 [applech2.com]が多分正しいのだろう。要するに有用なアプリのインストーラに見せかけて、管理者パスワードを入力させ、管理者特権を得た後に Keychain へのアクセスを得た特権でもってボタンを押す、ということのよう。
Windows に例えるなら UAC をユーザに了承させた後に、（いっそう）悪質な動作をするようになったということかな。UAC はユーザを騙してボタンを押させているわけだから「アプリケーションが」云々ではないかと。
Re: (スコア:0)
こいつの侵入、というかキーボード・マウスの擬似入力に必要な権限が管理者特権で保護されてるのかが重要なポイントなのは同意。
だけど「『（いっそう）悪質』な動作ができる場面ではこの手の自動操作を受け付けないUIへの切り替えがほしいよね」
って意味では別に勘違いでもなんでもないと思うけど。(あっても突破される可能性はあるがそれはそれで攻撃意図が明確になる)
# Windowsも未署名ドライバのインストールを擬似入力で切り抜けるインストーラが問題視された事はあった
単なるユーザ補助系のアプリであっても、キーチェーンの操作でまで有効となる必要があるのかは議論があるだろうし(UACは一応段階がある)、
WindowsでもUACでインストーラを許可してもドライバとかが特殊だと複数回UACで確認が要求されてその都度擬似入力は無効化されてた筈だし…
Re:OS の設計が脆弱ですね (スコア:1)
＞OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは
本来、OS Xではユーザーがアクセシビリティ機能権限をあらかじめ付与したアプリしかこのような攻撃を行うことは出来ないようになっています。
なぜこのマルウェアがアクセシビリティ機能権限を付与されたかのようにふるまうことが出来るのか不思議なのですが、本件に関する報道記事のどこを見ても書いていないのでよく分かりません。
別のセキュリティホールを突いているのか、それとも単なるソーシャルエンジニアリングなのか。
Re: (スコア:0)
マウスドライバとして入り込むってケースもあるけど、この場合Windowsもやられるね。
ドライバの場合署名を得るのが大変だからインストールにユーザの手をガッツリ借りる必要があるけど。
# ドライバの署名、MacではOS X Yosemite(10.10/2014年10月17日)まで不要だった(！)ようだが
Re: (スコア:0)
Windowsについて、すごい間抜けな質問かもしれないんだけど。
UACって、権限昇格用に通常と異なるデスクトップセッションを立ち上げるって認識です。
で、UACの昇格（黒っぽい画面）が聞かれてる場面でPrintScreen押したら黒っぽくない画面のスクリーンショットが取れたんだけど、
Windowsもやられるって本当にそうなの？
Re:OS の設計が脆弱ですね (スコア:1)
UACで別のセッションが立ち上がっても、そこにはマウスやキーボードが繋がってるわけです。
まあ、マウスドライバよりもキーボードドライバの方が楽でしょうけど、
「任意の文字列を送り込めるような疑似キーボードデバイス」ドライバをインストールさせることができれば、あとは、UACが画面表示されてるタイミングで ALT-Y を送り込むことで、UACをスルーできます。
Windowsに限らずどんなOSでも、「OKボタン一発」なUIで操作できる限りは、原理的に回避不能。
回避するにはUNIX系のsudoのようにパスワードを聞くようにするか、
「怪しいドライバはインストールできない」ようにするしかないですね。
Re: (スコア:0)
キーボードドライバレベルでマルウェアを混入できるなら、キーロガーとしてパスワードを盗めますな。
sudoでパスワードを要求するUNIX系なら、簡単に管理者パスワードを盗まれてしまうでしょう。
UACが気の利いているところは、あえてパスワードを入力させないことだと思います。よく考えられてる。
Re: (スコア:0)
すみません、管理者パスワードは必ずしも無理ですね。確実なのはログインユーザのパスワードです。
Re: (スコア:0)
いや、ログインユーザーのパスワードも隔離されてない？
CTRL+ALT+DELから"パスワードの変更"を押してPrintScreen押してみたけど、これもCTRL+ALT+DEL以後は効いてない画面でした。
キーボード(PrintScreen)を抑制して、マウスを抑制しない理由ってないよね？
Re: (スコア:0)
根本的に色々誤解してるよ……
とりあえずPrintScreenを押した時の挙動はこの話に何の関係もない。何の検証にもならない。
ここでいう「入り込むドライバ」はPCの「ハードウェアに近い場所に攻撃用の見えない機器を仕込む」ことだと思ってください。
UACを突破する場合は偽の見えないキーボードやマウスを繋いで、
攻撃アプリが権限昇格を要求した時にそのマウスで承諾操作を行います。
パスワードを盗む場合はキーロガーと呼ばれる有名な攻撃方法で盗まれます。
イメージとしては、キーボードの先に偽のPCがあってキー入力を勝手に記録しつつ、
入力された内容を本来のPCにもう一度送り直す見えないキーボードが追加される感じです。
パスワード入力中と思われるタイミングで記録された内容を特定されればパスワードが盗まれます。
PrintScreenを押した時の挙動はOSに正しくキー入力が伝えられた上で、
OSがこの画面ではこの内容を撮影する(しない)を決めているだけなので、全く関係ないです。
Re: (スコア:0)
誤解してるのはそうなんでしょう。でもそこが私が知りたいところでもあるので申し訳ない。
キーロガーについては、キーボードとUSB端子等の間にあるものは問題があるでしょう。
ソフトウェア（ドライバ）のものなら、OSの制御の下にあると思います。
UACで権限昇格する場合はデスクトップセッションが分かれるようなので、
ソフトウェアは別セッションの情報を読めるのか？っていう話になるのかなと思います。
PrintScreenのスクショがUACなしに見えるなら、きっとドライバもUACなしに見える画面までしか取れないでしょう。
妥当でないならごめんなさい。
Re: (スコア:0)
同じソフトウェアでもユーザモードとカーネルモードはかなり性質が違います。
全然正確な表現ではないけれど、UACとかセッションはユーザモードを区切る物、
アプリケーションやPrintScreenは区切られた何れかのユーザモードで動く物、
デバイスドライバはよりハードウェアに近い単一のカーネルモードで動く物です。
ユーザモードドライバもありますが、システム内で単一であることは同じです。
# 対応するハードウェアが一つなのでドライバをセッションごとに独立させると問題がある。
# 正確には、LocalServiceで動く単一のドライバスタックにリフレクター経由でアクセスするとの事 [microsoft.com]
カ
Re: (スコア:0)
ごめん、Alt-Yが妥当かどうかの確認は、話が違うと思うよ。
Re: (スコア:0)
無理、というかそれが出来ないからsudoみたいなのも出来なくなってる
Re:OS の設計が脆弱ですね (スコア:1)
> マウスやキーボードのドライバを書き換える必要があります
> 署名の無いドライバは最近のWindowsでは原則としてインストールできなくなっています。
見かけUSBメモリなデバイスだけど、HIDなマウスとして動作するようなトロイ [security.srad.jp]がUACを通過させるというのはあり得るような気がしてきました。
スクリーンセーバー稼働のタイミングとかでやっちゃえば、画面がごちょごちょ動いてもばれない可能性もあると思います。
Re: (スコア:0)
なにその後出しジャンケンみたいな話は？
Re:OS の設計が脆弱ですね (スコア:2, すばらしい洞察)
元コメの人があげてるのは UACなので Vista 移行だけど、NT3.1 から変わらずにずっと守られてるセキュリティポリシーですよ。
ログインパネルやロック画面、XPのユーザー切り替えなんかも同じもの。
Re: (スコア:0)
ログイン画面とかのやつって、セッション違うから一般ユーザアプリから触れないってだけではなかったんだ？
# UACが非難されてその辺の機能に注目が集まってる時に
# 「ウチもセキュリティ画面くらいはそういう機能つけよう」
# って話にはならなかったんだなぁ……
# まぁgksudoとかも'アレ'だしそう頑張る場所でもないのか
Re: (スコア:0)
ログインパネルに触れるのは唯一 WinLogin プロセスだけというのが伝統です。
UAC については UAC プロセスだけ。
Re:OS の設計が脆弱ですね (スコア:1)
UAC はそこまで完璧ではなくて、抜け道も用意されている。
純正以外の遠隔操作アプリ(VNC など)が UAC のダイアログを操作するために使っているよ。
アレゲなニュースと雑談サイト
Re: (スコア:0)
Windows NT 3.1 からだったら、「Windows Vista 以降なら」なんて書かずに、最初からそう書けよ。
それと、Windows XP (NT系だよね)の何度も世間を混乱に陥れたていたらくを見ると、「OS の設計が脆弱ですね」はそのまま NT にもあてはまるのじゃないの？たまたま UAC は当たりだったかもしれないけど。
要は、場数を踏んでいるかどうかの違いなんだよ。
Re: (スコア:0)
話をすり替えないように。いや、すり替えるにしても理解してからやれ。
こういう攻撃を防ぐセキュリティポリシーはNT3.1の頃からで、
それに従った分かりやすい機能の一例であるUACはVista以降。
何も矛盾しない。そもそも二つのコメントは投稿者が違う(一方はAC)。
で、何度も世間を混乱に陥れたって全く別の問題に関する話ですよね。
「MacOSはシェアが低くて狙われる率が若干低いってだけで安全性は別に高くない」
なんて余程の馬鹿でもなければみんな知ってるから、そんなバカ面晒して話を逸らす必要ありませんよ。
それとも信者のフリして大馬鹿晒すことでMacをdisってるんなら、鬱陶しいからやめてください。
MacユーザもWindowsユーザも*nixユーザも、誰も嬉しくないんで。
Re:OS の設計が脆弱ですね (スコア:1)
そこは、Vista登場から10年経とうと言うのになんでAppleは未だに改善してないんだ？では。
# 尚、UACのレベルを一つ下げると仮想スクリーンを生成しないので現行Keychainと同レベルに落ちます。
Re: (スコア:0)
OS Xのアクセスコントロールレベルは255段階ありますからWindowsより安全ですよ
Re: (スコア:0)
> Vista登場から10年経とうと言うのになんでAppleは未だに改善してないんだ？
割とマジで「ダサイから」って理由じゃないかな。
いや勝手な推測だけどさ。
ぶっちゃけUACなんてあろうとなかろうと、
他の侵入経路がいっぱいあるし、
どうせユーザーは自からマルウェアを積極的にインストールするし
所詮は「無いよりマシ」レベルなんだよね……悲しいことにさ。
Re: (スコア:0)
マルウェア対策なんて男のすることじゃない、やっぱり男はノーガードですよね……
と冗談はさておきセキュリティの問題において、安全性を高めるかだささを回避するか、
というのを天秤にかけるのはセンスあるとは言い難いと思うが。
Re: (スコア:0)
いいえ、先出しです。
先に手を打っておくのがセキュリティですから。
それが後出しになってしまった戦いの後にできた仕組みであったとしても、後発に対しては先出しの対策として働いています。
Re: (スコア:0)
確かにその通りですね。
アプリがマウスやキーボードを操作するのはユーザーがアクセサビリティ許可の設定をしない限り出来ませんけどね。
とはいえ、権限昇格に絡む部分では出来なくなっているべき。
Re: (スコア:0)
そもそものパクリもとのBSDの設計思想では「Keychain」みたいなのは想定してないでしょ。
増設したシロモノがダメだったてこと。
Re: (スコア:0)
Windowsの場合に、UACの画面がでてキャンセルするとまた即座にUACの画面を表示させることにより、
UACで許可させる以外ほかのウィンドウを操作できないように妨害することができ、
そうすることでマルウェアを許可させるやつに出会ったことがあります。
Genieo (スコア:2, 参考になる)
9月4日にOS Xのウィルス定義データベースXProtectが更新され、Genieoインストーラ（OSX.Genieo.C）はブロックされました。
XProtectのバージョンが2067であればアップデートが済んでいます。
ガセレポートに踊らされて楽しいか？ (スコア:0)
誰一人実地で確かめもせず、オリジナル記事も読まず。
あんたたち、他人の不幸を上から笑うだけのクズだな
http://applech2.com/archives/46183245.html [applech2.com]
> Jebaraさんらが主張していたiCloudキーチェーンへのアクセスが可能である点や画像ファイルへの埋め込みなどは不可能で、この方法は以下の様なプロンプトが必ず表示される
Re: (スコア:0)
結局WindowsよりOSXのほうがセキュリティ的にはマシってこと？
Re: (スコア:0)
なんでそういう結論になるんだ?
Gigazin 経由のネタ... だからそういうことだ (スコア:0)
「KeyChain 突破できたよ」って自称している Proof of Concept のビデオを見た記事を、都合良く日本語訳しているだけのサイト
をネタに雑談しているだけだ。