Descobre usuário sudoer com privilégios de root que executaram o comando X?

Question

Eu sou o administrador principal de um sistema. No sistema existem 3 usuários sudoers com privilégios de root.

O sistema executa um script em segundo plano que verifica o hash dos utilitários do sistema para detectar possíveis alterações maliciosas. Hoje fui alertado de que o hash do utilitário ssh mudou.

Não houve atualizações até agora, e acho que um dos sudoers é responsável por isso. É possível detectar qual sudoer alterou o utilitário ssh ?

    

Answer 1

Vou escrever uma resposta com o RHEL em mente, mas saiba que se você estiver em uma distribuição baseada no SuSE ou no Debian, haverá análogos para o que eu descrevo.

Primeiramente, se você quiser apenas verificar se era uma atualização do sistema e não alguém tentando rootkit da máquina, é possível "verificar" o pacote openssh-clients assim:

[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]#

Eu também fiz openssh-server para que você possa ver o que parece quando algo mudou. A parte importante é o "5", que nos diz que o md5sum do arquivo é diferente do que existe no banco de dados RPM. Se esse check-out foi provavelmente devido a uma atualização do sistema.

Se eles usaram o yum (muito provável), haverá uma entrada /var/log/yum.log para esse RPM sendo atualizado. Isso é útil para obter o horário específico em que a atualização ocorreu para revisão posterior com yum history .

Se eles usaram rpm diretamente, você pode fazer alguns queryformat magic ou rpm -q openssh-clients --last para obter a data em que aconteceu (embora pareça que você já conhece essa informação)

Existe um subcomando yum chamado history que registra o auid / loginuid do usuário invocador:

[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]#

O login é inválido porque como os filhos do init são desmembrados eles começam com um loginuid de -1 (negativo). Quando você efetua login via tty ou sshd pam_loginuid (há outros módulos que também fazem isso) o configura para o UID do usuário autenticado. Uma vez definido como algo diferente de -1 root mesmo não pode alterar este valor (somente nos kernels mais novos, no entanto), já que ele é não-funcional / apenas contábil e precisa levar em consideração que um invasor pode ter ganhado raiz. Todos os filhos herdam o loginuid do pai, assim, mesmo que sudo crie um programa com o EUID igual a zero (ou qualquer usuário), você ainda terá o mesmo loginuid.

Você pode testar isso apenas fazendo sua parte do sudo e fazendo um cat /proc/self/loginuid cada vez que o usuário com o qual você fez login inicialmente não importa quantas su ou sudo invocações feitas desde então. É assim que o yum history lá em cima sabe que jadavis6 fez o yum update , mesmo que eu tenha feito todos eles como o usuário root.

Se houver alguma ambiguidade entre duas transações do yum, você pode fazer um yum history info <transID> , como se eu quisesse saber mais sobre a última transação:

[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

Eu trunci-lo porque parece que esta foi uma atualização do sistema bastante longa.

AFAIK, não há como rastreá-lo se eles forem atualizados via rpm diretamente da configuração de auditd para monitorar as alterações nos arquivos de banco de dados do RPM. Fazer isso permitiria que você fizesse um ausearch e permitiria ver uma lista de PIDs que fizeram alterações e o loginuid associado (que será exibido como auid ).

Se eles o alterassem diretamente fora do RPM, você teria que estar observando cada um dos arquivos que você queria monitorar para alterações antes da alteração ser feita. Após o fato, você não pode fazer muito, mas você pode considerar fazer algo com auditd para monitorar os arquivos que considera alvos de rootkit. Fazer demais pode prejudicar o sistema. Também vale a pena mencionar que você deve enviar esses logs para fora do servidor em algum lugar para evitar adulterações maliciosas.

Espero que ajude.

EDITAR:

Uma coisa a notar, parece que o root pode alterar o loginuid se ele tiver CAP_SYS_AUDITCONTROL (não necessário se o loginuid for atualmente -1 ), mas você deve conseguir remover esse recurso do conjunto delimitador do sistema, o que exigiria que o atacante reinicializasse o sistema para obter essa capacidade, o que é uma operação barulhenta que deixa os eventos auditáveis em todo lugar, então é improvável que eles façam isso.

    

Answer 2

Se você der uma olhada no arquivo /var/log/audit/audit.log , será possível alinhar a hora / data em que o arquivo ssh foi alterado quando um dos três usuários com privilégios de sudoers se conectou.

O arquivo audit.log contém linhas como esta:

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)'

Você pode voltar atrás no AUID (Affective User ID - também conhecido como o usuário que executou o comando sudo ).

Então o AUID 500 é esse cara no meu sistema:

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

Agora, o audit.log pode ser usado, mas é muito mais fácil usar a ferramenta ausearch para digitalizá-lo. Por um lado, ele imprimirá o registro de data e hora do registro de auditoria de uma forma mais legível:

$ 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)'

Aqui estou pesquisando o arquivo de log procurando por correspondências que contenham o executável sudo, ( -x /usr/bin/sudo ).

    

Answer 3

Você verificou syslog ? De acordo com man sudo : sudo pode registrar tentativas bem-sucedidas e malsucedidas (assim como erros) no syslog (3), um arquivo de log ou ambos. Por padrão        O sudo irá logar via syslog (3), mas isso pode ser alterado no momento da configuração ou através do arquivo sudoers.

Eu acho que, a menos que eles tenham excluído intencionalmente o arquivo de log, você deve conseguir as informações lá. Para diminuir o intervalo de tempo, você pode verificar o carimbo de data modificado no utilitário SSH.