Bank Phishing: The Fulerage Never Ends!

Nesta postagem eu vou estar descrevendo uma pequena análise realizada em cima de um e-mail de phishing que eu recebi recentemente (Espero que isso sirva de ajuda para futuras análises de phishing e páginas maliciosas para os leitores do blog)..

Análise inicial do e-mail

 

A figura abaixo apresenta a mensagem original de phishing.

Figura 01: Mensagem Original

Já da para perceber pela figura 01 que este e-mail se trata de um phishing voltado para clientes de um determinado banco. A partir do conteúdo da mensagem, podemos ver que a mesma apresenta um link para endereço o qual não pertence ao banco (ver figura 02).

Figura 02: Link de origem

Analisando o link de origem

Através da figura 02 é possível ver o endereço do link da mensagem:

http://spaces.isu.edu.tw/~lawedu/media/system/images/sex5/?cliente=[E-MAIL]

O servidor 'spaces.isu.edu.tw' está localizado no endereço IP '140.133.46.51'. Através de um simples 'whois' nós podemos obter algumas informações sobre o endereço de origem do link (ver figura 03).

Figura 03: Whois

Vamos agora realizar uma requisição para o link citado sendo que com um endereço de e-mail diferente para o parâmetro 'cliente' (ver figura 04).

Figura 04: Acessando o servidor malicioso

Através da Figura 04 é possível ver que o servidor 'spaces.isu.edu.tw' realiza um redirecionamento da nossa requisição para 'www.prfprinting.ir' (localizado no servidor 144.76.219.88). Depois de uma pequena busca, eu acabei descobrindo que o servidor 'www.prfprinting.ir' foi previamente invadido e um webshell foi instalado por um atacante (ver figura 05).

Figura 05: Obtendo informações sobre o servidor

Analisando o conteúdo da página

 

Neste momento vamos analisar o conteúdo devolvido pelo servidor 'www.prfprinting.ir'. Três arquivos '.php' (topo, body e rodape) fazem parte da página retornada pelo servidor (ver Figura 06).  

Figura 06: Página principal do servidor

Depois de analisar um pouco cada um dos três arquivos '.php', eu percebi a presença de código javascript obfuscado em 'topo.php' e 'body.php'. O arquivo 'body.php' apresenta alguns pontos mais importantes para a análise do ataque: funções suspeitas e o arquivo 'cmds.js'.

Funções suspeitas

O arquivo 'body.php' apresenta algumas funções suspeitas: fCheck, cxk e puxaDados (ver figuras 07 e 08).

Figura 07: Funções puxaDados e cxk

Figura 08: Função fCheck

Arquivo cmds.js

 

A página 'body.php' importa um arquivo 'cmds.js' (ver figura 09)

Figura 09: Importando 'cmds.js

O início do arquivo 'cmd.js' é apresentado na figura 10.

Figura 10: arquivo cmd.js

As figuras 11 e 12 apresentam as funções cxk, puxaDados e fCheck (É importante notar que certas partes das funções puxaDados e fCheck estão obfuscadas!).

Figura 11: Funções cxk e puxaDados

Figura 12: Função fCheck

A função fCheck recebe dois parâmetros de entrada: 'ppl' e 'action'. A função realiza diversos 'ifs' comparando o conteúdo da variável 'action' com diversos valores (ex: 'ggc', 'sen' e 'wtv'). Vamos focar em uma dessas comparações (eu vou selecionar 'sen' (Mesmo valor presente na figura 08!)). A figura 13 apresenta a parte do código no qual o valor de 'action' é comparado com 'sen'.

Figura 13: Função fCheck (checando ifs)

A partir da figura 12, é possível constatar de que partes do código da função fCheck estãos obfuscados. Vamos deobfuscar estas partes para ter uma ideia melhor do que ocorre durante esta função. As figuras 14 e 15 apresentam os 'pedaços' de códigos antes e depois da deobfuscação.

Figura 14: Código Obfuscado

Figura 15: Código Deobfuscado

A partir da Figura 15, podemos ver uma variável 'sen' sendo criada a partir do elemento 'campo_s_se_1522_0922'. Esta variável contém a senha utilizada pelo usuário na página de phishing. A função verifica se a variável 'sen' tem 6 ou mais caracteres. A variável 'varsend' é formada por:

varsend = 'altera=senha&senhae=' + sen.value

A função 'enviaDados' é chamada com 2 parâmetros:

1. ppl = Endereço IP da vítima
2. varsend = 'altera=senha&senhae=' + sen.value

Função enviaDados

 

Vamos ver agora de que forma os dados do usuário são enviados para o atacante. Vamos continuar ainda nesse exemplo da senha do usuário. A função 'enviaDados' é apresentada na Figura 16.

Função 16: Função 'enviaDados' (Obfuscada)

A função 'enviaDados' apresenta uma parte de seu código obfuscada. Vamos agora deobfuscar esta seção do código (ver Figura 17).

Figura 17: Função 'enviaDados' (Deobfuscada)

A função 'enviaDados' cria uma requisição POST para o endereço 'http://www.prfprinting.ir/atendimento.online/components/com_user/user/plugin/index.php' enviando a senha da vítima através do parâmetro 'senhae'.

Conclusão

Nesta postagem eu apresentei uma análise básica de um e-mail de phishing contra clientes de um determinado banco. O phishing análisado obtinha dados dos clientes (como senha) e enviava estes dados para uma URL específica do servidor 'www.prfprinting.ir'. Os arquivos maliciosos do servidor  'www.prfprinting.ir' foram removidos recentemente (provavelmente pelos responsáveis do servidor). Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!

All your routers are belong to us: Atacando OSPF (Parte 1)

Nesta postagem eu vou estar falando um pouco sobre possíveis ataques contra o protocolo OSPF (Open Shortest Path First). Estarei focando nesta primeira parte na coleta de tráfego OSPF e ataques contra os métodos de autenticação utilizados pelo protocolo.

Observação:

O conteúdo apresentado nesta postagem deve ser reproduzido apenas em um ambiente no qual você possui autorização para a realização de testes de segurança.

Introdução

O OSPF é um protocolo importante utilizado para facilitar a troca de informações de roteamento entre roteadores. Para realizar os ataques, vamos primeiro analisar os tipos de mensagens utilizadas pelo protocolo:

1. Hello: Mensagem inicial utilizada por um roteador na descoberta de roteadores vizinhos em uma rede local.
   
2. Database Description: Estas mensagens contém informações sobre a topologia de um AS (Autonomous System)
3. Link State Request: Mensagem utilizada para realizar um pedido de informações para atualização de rotas.
4. Link State Update: Mensagens de atualizações enviadas em resposta à uma requisição Link State Request.
5. Link State Acknowledgment: Mensagem de confirmação (para o Link State Update).

 O protocolo OSPF permite que todos os tipos de mensagens possam ser autenticadas através de diferentes métodos (descritos mais adiante). A análise dos cabeçalhos das mensagens OSPF torna-se importante para entender como podemos atacar estes métodos de autenticação.

Formato de Mensagens:

O cabeçalho de uma mensagem OSPF costuma ter 8 campos (um total de 24 bytes):

• Version: Versão do protocolo
• Type: Tipo de mensagem OSPF (descrito na introdução)
• Packet Length: Tamanho da mensagem (incluindo o cabeçalho)
• Router ID: Identificador do roteador que gerou a mensagem.
• Area ID: Identificador da área a qual a mensagem pertence.
• Checksum: Código checksum da mensagem
• AuType: Tipo de autenticação utilizado pela mensagem
• Authentication: Campo utilizado para autenticação da mensagem (conteúdo do campo vai depender do tipo de autenticação utilizado).

Vamos focar no campos AuType e Authentication!

Figura 01: Cabeçalho OSPF

Método de autenticação 01: Autenticação nula

O primeiro método de autenticação utilizado pelo protocolo é uma autenticação nula (ou simplesmente a falta de autenticação hehe). Neste método o campo AuType apresenta um valor 0 e o campo Authentication encontra-se vazio. A figura 02 apresenta um exemplo de mensagem OSPF com autenticação nula.

Figura 02: Autenticação Nula

Método de autenticação 02: Autenticação simples

O segundo método de autenticação utilizado pelo protocolo apresenta a utilização de uma senha para trocar de mensagens OSPF. Neste método o campo AuType apresenta o valor 1, enquanto que o campo Authentication apresenta a senha em texto claro! A figura 03 apresenta um exemplo de mensagem OSPF com autenticação simples.

Figura 03: Autenticação Simples

Método de autenticação 03: Autenticação com criptografia

O terceiro método utiliza funções de hash para a autenticação de mensagem OSPF. Neste método o campo AuType apresenta o valor 2, enquanto que o campo Authentication apresenta um valor hash em MD5 (construção do hash é descrito a seguir).  A figura 04 apresenta um exemplo de mensagem OSPF autenticada através de criptografia.

Figura 04: Autenticação com criptografia

Construção do Hash

O hash presente no método de autenticação 03 é criado da seguinte forma:

1. Mensagem OSPF é gerada normalmente (checksum deve ser igual zero).
2. A senha secreta (em texto claro) deve ter tamanho igual a 16 bytes. Caso o tamanho da senha seja menor que 16, bytes nulos (0x00) são adicionados no final da senha. Caso contrário, apenas os primeiros 16 bytes da senha secreta devem ser utilizados.
3. Hash = MD5(Mensagem OSPF + senha secreta de 16 bytes).

Atacando OSPF: Criando um sniffer

Para iniciar os ataques, precisamos primeiro criar um sniffer para a coleta de tráfego OSPF. Eu vou utilizar a biblioteca Scapy para criar um sniffer em Python (como de costume hehe!). Os testes apresentados nesta postagem foram realizados em uma VM do Kali Linux 1.0.6 (antigo BackTrack).

A biblioteca Scapy não apresenta o suporte à mensagens OSPF  por padrão. Por isso, precisamos pegar uma extensão disponível publicamente para a coleta e manipulação de mensagens OSPF (extensão disponivel para download em http://bb.secdev.org/scapy/raw/300258ace1bc7e50a5c6e159d2919f474149d8ba/scapy/contrib/ospf.py).

A primeira parte da criação do sniffer é gerar um método para a filtragem de pacotes OSPF (o qual pode ser facilmente realizado através da classe OSPF_Hdr). A figura 05 apresenta uma maneira de realizar a filtragem de mensagens OSPF.

Figura 05: Filtrando pacotes

A segunda parte do script envolve a verificação do tipo de autenticação utilizado pela mensagem OSPF capturada. A figura 06 apresenta um exemplo de função para a verificação do tipo de autenticação.

Figura 06: Verificando o tipo de autenticação

A terceira parte é responsável por realizar um ataque de dicionário contra o hash encontrado no pacote coletado. A figura 7 apresenta um exemplo de criação de hash a partir de uma determinada wordlist.

Figura 07: Quebra de senha (Hash MD5)

As figuras abaixo apresentam o resultado do script rodando em 3 cenários possíveis de autenticação (autenticação nula, autenticação simples e autenticação com criptografia).

Figura 08: Autenticação Nula

 

Figura 09: Autenticação Simples

Figura 10: Autenticação com Criptografia

O script encontra-se para download no GitHub:
https://raw2.github.com/pasknel/hacking-com-tapioca/master/OSPF/ospf_crack.py

Conclusão

Nesta postagem foram apresentados alguns ataques contra o protocolo OSPF. Os métodos de autenticação utilizados nas mensagens OSPF podem ser atacados através da coleta de pacotes e ataques de força-bruta/dicionário. Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!