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

(In)Segurança em Desenvolvimento de Software e o modelo BSIMM

[ Update: 29/09/2010 ]

O Fabrício Braz divulgou sua tradução para o português do BSSIM:

http://softwareseguro.blogspot.com/2010/09/build-security-in-manturity-model-em.html

[ Post Original: 14/03/2009 ]

O Marcelo Souza fez um post muito interessante sobre segurança em desenvolvimento e o modelo BSIMM, publicado por Gary McGraw, Brian Chess e Sammy Migues.

"O BSIMM (Building Security In - Maturity Model), um modelo de maturidade focado em segurança de software. O modelo foi elaborado com base em iniciativas de segurança de 9 empresas diferentes, entre elas Adobe, EMC, Google e Microsoft. Utilizando um arcabouço de sua autoria denominado SSF (Software Security Framework), que aponta domínios e práticas comuns das iniciativas em segurança de software, o grupo conduziu pesquisas nas empresas participantes e utilizou os dados obtidos para construção do modelo.

O modelo lista 110 atividades divididas em 12 práticas dos 4 domínios do SSF. Cada prática pode receber até o nível 3 de maturidade. Totalmente livre (licença Creative Commons), o modelo pode ser obtido neste link (requer registro), ou acessado interativamente aqui."

Normalmente estes modelos são muito teóricos, mas o BSIMM me pareceu suficientemente específico e mais próximo da realidade. Me lembrou em certos aspectos os guias do NIST e do CERT, - cuidado você pode desanimar quando ler o primeiro ítem da lista: "Apoio da Alta Administração"...

O BSIMM é um esforço de organização e categorização de um problema complicadíssimo que é o desafio em desenvolver, manter, comprar, integrar e utilizar softwares de forma segura. Isto é tão difícil que é necessário todo interesse, apoio, priorização e investimento para que uma empresa alcançe um nível real razoável em qualquer das 12 práticas dos 4 domínios do Software Security Framework (Governança, Inteligência, Ciclo de Desenvolvimento e Implementação). Para uma empresa grande e com processos viciados é quase como um idoso aprender a falar outra língua fluentemente - pode demorar décadas (que ele não viverá).

Segundo o BSSIM, uma medição máxima de "maturidade" do modelo seria 12*4*3 = 144. O perigo é que as pessoas tenderão a se basear nesta medida para considerar mais seguro um projeto/software/empresa que alcance uma pontuação alta em um assessment do BSSIM.

Isto funciona até o próximo deslize mínimo de uma destas empresas envolvidas que estão implementando o modelo e todos os esforços, conquista de "compliance" e melhores práticas ou "nível de maturidade" vão embora. Alguns exemplos: SDL Microsoft, ex-PCI da Heartland (obtido em Abril e revogado ontem), ou a metodologia de outros participantes do BSSIM - Adobe por exemplo - que deixou o Reader PDF sem correção crítica por 15 dias...

Isto nos mostra quão longe realmente estamos de uma melhora significativa, e quanto este esforço - apesar de louvável - tem como maior mérito a conscientização dos próprios responsáveis e envolvidos pela segurança do desenvolvimento de softwares, e talvez uma falsa sensação de segurança para quem tem o "seu" na reta (CSO, CIO, C[A-Z]O), que ficarão felizes com uma pontuação alta no BSSIM.

Se compararmos este cenário com a facilidade que um atacante - bem preparado, com tempo e alvo fixo em mente - consegue explorar falhas de design, implementação, configuração e/ou programação de um destes controles, entendemos o porque do uso do termo "guerra assimétrica" para descrever ataques perpetrados por hackers.

Parafraseando o Kevin Mitnick: Uma empresa precisa conhecer, encontrar e corrigir todos os erros de segurança (e ainda detectar, encontrar e tentar prender o atacante) , um hacker só precisa encontrar e explorar uma falha. Ou seja, do ponto de vista do atacante, 143 = 0.

E pra piorar, já que a "Alta Administração" não vai apoiar por falta de interesse, investimento, compreensão e prioridade, enquanto você não consegue se esmerar nas 110 atividades listadas, se prepare para continuar a responder a muitos incidentes de segurança e esteja com sua equipe de computação forense sempre a postos e bem treinada... =)