意味のないマルウェアで私の.ssh/id_rsaを書き換えたのはなぜですか?

意味のないマルウェアで私の.ssh/id_rsaを書き換えたのはなぜですか?

これは、攻撃のシグネチャをよりよく識別できるように、ある種のハッキングから来た場合に備えて共有したかったやや奇妙な話です。

私はWeb開発者であり、Ubuntu 20.04を実行しており、私のコンピュータのdockerで奇妙なタスクを実行しています。 VSCには、品質が疑わしい開発拡張がたくさんあります。私はどこでもansible Python venvsなどを使用します。 SSHエージェントを使用しており、私のSSHキーはパスワードで保護されており、自動ログイン後はSSHキーを復号化しません。

昨日はいつものように働き、夜はコンピュータを切った。今日は、このメッセージを使用してSSH経由でリモートコンピュータに接続することはできません。

sign_and_send_pubkey: signing failed for RSA "/home/xxxxx/.ssh/id_rsa" from agent: agent refused operation
[email protected]: Permission denied (publickey).

少し操作の最後に秘密鍵を確認しましたが、驚くべきことに秘密鍵が破壊されました。

$ cat ~/.ssh/id_rsa
-e 

-eファイルの内容でしたが、最も幸せな瞬間ではありませんでしたが、コールドバックアップがあり、しばらくしてから再び作業を行いました。

しかし、私は眠ることができず、どのようにこれが起こったのかわかりませんでした。最近、新しいキーを作成したこともなく、.ssh/ファイルを手動で操作したこともありません。

id_rsa私が作業している間、タイムスタンプは昨日正午でタイムknown_hostsスタンプも同じで、他のファイルにも.ssh/正当な記録タイムスタンプがあります。その頃、私は古いマシンにSSHを接続していたので、known_hostsファイルに触れる理由はまったくありませんでした。

id_rsaこのような言葉にならないことを無視するような状況を考えることができる人はいますか-e?私が使用しているいくつかのツールに悪意のあるコードがあるという事実に妄想がありました。それとも確かに私の部分に人間の間違いがありますが、一般的には境界です。あなたの考えに感謝します。


編集する:

  1. 私の設定が最適では bash_historyないため、私の設定は不完全ですbashtmuxhttps://askubuntu.com/questions/80371/bash-history-handling-with-multiple-terminals/80882。したがって、残念ながら、特定のコマンドを追跡することは不可能です。

  2. に基づいて回答VSCodeは、-例えば~/.config/Code/User/History/-707c1648。処理中のファイル。これは、gitコマンドとVSCodeで一時的に生成されたファイルとの間に競合がある可能性があるという仮説をもたらしました。これを追跡するには特別な注意が必要です。

ベストアンサー1

いいえ、これは攻撃ではありません。どこかで問題が発生しました。

秘密鍵ファイルを無効なコンテンツに置き換えることは、攻撃者にとって理想的なターゲットではありません。攻撃者が望むかもしれない読むしかし、認証に使用される秘密鍵を変更することは意味がなく、誤ったテキストに置き換えて破棄することは言うまでもありません。これは攻撃者に何の利点も与えず、簡単に検出できます。攻撃者は上書きしようとするかもしれませんが、known_hosts自分の公開鍵だけを追加できます。自分の公開鍵を破棄しても、攻撃者には何の利点もありません。これが攻撃であれば、非常に奇妙な方法で失敗し、攻撃者はクリーンアップしようとしませんでした。もちろんこれが物理法則を破るわけではないが、全く信じられないことだ。

コンテンツとして、オプションとして意図されたがコンテンツとして解釈された-e一部のシェルコマンドのバグである可能性が高いです。-e他のファイルが同時に変更される場合、考えられる原因は、一部のファイル内容置換コマンドです。たとえば、find … | xargs perl -i -p -e …誤った引用符、コピー&ペーストエラー、誤った空白、または予期しない文字が原因でコマンドが実行されるファイルの数ファイル名などが予想以上でした。

ダッシュで始まるファイル名があることを確認してください(公開されてlocate /-いる場合は見つかり、そうでない場合は見つかりますfind ~ -name '-*')。あるいは、スペースの後にダッシュ(locate ' -'または)が続くfind -name '* -*'ファイル名である可能性があります。これは--、スペースを使用せずにファイル名を渡すコマンド、変数拡張の周りに引用符を使用しない、またはを使用せずにコマンドがファイル名をxargs渡すことによって発生する不思議な影響の原因である可能性があります-0。犯人を見つけて、それがあなたが書いたシェルコマンドにあることがわかったら、次を参照してください。スペースやその他の特殊文字が原因でシェルスクリプトが停止するのはなぜですか?そしてbash / POSIXシェルで変数を引用することを忘れてしまうセキュリティリスク。他の人が作成したシェルコマンドにあることがわかったら、バグを報告してそのリソースを教えてください。あなたの場合、これは偶然ですが、ファイル名を制御できる攻撃者はバグを使用して便利なタスクを実行する可能性があります。

おすすめ記事