私が一つ見つけた興味深い記事ps
、、top
...などのプロセス監視ツールでlsof
Linux上の特定のプロセスを非表示にする方法について説明します。
Personは、プロセスを隠す方法にはいくつかの方法があると指摘しています。
- 適切なフレームワークの使用
SELinux
:Grsecurity
となど、まさにこれを行う本当に良いフレームワークがたくさんあります。生産システムでは、私は確かにこれを検討します。しかし、今日は手を汚して最初から何かを作ることを楽しみたいと思いました。top/ps/...
バイナリファイルの変更:各ツールのソースコードを取得して直接実装できます。「Linuxプロセスを隠す」 バイナリを論理、再コンパイル、および置き換えます。非常に非効率的で時間がかかります。- 調整
libc
readdir()
:内部の機能を変更し、特定のファイルへのアクセスをブロックするlibc
コードを入力できます。/proc
しかし、再コンパイルがlibc
負担になり、libc
コードが理解しにくいことが多いです。- カーネルでシステムコールを変更する:これは最も先進的なものであり、カスタム
getdents()
モジュールを使用してカーネルから直接システムコールを傍受して修正する方法で機能します。確かに誘惑的ですが、私はすでにPythonでシステムコールのブロックがどのように機能するかに慣れているので、今日はこのパスに従わないでしょう。sysdig
それで新しいことをしたかったです。私は面白くてシンプルで、1時間以内に実装できる中間ソリューションを選択することにしました。 「libcの修正」が提供するトリッキーな機能に基づいてLinuxダイナミックリンカー(実行時にプログラムに必要なさまざまなライブラリをロードする役割を担うコンポーネント)、事前ロード。
そして事前ロードLinuxは、他の一般的なシステムライブラリをロードする前にカスタム共有ライブラリをロードするオプションを提供するのに十分親切です。つまり、カスタムライブラリがシステムライブラリの関数と同じシグネチャを持つ関数をエクスポートすると、実際にライブラリのカスタムコードでそれをオーバーライドでき、すべてのプロセスが自動的にカスタム関数を選択します。
readdir()
libcをオーバーライドする非常に単純なカスタムライブラリを作成し、プロセスを隠すロジックを書くことができるので、これは私の問題に対する解決策のように聞こえます!ロジックも非常に簡単です。ディレクトリを見るたびに/proc/PID
(ここでPID~であるプロセスPID名前を読んでいます"evil_script"
)、そのアクセスをきちんとブロックしてディレクトリ全体を非表示にします!私はこれらのアイデアを続けてコードで実装しました。以下からソースを入手できます。 https://github.com/gianlucaborello/libprocesshider/blob/master/processhider.c (実際にコメントまで含めるとコードが100行もないので必ず読んでください!) コードが作成されたら、それを共有ライブラリにコンパイルし、システムパスにインストールします。
ソースコード:プロセス hider.c
したがって、ステップは次のようになります。
make
=>gcc -Wall -fPIC -shared -o libprocesshider.so processhider.c -ldl
mv libprocesshider.so /usr/local/lib/
(ように根)echo /usr/local/lib/libprocesshider.so >> /etc/ld.so.preload
今私の質問/質問に戻ります。:ここで説明する内容は次のとおりです。Linuxシステム。 Ubuntu 18.04(64ビット)コンピュータでテストしましたが、すべてがうまく機能しました。今プロセスがps
。
まず、コードの次の部分を削除する必要がありました。
DECLARE_READDIR(dirent64, readdir64);
エラーが発生したため(定義dirent64
されていませんディレンテ.h-locate dirent.h
コードを使っていくつかのインターネットリソースと比較しました。)
processhider.c: In function 'readdir64':
processhider.c:87:37: error: dereferencing pointer to incomplete type 'struct dirent64'
get_process_name(dir->d_name, process_name) && \
^
processhider.c:97:1: note: in expansion of macro 'DECLARE_READDIR'
DECLARE_READDIR(dirent64, readdir64);
^
*** Error code 1
削除後、フラグDECLARE_READDIR(dirent64, readdir64);
について不平を言う別のエラーが発生します。-ldl
/usr/local/bin/gcc5 -Wall -fPIC -shared -o libprocesshider.so processhider.c -ldl
/usr/local/bin/ld: cannot find -ldl
collect2: error: ld returned 1 exit status
*** Error code 1
Stop.
私が一つ見つけた解決策私のファイルの場所に置き換えることができる-ldl
場所(意味-L/usr/local/lib
libdl.so
Collect2:エラー:ldが1つの終了ステータスを返しました。「間違い)。
その後、コードをコンパイルできます。ライブラリ/usr/local/lib/
を置きます/etc/ld.so.preload
。
ただし、スクリプトを呼び出すとevil_script.py
(コードは異なりますが(もはやUDPパケットスパムはありません)while true
ループがあるため、time.sleep(60)
プロセスはそこにある必要があります)、プロセスリスト(ps auxww
)に表示され続けます。たぶん/etc/ld.so.preload
働いていませんか?ld.so
共有ライブラリに問題がある可能性がありますか?この時点で発生する問題をテストする方法はありますか?
答え1
方法2と3(ps、top、libraryの修正)は脆弱性を迂回する傾向があります。たとえば、攻撃者は自分のps
。
より良いアプローチは、これらのツールが他のユーザープロセスに関する情報にアクセスするのを防ぐことです。次に、非表示にするプロセスを別のユーザーとして実行します。
最初の部分では編集して埋め込み/etc/fstab
ます。
#protect /proc
proc /proc proc defaults,nosuid,nodev,noexec,relatime,hidepid=2,gid=admin 0 0