(ソフトウェアの)キーロギングを防止する比較的明白な方法のように思われるのは、現在の(フォーカスされている)アプリのみがキーストロークを受信できるようにすることです。
マクロアプリなどに対して明示的な例外を作成する方法が考えられます。例外リストを照会すると、キーロガーを簡単に見つけることができます。
オペレーティングシステムが既定でこのポリシーを適用しない理由はありますか?
それは役に立たないので。
ほとんどのキーロガーはオペレーティングシステムレベルでインストールされ、オペレーティングシステムはキーストロークにアクセスできる必要があります。 Alt-Tabプログラムの切り替え、Ctrl-Alt-Delを使用して誤動作しているプログラムを終了、およびキーボードアクティビティを検出してスクリーンセーバーがすべてアクティブにならないようにするには、OSにキーストロークを表示する必要があります。
OSがキーボードにアクセスできないようにすると、すべてのアプリケーションにキーボードドライバーの完全なセットを組み込む必要があるというマイナーな問題もあります。
キーボードからアプリケーションへのインターフェイスはいくつかの段階を経ます。その一部はOSによる制御がほとんどなく、一部は追加機能への明示的なフックを提供します。基本的な設計は次のようになります。ハードウェアイベントはドライバーチェーンによって受信され、ドライバーチェーンによってメッセージがカーネルに渡され、グローバルホットキーチェーンに送信され、最終的に目的のアプリケーションに送信されます(チェーンの前のステップでキャンセルされない場合)。 )。
ドライバーチェーンにより、カーネルはキーストロークが「どのように」生成されるかを気にする必要はありません。それらは、キーボード、IRデバイス、またはキーボードとして解釈されるように設計された信号を送信できるその他のソースからのものである可能性があります。たとえば、ハードウェアキーボードロガーは、一方の端にUSBまたはPS/2入力があり、もう一方の端にUSBポートまたはPS/2があるドングルで、キーボードがこのデバイスを介してデータを渡し、傍受されます。 OSは、そのようなロギングが行われていることを文字通り検出できません。
他の一般的な種類のロギングはソフトウェアで発生します。これは、OSがキーボードメッセージを表示する前または後に発生する可能性があります。ドライバーは何でも好きなことができ、OSがメッセージを検査する前にドライバーがメッセージを迂回していることをOSが厳密に検出することはできません。これは、ドライバーが含まれているハードウェアアブストラクションレイヤー(HAL)の性質です。幸い、それらはメモリ内にあるため、マルウェア対策ソフトウェアはそのような動作を検出して無効にすることができます。
最後に、OSに意図的な「穴」があり、通常「グローバルホットキー」と呼ばれ、フォーカスのあるアプリケーションの前にキーボードメッセージを渡すようにアプリケーションから要求できます。これにより、Alt-Tabが機能するだけでなく(ウィンドウマネージャーがこれらのメッセージをインターセプトしてアプリを切り替える)、ほとんどのメディアプログラムがハンドラーをリクエストして、再生、巻き戻し、早送りなどのマルチメディアキー、およびその他のユーザー向けアプリをサポートできます。ボリュームコントロールなど。これらのグローバルホットキーをすべて使用しないと、OSの使用が非常に煩わしくなり、その結果、アプリがはるかに複雑になります。ただし、これは優れた機能であると同時に、プログラムによって悪用される可能性もあります。
ただし、「すべての」プログラムがキーボードメッセージのコピーを取得するのではなく、ドライバー、グローバルホットキーハンドラー、フォーカスされているアプリケーションのみを取得することに注意してください。問題は、すべてのプログラムがキーボードイベントのコピーを取得するという事実とは関係ありませんが、HALがメッセージをハードウェアからカーネルメッセージに変換できる必要があり、グローバルホットキーが機能を提供するために必要です。同じ機能を提供するために各プログラムを構築する必要のないユーザー。
haveプロセスへのロックダウンが進んでいます。たとえば、「署名されたドライバー」が必要です。これにより、悪意のあるドライバーがドライバーチェーンに侵入する可能性が減り、アプリによる不正な動作を検出できるウイルス対策が行われます。 。ただし、ハードウェアレベルのキーボードロギングや安全でないグローバルホットキー登録など、セキュリティの脆弱性の多くに対処するまで、ロガーはキーストロークを記録する機会を持ちます。通常のキーストロークはハードウェアからアプリに単純に移動するように見えますが、実際にはいくつかの介入ステップが必要であり、これらのステップは基本的な互換性(ドライバー)と機能(グローバルホットキー)に必要です。
これがデフォルトで行われない理由は、前世代のオペレーティングシステムの設計ではサンドボックス化などにあまり重点が置かれていなかったためです。そのため、このような変更を機能させるには、大きなアーキテクチャの変更が必要になります。 Markは彼の回答でそれらにある程度触れていますが、結局のところ、アプリケーションをOS特権で盲目的に実行することを許可することはできません。
ただし、たとえばGoogleのAndroid、AppleのiOS、さらにはGoogle(デスクトップ)のChromeOSなどの最新のOSはすべて、キーストロークを現在のアプリケーションのみに制限していることに注意するのは、はるかに興味深いことです。1。 ChromeOSだけに注目してください。リストで唯一のデスクトップOSであるため、グローバルショートカットはそのような場合に問題を引き起こさないことに注意することも重要です。アプリケーションは、特定のショートカットにバインドしたいことをOSに「簡単に」通知できます。特定のショートカットは、ユーザーがOSで設定できます。関連する仕様は次のとおりです ここ これがどのように見えるのか知りたい人のために。
同様に、Androidを見てみると、グローバルキーボードアクセスを必要とするユーザー補助ソフトウェアは、そのような情報を公開することで(= /// =)、アプリケーションのみアクセシビリティ設定パネルでそのような権限が明示的に付与されます。これにより、そのようなソフトウェアのセットアップは少し面倒になりますが、キーロガーが配布されるのを防ぎます。
結論として、それが行われない唯一の理由はnotですが、それは役に立たないか不可能ですが、歴史的な優先事項のために少しだけ取っているためですそこに着くのに時間がかかります。そのうちに到達しますが、その間、安全な環境でより最新のロックダウンされたOSを使用することは理にかなっています。
1 Mac OS Xが最近、アプリケーションのサンドボックス化の取り組みを拡大していることを知っています。適切にサンドボックス化されたアプリケーション(管理者権限を必要としないアプリケーション)もキーロガーとして機能できないと思いますが、サンドボックス化が実際にどのように機能するかを読むのにほとんど時間をかけていません。誰かが確実に知っている場合は、共有してください!
Windowsでは、同じユーザーとして実行されているアプリケーション間の保護はほとんどありません。 SetWindowsHookEx
を取り除こうとすると、マルウェア作成者はDLLインジェクションとその他のテクニックのセット全体に切り替わります。透明なウィンドウを描画することさえできますoverフォーカスがあり、キーストロークを受け取るターゲットアプリケーションで、Windowsメッセージを送信してそれらのキーストロークを渡します。基本的に、Windowsは悪意のある実行可能ファイルの可能性を考慮して設計されていません。
信頼できないアプリケーションを実行するために設計されたシステムは、それらを互いにサンドボックス化できます。しかし、サンドボックスからカーネルにパンチアウトする(非常にまれな)エクスプロイトに対しては依然として脆弱です。
使用できる別の手法もあります。ブラウザーで任意のコードを実行すると、サンドボックスをエスケープできない場合でも、ブラウザーが見るすべてのキーストロークを記録する機能が悪用されます。
現在実行中のフォアグラウンドプロセス以外のアプリケーションからキーストロークを見えるようにしたい非常に有効な理由があります。たとえば、すべてのプログラマーが切り取り/コピー/貼り付けを実装しない限り、OSは特定のキーストロークを監視する必要があります。スクリーンショットを撮るためのプログラムがあり、それを特定のキーストロークによってアクティブにしたいとします。そのプログラムは、キーボードアクティビティを監視して、キーストロークがアクティブになったことを検出できる必要があります。すべてをサンドボックスで実行する方が理にかなっており、入力の監視がバックグラウンドプログラムの要件である場合は、許可する必要がある権限ですが、何が行われても、常に回避策があります。誰かがあなたのタイピングを知りたければ、彼らは道を見つけるでしょう。私たちにできることは、それをより難しくすることです。難読化は興味深い方法です。実行中のプログラムが生成するOSに誤った入力メッセージを大量に注入して、外部に何かをだますのですか?
他の正当なアプリケーションが元のキーボード入力(キーキャップXが押された/離された形で来ます)をある種のテキストに変換する必要があるかもしれないことをいくつか観察しました。たとえば、片手が使えなくなった人。
OSがその言語のキーボードマップを提供していない言語を入力できるキーボードマッピングツールもあります(または、ユーザーがOS定義のキーボードマップを使用したくない場合、たとえば、Dvorak-英語以外の言語のレイアウトのように)。そのようなアプリの1つがKeyman(keyman.com)です。
最後に、私のような(またはおそらく私が1人だけかもしれない)人々が、-Hを左カーソル矢印に、-Bを-などにマッピングするキーボードマッパーを持っています。したがって、怠惰な人々(または私だけ)は、キーボードのアルファベットの部分から手を動かす必要はありません。
理由の1つは、一部のソフトウェアでは、アクティブで現在選択されていないときにキーストロークを読み取ることができることが、ソフトウェアの動作に不可欠であることです。
実際には、これを許可するいくつかのオペレーティングシステム、つまりMac OS Xがあります。「予約済み」のシステムキーの組み合わせまたは「修飾子」キー(alt、ctrl、shiftなど)ではないキープレスは、現在フォーカスされているアプリケーションにのみ送信されます。
もちろん、プッシュツートークキーを必要とするVoIPを使用するアクセシビリティやプログラム向けに設計された一部のアプリケーションにとっては、これは非常に煩わしいことになります。このため、特定のアプリケーションに対してこの機能を有効にできるシステム設定の一部があります。
Windowsに関しては、キープレスを処理する現在の方法は非常に複雑であり、現在のすべてのドライバーとプログラムで動作するように設計されているので、実行されないと思います。
X Windowシステムはすでにある程度これを行っています。これにより、プログラムはマウスとキーボードをつかむことができ、他に入力を傍受することはできません。ウィンドウマネージャーすらありません。ゲームから切り替える方法がないため、フルスクリーンのゲームにはかなり迷惑です。 xtermを開いてctrlキーを押したまま右クリックし(私はそう思います)、キーボードを選択します。これで、xtermに入力した内容は、Xサーバーに接続している他のクライアントからは見えなくなります。編集:Xにはまだこれをバイパスしてキーロガーが使用できるXQueryKeymap関数があるようです。
編集:Windowsは、高速ユーザー切り替えがオフになっている限り、ctrl + alt + delを押すと常に有効なWindowsアカウント管理画面が表示されるように、このような機能を実装しています。したがって、偽のパスワード入力画面は使用できません。
いくつかの実用的な例を挙げましょう。
一部の障害者はタイピングが難しいと感じ、タイピングが非常に遅い。彼らはしばしば「 Word予測 」ソフトウェアを使用して、これまでに入力した単語と一致する単語のリストを表示し、リストから単語を1回のキーストロークで選択できるようにします。
視覚障害者は、画面に表示されたテキストを読み取るソフトウェア(スクリーンリーダー)を使用します。このソフトウェアは、キーボードで押すたびに各文字を読み上げることもできます。ソフトウェアには、現在の行などを読み取るホットキーがいくつかあります。
英国では、郵便番号を入力し、ホットキーを押して郵便番号をほぼ完全な住所に展開することで、住所を文字に入力できるソフトウェアがあります。このソフトウェアは、「クイック」アドレス入力自体をサポートしていない顧客データベースなどでよく使用されます。
テスト担当者は、ソフトウェアのテスト中に行ったすべてのキーストロークとマウスの動きを記録して、テストを繰り返すために再生できるようにしたいと考えています。
上記のすべての場合において、ソフトウェアは、他のプログラムに送信されているキーストロークを確認できるかどうかに依存します。
スマートフォンとタブレットは、ほとんどの人が複数のアプリケーションの使用を必要とする仕事をしたいときに依然として「PC」またはMacに頼る範囲で、アプリケーションが互いに対話する方法を制限します。
安全性と生産性の自由は必ずしも両立するわけではありません。トレードオフがあります。 iPhoneはスペクトルの一方の端にあり、Windows/Maxはもう一方の端にあります。