Rootkit ataca servidores Linux para inserir malware em páginas web
Como parte da sua instalação, o rootkit adiciona a linha “insmod /lib/modules/2.6.32 5-amd64/kernel/sound/module_init.ko” aos scripts de inicialização. Leia também: Rootkit infects Linux web servers.
Via g1.globo.com:
Um administrador de sistemas publicou na lista de segurança “Full Disclosure” uma informação sobre um servidor Linux que foi comprometido para alterar as páginas web servidas com um código capaz de infectar sistemas Windows de visitantes.
O código, que era até então desconhecido, infecta o sistema Linux agindo como um “rootkit”. Em outras palavras, o programa não aparece na lista de tarefas em execução do sistema. Ele é injetado diretamente no kernel para alterar funções do sistema operacional. De acordo com uma análise da fabricante de antivírus Kaspersky, a praga foi especificamente desenvolvida para atacar sistemas 64-bit baseados na distribuição Debian Squeezy.
A alteração do conteúdo enviado ocorre com uma modificação na função do sistema que constrói os pacotes TCP/IP. O administrador que relatou o ataque descobriu respostas alteradas em um servidor de proxy usando o software “nginx”, mas não se sabe se outros softwares poderiam também ter a resposta alterada pela praga.
Usuários de Windows que visitarem páginas de um site hospedado em um servidor infectado podem também ser infectados por pragas digitais se não estiverem com o navegador web e plug-ins atualizados. (…)
Enviado por Alexandro Silva (alexoslabsΘgmail·com):
Segundo stack trace, vítima do ataque, o malware adiciona um iFrame malicioso na resposta HTTP enviada pelo servidor web. Após o comprometimento o servidor passa a encaminhar as requisições para outros sites maliciosos, além disso um Blackhole varre o host do visitante a procura de falhas no Java, Flash entre outras aplicações rodando na máquina cliente.
Foi descoberto até o momento um módulo especifico para o kernel 2.6.32-5-amd64, presente no Debian Linux. Pesquisadores da Karpersky Labs nomearam o malware como Rootkit.Linux.Snakso.a, outra análise bastante interessante é do pesquisador Georg Wicherski da CrowdStrike, ele considerou o rootkit como parte da operação do cybercrime e que pelas técnicas adotadas foi desenvolvido por programador russo sem muito conhecimento do kernel.” [referência: blog.alexos.com.br]
@brlinuxblog
Feed RSS
Leia a materia completa em:
http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html
e tire sua conclusões
Acho que esta na hora dos desenvolvedores, e ate o próprio linus, tomarem cuidado mesmo sabendo que o linux é um sistema difícil de se quebrar segurança ou qualquer coisa, mas como diz um amigo, de pouquinho em pouquinho a galinha enche o papo, hj é isso quem sabe amanha, apenas um ataque deliberado ou explorando brechas que pessoas responsáveis pelo sistema deixaram de se preocupar.
Nenhuma novidade muito grande, mas eu achei esse mecanismo de interceptar o tcp_sendmsg bastante sofisticado. Muitos rootkits se limitam a interceptar rotinas relacionadas a processos e arquivos.
E isso foi feito por um programador russo sem muito conhecimento do kernel! Imagina se ele possuísse muito conhecimento…
Daí a importância do Secure Boot que tantos criticaram.
@Andre, Dependendo de como o módulo do malware se carrega, o Secure Boot não adiantaria nada.
o Secure Boot só assina o kernel. Se o módulo é externo e é carregado após a carga de kernel já durante a sequencia do INIT, bau bau.
Secure boot não resolveria nada.
e como ele se instala? se for usando metodos mirabolantes* tem mais é que demitir o administrador que conseguiu infectar o servidor.
*instalar recompilando o kernel com parametros obscuros e poucos usuais, ou explorando vulnerabilidades antigas(e ja corrigidas) para um escalonamento de privilegios.
eu tenho a mesma dúvida do @stribus
como este rootkit se instalou dentro do servidor linux?
Isso parece mais um ‘pum’ do que um rootkit. Não há nenhuma explicação sobre a forma de injeção. Se for por interação do usuário root, um ‘rm -rf /’ é mais efetivo.
André, na verdade, se vc quiser modificar o Kernel pra injetar um Malware, você precisa reiniciar, como quando atualizamos, e daí o secureboot percebe a falta da assinatura e proíbe a reinicialização.
Fui ler os comentários da notícia original pra ver se falavam sobre como ele foi instalado. Tem umas sugestôes:
module loaded at usb probing… with no securelevels this works.
Isso pode num servidor?
E tinha essas também:
Vishal SharmaNovember 21, 2012 8:55 AM
1) Your network or machine is infected and you have ftp accounts configured on your system it will sniff the passwords sends back to the person and then they connect to the ftp and put the stuff.
2) You have your server password sheet saved in your computer and they will get it
3) Your server is not patched and have some thing open and they can get a root shell
4) Your php is not configured properly and they get root access using a php shell
5) You have a lame password DUH
Linux é ***mto*** seguro. Sei.
“Your php is not…” já começa bem a definição da segurança do SO indo pro espaço por causa de um mísero php.
Não existe diferença nenhuma para o windows. Se um usuário windows usar/administrar a máquina linux, qual a diferença ? As técnicas de entropização do sistema serão as mesmas.
Aliás, nem faz mais sentido falar de usuário linux e usuário windows. Se até mesmo um programador faz isso sem conhecer o linux – supoe-se que seja usuario windows – a questão passa pro preconceito intelectual. Gente desfavorecida de neuronios funcionais, não importa o sistema utilizado, faz caca.
Existe todo um universo de diferenças.
>>>> Daí a importância do Secure Boot que tantos criticaram.
1 – O Foco do secureboot é desktop/tablet
2 – Existem tantas iniciativas para “inibir”(não acabar) com este tipo de ataque: Chroot(que algumas aplicações já possuem nativamente), Linux Containers, SELinux/GRSecurity, proxies reversos na frente do seu site, que esse teu papinho de Secure Boot só serviu pra ressucitar um tópico pra gerar flame.
Um Nginx num container/jail/chroot por exemplo, não teria acesso a lsmod, insmod e modprobe. Exemplo simples:
http://www.cyberciti.biz/faq/howto-run-nginx-in-a-chroot-jail/
O problema é que o pessoal só pensa nisso depois que a “tora já entrou”
Na verdade não houve modificação alguma no kernel, e sim em um de seus módulos, que podem ou não ser carregados no boot.
O módulo referido, de som, é completamente dispensável em um servidor e não é carregado automaticamente no boot, ele é chamado por algum arquivo de inicialização como citado com o insmod.
Como disse o Suhanko, já que houve privilégios para alterar arquivos de domínio do root, poderia simplesmente destruir o sistema, mas o objetivo é apenas distribuir malware.
A falha não é especificamente o rootkit, e sim que o sistema estava vulnerável a ponto de ser invadido e permitir tais modificações.
Firewall e sistemas de segurança são feitos para serem usados.
firewall ? como assim, firewall ? Voce por acaso iria colocar o firewall para bloquear o acesso a porta 80, impedindo assim o virus de invadir o sistema de vendas AO PUBLICO online do site? é essa a sua brilhante idéia ?
Deixa eu ver, vc lê a pc-master/infoexame e olhardigital, né? acertei ?
Salamão, sim Firewall.
O sistema não foi infectado pela porta 80, e nem mesmo modificou nada no serviço Web diretamente. “A alteração do conteúdo enviado ocorre com uma modificação na função do sistema que constrói os pacotes TCP/IP.” Lê-se iptables. Foi um ataque que forçava redirecionamentos independente do webserver.
A segurança é feita em degraus. O rootkit não foi instalado magicamente, e sim por meio de escalonamento de privilégios, por meio de serviços porcamente configurados pelo administrador, os mais vulneráveis são ftp e senhas ruins de acesso ssh, que facilitam ataques bruteforce.
O rootkit só foi instalado por um trabalho malfeito na segurança, que envolve principalmente o Firewall, e depois auditores como SElinux.
O Secureboot de nada adiantaria, pois não houve modificação no kernel, e insmod não necessita reboot para habilitar um novo módulo.
À propósito. Sou Linux Professional LPIC-1 e Novell CLA.
O tal “secure boot” protege contra módulos?
A assinatura cobre todo e qualquer módulo *externo* então ou é mais um FUD?
Não se incomode com comentários provocativos, senão você acabará perdendo o gosto de trocar informação em comentários. Sugiro um filtro psicológico, é bastante efetivo. rs
Weber Jr.
Mesmo que o Secureboot verifique módulos, ele faz isso no boot e não pós boot.
A tática desde rootkit é subir o módulo modificado depois do boot por qualquer arquivo que passe argumentos para o shell como o rc.local.
O insmod dispensa qualquer necessidade de reboot, ele apenas habilita o módulo, que já é o bastante, tornando o Secureboot totalmente ineficaz especificamente neste caso.
Jader Malaquias
“Mesmo que o Secureboot verifique módulos, ele faz isso no boot e não pós boot.”
Sim, disso eu sei, e justamente acho difícil o tal “secure boot” proteger visto que a assinatura se dá, imagino eu, sobre o kernel, não arquivos que podem ser carregados depois, como no caso dos módulos.
Pelo que eu entendi a ação do malware é inserir uma linha de texto na inicialização do linux (um servidor rodando Debian Squeezy), ou seja, pra isso funcionar precisa reiniciar a máquina.
Mas antes disso acontecer, ninguém sabe como que aquela linha foi parar ali.
Ou a máquina já estava infectada, ou o administrador não aplicou todas as medidas de segurança que precisavam. Pra servidor é preciso sempre mais cautela.
Analisando os comentários nos sites citados, parece que o único jeito é se o sistema instalado na máquina já esteja comprometido antes.
acho q todo mundo devia abandonar o gnu/linux e usar openbsd q é muito mais seguro.
Genilson. Sua colocação foi pertinente porém esclarecendo como acontece:
De alguma forma, seja por meio de vulnerabilidade de serviços como ftp ou mesmo senhas forçadas por bruteforce o atacante obtém acesso de root ou ao menos sudo.
A partir daí ele modifica qualquer arquivo de inicialização adicionando a linha “insmod /lib/modules/2.6.32 5-amd64/kernel/sound/module_init.ko”. Isto nada mais é que executar este comando, que é comum e muito usado para habilitar módulos “insmod”. O comando em si é inofensivo.
A grande jogada é alterar ou substituir completamente o módulo module_init.ko pelo módulo que faz os redirecionamentos de link.
Teoricamente, se houve permissão para editar arquivos e modificar módulos, também há permissão de executar o comando, sem necessidade de reboot, tornando o ataque invisível pois não gera warnings ou downtime, e apagar logs que registram entradas e modificações é regra para qualquer atacante.
“Desinfectar” o sistema se torna simples neste caso, basta repetir este mesmo comando substituindo o insmod por rmmod na linha, depois remove-se o módulo manualmente e retira-se a linha dos arquivos de configuração.
Jader
O ponto que você explicou eu entendi. Sei como funciona.
A parte que não foi dita é, nesse caso específico, como alguém teve acesso à máquina da vítima, qual vulnerabilidade foi usada. Os comentários indicam falha do administrador.
Outra coisa, vai depender muito de como o sistema esta instalado e configurado para ser possível executar um comando remotamente.
Eu não entendo nada de invasão de sistemas, mas lembro de ter lido algo a respeito há alguns anos sobre alterar arquivos remotamente no win9x pelo netbios (ou netbt sei lá). Imagino que no linux sejam ações diferentes, explorando vulnerabilidades diferentes, um caso é ler/editar, outro é executar remotamente um comando.
Dado o rumo que tomou essa conversa, posso concluir que todo esse alarde foi apenas uma jogada da Kapersky e da imprensa especializada para chamar a atenção quanto ao Linux com o simples objetivo de expor o quanto ele é sensível a vírus ainda que sem considerar as configurações de segurança do(s) servidor(es) infectado(s)?
Qual distro ainda utilizar kernel 2.6.32 nos dias atuais?
Rodrigo Pinheiro Matias, as distribuições como Debian, Red Hat, CentOS, etc, etc, etc.
@Suhanko – “Não se incomode com comentários provocativos, senão você acabará perdendo o gosto de trocar informação em comentários. Sugiro um filtro psicológico, é bastante efetivo. rs”
(2)
Genilson,
Realmente não foi esclarecido como se obteve o acesso privilegiado, porém a alteração de arquivos de inicialização só pode ser feita por root ou equivalente como o uso de sudo.
Obtendo tal privilégio suficiente para alterar estes arquivos, que tem restrições severas por meio de permissões, poderia-se facilmente também executar um comando, ou alterar o crontab adicionando uma linha para execução em horário específico.
As possibilidades são muitas. O difícil é achar a brecha, os modos de explorá-la são ilimitados. Esse rootkit foi até bem inocente, pois o alvo como disse o artigo são usuários de Windows desktop.
Secure Boot não é panacéia. Não vai resolver todos os problemas de segurança, principalmente não as senhas fracas e outras falhas.
O Nível técnico de certos comentaristas é frustrante.
Na verdade o mérito da senha fraca ou forte não está sendo levada em questão. Se tratando de acesso físico a senha não é um obstáculo maior que alguns poucos segundos.
Outro ponto que poucos discutem Suhanko.
Mas me refiro ao fato de estarem caracterizando o Secure Boot como ineficaz, simplesmente por não impedir este Rootkit.
Só queria colocar uma coisa antes de tudo, porque parece que algumas pessoas estão achando que o pessoal que comentou no site da notícia original sabia algo sobre o que levou à invasão do servidor. O que foi dito nos comentários do site são só suposições. Estão na verdade colocando falhas comuns que levam a uma invasão. Não tem como saber o que aconteceu nesse caso em específico se eles não divulgaram nenhuma informação além do rootkit.
Quer evitar rootkits? Compile um kernel estático, sem suporte a módulos, com patch do grsec desabilitando acesso direto ao I/O a partir do userspace. Mas para isso é necessário um sysadmin experiente, não existe distribuição que faça isso sozinho por você.
@Jader Malaquias,
Infelizmente eu devo concordar com o Salamão no aspecto do firewall, apesar de ele estar trollando em outros aspectos. É interessante ter um firewall? Sim. Ele dificulta uma invasão em alguns casos? Sim. Mas ele vai parar um ataque de uma pessoa experiente? Não.
Vou lista alguns ataques comuns e dizer se o firewall barra ou não.
PHP injection – Firewall só barra se tiver uma política de conexões baseada em whitelist e muito estrita. Por exemplo, se você barrar todos os pacotes saindo da rede, exceto aqueles originados pela porta 80 (considerando um servidor http) e pacotes destinados a servidores de atualização da distribuição. Mas nem sempre isso é possível, pois você vai ter que atualizar a whitelist sempre que os programadores precisarem abrir uma conexão para algum serviço externo.
SQL injection – Suponha que tenha uma base de usuários no seu site e algum desenvolvedor da equipe cometeu a burrice de se cadastrar lá com a mesma senha do acesso ssh dele. Tudo bem, é um ataque indireto, mas é um exemplo de caso impossível de evitar com firewall.
Exploits em geral contra falhas nos serviços – Algum serviço está desatualizado, ou quem está atacando tem acesso a um exploit 0day (o que é cada vez mais comum). Se ele não for um script kiddie, vai saber Assembly e vai saber escrever seu próprio shellcode. Com um shellcode bem elaborado é possível burlar a proteção de qualquer firewall. Por exemplo, suponha que ele dirige um ataque a um serviço e coloca um shellcode que fica esperando comandos na mesma porta que o serviço original. Como você barra isso com um firewall? O iptables não tem como identificar que é o shellcode que está escutando na porta. Outro shellcode que vai furar seu firewall – se você tiver um servidor web capaz de rodar PHP ou qualquer outro tipo de script ou CGI, o shellcode pode instalar um script capaz de receber comandos a partir de uma url.
Bom, isso são apenas alguns exemplos.
Agora respondendo o parágrafo a seguir:
“A alteração do conteúdo enviado ocorre com uma modificação na função do sistema que constrói os pacotes TCP/IP” – Aí eles estavam descrevendo a forma de atuação do rootkit, não a forma como o sistema foi invadido.
“Lê-se iptables” – Isso não tem nada a ver com o iptables. A função tcp_sendmsg não faz parte do netfilter. Novamente, o que eles estavam descrevendo nessa frase é a forma como o rootkit alterava as páginas servidas para inserir malware, que não era modificando os arquivos das páginas no disco, mas sim interceptando as requisições HTTP e modificando a resposta do servidor diretamente no kernel.