Porque é que uma conta root comprometida significa reconstruir o servidor, não limpá-lo.
Uma conta UID 0 sem registo de criação não foi criada, foi escrita. Como encontrar uma conta root escondida, e porque é que um root comprometido significa reconstruir, não limpar.
Neste artigo 5 secções
Todas as contas num sistema Unix têm uma certidão de nascimento. Uma linha no log de autenticação que regista quem a criou, quando, e com que ferramenta. Uma conta sem essa linha não foi criada através de ferramenta nenhuma. Foi escrita, à mão, diretamente no ficheiro de utilizadores. Quando essa conta também tem UID 0, a linha em falta não é uma lacuna nos seus registos. É a prova.
- Uma conta root escondida é o backdoor mais difícil de ver, porque em Unix root é um número, não um nome. Qualquer conta cujo UID seja 0 tem root completo. Dê a uma dessas contas um nome que difira num único carácter de um daemon legítimo do sistema, e ela sobrevive a uma passagem casual pela lista de utilizadores. O olho lê-a como uma gralha, não como uma ameaça.
- Duas observações vulgares mandam o responder na direção errada: o nome disfarçado parece um erro ortográfico de um daemon real, e uma verificação de saúde automatizada já reportou sucesso. Um sinal de tudo bem.
- O indício que atravessa as duas: não há nenhuma entrada de criação de conta nos logs. O atacante nunca usou a ferramenta de criação de contas. O hash da palavra-passe foi escrito diretamente no ficheiro de utilizadores, e no ficheiro de utilizadores, não no ficheiro shadow, o que por si só é um segundo indicador.
- A doutrina: procure contas UID 0 independentemente dos logs de criação, trate um hash no ficheiro errado como um achado, nunca trate uma única verificação automatizada como prova, e quando o root esteve acessível durante qualquer janela de tempo, reconstrua a partir de um ponto comprovadamente limpo, anterior ao comprometimento. Não limpe no local.
UID 0 é um número, não um nome
Root não é a conta chamada root. Root é qualquer conta cujo user ID seja 0. O kernel concede o privilégio com base no número, e o nome é decoração. Por isso um backdoor não precisa de tocar na conta root nem de adivinhar uma palavra-passe. Precisa de mais uma linha no ficheiro de utilizadores com um 0 no terceiro campo.
Dê a essa linha um nome que difira num único carácter de um daemon legítimo do sistema, e ela desaparece à vista de todos. Uma lista de utilizadores é longa, os nomes são crípticos por desenho, e um responder que a percorre lê um daemon conhecido, ligeiramente mal escrito, e segue em frente. O disfarce não é sofisticado. Só tem de sobreviver a um relance.
# Root is a UID, not a name. List every account with UID 0.
awk -F: '$3 == 0 { print $1 }' /etc/passwd
# Exactly one line should come back: root. Any second line is a
# full-privilege account, whatever it calls itself.Duas razões para seguir em frente. Ambas erradas.
Um bom responder pode ser conduzido a passar ao lado de uma conta root escondida por duas observações razoáveis. Ambas são do género a que se acena com a cabeça e se segue em frente. Nenhuma sobrevive a um segundo olhar.
| O que parece | O que é |
|---|---|
| O nome da conta lê-se como uma gralha de um daemon legítimo do sistema | Uma conta UID 0 completa, com um nome feito para sobreviver a um relance, a um carácter de distância de um daemon real |
| Uma verificação automatizada reporta sucesso. | Uma verificação automatizada não é prova. |
“Uma única verificação automatizada não é prova. Confirme-a com uma análise independente.”
A conta sem certidão de nascimento
Todas as contas criadas através das ferramentas padrão deixam uma linha no log de autenticação: criada por quem, quando, com que comando. Uma conta plantada não tem nenhuma. Não uma linha apagada, nenhuma linha, porque o atacante nunca usou a ferramenta. O hash da palavra-passe é escrito diretamente no ficheiro de utilizadores à mão, e é por isso que não há nada a registar.
E é escrito no ficheiro errado. Em qualquer sistema Unix moderno, o campo da palavra-passe no ficheiro de utilizadores está delegado no ficheiro shadow. Guarda um marcador de posição, nunca um hash real. Um hash genuíno dentro do ficheiro de utilizadores não é uma opção de configuração nem uma particularidade antiga que se possa ignorar. É a impressão digital de uma edição manual, e é um indicador por si só.
Sem linha no log, a verdadeira hora de criação da conta tem de ser reconstituída a partir de canais laterais: carimbos temporais de ficheiros, e os registos que outros eventos deixaram à volta dela. A ausência de certidão de nascimento não impede de estabelecer a hora do nascimento. Significa apenas que vai dar trabalho.
# The password field in /etc/passwd should be a placeholder (x),
# never a hash. The real hash lives in /etc/shadow.
awk -F: '$2 != "x" && $2 != "*" && $2 != "!" { print $1 }' /etc/passwd
# A name that comes back here has its hash in the wrong file.
# That is a manual edit, not a managed account.“Uma conta UID 0 sem registo de criação não foi criada. Foi escrita.”
Quando uma atualização tranca o atacante do lado de fora por acidente
O mais estranho neste modo de falha é o que uma atualização automática de rotina lhe pode fazer. Uma atualização não assistida pode reescrever um hash plantado como efeito secundário e trancar o atacante fora do seu próprio backdoor. A conta fica. O acesso desaparece. O backdoor pode então ficar adormecido indefinidamente: uma porta destrancada para uma sala cuja chave já não roda. Isso parece segurança. Não é.
Um backdoor que deixou de funcionar não é um backdoor que desapareceu. Uma conta UID 0 adormecida continua a ser uma conta UID 0 que alguém plantou. A presença é o comprometimento, não o login.
Não se limpa. Reconstrói-se.
O desfecho tentador é «apagamos a conta má, aplicamos o patch, pronto». Recuse-o. Acesso root durante qualquer janela de tempo, mesmo uma janela que a sorte fechou depois com estrondo, significa que todos os bytes dessa máquina são agora suspeitos: binários, cron jobs, bibliotecas, e as próprias ferramentas que usaria para a inspecionar. Não se consegue auditar o caminho de volta à confiança num sistema cujas ferramentas de auditoria já não merecem confiança.
Procure root independentemente dos logs.
Liste todas as contas UID 0 com awk. Não confie no log de criação, numa única verificação automatizada, nem no facto de a lista de utilizadores parecer normal.
Trate um hash no ficheiro errado como um achado.
Um hash real no ficheiro de utilizadores em vez do ficheiro shadow é uma edição manual. Investigue-o, não arranje explicações para ele.
Confirme todas as verificações automatizadas de forma independente.
Se uma verificação automatizada diz «limpo» e a sua própria análise encontra uma conta UID 0 inexplicada, persiga o achado, não o conforto.
Fixe a hora do comprometimento, não a hora em que reparou.
Reconstitua o comprometimento plausível mais antigo a partir de canais laterais. O seu ponto de restauro limpo tem de ser anterior a esse momento, não à descoberta.
Reconstrua a partir de um ponto comprovadamente limpo.
Restaure a partir de uma imagem reconhecidamente boa, anterior ao comprometimento, troque todas as credenciais a que a máquina pudesse chegar, e volte a verificar. Não limpe no local.
Root durante qualquer janela de tempo significa um sistema não fiável. Um sistema não fiável não se limpa. Reconstrói-se a partir de um ponto que se consegue provar que estava limpo, anterior ao comprometimento, nunca posterior.
“Root durante um minuto é root até à reconstrução. Essa máquina não se limpa. Reconstrói-se a partir de um ponto que se consegue provar que estava limpo.”
Respostas diretas
Como encontro uma conta root escondida em Linux?+
Liste todas as contas com UID 0, não apenas a que se chama root: awk -F: '$3 == 0 {print $1}' /etc/passwd. O kernel concede root pelo UID, não pelo nome, pelo que qualquer segunda linha é uma conta com privilégios completos, chame-se ela o que se chamar. Procure-a diretamente. Não confie no facto de a lista de utilizadores parecer normal nem numa única verificação automatizada a reportar «limpo».
O que significa um hash de palavra-passe em /etc/passwd em vez de /etc/shadow?+
Em qualquer sistema Unix moderno, o campo da palavra-passe em /etc/passwd é um marcador de posição, normalmente x, e o hash real vive em /etc/shadow. Um hash genuíno dentro de /etc/passwd não é uma configuração normal. É a impressão digital de uma edição manual do ficheiro de utilizadores, e é por si só um indicador de comprometimento.
Porque é que não há nenhuma entrada no log para uma conta que claramente existe?+
Porque não foi criada com as ferramentas de contas padrão, que são o que escreve o log de autenticação. Se alguém editar o ficheiro de utilizadores à mão, a conta existe sem qualquer registo de criação. Uma conta UID 0 sem registo de criação não foi criada através de ferramenta nenhuma. Foi escrita.
Posso simplesmente apagar a conta maliciosa e aplicar o patch ao servidor?+
Não. Acesso root durante qualquer janela de tempo significa que todo o sistema é não fiável: binários, cron, bibliotecas, e as ferramentas com que o inspecionaria. Apagar a conta e aplicar o patch deixa-o a confiar numa máquina que já não consegue verificar. Reconstrua a partir de um ponto de restauro anterior ao comprometimento, troque as credenciais e volte a verificar.
A conta backdoor parece inativa. Continua a ser um problema?+
Sim. Uma conta UID 0 adormecida ou trancada continua a ser uma conta com privilégios completos que alguém plantou. A sua presença é o comprometimento, não um login qualquer. Uma atualização automática ou uma alteração de configuração pode desativar um backdoor por acidente sem remover a violação subjacente. Trate a presença, não a atividade, como o gatilho.
Uma conta root que não consegue explicar?
Se encontrou uma conta UID 0 sem registo de criação, ou não tem a certeza de que o seu último ponto de restauro limpo é anterior ao problema, não a limpe no local. Fale com um engenheiro que vai reconstituir a cronologia a partir de canais laterais e reconstruir a partir de um ponto que se consegue provar que estava limpo.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro