Phenixサーバ クラックまとめ.

Presentation on theme: "Phenixサーバ クラックまとめ."— Presentation transcript:

1 Phenixサーバ クラックまとめ

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

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

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

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

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

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

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

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

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

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

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

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

14 参考 ・eximの脆弱性に関して