アカウント名:
パスワード:
マウスポインタを操作して勝手に「許可」をクリックさせるという力技だが、有効性は高い。
OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは、Mac OS というものは設計からして脆弱なんですね。
Windows の場合、Windows Vista 以降ならOSが出す権限昇格などを求めるダイアログ（UAC）は、ダイアログが表示された時点で内部的に隔離された仮想スクリーンに切り替わるので、アプリケーションがマウスやキーボードを操作して承認させることはできません。
どうしてもやりたかったら、マウスやキーボードのドライバを書き換える必要がありますが、署名の無いドライバは最近のWindowsでは原則としてインストールできなくなっています。また、当然ながらドライバのインストールには管理者権限が必要です。
＞OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは
本来、OS Xではユーザーがアクセシビリティ機能権限をあらかじめ付与したアプリしかこのような攻撃を行うことは出来ないようになっています。
なぜこのマルウェアがアクセシビリティ機能権限を付与されたかのようにふるまうことが出来るのか不思議なのですが、本件に関する報道記事のどこを見ても書いていないのでよく分かりません。別のセキュリティホールを突いているのか、それとも単なるソーシャルエンジニアリングなのか。
マウスドライバとして入り込むってケースもあるけど、この場合Windowsもやられるね。ドライバの場合署名を得るのが大変だからインストールにユーザの手をガッツリ借りる必要があるけど。# ドライバの署名、MacではOS X Yosemite(10.10/2014年10月17日)まで不要だった(！)ようだが
Windowsについて、すごい間抜けな質問かもしれないんだけど。UACって、権限昇格用に通常と異なるデスクトップセッションを立ち上げるって認識です。で、UACの昇格（黒っぽい画面）が聞かれてる場面でPrintScreen押したら黒っぽくない画面のスクリーンショットが取れたんだけど、Windowsもやられるって本当にそうなの？
UACで別のセッションが立ち上がっても、そこにはマウスやキーボードが繋がってるわけです。
まあ、マウスドライバよりもキーボードドライバの方が楽でしょうけど、「任意の文字列を送り込めるような疑似キーボードデバイス」ドライバをインストールさせることができれば、あとは、UACが画面表示されてるタイミングで ALT-Y を送り込むことで、UACをスルーできます。
Windowsに限らずどんなOSでも、「OKボタン一発」なUIで操作できる限りは、原理的に回避不能。回避するにはUNIX系のsudoのようにパスワードを聞くようにするか、「怪しいドライバはインストールできない」ようにするしかないですね。
キーボードドライバレベルでマルウェアを混入できるなら、キーロガーとしてパスワードを盗めますな。sudoでパスワードを要求するUNIX系なら、簡単に管理者パスワードを盗まれてしまうでしょう。UACが気の利いているところは、あえてパスワードを入力させないことだと思います。よく考えられてる。
すみません、管理者パスワードは必ずしも無理ですね。確実なのはログインユーザのパスワードです。
いや、ログインユーザーのパスワードも隔離されてない？CTRL+ALT+DELから"パスワードの変更"を押してPrintScreen押してみたけど、これもCTRL+ALT+DEL以後は効いてない画面でした。キーボード(PrintScreen)を抑制して、マウスを抑制しない理由ってないよね？
根本的に色々誤解してるよ……とりあえずPrintScreenを押した時の挙動はこの話に何の関係もない。何の検証にもならない。
ここでいう「入り込むドライバ」はPCの「ハードウェアに近い場所に攻撃用の見えない機器を仕込む」ことだと思ってください。
UACを突破する場合は偽の見えないキーボードやマウスを繋いで、攻撃アプリが権限昇格を要求した時にそのマウスで承諾操作を行います。
パスワードを盗む場合はキーロガーと呼ばれる有名な攻撃方法で盗まれます。イメージとしては、キーボードの先に偽のPCがあってキー入力を勝手に記録しつつ、入力された内容を本来のPCにもう一度送り直す見えないキーボードが追加される感じです。パスワード入力中と思われるタイミングで記録された内容を特定されればパスワードが盗まれます。
PrintScreenを押した時の挙動はOSに正しくキー入力が伝えられた上で、OSがこの画面ではこの内容を撮影する(しない)を決めているだけなので、全く関係ないです。
誤解してるのはそうなんでしょう。でもそこが私が知りたいところでもあるので申し訳ない。
キーロガーについては、キーボードとUSB端子等の間にあるものは問題があるでしょう。ソフトウェア（ドライバ）のものなら、OSの制御の下にあると思います。UACで権限昇格する場合はデスクトップセッションが分かれるようなので、ソフトウェアは別セッションの情報を読めるのか？っていう話になるのかなと思います。
PrintScreenのスクショがUACなしに見えるなら、きっとドライバもUACなしに見える画面までしか取れないでしょう。妥当でないならごめんなさい。
同じソフトウェアでもユーザモードとカーネルモードはかなり性質が違います。
全然正確な表現ではないけれど、UACとかセッションはユーザモードを区切る物、アプリケーションやPrintScreenは区切られた何れかのユーザモードで動く物、デバイスドライバはよりハードウェアに近い単一のカーネルモードで動く物です。ユーザモードドライバもありますが、システム内で単一であることは同じです。# 対応するハードウェアが一つなのでドライバをセッションごとに独立させると問題がある。# 正確には、LocalServiceで動く単一のドライバスタックにリフレクター経由でアクセスするとの事 [microsoft.com]
カ
ごめん、Alt-Yが妥当かどうかの確認は、話が違うと思うよ。
無理、というかそれが出来ないからsudoみたいなのも出来なくなってる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
OS の設計が脆弱ですね (スコア:2, 興味深い)
OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは、Mac OS というものは設計からして脆弱なんですね。
Windows の場合、Windows Vista 以降ならOSが出す権限昇格などを求めるダイアログ（UAC）は、ダイアログが表示された時点で内部的に隔離された仮想スクリーンに切り替わるので、アプリケーションがマウスやキーボードを操作して承認させることはできません。
どうしてもやりたかったら、マウスやキーボードのドライバを書き換える必要がありますが、署名の無いドライバは最近のWindowsでは原則としてインストールできなくなっています。また、当然ながらドライバのインストールには管理者権限が必要です。
Re: (スコア:1)
＞OS（かOSの付属アプリ）の出しているセキュリティ上の承認を求めるダイアログに対して、そんなレベルの低い手段が通用するとは
本来、OS Xではユーザーがアクセシビリティ機能権限をあらかじめ付与したアプリしかこのような攻撃を行うことは出来ないようになっています。
なぜこのマルウェアがアクセシビリティ機能権限を付与されたかのようにふるまうことが出来るのか不思議なのですが、本件に関する報道記事のどこを見ても書いていないのでよく分かりません。
別のセキュリティホールを突いているのか、それとも単なるソーシャルエンジニアリングなのか。
Re:OS の設計が脆弱ですね (スコア: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みたいなのも出来なくなってる