Malware – Vírus, Worms, Bots, Trojan Horses, Rookits…

Julio Auto - jam

Roteiro

Introdução– Definições

Vírus– Tecnologias

Worms– Análise histórica e técnica

O que é Malware?

Malicious Software Software com propósito “desagradável” – do

irritante ao danoso Alcunha para se referir em termos gerais a

conceitos confusos– Vírus, worms, trojans, rootkits…

Tipos de Malware

Vírus (Fred Cohen – 1983)– Código que reside em outro arquivo (hospedeiro)

e pode infectar outros arquivos

Worm (PARC - 1982)– Código “auto-remoto-replicável”

Trojan Horse– “Presente de grego”

Tipos de Malware

Backdoors– Programas que abrem acesso remoto a um

usuário não-autorizado

Rootkits– Conjunto de software com medidas para (ganhar

e) manter acesso a um host– Tipicamente uma combinação de trojan, backdoor

e mais...

Tipos de Malware

Bots (de botnet)– Software que executa tarefas automatizadas, sob

controle de um operador– Frequentemente controlados via IRC (Internet

Relay Chat)– Comuns spammers

Tipos de Malware

Spyware– Interceptação da interação do usuário com o

computador– Monitoramento e interferência (redirecionamento

de páginas, instalação de programas...)

Adware– Programa que exibe propagandas– Muitas vezes faz uso de spyware

Tipos de Malware

Keylogger– Intercepta e registra a interação do usuário com o

teclado do computador Click-logger

– Semelhante ao keylogger, mas para mouse clicks Dialer

– Discador de 0900 Outros?

– Uma nova buzzword a cada instante

Vírus

Vírus (ou virii) são uma espécie de dark art Semelhança com a biologia Estado-da-arte oriundo do underground Complexidade alta, exige _excelentes_

programadores Comumente feito por gente do leste europeu

– Rússia, ex-URSS, Hungria, Polônia... Intolerado pela lei e grandes indústrias

Vírus

Combatidos pelos softwares de anti-vírus– Signature-based

Não-trivial

– Comportamental Pouco inteligente

Evolução = vírus x anti-vírus Virus engines MS-DOS: uma plataforma de ótimos vírus

– As coisas meio que recomeçaram com o 32-bits

Vírus

Encriptado– Consiste do corpo do vírus “encriptado” de

alguma forma e uma rotina decriptadora (não-encriptada)

– O ponto de entrada do vírus é a rotina decriptadora

– Ao término da decriptação, o programa transfere o controle para o vírus em si

Vírus

Encriptado– Detecção trivial através da assinatura do código

decriptador

Vírus

Oligomórfico– Modifica o código decriptador ao longo das

gerações Win95/Memorial criava 96 padrões diferentes

– Detecção através do código decriptador não é uma boa idéia

– Melhor decriptar e detectar usando o corpo decriptado do vírus

Vírus

Polimórfico– Geração de inúmeros decriptadores– Uso de diferentes formas de encriptação– Às vezes, múltiplas camadas de encriptação– Novos truques:

EPO (Entry-Point Obscuring) Anti-emulation

Vírus

Metamórfico– Não só altera o código do decriptador, como

também o código do próprio vírus– Ainda assim, executam as mesmas funções– Sem seção de dados

Dados embutidos no corpo do vírus

– Detecção = ? O grande desafio está na metodologia da evolução

Anti-vírus

Desafios– Detecção de vírus não-cadastrados– Detecção de vírus metamórficos complexos– Performance

Worms

Propagação automática Freqüente uso das técnicas de vírus A seguir, análise de alguns worms clássicos

– Slides por cortesia de Julio Cesar Fort

Morris worm

Surgiu no dia 02/11/1988 e foi criado pelo estudante da University of Cornell, Robert Morris Jr., filho do cientista-chefe da NSA à epoca

Duas horas após o lançamento já havia atingido computadores em Berkeley, LLNL, Los Alamos, NASA, etc.

O task-force liderado por Eugene Spafford, da Purdue University, conseguiu analisar o worm e freá-lo antes que houvessem mais danos

Capa do NY Times, “ofuscando” as eleições presidenciais que ocorreriam dentro de quatro dias

Morris foi condenado a 440 horas de serviço comunitário e multa de US$ 10 mil. Estima-se um prejuízo de US$ 15 milhões

Hoje Robert Morris Jr. é professor do MIT

Morris worm – análise técnica (1)

O worm foi escrito na linguagem C e portado para máquinas rodando SunOS e BSD UNIX

Foi a primeira aparição pública do buffer overflow, até então meramente teoria

O worm procurava seus alvos no arquivo ‘/etc/hosts’ e usando ‘netstat –r –n’

E se propagava através de três formas: buffer overflow no fingerd, bug no sendmail e pelo rshd

Morris worm – análise técnica (2)

fingerd– A propagação pelo buffer overflow do fingerd foi a de maior

sucesso– O worm sobreescrevia um buffer de 512 bytes do fingerd, que

usava a função gets(), que não provê checagem– Nas máquinas Sun o método não funcionou por conta de Morris

não ter acertado o endereço de retorno para o shellcode, fazendo o daemon gerar core dump

Morris worm – análise técnica (3)

sendmail– O worm conectava na porta de smtp e invocava o modo DEBUG

do sendmail, que continha uma falha onde era possível passar comandos arbitrários

– Sendo assim, o worm envia um shell script que compila um pequeno programa em C, que será responsável por copiar os objetos ‘.o’ do worm a partir da máquina de onde veio

– O script verifica qual o SO e faz o linking apropriado para produzir o ‘/usr/tmp/sh’, mais uma cópia do programa

Morris worm – análise técnica (4)

rshd– Abusava da política de “trusted hosts” (arquivos ‘/etc/hosts.equiv’

e ‘.rhosts’)– Como o worm nem sempre rodava como root ele tentava lia o

‘/etc/passwd’ e tentava advinhar as senhas dos usuários do sistema, fazendo diversas combinações

E para tal ação ele continha uma lista de senhas mais comuns e ainda contava com a ajuda do ‘/usr/dict/words’

– Com uma conta comprometida, ele usa ‘rsh’ ou ‘rexec’, e copiando o payload como ‘/usr/tmp/sh’ na máquina remota

Morris worm – fatores do sucesso

Fatores do sucesso– A propagação através de três maneiras, incluindo

buffer overflow, foi altamente eficaz – Portabilidade também foi um fator primordial para

o sucesso do worm– O pouco conhecimento sobre segurança que havia

na época Erros do worm e lições aprendidas

– Com certeza o erro mais grave era que o worm não checava se havia uma instância dele já rodando

– Programação segura e a escolha de senhas fortes são fundamentais

Melissa

A primeira aparição foi no dia 26 de março de 1999 Espalhou-se muito rapidamente através de

mensagens de e-mail maliciosas e arquivos do Word Pelo fato de se espalhar por e-mail, diversos

servidores smtp foram derrubados ou desativados (até mesmo o da microsoft.com)

Foi um divisor de águas: deu início a era de escrita de worms em VB Script

O worm causou US$ 80 milhões em prejuízos somente nos EUA

O autor, David L. Smith, foi condenado a 10 anos mas reduziu a pena para 20 meses e multa de US$ 5000 ao fazer um acordo com o FBI

Melissa – análise técnica

O Melissa espalhava-se através de opções de macro do Word 97 e 2000 em conjunto com o Outlook 97 e 98

Replicava-se através de “mass mailing”, enviando mensagens infectadas para os 50 primeiros endereços na lista contato da máquina infectada

Caso a máquina não se encontrasse online ele infectava todos os arquivos ‘.doc’ e inseria uma mensagem neles

Algumas variantes do Melissa apagavam arquivos importantes do sistema

Source do Melissa: http://www.62nds.co.nz/62nds/documents/melissa.txt

Melissa – fatores do sucesso

Grande número de usuários do Microsoft Outlook e Word

A enorme curiosidade das pessoas ;)

Code Red

Sua primeira aparição foi no dia 13 de julho de 2001 e somente no dia 19 de julho o worm havia infectado 359 mil computadores

Explorava uma condição de buffer overflow no Microsoft IIS 4 e 5

Até mesmo servidores da da Microsoft foram comprometidos

Mais uma vez a autoria foi atribuída a hackers chineses e cogitou-se que até mesmo do governo da China estaria envolvido

Os prejuízos causados pela primeira versão são estimados em US$ 1.5 bilhões

Code Red – análise técnica (1)

O overflow foi descoberto por acaso pela eEye enquanto faziam fuzzing contra o filtro .ida do ISAPI

– GET /NULL.ida?[buffer]=X HTTP/1.0 (com [buffer] aproximadamente 240 bytes)

Após se utilizar do overflow para penetrar no sistema, o worm abre 100 processos filhos, onde 99 são usados para procurar por outras máquinas vulneráveis

O processo-filho restante checa se o idioma padrão é inglês; caso afirmativo, modifica o ‘index.html’ com o conteúdo “HELLO! Welcome to http://www.worm.com! Hacked By Chinese!”

Code Red – análise técnica (2)

Todos os processos-filhos procuram pelo diretório ‘c:\notworm’ para assegurar que o sistema já não havia sido infectado anteriormente

A data do sistema é lida e se o dia for maior ou igual a 20 é lançado um ataque ao site da Casa Branca (www.whitehouse.gov)

Code Red – fatores do sucesso

A demora para a instalação dos devidos patches

O worm afetava as versões mais usadas do IIS, que é um dos mais populares servidores de HTTP do mundo

SQL Slammer (Sapphire)

Surgido em 24 de janeiro de 2003, se espalhava por uma falha no Microsoft SQL Server, bug este descoberto e com patch disponível há vários meses

É considerado o primeiro “Warhol worm” da história, tendo infectado a grande maioria dos servidores nos primeiros 10 minutos

O sistema de reservas da Continental Airlines e os caixas eletrônicos do Bank of America ficaram inoperantes, assim como boa parte da internet na Coréia do Sul

Mais uma vez a suspeitava-se de hackers chineses do grupo Honkers Union of China, mas nada foi provado

Estima-se que o worm causou entre US$ 1 e 2 bilhões em prejuízos

SQL Slammer – análise técnica

O worm iniciava enviando apenas 1 byte (0x04) para um IP aleatório na porta do MS-SQL (1434/UDP) e logo em seguida o payload malicioso, corrompendo um stack-based buffer de 128 bytes

Após infectar o sistema, o Slammer criava um socket UDP, gerava um IP aleatório e enviava o seu payload, sem a necessidade de se copiar de forma comum

Aparentemente o worm foi todo feito em assembly, justificando o seu pequeno tamanho (376 bytes) e velocidade

SQL Slammer – fatores do sucesso

Fatores de sucesso– A não instalação do patch e o “esquecimento”

da falha– O worm era minúsculo, rápido e não-residente

em disco … mas poderia ter sido melhor (ou não?)

– O uso de endereços “hardcoded” para explorar o stack overflow impediu que o worm se espalhasse em várias versões de Service Packs do Windows

Se o worm não fosse Service Pack-dependant poderia ter um tamanho maior

Blaster

Surgido em 11 de agosto de 2003, se espalhava por uma falha no RPC DCOM, bug descoberto e publicado pelos poloneses do LSD e exploit pelos chineses do X-Focus

Atingiu com sucesso milhões de computadores Windows XP e 2000 e causou instabilidade e negação de serviço nos Windows NT, 2003 e XP 64 bit

O worm continha várias mensagens escondidas como “I just want to say I love you San”, entre outras

Vários provedores (incluindo o Velox) tentaram conter o ataque bloqueando as portas que o Blaster usava

A autoria original do worm é desconhecida, mas criadores de duas variantes foram presos nos EUA e Romênia

O Wall Street Journal estimou prejuízos de US$ 329 bilhões em todo o mundo (certamente este número é irreal)

Blaster – análise técnica

O serviço RPC escuta na porta 135/TCP O payload do worm abria uma shell na porta

4444/TCP e instruía o computador atacado a baixar a praga do computador de origem

– Por causa de uma falha de design do worm, o ataque ao RPC causava uma instabilidade no Windows e o forçava a reiniciar

O Blaster foi programado para executar um ataque de negação de serviço ao site do Windows Update no dia 15 de agosto de 2003, desta forma ninguém iria conseguir baixar as atualizações

O ataque não obteve êxito pois a Microsoft removeu o endereço windowsupdate.com

Blaster – fatores do sucesso

Fatores do sucesso– Enorme popularidade do Windows 2000 e

sobretudo XP A exposição dos usuários devido a não instalação

dos patches

– Os detalhes técnicos e o exploit da falha haviam sido lançados poucas semanas antes

… mas poderia ter sido melhor– Se não fosse a instabilidade causada no sistema

invadido, a maioria dos usuários sequer saberiam que estavam infectados com o Blaster

MyDoom

Surgido em 26 de janeiro de 2004, o Mydoom foi o worm de e-mails mais rápido da história

1 em cada 10 e-mails estavam infectados O alto tráfego gerado fez com que a internet ficasse 10%

mais lenta que o normal O worm original era programado para atacar o site da

SCO Dois dias após a primeira versão, foi detectada a variante

MyDoom.B, reprogramada para atacar sites de 20 empresas de anti-vírus e segurança

2 em cada 10 e-mails estavam infectados– Outras variantes atacaram o Google e o Altavista

Mesmo após a SCO ter oferecido US$ 250 mil pela captura do autor da praga e o FBI e o Serviço Secreto terem sido acionados, ninguém foi preso.Sabe-se que a mensagem original partiu da Rússia eque o worm é obra de um programador profissional

MyDoom – análise técnica (1)

Para se espalhar por e-mail o MyDoom tinha uma engine própria de SMTP

O assunto do e-mail continha uma mensagem que sugeria erro no envio, com os supostos detalhes em anexo

"Error", "Mail Delivery System," "Test" ou "MailTransaction Failed“, em inglês ou francês

"The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.", ou "Mail transaction failed. Partial message is available.“

O sistema de mass-mailing do MyDoom é inteligente e evita que e-mails infectados sejam enviados para universidades como MIT, Berkeley, Stanford e empresas como IBM e Google, que detectariam rapidamente que um worm estava a solta

MyDoom – análise técnica (2)

Um backdoor na porta 3127/TCP era instalado para posterior controle do computador afetado

O worm estava programado para atacar o site da SCO no dia 1 de fevereiro de 2004, o que acabou não acontecendo

MyDoom – fatores do sucesso

O despreparo dos usuários e a enorme curiosidade das pessoas ;)

Sasser

Sua primeira aparição foi em 30 de abril de 2004 O Sasser explorava um buffer overflow no serviço

LSASS, padrão no Windows XP, 2000 e 2003 Em menos de um dia de vida a praga atingiu mais de

1 milhão de computadores Devido os efeitos do worm, a agência de notícias AFP

teve sua comunicação de satélite cortada, computadores da União Européia ficaram inoperantes, a Delta AirLines foi obrigada a cancelar vôos, etc.

A Microsoft ofereceu US$ 250 mil pela captura do autor e uma denúncia levou a polícia a prender Sven Jaschan, em Rotemburgo, Alemanha

Calcula-se prejuízos de US$ 18 bilhões

Sasser – análise técnica

O worm explora um overflow na função DsRolerUpgradeDownlevelServer()

Após infectar um sistema ele se instala na pasta %windir% com o nome de ‘avserve.exe’ e se adiciona ao registro do Windows

Cria-se um mutex para assegurar que somente uma instância está rodando

Um servidor FTP era aberto na porta 5554 e um shell na porta 9996

AbortSystemShutdown() era chamada Iniciava-se o scanning primeiramente na rede

local e depois em IPs externos

Sasser – Fatores do sucesso

A grande quantidade de usuários de Windows XP com o serviço LSASS ativado

A exposição dos usuários devido a não instalação dos patches

O não-reiniciamento da máquina invadida Pequena janela de tempo entre o lançamento

público da falha e do primeiro exploit

Worms do bem

Nachi worm– O Nachi utilizava-se da mesma vulnerabilidade do

Blaster para assumir controle do sistema e instalar os patches da Microsoft

– Apesar da boa intenção, o worm gerava muito tráfego e conseqüente lentidão na rede

O worm desenvolvido no PARC da Xerox procurava por computadores idle e lhes delegava tarefas, aproveitando, assim, melhor o tempo de CPU

Futuro

Próximas tendências– Worms de web

A web 2.0 e sites dinâmicos abrem portas para novos tipos de ataque, como XSS, CSRF, etc.

O worm SamyWorm para MySpace e GreyGoo para Second Life

– Worms para aparelhos celulares O worm Cabir, para celulares Nokia com Symbian (se

espalha por bluetooth) Buffer overflows em celulares (“Advanced Attacks

Against PocketPC Phones” by Colin Mulliner)

Futuro– Worms para videogames e outros dispositivos

Já foram encontrados e explorados com sucesso buffer overflows no Playstation 2

Agradecimentos

Julio Cesar Fort pelos slides sobre worms

Malware – Vírus, Worms, Bots, Trojan Horses, Rookits…

Julio Auto - jam