☰

Xコマンドを実行するroot権限を持つsudoerユーザーを見つけましたか？

tag-icon • tag-icon security sudo logs audit
Xコマンドを実行するroot権限を持つsudoerユーザーを見つけましたか？

私はシステムの基本的なシステム管理者です。システムには、root権限を持つ3人のsudoerユーザーがいます。

システムは、可能性のある悪意のある変更を検出するために、システムユーティリティのハッシュをチェックするスクリプトをバックグラウンドで実行します。今日、私はsshこのユーティリティのハッシュが変更されたという通知を受けました。

これまでのアップデートはなかったし、sudoerの一人がこれに責任があると思います。どのsudoerがsshユーティリティを変更したかどうかを検出できますか？

答え1

私はRHELを使用して答えを書くつもりですが、SuSEまたはDebianベースのディストリビューションを使用している場合は、私が説明したものと似たようなものになります。

まず、それがシステムアップデートであり、誰かがあなたのコンピュータをルートキットしたくないことを確認したい場合は、openssh-clients次のようにパッケージを「確認」できます。

[root@hypervisor scsd]# rpm -V openssh-clients
[root@hypervisor scsd]#
[root@hypervisor scsd]# rpm -V openssh-server
S.5....T.  c /etc/pam.d/sshd
S.5....T.  c /etc/ssh/sshd_config
[root@hypervisor scsd]#

私はopenssh-server状況が変わったときにどのように見えるかを見ることができるようにしました。重要な部分は「5」です。これは、ファイルの md5sum が RPM データベースに存在するものと異なることを示します。チェックアウトすると、システムのアップデートが原因である可能性があります。

yumを使用している場合（おそらく）、更新されるRPMの/var/log/yum.logエントリがあります。これは、後で表示するために更新が行われた特定の時間を取得するのに役立ちますyum history。

自分で使うと、魔法をかけたり、発生した日付を知るrpmことができます（この情報を既に知っているように聞こえますが）。queryformatrpm -q openssh-clients --last

呼び出し元のauid / loginuidを記録するyumサブコマンドがあります。history

[root@hypervisor scsd]# yum history
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    54 |  <jadavis6>              | 2013-07-15 09:03 | Install        |    2
    53 |  <jadavis6>              | 2013-07-09 17:25 | Update         |   23
    52 |  <jadavis6>              | 2013-06-24 10:10 | Install        |    3  <
    51 |  <jadavis6>              | 2013-06-14 22:33 | Install        |    1 >
    50 |  <jadavis6>              | 2013-06-14 07:47 | E, I, U        |   90
    49 | root <root>              | 2013-06-14 00:58 | Update         |    1
    48 |  <jadavis6>              | 2013-06-03 08:28 | Install        |    3
    47 |  <jadavis6>              | 2013-05-28 11:57 | Install        |    3  <
    46 |  <jadavis6>              | 2013-05-20 18:25 | Install        |    1 >
    45 |  <jadavis6>              | 2013-05-20 12:00 | Install        |    1
    44 |  <jadavis6>              | 2013-05-19 15:29 | Install        |    6
    43 |  <jadavis6>              | 2013-05-18 20:16 | Install        |    3
    42 |  <jadavis6>              | 2013-05-16 16:21 | Install        |    2  <
    41 |  <jadavis6>              | 2013-05-16 12:48 | Install        |    1 >
    40 |  <jadavis6>              | 2013-05-10 09:28 | Install        |    1
    39 |  <jadavis6>              | 2013-05-10 09:28 | Install        |    1
    38 |  <jadavis6>              | 2013-04-29 19:45 | Install        |    2  <
    37 |  <jadavis6>              | 2013-04-29 18:51 | Install        |    8 >
    36 |  <jadavis6>              | 2013-04-29 18:35 | Update         |   11
    35 |  <jadavis6>              | 2013-04-27 15:44 | E, I, O, U     |  429 EE
history list
[root@hypervisor scsd]#

initの子プロセスが分離されるとloginuid -1（負の数）で始まるため、loginuidは偽造できません。 ttyまたはpam_loginuidを介してログインするときにsshd認証されたユーザーのUIDに設定します（これを実行する他のモジュールもあります）。-1ルート以外の値に設定すると、この値は変更できません。（ただし、最新のカーネルでのみ）非機能/アカウント機能のみがあり、攻撃者がroot権限を得た可能性があることを考慮する必要があります。すべての子プロセスは親プロセスのloginuidを継承するため、sudoEUIDが0（または任意のユーザー）のプログラムを作成しても、まだ同じloginuidを持つことになります。

sudoジョブを実行してこれをテストできます。cat /proc/self/loginuid元のログインユーザーは、その後の呼び出し回数に関係なく毎回ジョブを実行する必要がありますsu。 rootでこれをすべて行ったにもかかわらず、上記は既知の方法sudoです。yum historyjadavis6yum update

2つのyumトランザクションの間にあいまいさがある場合は、最後のyum history info <transID>トランザクションについてさらに知りたい場合は、次のことを実行できます。

[root@hypervisor scsd]# yum history info 35
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security,
              : subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Transaction ID : 35
Begin time     : Sat Apr 27 15:44:57 2013
Begin rpmdb    : 959:3d300ae2e8dc239f9f972306ba2406bd22ba29bc
End time       :            15:50:39 2013 (5 minutes)
End rpmdb      : 972:381cb76592ea2f779ee4521a4e7221196520486a
User           :  <jadavis6>
Return-Code    : Success
Command Line   : update -y
Transaction performed with:
    Updated       rpm-4.8.0-27.el6.x86_64                       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Updated       subscription-manager-0.99.19.4-1.el6_3.x86_64 @rhel-x86_64-server-6
    Updated       yum-3.2.29-30.el6.noarch                      @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Installed     yum-metadata-parser-1.1.2-16.el6.x86_64       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Packages Altered:
    Updated     NetworkManager-glib-1:0.8.1-34.el6_3.x86_64                    @rhel-x86_64-server-6
    Update                          1:0.8.1-43.el6.x86_64                      @rhel-x86_64-server-6
    Updated     PackageKit-0.5.8-20.el6.x86_64                                 @rhel-x86_64-server-6
    Update                 0.5.8-21.el6.x86_64                                 @rhel-x86_64-server-6
    Updated     PackageKit-device-rebind-0.5.8-20.el6.x86_64                   @rhel-x86_64-server-6

[...snip...]

    Updated     yum-3.2.29-30.el6.noarch                                       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Update          3.2.29-40.el6.noarch                                       @rhel-x86_64-server-6
    Updated     yum-rhn-plugin-0.9.1-40.el6.noarch                             @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Update                     0.9.1-43.el6.noarch                             @rhel-x86_64-server-6
Scriptlet output:
   1 warning: /etc/shadow created as /etc/shadow.rpmnew
   2 No input from event server.
   3 warning: %postun(wdaemon-0.17-2.el6.x86_64) scriptlet failed, exit status 1
history info

システムアップデートが多少長くなりそうだったのでカットしました。

rpmAFAIK構成の外部から直接更新してauditdRPMデータベースファイルの変更を監視している場合は、遡及的にこれを行う方法はありません。これにより、ausearch変更を行ったPIDのリストと関連するログインID（で示されているauid）を表示できます。

RPMの外部から直接変更する場合は、変更する前に監視する各ファイルの変更を監視する必要があります。実際にできることはあまりありませんが、auditdルートキットのターゲットと思われるファイルを監視するためにいくつかのことを行うことを検討することができます。あまりにも多くの操作をすると、システムがクラッシュする可能性があります。悪意のある改ざんを防ぐために、サーバーはこれらのログをどこかに送信する必要があることにも言及する価値があります。

お役に立てば幸いです。

編集する：

1つの注目すべき点は、ルートのように見えることです。できるloginuidがある場合はそれを変更してくださいCAP_SYS_AUDITCONTROL（loginuidが現在の場合は必要ありません-1）。ただし、システム境界セットからその機能を削除できるはずです。これにより、攻撃者はその機能を取得するためにシステムを再起動する必要があります。 hell タスクでは、監査可能なイベントをどこにでも残しておくため、そうする可能性が低くなります。

答え2

ファイルを見ると、ファイルの変更時刻/日付をsudoer権限を持つ3人のユーザーの1人がログインした時刻/日付と一致する必要/var/log/audit/audit.logがあります。ssh

ファイルaudit.logには次の行が含まれています。

type=USER_START msg=audit(1374006520.730:480): user pid=28303 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=CRED_ACQ msg=audit(1374006535.446:488): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=USER_START msg=audit(1374006535.448:489): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'

AUID（Affective User ID -sudoコマンドを実行したユーザーとも呼ばれる）で逆追跡できます。

AUID 500は私のシステムのこの人です。

$ grep 500 /etc/passwd
sam:x:500:500:Sam M.:/home/sam:/bin/bash

これでaudit.loggrepを使用できますが、ausearchこのツールを使用するとスキャンする方がはるかに簡単です。まず、監査ログのタイムスタンプを人が読みやすい形式で印刷します。

$ ausearch -x /usr/bin/sudo
...
time->Thu Jul 18 14:41:48 2013
type=CRED_ACQ msg=audit(1374172908.936:45): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
----
time->Thu Jul 18 14:41:48 2013
type=USER_START msg=audit(1374172908.937:46): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'

-x /usr/bin/sudoここでは、実行可能なsudo（）を含む一致をログファイルから検索しています。

答え3

確認してみましたsyslogか？によると、man sudosudoは成功と失敗の試行（エラーを含む）をsyslog（3）、ログファイル、またはその両方に記録できます。デフォルトでは、sudoはsyslog（3）を介して記録されますが、設定時またはsudoersファイルを介して変更できます。

意図的にログファイルを削除しない限り、そこから情報を取得できる必要があると思います。時間範囲を絞り込むには、SSH ユーティリティで修正日スタンプを確認できます。

関連情報