Phenixサーバ クラックまとめ

クラック前後に起きたこと -1- 2011.3.30 eximの脆弱性を狙って、パスワードが流出する ・eximのバージョンを上げて対処 　・sshdやsftpの書換が行われていた（2012.1に確認） 2011.4.?? ssh, scpが動作しない報告 　・ssh, scpをインストールし直し、解決 2011.11.17 phenixマシンがパスワード認証へ移行 2011.12.17 パスワード認証の報告 　・パスワード認証から鍵認証へ戻す 2011.12.27 パスワード認証へ再び戻っていた 　・鍵認証へ戻す

クラック前後に起きたこと -2- 2012.1.3 sshの書換が行われる(2012.1.12に確認) 　・ログ（/var/log/secure）が消されていた 2012.1.5 sshの不具合 　・OpenSSLの再インストールで解決 2012.1.12 メールサーバでMewの不具合の報告 　・「incm」という実行ファイルが見つからないのが原因 　　- パスの不具合が生じている 　 クラック時に、パスを変えられた可能性大

クラック前後に起きたこと -3- 2012.1.12 メールサーバでsshの不具合 ・phenixサーバとエラーの状況は一緒 　　- メールサーバのログ（/var/log/secure）を確認し、 クラック発覚 2012.1.25 phenixのMLが動作していない 　・eximのバージョンが4.6に戻されていた 　　- 最新バージョンのeximをインストールした

考えられる進入ルート -1- 1. パスワード認証期間中にログイン ・sshやscpは問題ないが、sshdなどはすでに置き換わっ 　　ていたと考えられるため、rootのパスワードも入手し 　　ていたと思われる。 2. パスワードを平文で書いたファイルや秘密鍵のコピー 　・root権限を持った状態で、秘密鍵などをコピーした 　・phenixサーバでは秘密鍵やパスワードを平文で書いた 　　ファイルをそのまま置いている人もいるらしい（ただ 　　し話で聞いただけで、調査はしていない） 3. 秘密鍵を持った状態で、鍵認証中にログイン

考えられる進入ルート -2- 4. rootになる ・rootのパスワードはすでに分かっている 5. ssh, scpの書換 　・この2つのプログラムは、前に変更したものなので、 　　使用頻度の高いsshとscpを改めて書き換えた可能性 　　が高い 6. パスワードを入手し、書き換えたsshで進入 ※　コネクションを保ったままにした場合、秘密鍵がなく 　　ても1の状態からログインし続けることが可能 　　phenixサーバの再起動は行っていない

書き換えられたファイル -1- ・ssh、scp、sftp等のバイナリファイルが書き換えられた 　　- グループ名がmailとなっていた（通常はroot） 　　- シンボリックリンクを貼ってクラックするための ファイルを実行させようとしていた 例 : /usr/local/bin/sshd -> /usr/local/bin/sshd2 　　　疑問点 : なぜ直接sshdを書き換えなかったのか？ 　　- 書き換えられた日は、2011.3.30でeximへの攻撃と 一致するためeximに関しても再調査

書き換えられたファイル -2- ・書き換えられたsshdのバイナリを調査 - /etc/issue.tabにパスワードが平文で書かれたファ 　　 イルが作成されていた（現在は削除） 　　- sshdのバイナリ内に、それらしき文字列が存在した ・このファイルは調べてみると、誰でも簡単に入手できる

書き換えられたファイル -3- ・eximのバージョンが脆弱性のあるバージョンに書き換え 　られていた 　　- 情報不足のため、ルートは不明

eximへ攻撃された時のメール ・eximへ攻撃された時のメールの内容（一部） - sshdに書かれていた文字列と一緒 　　 ていた可能性がある 秘密鍵を公開鍵と一緒に置いている人もいたため、 秘密鍵を入手された可能性がある

exim攻撃に使われたプログラム ・eximへの攻撃に使われたと思われるプログラムをWeb上 から入手できた。 　から入手できた。 　-> 「/」ディレクトリに、ファイル「tmp.l」が存在し、 　　　内容が「ifconfig | grep inet」のものだった。 　　　スクリプトを間違えて、「/tmp/.l」とするところ 　　　を「/tmp.l」としてしまい、残ったのではないか。 ・eximへの攻撃に使われたと思われるプログラムをWeb上 　から入手できた。 　-> 「/」ディレクトリに、ファイル「tmp.l」が存在し、 　　　内容が「ifconfig | grep inet」のものだった。 　　　スクリプトを間違えて、「/tmp/.l」とするところ 　　　を「/tmp.l」としてしまい、残ったのではないか。

phenixサーバでの対応 -1- ・不要なポートを閉じる 　　- 22(ssh), 25(smtp), 80(http), 443(https), 2049(nfs) 以外全てのポートを閉じた。 　　- 新たに閉じたポートは、111, 740, 754, 808, 8443 ・IP制限 　　- 今後もIP制限を行うかは要検討 　　- IP制限を行う利点は、今回のようにパスワードの認証 に戻されたときに、保険となり、調査もしやすくなる ・鍵認証 　　- ユーザ名は判明しているため、今後も継続必須

phenixサーバでの対応 -2- ・パスワードの管理体制 - 以前のrootのパスワードを知る人が多すぎる 可能であれば、管理者のみパスワードを知っているこ 　　　とが望ましい 　　- 秘密鍵、パスワードの取り扱いがよくない 　　　秘密鍵やパスワードをサーバ上に置かない 　　　置いたとしても、早めに削除する

参考 ・eximの脆弱性に関して http://scan.netsecurity.ne.jp/article/2011/01/19/26187.html