Techbiz Forense Digital abre 12 vagas técnicas em 4 cidades

Há 2 anos trabalho como Consultor em Forense Computacional na Techbiz Forense Digital, tem sido uma oportunidade única de crescimento profissional e técnico com a vantagem de atuar em grandes organizações do mercado Privado, de Segurança Pública e Governo .

Tive ontem a ótima notícia ontem que nossa área técnica está crescendo ainda mais, e foram abertas 12 novas vagas assim distribuídas: 4 Consultores em Computação Forense, 4 Analistas de Segurança e 4 Suportes Técnicos - uma posição de cada tipo em cada uma das cidades que possuímos sede (excetuando Floripa): Brasília, São Paulo, Rio de Janeiro e Belo Horizonte.

O desafio é entregar Produtos e Serviços fundamentados pelas mais inovadoras tecnologias de Combate à Incidentes de Segurança, Crimes envolvendo alta tecnologia e Forense Computacional.

Além do laboratório forense e desenvolvimento interno, temos ao nosso lado líderes em tecnologia de Reação a CiberCrimes de vários países (Estados Unidos, França, Israel e Suécia) como NetWitness, AccessData, Guidance Software, ArcSight, Digital Intelligence, Micro-Systemation, WetStone, ICS, Tableau entre outras.

O perfil desejado para cada um dos cargos está descrito abaixo e interessados devem procurar o nosso RH no telefone (31) 3211-1800

I - Consultores em Computação Forense Sênior

A - 2 ou mais das certificações EnCE, GCFA/GIAC, CCE, ACSA e CISSP; e
B - ao menos 4 anos de experiência comprovada em Forense Computacional e/ou Resposta a Incidentes de Segurança **em empresas de grande porte**; e
C - experiência com Encase, FTK, ferramentas de SIEM (correlação de logs) e rede (IDS/IPS/Forense de Rede); e
D - Palestra Técnica e/ou Paper publicado em conferências de renome nacional; e
E - entrevista técnica de 1h necessária com um Consultor Sênior; e
F - entrevista com o RH; e
G - disponibilidade para viagens; e
H - referência de 2 ex-gerentes técnicos para entrevista; e
I- levantamento de antecedentes criminais: "capivara" / certidão negativa justiça

II - Analistas de Segurança da Informação – Para serem formados como consultores em computação forense

A - Uma certificação relacionadas à Segurança da Informação (5 acima ou CCSP, MCSO) outros GIAC SANS Institute); e
B - ao menos 2 anos de experiência comprovada em 1) Forense Computacional e/ou 2) Resposta a Incidentes de Segurança e/ou 3) Segurança da Informação **em empresas de médio ou grande porte**; e
C - disponibilidade para viagens; e
D - entrevista técnica de 30min necessária com um Consultor Sênior; e
E - entrevista com o RH; e
F - referência de 1 ex-gerente técnico para entrevista; e
G- levantamento de antecedentes criminais: "capivara" / certidão negativa justiça

III - Analista de Suporte Técnico - Para serem formados como analistas de suporte em computação forense:

A - curso técnico de montagem de computadores, conhecimento prático com hardwares, suporte, troubleshooting; e
B - experiência de ao menos 1 ano com suporte técnico (SW/HW), montagem de computadores; e

D - disponibilidade para viagens; e
E - entrevista com o RH; e
F- levantamento de antecedentes criminais: "capivara" / certidão negativa justiça

Skypeex - análise de dump de memória - chats do Skype

Já comentamos em algumas oportunidades aqui no blog a importância e o crescente interesse pelo processo de dump e posterior análise de memória RAM em máquinas investigadas em casos de resposta a incidentes e crimes envolvendo alta tecnologia.

Nesta linha, Nick Furneaux lançou na semana passada uma interessante ferramenta em python para busca de comunicações de Instant Messaging feitas com o Skype em dumps de memória.


Me impressionou a quantidade de mensagens antigas (possivelmente vindas do histórico armazenado de até 30 dias do skype) estavam presentes ainda na RAM de dois computadores analisados em meu laboratório...

Passos Necessários:

1) Instalar o Python na máquina de análise;

1) Na máquina alvo, fazer o dump de memória com uma das muitas ferramentas disponíveis:

C:\> win64dd /m 0 /r /f F:\physmem.bin

2) Executar um comando strings (linux ou windows) no dump criado:

c:\> strings physmem.bin > physmem-strings.txt

3) Rodar a ferramenta skypeex.py, e digitar o caminho do arquivo gerado no passo 2.

Pronto.

Mais Detalhes em: http://nickfurneaux.blogspot.com/2010/03/skype-chat-carver-from-ram-skypeex.html

Download: http://csitraining.co.uk/skypex.aspx

O autor da ferramenta recomenda o uso do windd para efetuar o dump de memória - para mais opções veja o primeiro post relacionado abaixo.

Posts relacionados:

• Forense de Memória - Uma comparação de Ferramentas Disponíveis
• Pdgmail: nova ferramenta para Forense de Memória do GMAIL (Out/2008)
• Pdymail - Forense de Memória para o Yahoo Mail (Jan/2009)
• Outros posts sobre análise forense de memória
• Outros posts sobre skype

Cheat Cheets de Segurança - Atalhos para CSIRTs

Eu sou um fã de carteirinha das Cheat Sheets do Lenny Zelster. Elas são um excelente atalho para grupos de Resposta a Incidentes (CSIRT) funcionarem como devem - o mais rapidamente possível.

A última Cheat Sheet que ele publicou juntamente com o Anton Chuvakin, foi sobre "Revisão de Logs para Incidentes de Segurança" (formatos HTML, DOC e PDF) e inclui várias dicas interessantes sobre a fonte, localização e dados em logs de Linux, Windows, equipamentos de Rede, Servidores Web, etc.

Estas tabelas são uma mão na roda para auxiliar um analista de segurança em diversas atividades diárias. Segue a lista de tabelas de referências já publicadas:

• Analyzing Malicious Documents
• Security Architecture for Internet Applications
• Troubleshooting Human Communications (interface humana em engenheiros.. =)
• Security Incident Survey for Server Admins
• Initial Security Incident Questionnaire for Responders
• Network DDoS Incident Response
• Reverse-Engineering Malware
• Information Security Assessment RFP
• How to Suck at Information Security

Existem ainda links para outras interessantes tabelas de referência na internet, com links na página do Zelster:

x86 Intel Assembly, Win32 x86 Assembly, Network Cheat Sheets, SQL Injection Prevention, XSS (Cross Site Scripting) Prevention, TCP/IP and Tcpdump, Google Hacking and Defense, Windows Command Line, Netcat Cheat Sheet, ASP.NET Security Architecture, SSL/TLS Protection Cheat Sheet)

Vale a pena também citar as cheat-sheets do site PacketLife (networking):

Protocols (BGP, EIGRP, First Hop Redundancy, 802.11, 802.1x, IPsec, IPv4 Multicast, IPv6, IS-IS, OSPF, PPP, Spanning Tree)

Applications (tcpdump, WireShark Display Filters)

References (Common Ports, IOS IPv4 Access Lists, IPv4 subnetting)


Technologies (Frame Mode MPLS, NAT, QoS, VLANs, Cisco IOS Versions, Physical Terminations)

Validação de Hardwares e Softwares para Computação Forense

[ Update: 07/03/2010 ]

Para quem

acha que os relatórios de validações de ferramentas forenses disponíveis estão um pouco antigos, existe uma oportunidade única oferecida pelo pessoal do NIST e do NW3C [National White Collar Crime Center (NW3C) ] - eles disponibilizaram este formulário para que a comunidade escolha quais produtos merecem ser revisados pela equipes destes órgãos.

Mais detalhes:

http://blogs.sans.org/computer-forensics/2010/03/04/computer-forensics-tool-testing-cftt-survey/

[ Post Original: 04/02/2010 ]

Dentre os princípios que norteiam a Computação Forense, a VALIDAÇÃO DAS FERRAMENTAS e técnicas utilizadas ocupa sempre um espaço de destaque.

Com o objetivo de facilitar este trabalho seguem algumas referências de validações técnicas (testes de hardwares e softwares) relacionados à Computação Forense publicadas por 3 diferentes entidades:

1) NIST - National Institute of Standards and Technology
2) US Department of Justice
3) Marshall University

Certamente os resultados presentes nos links abaixo podem ser úteis para o avaliar e comparar a qualidade e funcionalidade de diversos produtos, além de apresentar uma interessante visão das das metodologias utilizadas durante os testes.

Observação: Foram omitidos da relação que publicamos os testes realizados há mais de 3 anos - mas a totalidade dos testes pode ser verificada nos links fornecidos abaixo.

I) http://www.cftt.nist.gov/
II) http://www.nist.gov/itl/ssd/computer-forensics.cfm (projeto reiniciado em 2010)
III) http://nij.ncjrs.gov/publications/Pub_Search.asp?category=99&searchtype=basic&location=top&PSID=55


Geração de Imagens de Discos:

• Logicube Forensic Talon Software Version 2.43 (January 2010)
• BlackBag MacQuisition 2.2 (September 2009)
• EnCase 6.5 (September 2009)
  
• EnCase LinEn 6.01 (October 2008)
• EnCase 5.05f (June 2008)
• FTK Imager 2.5.3.14 (June 2008)
• DCCIdd (Version 2.0, June 1 2007) (January 2008)
• EnCase 4.22a (January 2008)
• Encase Linen 5.05f (January 2008)
• IXimager (Version 2.0, Feb-01 2006) (April 2007)

Preparação de Discos (WIPE/Sanitização)

• Darik's Boot and Nuke 1.0.7 (January 2010)
• Voom HardCopy II (Model XLHCPL-2PD Version 1.11) (January 2010)
• WiebeTech Drive eRazer: DRZR-2-VBND & Drive eRazer PRO Bundle (September 2009)

Bloqueadores de Escrita via Software:
ACES Software Write Block Tool Test Report: Writeblocker Windows 2000 V5.02.00 (January 2008)
ACES Software Write Block Tool Test Report: Writeblocker Windows XP V6.10.0 (January 2008)

via Hardware:

T4 Forensic SCSI Bridge (FireWire Interface) (September 2009)
T4 Forensic SCSI Bridge (USB Interface) (September 2009)
Tableau T8 Forensic USB Bridge (FireWire Interface) (August 2008)
Tableau T8 Foresnic USB Bridge (USB Interface) (August 2008)
FastBloc FE (USB Interface) (June 2007)
FastBloc FE (FireWire Interface) (June 2007)
Tableau T5 Forensic IDE Bridge (USB Interface) (June 2007)
Tableau T5 Forensic IDE Bridge (FireWire Interface) (June 2007)
Tableau Forensic SATA Bridge T3u (USB Interface) (January 2007)
Tableau Forensic SATA Bridge T3u (FireWire Interface) (January 2007)
Tableau Forensic IDE Pocket Bridge T14 (FireWire Interface) (January 2007)


Dispositivos Móveis:

• Test Results for Mobile Device Acquisition Tool: BitPim - 1.0.6-official (January 2010)
• Test Results for Mobile Device Acquisition Tool: MOBILedit! Forensics 3.2.0.738 (January 2010)
• Test Results for Mobile Device Acquisition Tool Susteen DataPilot Secure View 1.12.0 (September 2009)
• Test Results for Mobile Device Acquisition Tool: Final Data - Final Mobile Forensics 2.1.0.0313 (September 2009)
• Test Results for Mobile Device Acquisition Tool: Paraben Device Seizure 3.1 (September 2009)
• Test Results for Mobile Device Acquisition Tool: Cellebrite UFED 1.1.05 (September 2009)
• Test Results for Mobile Device Acquisition Tool: Micro Systemation .XRY 3.6 (October 2008)
  
• Test Results for Mobile Device Acquisition Tool: Guidance Software Neutrino 1.4.14 (October 2008)
  
• Test Results for Mobile Device Acquisition Tool: Paraben Device Seizure 2.1 (October 2008)
  
• Test Results for Mobile Device Acquisition Tool: Susteen DataPilot Secure View 1.8.0 (October 2008)

IV) http://forensics.marshall.edu/Digital/Digital-Pubs.html

Hardware Validations:

Validation Testing of Guidance Software’s FastBloc 2 Field Edition (FE)
Validation Testing of Guidance Software’s FastBloc Field Edition (FE)
Validation Testing of FastBloc Laboratory Edition (LE)
Validation Testing of Guidance Software’s FastBloc Software Edition (SE)
Verification of the Functionality of the X-Late HardCopy ATA Hard Drive Data Capture Unit
Sending multiple dd Image Captures to a Single Hard Disk Using Logicube Forensic MD5 Capturing System
Validation Testing of Paraben’s Lockdown
Validation Testing of the Logicube Serial-ATA (SATA) cloning adapter
Functionality Test of the Logicube® Forensic Talon Capturing System
Functionality Test of the UltraBlock™ Forensic Card Reader
Functionality Test of Tableau® UltraBlock™ Forensic USB Bridge Device
Functionality Test of the Logicube® Desktop Write-PROtect Adapter

Software Validations:

Independent Validation and Verification (IV&V) of EnCase Forensic Edition Law Enforcement and Government Edition Version 5 (update v.5.05d)
Independent Validation and Verification (IV&V) of AccessData’s Forensic Toolkit (FTK) Imager v.2.5.1

Criptografia: Ataques RSA 768 e 1024 bits & FRED-SC

[ Update - 07/03/2010 ]

Pesquisadores da Universidade de Michigan divulgaram um ataque bem sucedido (*) a criptografia RSA 1024 bits - para mais detalhes, veja o paper publicado (PDF).

"The RSA algorithm gives security under the assumption that as long as the private key is private, you can't break in unless you guess it. We've shown that that's not true," said Valeria Bertacco, an associate

professor in the Department of Electrical Engineering and Computer Science, in a statement.

Uma bom resumo: http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/

Since 1977, RSA public-key encryption has protected privacy and verified authenticity when using computers, gadgets and web browsers around the globe, with only the most brutish of brute force efforts (and 1,500 years of processing time) felling its 768-bit variety earlier this year. Now, three eggheads (or Wolverines, as it were) at the University of Michigan claim they can break it simply by tweaking a device's power supply. By fluctuating the voltage to the CPU such that it generated a single hardware error per clock cycle, they found that they could cause the server to flip single bits of the private key at a time, allowing them to slowly piece together the password. With a small cluster of 81 Pentium 4 chips and 104 hours of processing time, they were able to successfully hack 1024-bit encryption in OpenSSL on a SPARC-based system, without damaging the computer, leaving a single trace or ending human life as we know it. That's why they're presenting a paper at the Design, Automation and Test conference this week in Europe, and that's why -- until RSA hopefully fixes the flaw -- you should keep a close eye on your server room's power supply.

Outros detalhes: http://rdist.root.org/2010/03/08/attacking-rsa-exponentiation-with-fault-injection/

(*) For whatever reason, the OpenSSL programmers decided to retry with fixed-window exponentiation and trust that since there were no published fault attacks for it, they didn’t have to validate its result (...) This was a nice attack but nothing earth-shattering. The only thing I was floored by (yet again), was the willingness of crypto implementers to perform unsafe operations in the face of an almost certain attack. Shame on OpenSSL.

A RSA demorou, mas respondeu de forma quase realista =) :

(...) Bottom line, FBARA does not report an attack against the RSA algorithm. It describes a hardware-based attack. This essentially induces computational faults by manipulating the power supply on the target device. The resulting faulty output means that it is possible to extract a private RSA key.

The real-world applications of this are limited since it requires physical access to a device operating OpenSSL (or at least to its power supply). Since OpenSSL typically executes on a server (and not something like a smartcard or a light device or consumer device), the attacker would probably have to overcome significant physical obstacles to get to the target. (...)

Para informações em português, leia: http://www.crkportugal.net/?p=892

[ Post Original - 08/01/2010 ]

1) Fatoracao RSA 768 bits

A vasta maioria da criptografia utilizada hoje depende de números enormes (algo maior de 200 dígitos) que sejam resultado do produto de outros dois números primos. É possível criptografar e descriptografar dados a partir do conhecimento dos números. E - se você não os sabe e precisará fazer um ataque de força bruta, é bom que você tenha tempo livre, muitos computadores a disposição e muita paciência e conheça muita gente como você (espere... esta parece ser a perfeita descrição da condição de pesquisadores acadêmicos! =).

Pois então, em um paper (pdf) divulgado a apenas algumas horas atrás, um grupo de pesquisadores anunciou a fatoração de um módulo 768 bit RSA em 12 de dezembro de 2009 e aproveitaram para recomendar que se deixe de usar criptografia RSA 1024 bits dentro dos próximos 3 anos. O paper é leve e tem até link para o Youtube usando o filme Bastardos Inglórios do Tarantino para a hora do "Bingo".

Bem, na verdade é leve até um momento, quando você possivelmente vai dar alguns page-downs por não querer sobrecarregar seus neurônios tentanto compreender as descrições teóricas das fórmulas matemáticas utilizadas durante o processo =)

Mas, o que isto significa, afinal? Bem, não é fácil para um humano imaginar um número de 232 dígitos. Para ajudar, segue o número:

12301866845301177551304949583849627207728535695953347921973224521517264
00507263657518745202199786469389956474942774063845925192557326303453731
54826850791702612214291346167042921431160222124047927473779408066535141
9597459856902143413

e os fatores (multiplicadores primos) encontrados:

33478071698956898786044169848212690817704794983713768568912431388982883793878002287614711652531743087737814467999489 

X 

36746043666799590428244633799627952632279158164343087642676032283815739666511279233373417143396810270092798736308917

Este número de 232 dígitos não foi escolhido a esmo, ele estava em uma lista de desafios da RSA já desativada.

O que acontence é que a com o tempo a dificuldade de quebra é reduzida com o aumento exponencial de velocidade dos processadores. (Moore´s Law). E pode ser ainda mais rápida com as novidades da utilização dos processadores gráficos (GPU), ou computação CUDA e/ou outros multiplos aceleradores gráficos integrados (ou 200 video-grames PS3, como no caso da colisão de hashes MD5 usados em certificados SSL que comentamos aqui há exatamente um ano atrás).

Para informações old-school - vá direto ao MIT do ano de 1978, quando Rivest, Shamir e Adleman - futuros RSA- publicaram o célebre documento "A Method For Obtaining Digital Signatures And Public Key Cryptosystems" (pdf).


2) FRED-SC

Aproveitando o assunto criptografia, e sendo muito comum em análises forenses nos depararmos com documentos criptografados, vale a notícia de um fabricante de hardware especializado para forense computacional que anunciou há poucos dias que está comercializando servidores com múltipas GPUs gráficas prontos para o trabalho de quebra especializada de senhas.

Trata-se da Digital Intelligence, que já fornece o sistema Fred-SC, que vem com quatro placas de vídeo NVIDIA GTX-295 customizadas para funcionar em paralelo (cada placa tem dois GPUs em um total de 1920 processadores!)

Isto possibilita uma velocidade de processamento MONSTRUOSO obviamente para aplicações especialmente construídas para este fim. Por exemplo, este sistema já vem embarcado com a ferramenta da empresa russa Elcomsoft chamado "Distributed Password Recovery (EDPR)" - e a licença permite que este sistema pode ser utilizado em até 20 servidores FRED-SC em paralelo.

Além de possibilitar uma maior eficiência em ataques de força bruta e dicionário, este poder computacional todo conseguir calcular rainbow tables para gerar hashes pré-calculados de forma rapidíssima.

Para deixar bem claro o tamanho da evolução (e também para entender porque dizem que o processamento com múltiplos GPUs explodiu com a lei de Moore), dê uma olhada nos gráficos comparativos de quebra de senha de arquivos do Office 2007, Vista e Win7 (NTLM) e Unix (MD5) em um sistema versus o "Fred-SC" da Digital Intelligence.

Exemplos:

Senhas do Vista (NTLM): CPU Quad-Core stand-alone: 177 mil senhas por segundo.
Senhas do Vista (NTLM): FRED-SC stand-alone: 3.9 bilhões de senhas por segundo.

Senhas do Linux (MD5): CPU Quad-Core stand-alone: 219 mil senhas por segundo.
Senhas do Linux (MD5): FRED-SC stand-alone: 5.3 bilhões de senhas por segundo.

Seguem os tipos de aplicações que são os "alvos-ideais" para trabalhos de quebra de senha com o FRED-SC + EDPR (todos otimizados / acelerados para GPU):

- Microsoft Word/Excel/PowerPoint/Project 2007 (.DOCX, .XLSX, .PPTX, .MSPX)

- PGP disks with conventional encryption (.PGD), whole disk encryption.

- Windows NT/2000/XP/2003/Vista logon passwords (LM/NTLM)

- Windows DCC (Domain Cached Credentials) passwords (password recovery).

- MD5 hashes (plaintext recovery).

- WPA and WPA2 passwords (password recovery).

[ Update - 31/12/2010 ]

Na BlackHat 2010 será apresentado um server capaz de processar "280 DES decryptions per second! permitting the full 56-bit key space to be searched in 3 days" Mais informações aqui.

Tendência: sites invadidos por hackers (Vivo/Oi/IG/Veja) utilizados como veiculo em Fraude de Phishing

[ Update - 04/03/2010 ]

A repetição é tão frequente que infelizmente podemos chamar isto de tendência: mais uma vez um domínio brasileiro (abril.com.br) foi afetado (Revistas Veja, Super, etc) e outra vez houve a utilização de Drive By Download (neste caso usando o Flash Player como vetor) para ataques em massa à visitantes. Como pode ser visto nos updates sobre o assunto abaixo, vários grandes portais no Brasil já foram afetados.

O incidente mais recente (Grupo Abril) foi reportado via twitter por @jbonagura, @spookerlabs, @nbrito e @jespinhara e pode ser visto na captura acima.


[ Update - 15/10/2009 ]

O site LinhaDefensiva informa que o discador do IG foi substituído por uma versão que continha um trojan bancário. Os atacantes utilizaram um joiner (aplicativo que concatena dois executáveis em um só). Desta forma os internautas que baixaram o discador de alguns dias até ás 10h30 de ontem acabaram executando também o malware que possui uma baixíssima taxa de identificação entre os anti-vírus.

O post ainda cita outros sites que foram utilizados recentemetnte para infecção em massa usuários, como o Baixaki e o site da Ambev e do São Paulo F.C.

Mais detalhes sobre este ataque na análise do LinhaDefensiva.

[ Update 30/09/2009 ]

Para mais informações sobre como applets java maliciosos estão sendo utilizados em ataques a internautas brasileiros, veja o excelente artigo "Como funcionam as infecções por applets Java", publicado no site Linha Defensiva.



[ Update - 22/09/2009 ]

O Info/Abril informa que um site da operadora Oi, chamado "mundo oi" também foi utilizado no dia de hoje (22/09/2009) como veículo de infecção de trojan bancário através de um falso applet java (o mesmo modus operandi do ocorrido no ataque da Vivo) - vale ressaltar que este tipo de abordagem não é nova e por exemplo já havia ocorrido em 2008 (segundo o IDG/Now) e em 2007 (segundo o site Linha Defensiva) em sites da operadora.

Mais informações sobre este tipo de ataque (Drive-By Infection) no Post original abaixo.

[ Post Original - 09/09/2009 ]

Segundo informações da Folha de São Paulo (http://www1.folha.uol.com.br/folha/informatica/ult124u621523.shtml), (ao menos) um servidor do pool de balanceamento de carga do portal web da operadora de celular VIVO foi invadido.

A empresa Vivo se pronunciou oficialmente sobre o assunto:

"Comunicado à Imprensa

Um dos servidores de acesso de usuários ao Portal da Vivo na Internet foi vítima de um ataque de hackers nesta terça-feira, dia 08 de setembro. A partir da detecção do ataque, as equipes de segurança da informação da Vivo entraram em ação e solucionaram o problema às 00h50 desta quarta-feira.

A Vivo informa que os usuários que clicaram numa falsa janela de “warning security” para execução de arquivo, é que podem ter tido o seu computador infectado. Portanto, a recomendação da Empresa é que usuários que tenham acessado o portal www.vivo.com.br no período de 16h07 de 08.09.2009 até às 00h50 de 09.09.2009, e que tenham executado o falso arquivo, evitem acessar sites de bancos até que façam uma verificação de segurança em seu computador.

A Vivo informa que os serviços disponíveis no seu portal não foram afetados e continuam disponíveis e seguros aos seus clientes."

Internautas que tenham acessado o portal Vivo (www.vivo.com.br) entre 16h de ontem e 0h50 de hoje podem ter sido infectados por um código java que alterava o arquivo local de resolução de nomes (hosts) de suas máquinas - direcionando-os (antes mesmo da resolução via DNS) para clones de sites de internet banking de instituições financeiras brasileiras (Bradesco, Itaú, Santander e Nossa Caixa) .

Vale ressaltar que a seguinte mensagem era exibida para confirmação de execução do código java malicioso: "Vivo Online - IMPORTANTE: (Para executar corretamente o Vivo Online clique em Run". Caso você tenha acessado o site nos últimos dias - especialmente se clicou na mensagem do applet java malicioso, deve evitar entrar em sites de internet banking até se certificar que não foi afetados pelo ataque - veha abaixo como fazê-lo.

Recomendação: para ter certeza que você não foi afetado, abra com o notepad do windows o arquivo "c:\windows\system32\drivers\etc\hosts" - você não deve ver nenhuma linha não comentada (sem um "#" na frente) além do endereço de localhost ipv4 e ipv6 (127.0.01 e ::1) . Caso existam linhas contendo sites bancários como www.bradesco.com.br e www.itau.com.br - má notícia, você foi um um dos cerca de 100 mil usuários atingidos pelo ataque.

Do ponto de vista dos fraudadores, esta abordagem é mais arriscada e ao mesmo tempo mais efetiva para a distribuição de códigos maliciosos, pois ao contrário de utilizar a tradicional engenharia social via spam, os fraudadores neste caso invadiram um site muito utilizado e prepararam um ataque a seus visitantes conhecido como "Drive By Infection".

O uso de Drive By Infection é mais arriscado pois:

• chama mais atenção, deixa mais vestígios (1 - logs de segurança da operadora, 2 - logs de roteadores, 3 - logs do servidor web, 4 - o código java utilizado para alterar o arquivo hosts aponta para outros sites comprometidos (como o da USP) com mais vestígios...
• permite um bloqueio mais fácil dos IPs dos falsos sites bancários por parte das operadoras de Backbone (depende apenas da velocidade na comunicação entre as equipes de resposta a incidentes envolvidas)
  

E ao mesmo tempo mais efetivo do ponto de vista do atacante, pois:

• Pelo alto número de acessos de sites como os da Vivo/Oi/IG/Veja, o grau de sucesso do ataque é alta - a contagem de acessos ao código malicioso colocado no site da Vivo ultrapassou os 100.000 (cem mil) acessos.
• a sensação de segurança do usuário durante a navegação em sites legítimos diminui a atenção em relação à possíveis ataques.
  

Para obter sucesso neste ataque os fraudadores se aproveitaram de dois descuidos muito comuns:

• Problemas de segurança no desenvolvimento PHP do site da Vivo (Local File Inclusion - LFI) - Recomendações: Validação de Input e Metodologia de Desenvolvimento Seguro
  

• Desatualização (falta de patches) do Java em máquinas dos usuários que acessam o site - Recomendações: além de manter seu windows atualizado, cuide da atualização de outros aplicativos, com o PSI da Secunia, por exemplo. Observação: apesar de algumas informações divulgadas, o uso de anti-vírus tradicionais não traz segurança neste caso - como pode ser visto na análise do Virustotal dos dois arquivos java utilizados no ataque : logo_top.jpg e laa.class. (nenhum AV detectou os malwares).

Curiosamente, também por uma falha de desenvolvimento dos fraudadores, o ataque foi descoberto por um usuário de Linux - Miguel de Curcio Filho, que informa em seu blog que estranhou entradas com caminho do arquivo hosts de máquinas windows em seu diretório home de uma máquina Linux!

Caso você tenha acessado o site da Vivo recentemente, insisto em recomendar que você verifique que o arquivo "c:\windows\system32\drivers\etc\hosts" não possua entradas extras apontando para sites bancários.

Recomendações: via prompt de comando (execute o cmd.exe como usuário administrador), configure o arquivo hosts como somente leitura, dificultando sua alteração por parte de ataques como este:

C:\WINDOWS\System32\drivers\etc> attrib +R hosts

Além disto, conheça as 10 Dicas de como manter o seu Desktop Seguro.

Mais detalhes técnicos nos links abaixo:

• Filipe Balestra - http://www.linuxnewmedia.com.br/blogs/seguranca/analise_vivo/

• Rafael Santos - http://rafaelsantos.com/2009/09/09/falhas-grotescas-no-portal-da-vivo-insegurana-total/

• SecuriTeam - http://blogs.securiteam.com/index.php/archives/1319

• Marcio Avila - http://blog.mhavila.com.br/2009/09/09/portal-da-vivo-comprometido-prolifera-fraude
  

Outras notícias relacionadas:

• INFO Abril
• Bandeirantes
• O DIA
• IDG NOW
• WNews UOL
  
• O Globo

Simulação de CyberWar Norte Americana e Hitler vs Segurança da Nuvem

Neste rápido post vou sugerir dois vídeos interessantes sobre a Resposta Governamental à Ataques Digitais. Pegue sua pipoca e boa sessão...

1) Primeiro Vídeo (9 partes, 1h30m):

Cyber ShockWave da CNN:

http://www.youtube.com/watch?v=tfv5JASJxbA

Simulações de Guerra são comuns entre os integrantes das Forças Armadas. No caso do vídeo indicado abaixo, a rede americana CNN apresentou um exercício para testar a capacidade de resposta do governo à ataques coordenados de CyberWar.

O cenário foi criticado por muitos especialistas, mas tem seu valor para visualizarmos o tipo de discussões e até mesmo desinformação entre o mais alto escalão do pseudo-governo em um momento de crise. Foi muito válida a experiência - se não considerarmos os detalhes técnicos e sim as discussões e decisões tomadas.

Vale ressaltar que apesar de ser um exercício, foram aproveitados vários tópicos reais já tratados aqui como ataques à smartphones, à linhas de tranmissão de energia e impacto no setor financeiro, entre outros. Além disto, os participantes são ex-integrantes do governo americano acostumados a este tipo de simulação.

Uma consideração paralela: normalmente os atacantes se infiltram e roubam informações estratégicas dos alvos de forma stealth - como no caso real da Operação Aurora China vs Google + 100 (que foi na minha opinião o Perl Harbor / 11 de Setembro da CyberWar).

Mas quando imaginamos um cenário de guerra tradicional em conjunto com ações de CyberWar, o estardalhaço apresentado faz muito sentido. De qualquer forma um bom FUD funciona melhor com mais barulho =)

Como notícia real, os Estados Unidos acabaram de de-classificar parte do seu plano de CyberSegurança - leia-o e baixe o PDF aqui.

Aproveitando o assunto, seguem outros artigos sobre CyberWar:

• Espionagem industrial China x Tibet
• Apagão e Hackers: Aconteceu ou é Possível?
• Cyberwar: Rússia x Estônia: a confirmação
• China vs Google - Operação Aurora
• Guerra cibernética: um apanhado sobre o tema (Emerson Wendt)

2) Segundo Vídeo (4m27s ):

Hitler and Cloud Security:

http://www.youtube.com/watch?v=VjfaCoA2sQk

Para descontrair, segue também um link para (mais) uma redublagem feita em cima da cena do filme DownFall (por Marcus Ranum and Gunnar Peterson). Acompanhe o desenrolar da Resposta a um Incidente seríssimo na cúpula do Terceiro Reich, quando é descoberta uma invasão de alta criticidade em um provedor de "Cloud Computing" - utilizado pela Alemanha. Hitler não ficou muito feliz...

Talvez esta tenha sido a melhor piada feita com o assunto Segurança da Informação que eu já vi (alguém sugere outras?) - barrando inclusive as impagáveis tirinhas do Dilbert.

Depois de parar de rir e antes de começar a achar que a história não tem um pé na realidade, veja este artigo sobre a crescente e preocupante dependência governamental (ex: 60% dos estados americanos) em soluções "na nuvem" como o Google Apps.