Phenixサーバ クラックまとめ クラック前後に起きたこと -12011.3.30 eximの脆弱性を狙って、パスワードが流出する ・eximのバージョンを上げて対処 ・sshdやsftpの書換が行われていた（2012.1に確認） 2011.4.?? ssh, scpが動作しない報告 ・ssh, scpをインストールし直し、解決 2011.11.17 phenixマシンがパスワード認証へ移行 2011.12.17 パスワード認証の報告 ・パスワード認証から鍵認証へ戻す 2011.12.27 パスワード認証へ再び戻っていた ・鍵認証へ戻す クラック前後に起きたこと -22012.1.3 sshの書換が行われる(2012.1.12に確認) ・ログ（/var/log/secure）が消されていた 2012.1.5 sshの不具合 ・OpenSSLの再インストールで解決 2012.1.12 メールサーバでMewの不具合の報告 ・「incm」という実行ファイルが見つからないのが原因 - パスの不具合が生じている クラック時に、パスを変えられた可能性大 クラック前後に起きたこと -32012.1.12 メールサーバでsshの不具合 ・phenixサーバとエラーの状況は一緒 - メールサーバのログ（/var/log/secure）を確認し、 クラック発覚 2012.1.25 phenixのMLが動作していない ・eximのバージョンが4.6に戻されていた - 最新バージョンのeximをインストールした 考えられる進入ルート -11. パスワード認証期間中にログイン ・sshやscpは問題ないが、sshdなどはすでに置き換わっ ていたと考えられるため、rootのパスワードも入手し ていたと思われる。 2. パスワードを平文で書いたファイルや秘密鍵のコピー ・root権限を持った状態で、秘密鍵などをコピーした ・phenixサーバでは秘密鍵やパスワードを平文で書いた ファイルをそのまま置いている人もいるらしい（ただ し話で聞いただけで、調査はしていない） 3. 秘密鍵を持った状態で、鍵認証中にログイン 考えられる進入ルート -24. 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攻撃時の対応・調査が不十分で、書き換えられ たsshd等により、パスワードなどを常に抜き取られ ていた可能性がある 秘密鍵を公開鍵と一緒に置いている人もいたため、 秘密鍵を入手された可能性がある exim攻撃に使われたプログラム ・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
© Copyright 2024 ExpyDoc
