23 de julho de 2012

Alerta pessoal - canais IRC

Caros,

Nesses últimos dias estive descobrindo algumas coisas à respeito daqueles que ainda tentam prejudicar minha imagem de alguma forma.

Vejam o trecho abaixo de uma pseudo conversa no IRC com alguém se passando por mim:

22:19 -!- hack_proofing [~lvieira@09GAAGVFX.tor-irc.dnsbl.oftc.net
lvieira@09GAAGVFX.tor-irc.dnsbl.oftc.net>] has joined
#brasil-underground
22:21 < hack_proofing> ol'a
22:22 < Sonic3D> holá sir.
22:24 < Sonic3D> o sr. ser o hax0r pericial?
22:25 < hack_proofing> como assim?
22:27 < Sonic3D> hax0r pericial: Definição: aquele que realiza
perícias avançadas em equipamentos de alta tecnologia e, ainda, possui
notáveis capacidades intelectuais
                 (ie. criação de arquitetura própria e afins). AurelÃo
22:27 < hack_proofing> nao vou discutir com vc
22:28 < hack_proofing> nao vale a pena
22:28 < Sonic3D> sorry
22:28 < Sonic3D> foi só uma perguda :D
22:28 < Sonic3D> [Y/n]:
22:28 < Sonic3D> veja que a resposta defaul eh Y
22:28 < Sonic3D> heauheua
22:28 < _hide> uma pergunta simples para caralho, alias
22:29 < Sonic3D> poiseh :D
22:30 < Sonic3D> eu só queria pedir umas dicas e tals
22:30 < Sonic3D> um dia quero ser um hax0r
22:33 < hack_proofing> quero ser op do canal
22:33 < hack_proofing> ja q eu quem tive ideia dessas listas
22:34 < Sonic3D> heuaheauehauehauehauea
22:34 < Sonic3D> ouviu ai dmr
22:34 < Sonic3D> reza a lenta que para o cara ser op do canal, tem que
passar na esfinge e responder 3 perguntas
22:34 < hack_proofing> quem 'e dmr ?
22:34 < Sonic3D> mas relaxe, nao eh sobre arquitetura
22:34 <@dmr> opa
22:34 <@dmr> xo ler
22:34 < Sonic3D> dmr eh a mulher do BSDaemon
22:35 < Sonic3D> *lenda
22:35 < hack_proofing> ah ok
22:35 <@dmr> Sonic3D: o enigma da esfinge?
22:35 <@dmr> ehuehuehueh
22:35 <@dmr> hack_proofing: dmr sou eu, prazer sr.
22:35 < Sonic3D> heuahauea
22:35 <@dmr> hack_proofing: quem eh owner eh o BSDaemon
22:35 <@dmr> tem q falar com ele sobre ser OP
22:35 < hack_proofing> ahh ok
22:35 < Sonic3D> ou seja, quem manda eh a mulher do BSDaemon , que eh
o dmr
22:35 <@dmr> hack_proofing: e quem seria o Sr.?
22:35 < Sonic3D> ehauehauea
22:35 < hack_proofing> s'o quero oq 'e de direito
22:36 <@dmr> hack_proofing: direito? nao entendi
22:36 < Sonic3D> direito civil, processual ou penal? heuaheua
22:36 <@dmr> desenha, por favor?
22:36 < hack_proofing> precisa?
22:37 <@dmr> hack_proofing: sim
22:37 < hack_proofing> eu quem dei ideia da lista
22:37 < hack_proofing> entao
22:37 < hack_proofing> e tbm
22:37 < hack_proofing> o canal precisa de gente que ajude
22:37 < Sonic3D> eh verdade, dmr
22:37 < Sonic3D> ele tem direito
22:37 < Sonic3D> só tem que passar pela esfinge antes
22:37 < Sonic3D> kkkkkk
22:37 < Sonic3D> vc topa, hack_proofing ?
22:37 < hack_proofing> nao
22:37 <@dmr> hack_proofing: eu nao to nem ai pra lista... eu nem ia
entrar aqui... mas ai o BSDaemon pediu pra ajudar e tals... ai to aqui
22:37 < hack_proofing> nao preciso provar nada
22:37 < Sonic3D> ops desse canal tem que ter conhecimentos para poder
responder às perguntas dos noobs
22:38 < Sonic3D> vc ta certo, nao precisa mesmo :D
22:38 <@dmr> hack_proofing: se vc tem direito ou nao, nao me
interessa... quem decide eh quem criou... se vier pra somar blz... acho
legal
22:38 < j3r3mias> [22:34:39] dmr eh a mulher do BSDaemon
22:38 < j3r3mias> [22:34:45] *lenda
22:38 < j3r3mias> aeuaeueaueueueau
22:38 < hack_proofing> isso mesmo dmr
22:38 <@dmr> se chegar soh pra causar (como esta aparentando pela sua
postura), vaza fora
22:39 < hack_proofing> ok
22:39 <@dmr> "tenho direito... me da OP agora senao blablabla..."
22:39 <@dmr> acho q a postura nao eh essa
22:39 < hack_proofing> vcs quem perdem
22:39 -!- hack_proofing [~lvieira@09GAAGVFX.tor-irc.dnsbl.oftc.net
lvieira@09GAAGVFX.tor-irc.dnsbl.oftc.net>] has quit [Quit:
Leaving]



Todos podem perceber que alguém ainda foi "esperto" o suficiente para acessar o canal irc via TOR e colocar o e-mail de lvieira@09GAAGVFX.tor-irc.dnsbl.oftc.net além de utilizar o nome de meu blog como nick.

Alguém conhece comportamento mais baixo do que esse? E será que essa pessoa merece algum tipo de respeito?

De qualquer forma, já sei quem agiu dessa forma tão asquerosa e falsa, e ainda assim preciso conviver com pessoas desse tipo no mundo.

Mas o principal objetivo desse post é para alertar à todos que frequentam os canais de IRC, principalmente o brasil-underground e exploits-brasil: não acreditem em ninguém que se diga ser Luiz Vieira, com qualquer nick que seja, pois não tenho o hábito de acessar tais canais de bate-papo.

Tenho coisas muito importantes para fazer em minha vida, que é trabalhar para ganhar meu pão e de minha família e contribuir com a comunidade de SI, ao invés de tentar viver a vida dos outros.

Quando quero falar algo para alguém, utilizo 3 canais principais: meu e-mail (que muitos conhecem), meu twitter e aqui no meu blog. E sempre assumo a autoria do que escrevo, usando meu nome, ao invés de máscaras.

Outro ponto: os canais de bate papo via IRC, não possuem nenhum vínculo com a lista Exploits Brasil, da qual eu e Ronaldo Lima somos os moderadores. Quem criou o canal foi o Sr. BSDaemon e não dou a mínima importância para a criação do mesmo, como disse ao Sr. citado, pois não tenho tempo disponível para troca de figurinhas por bate-papo e/ou controlar qualquer canal desse tipo. Afinal, minha esposa e meus filhos são mais importantes do que qualquer briguinha de ego entre adolescentes.

Tenho dito!

12 de julho de 2012

Debugging como técnica de análise estática de malwares


Aproveitando o webcast realizado ontem à noite sobre Análise de Malwares como Técnica de Forense, resolvi escrever esse pequeno texto sobre um assunto que surgiu ao final.

Havia um “participante”, Raquere, que desde o início o intuito do mesmo estava claro, mas não vou entrar nesses pormenores... Mas surge sempre a dúvida: se a pessoa já sabe de tudo, porque participar de eventos, palestras, apresentações e etc? Ela não precisa disso, basta sentar numa cadeira, e esperar morrer :-)

Mas vamos lá... Esse Raquere (que deve ser um “raquere” l33t0 do mal, membro da Liga da Estrela da Morte), fez uma pergunta sobre debugging ser análise dinâmica ou estática. E como sempre, procurei ser bem claro, pois sei que pessoas com limitações cognitivas tem dificuldade de entendimento e aprendizado, mesmo que desenhemos bonecos de pauzinhos conversando entre si para explicar um conceito.

Minha explicação basicamente foi a seguinte:

“Em um caso onde temos um malware com packer, precisamos debuggar o código, descobrindo onde está o tail jump no unpacking stub, para aí colocarmos um breaking point, avançarmos com um step into e paramos o processo assim que o debugger atingir a primeira instrução do código do malware em si, antes de executá-lo. Sendo assim, nesse momento já teremos o malware desempacotado na memória física e podemos fazer um dump do mesmo, usando ferramentas específicas para isso, e prosseguirmos com a análise estática com o código desencriptado.”

Infelizmente achei que através dessa explicação, ficaria claro que debugging é uma técnica parta análise estática em processos de unpacking do malware, apenas nesse contexto,pois era disso que estava falando. Mas o Raquere, coitado, não entendeu. Vou ficar inclusive devendo um desenho, pois não sou tão bom desenhista assim :-)

Debugging é técnica de análise dinâmica quando executamos o código do malware, o que não é feito nos passos que expliquei acima. Esse é meu entendimento. Meu conceito pode até estar errado, mas a explicação acima não tem nada de errado.

Agora, para quem tem um pouco mais de interesse de entender o que foi explicado acima, vamos prosseguir. Para os demais, não vale a pena prosseguir, pois não vou mostrar telas do IDA Pro...

Malwares, em sua maioria das vezes, possuem proteções contra sua análise e acesso ao código fonte. E essas proteções muitas vezes são utilizadas em camadas.

As mais comumente encontradas são:
- Packer
- Crypter
- Anti-Debugging
- Anti-Disassembling
- Anti-VM

Vamos focar no primeiro tipo, packers.

Packers são ferramentas que permitem o empacotamento de executáveis, criptografando-os e comprimindo-os, o que permite deixá-los protegidos contra AV’s que trabalham com assinaturas, e dificultar a análise do código original do malware. Isso inclusive diminui sensivelmente a extração de strings a partir do PE analisado. Basta compararmos quantas strings conseguimos extrair de um PE normal e de seu equivalente “packeado”.

Então, como o malware consegue ser executado se está encriptado e compactado? Ao ser chamado, o packer desempacota o malware, jogando-o na memória, já desencriptado, e passa o controle de execução para código do malware através do OEP (Original Entry Point).

Mas porque isso acontece?

Porque quando o packer é executado em cima do malware para empacotá-lo, um novo PE é criado, para armazenar o PE original, com o acréscimo de mais um código em uma seção que chamamos de unpacking stub, que é o código para desempacotá-lo quando o mesmo é chamado. Ao final desse unpacking stub, temos o tail jump, que é uma função jmp (algumas vezes ret ou call, quando os desenvolvedores querem esconder a localização do tail jump), que direciona o ponteiro de execução para o endereço da memória onde está o OEP, para que o malware, já desempacotado, possa ser executado na memória onde já está localizado nesse momento.

Quando é utilizado um packer, passa a existir o EP e o OEP, onde o EP está apontando para o unpacking stub e o OEP para o ponto inicial do código original do malware (original entre aspas, porque depois de empacotado, após extraí-lo, se compararmos com o PE original, podemos perceber que sua estrutura foi alterada).

Logo abaixo temos um exemplo de identificação de packer utilizado, através do PEiD:



E abaixo, temos um gráfico que explica como funciona o processo de packing e unpacking:



Logo, quando utilizamos um debugging para executar apenas o código do unpacking stub, para descobrir o OEP e podermos realizar o dump da memória, recuperando o código original do malware, estamos executando o malware?

Será que quando, mesmo em um processo de debugging, e apenas nesse contexto, executamos apenas o unpacking stub para recuperar seu código, sem executar o código do malware, estamos realizando um processo de análise dinâmica, ou estática?

Depois que realizamos o dump da memória, com o malware desempacotado, podemos prosseguir com o processo de análise estática, extraindo strings e analisando as chamadas que faz à API e syscalls. O grande problema, é que quando fazemos isso, normamente a IAT (Importa Address Table) não é recuperada, então há a necessidade de recriá-la. Aí entramos na necessidade de uma análise dinâmica, onde executamos o malware (ainda empacotado), para remontar a IAT e fazer um fix no dump realizado anteriormente a partir da memória fixa.

Uma das ferramentas que permite essa recuperação da IAT, é o ImpREC. E para o dump da memória física, podemos usar o LordPE ou o plugin do OllyDBG, OllyDump.

Resumindo: debugging quando na execução do código do malware, é utilizado em análises dinâmicas. Entretanto, debugging como técnica de execução apenas do unpacking stub, sem executar o malware em si (será que tem alguém que considera o unpacking stub, do packer, como código do malware?), é uma técnica como parte de um processo de análise estática.

6 de julho de 2012

OYS Webcast - Análise de Malwares como Técnica de Forense Digital


O Webcast tem como objetivo apresentar uma explicação sobre como agir em situações onde, durante uma investigação forense, são encontrados malwares como evidências e ferramentas de execução de crimes digitais. Através dos mesmos, criminosos podem realizar roubo de identidade, captura de informações bancária, violação de e-mails, acesso à informações confidenciais e etc. 

Algumas das perguntas que serão respondidas durante o Webcast:
  • Por que analisar um malware?
  • Quais os passos necessários?
  • Diferentes tipos de análises?
  • Quais os tipos mais comuns de malwares encontrados?
  • Quais as ferramentas de forense digital homologadas, podem ser utilizadas em análises?

O perito forense, Luiz Vieira, sócio-diretor da OYS, apresentará esse webcast e responderá as perguntas dos participantes.

Data: 11/07/2012
Horário: 20h00

Para inscrever-se, basta enviar seu nome completo e e-mail para academia@oys.com.br