web-dev-qa-db-ja.com

クリップボードを介して実行中のシステムからSudoパスワードを抽出する可能な方法

私は、KeePassファイルからSudoパスワードをコピーして貼り付けるのに使用しているので、たとえば、更新を受け入れるためにそれを使用するときに、プレーンテキストのユーザーパスワードがRAMに保存されると思います。そうですか?

攻撃者がRAMを別のマシンに接続することにより(たとえば、コールドブート攻撃)、このパスワード文字列またはその一部を抽出することは理論的に可能ですか?次に、攻撃者はRAMをまだ実行中の最初のマシンに再接続し、たとえばユーザーパスワードを入力して画面のロックを解除することができますか?

必要なときに毎回キーボードでSudoパスワードを入力すると、違いがありますか?単純なキーストロークはRAMに保存されていないと思いますよね?

これを防ぐ別のオプションは、カスタムスクリーンロッカーのパスワードだと思います。

5

はい。実際、これはキーロガーの一般的な機能です。多くの場合、X秒ごとにスクリーンキャプチャを取り、クリップボードを監視し、キーストロークを記録します。これらの機能は、コピー/貼り付けではなく、タイピングの戦略をかなり無効にします。

しかし、あなたはkeepassを使っていると言っています。だからあなたは保護されるかもしれません。よくある質問の this 情報をご覧ください

クリップボードを頻繁に使用しているため、現在のすべてのクリップボードモニターをブロックすると便利です。つまり、KeePassがクリップボードを変更しても、他のアプリケーションには通知されません。

このために、非表示のウィンドウが作成され、クリップボードイベントハンドラチェーンの最上部に追加されます。このウィンドウは、受信するすべてのクリップボード変更メッセージを破棄するだけで、他のすべてのアプリケーションがイベントを受信するのを事実上ブロックします。

キーロガーを倒すための別の機能についても詳しく説明します。

KeePassのオートタイプ機能は非常に強力です。シミュレートされたキープレスを他のアプリケーションに送信します。これはすべてのWindowsアプリケーションで機能し、ターゲットアプリケーションでは、実際のキープレスとオートタイプによってシミュレートされたキープレスを区別することはできません。キーロガーがシミュレートされたキーを盗聴できるため、これは同時にオートタイプの主な欠点です。そこで登場するのが、2チャネル自動タイプ難読化(TCATO)です。

TCATOは、標準のキーロガーを役に立たなくします。 Windowsクリップボードを使用して、自動入力されたテキストの一部をターゲットアプリケーションに転送します。キーロガーはCtrl-Vの押下を確認できますが、クリップボードから貼り付けられた実際の内容はログに記録しません。

結論として、新しい攻撃が発生すると新しい防御も発生します(逆も同様です)。

6
KDEx

CentOSで Lime を使用してテストします。まず、KeePassXは単純な検索可能なパスワードを生成するように設定されており、検索によりパスワードがメモリに配置されるため、毎回再生成されます。

これらすべては安全でした(明記せず、特に指示がない限り、Limeダンプを開始する前に手順を実行しました)。

  • KeePassX内でパスワードを生成し、保存を終了しないでください。
  • パスワードを再生成し、パスワードを保存して、メインウィンドウを開いたままにします。
  • メモリキャプチャを開始し、パスワードを再生成し、パスワードタイムアウトの期限が切れる前にキャプチャが終了します(タイミングによって異なりますが、可能性は低いです)。
  • パスワードを再生成し、KeePassXのコピー機能を使用してクリップボードにコピーします。パスワードのタイムアウトは期限切れになりません。
  • パスワードを再生成し、KeePassXのコピーを使用してクリップボードにコピーし、ダンプを開始します。パスワードは10秒で期限切れになります(ダンプは30秒で終了します)
  • パスワードを再生成し、Ctrl-Cを使用して手動でクリップボードにコピーし、タイムアウトが経過した後にダンプを開始します。
  • パスワードの再生成、手動でのクリップボードへのコピー(Ctrl-C)、タイムアウトの期限が切れていません.
  • パスワードを再生成して保存し、ダンプ中に[パスワードの表示]をアクティブのままにします。
  • KeePassXからGNoteに再生成、コピー、貼り付け。
  • KeePassXからFirefox + Gmailのパスワード入力フィールドに再生成、コピーして貼り付けます。
  • 再生成、パスワードの表示、Firefox + Gmailパスワード入力フィールドへの手動入力。

フルークの検出が1回ありました。おそらくエラーです。実際の検出は、ダンプが完了するのを待つ間に手動で検索コマンドをキューに入れようとしたことです。これにより、パスワードがメモリに注入されました。

あなたの質問に:

コピーされたメモリ+暗号化キーでVolatilityを使用する時間は十分にありますが、物理的なアクセスはしばしば困難です。ほとんどの人は(私の意見では)ハードウェアについてあまり心配する必要はありません。はい、低レベルのI/O、BIOSアップグレード、BadUSB、Thunderstrike、超音波通信、さらにはハードドライブファームウェアの変更さえあります。すべてがニュースになりますが、ほとんどの場合、対象範囲は狭くなります。

KeePassXよりもクリップボードマネージャーやセキュリティの低いプログラムの方が問題であり、シェルの相互作用は実際には喫煙銃のように見えます(特に、タブ補完、検索、コマンドキューイング)。

クリアテキストのSudoパスワードは、昇格してもメモリに保持されますが、何度も実行します。低使用をエミュレートするために、新しいアカウントからのテストをrootから始めます(Sudoの機会を減らします)。上記のようにパスワードを保護するためにKeePassXを信頼して、メモリダンプ間を検索しませんでした。

Terminal 1:
========================
# adduser keepasstest
# su keepasstest            ' user is working
$ exit
# passwd keepasstest
Changing password for user keepasstest.
New password:               ' paste from KeePassX
Retype new password:        ' paste from KeePassX
passwd: all authentication tokens updated successfully.

# exit                      ' dump memory #1

Terminal 2:
=====================
$ Sudo -s                        ' my account
# su keepasstest                  ' substitute user
$ Sudo -s                        ' elevate
[Sudo] password for keepasstest:  ' Paste from KeePassX
#                                ' dump memory #2

結果:

$ Sudo grep Ifnavcogi... Lime*.txt

Lime1.txt:Ifnavcogi...
Lime1.txt:Ifnavcogi...     ' 3 entries after passwd
Lime1.txt:Ifnavcogi...

Lime2.txt:Ifnavcogi...
Lime2.txt:Ifnavcogi...
Lime2.txt:Ifnavcogi...     ' 5 entries after Sudo
Lime2.txt:Ifnavcogi...
Lime2.txt:Ifnavcogi...

15分後、Sudoのキャッシュタイムアウトの期限が切れた後でも、少なくとも1つのパスワードがダンプに残っています。残りはブラウザのメモリからのものです。

別の懸念事項ですが、KeePassXは lock ページをディスクにスワップしないようにします(ps -axuはフラグに "L"を表示します) hibernate システムであり、適切なフルディスク暗号化を使用しないでください。

Sudoを使用すると、パスワードがKeePassXの外のいくつかの場所にあるようです(アクセス方法は関係ありません)。ただし、ライブメモリダンプには、システムにマルウェアを配置したり、ハードウェアを交換したり、メモリをコピーするために必要な物理的なアクセス権を取得したりするために必要なレベルなど、高度な権限が必要です。平文のパスワードは好きではありませんが、リスクは依然として平均的です。

2
ǝɲǝɲbρɯͽ