IDG NOW publica os maiores problemas de 2007. Quase sem Novidades!

O IDG Now publicou em seu site ontem a lista dos maiores problemas, ou dores de cabeça como diz a publicação. A sensação é de ouvir mais do mesmo. Cavalos de tróia, spams, vulnerabilidades de software, botnets e outras ameaças conhecidas. Empresas continuaram a perder dados de clientes, algumas de maneira estúpida, como o órgão britânico que enviou um disco rígido não criptografado por correio... e que não chegou. O que há de mais novo mesmo é a constatação, geral, que a época dos pichadores acabou. Estamos na época do crime propriamente dito, e todo mundo quer levar una vantagenzinha; e a do novo ambiente da guerra do crime digital: a Web 2.0. O que também não deixa de algo a esperado. O crime irá sempre atacar onde o dinheiro e o usuário estão.

Essa repetição de problemas, e falta de grandes novidades, é o que mais chama a atenção. Sai ano, entra ano, continuamos a conviver com os problemas antigos, que vão se acumulando aos novos. O ótimo levantamento do IDG está em http://idgnow.uol.com.br/seguranca/2007/12/19/idgnoticia.2007-12-19.0309666683/

Maturidade

Na semana passada o forum web da F-Secure, empresa européia de segurança, foi pichado por um grupo da Turquia com nome engraçado: Turkish Nationalist and Republican Hacker Group.

E qual foi a reação da F-Secure? Quem pensou em "tirou o site do ar e inventou uma desculpa" está errado. A empresa postou a notícia do próprio defacement em seu próprio weblog (http://www.f-secure.com/weblog/archives/00001336.html), e comentou abertamente o que aconteceu. O grupo invadiu o forum por um falha no software utilizado. Como a própria empresa comenta, o fato é embaraçoso por se tratar de uma empresa de segurança, mas que poderia acontecer com qualquer um. O fato não quer dizer muita coisa, mas é louvável a atitude da F-Secure, um claro sinal de maturidade.

Abaixo segue o screenshot da página pichada. Valeu pelo logo do grupo!

Qual a diferença entre um projeto bem e mal sucedido?

Podemos dizer que hoje o tema da segurança alcançou um bom nível de maturidade. Empresas (a até mesmo pequenos usuários) entendem os riscos da Internet e que não podem utilizar a rede sem algum plano de segurança. Passar do entendimento para uma proteção eficiente é outro problema, e ainda um grande desafio. Mesmo empresas de porte e bem estruturadas fracassam em implementar seus planos de segurança.

Essa é uma discussão antiga e ainda comum, e existe para quase todas as aplicações de informática. Por que projetos fracassam enquanto outros, usando as mesmas tecnologias, são bem sucedidos? Revisando os projetos de segurança que acompanhei pude elaborar uma pequena lista, com a pretensão de ajudar empresas de diferentes tamanhos e desejando implementar distintas tecnologias. Estou partindo do pressuposto que a tecnologia e produtos escolhidos não só funcionam (é incrivel dizer isso mas há produtos a venda no mercado que simplesmente não funcionam ou praticamente não fazem o que prometem) como atendem aos requerimentos para a solução dos problemas que originaram a compra.

A equipe: o começo de tudo
O ponto de partida é obviamente a equipe que irá instalar o produto. Do gerente de projeto aos técnicos de instalação, passando pelos patrocinadores do projeto. Um projeto de segurança, seja a instalação de um personal firewall ou de um sistema de gestão de identidades, sempre irá mexer com pessoas, com áreas e suas práticas e ações políticas. A equipe como um todo precisa estar ciente e sensível a esse fato, e o gerente de projeto precisa ser uma pessoa equilibrada e experiente em relações pessoais. Não seria preciso dizer mas os técnicos precisam dominar as tecnologias/produtos que serão instalados. Produto de segurança não é aplicativo que se instala “apertando next”.

Não se esqueça dele, o usuário
O segundo passo é obter o comprometimento e confiança (ou no mínimo a aceitação) de todas as áreas que serão afetadas pela implantação. Todas mesmo, sem exceção. Áreas de negócio, de suporte ao usuário, gerências diversas, etc. Dá um trabalhão enorme mas reduz em mais da metade as possíveis turbulências. Quanto maior a empresa mais necessária se torna essa atividade. É nessa hora que eventuais oposições serão resolvidas.
Há alguns anos fiz um curso muito interessante, destinado a implementadores de produtos, chamado de “Gerenciando Expectativas dos Clientes”. Como o nome já explica, o curso ensinava sobre como trabalhar com as expectativas daqueles que irão trabalhar ou serão afetados pelo produto instalado. Se o cliente final espera A e lhe damos B, haverá alguma insatisfação. Logo temos que identificar o que o cliente espera, dissipar seus receios, solucionar dúvidas, passar-lhe confiança e avisar o antes possível que algo irá dar errado.
Se for o caso, o usuário precisa ser treinado antes que o produto seja instalado em sua área ou computador. Se for apenas um caso de informá-lo uma apresentação via rede dá conta do recado. Se algum produto for instalado nos computadores pessoais a área de suporte ao usuário precisa também ser treinada.

Testes, testes, testes
Enquanto se trabalha na parte humana e política os especialistas de produto devem trabalhar na revisão do projeto (ou na criação de um caso não este tenha sido feito antes). Todos sabemos que algumas vezes o tempo entre a confecção inicial do projeto e o inicio de instalação dá meses. Esse projeto precisa ser validado em um piloto que tente reproduzir o ambiente em pequena escala. Um bom piloto poderá identificar muitos problemas ou desvios, mais uma vez reduzindo turbulências futuras.

Instalação
O momento ideal para começar a instalação propriamente dita é quando todos souberem o que irá acontecer, inclusive os técnicos. Em um dos projetos que acompanhei, para instalação de personal firewall em milhares de computadores, as fases anteriores foram tão bem realizadas que a instalação ocorreu via software de distribuição com uma porcentagem de problemas desprezíveis. Como a instalação ocorre de maneira planejada e previsível, e portanto com menos incidentes, a agilidade da fase compensa o tempo gasto nas fases anteriores, e com o cliente muito mais satisfeito.

Quem vai gerenciar esse negócio?
Mais eis que mesmo projetos bem planejados fracassaram? O que deu errado? Na verdade nada deu errado, apenas esqueceram do gerenciamento do produto já instalado. Um erro freqüente é iniciar a fase de gerenciamento depois do término da instalação. Este erro se agrava quando o projeto é grande e demanda meses, o que faz com que os produtos instalados no inicio do projeto cheguem ao inicio do gerenciamento possivelmente exigindo uma nova instalação ou com problemas acumulados.

A fase de gerenciamento, portanto, é paralela a de instalação. O inicio do gerenciamento de um produto começa no final de sua instalação, seja qual for o produto, seja para redes, servidores ou computadores. O que está implicado nessa afirmação? Que a equipe de gerenciamento deve fazer parte do projeto desde o seu inicio, e que a infra-estrutura de gerenciamento deve estar funcionando, pronta, antes que se instale o primeiro produto do projeto.

Já vi projetos em que a infraestrutura de gerenciamento foi instalada na fase de piloto, que contribuiu para os ajustes finos no gerenciamento. Mas pode também ser a primeira etapa da fase de instalação. O mais importante é que no momento seguinte à instalação, o produto (software ou hardware) comece a ser gerenciado. Outro efeito importante é que a equipe de gerenciamento fica responsável por resolver problemas em produtos instalados enquanto a equipe de instalação continua a fazer o que deve fazer: instalar. Usar os instaladores para resolver problemas é problema na certa.

Cadê a documentação?
Por fim vem a documentação, que não por acaso é sempre deixada para o fim: ninguém gosta de fazê-la. Diagramas de instalação, cópias de configuração dos diversos sistemas envolvidos, etc e etc são uma dor de cabeça para todos. A equipe de instalação não se entende com a equipe de gerência, o usuário final reclama que “nada está documentado” e por aí temos o projeto morrendo na praia. Mas a documentação tem uma função importante: descrever o que foi instalado e como foi instalado, tornando o projeto impessoal. Todo projeto deveria ser impessoal mas isso nem sempre ocorre.A documentação deve começar a ser gerada desde o inicio, na fase de piloto. Os instaladores deveriam já ter uma documentação guiando-os durante o processo de instalação, para que não necessitem decidir nada durante a instalação. As decisões devem ser tomadas antes do início da instalação propriamente dita. Os instaladores devem apenas seguir um guia que contenha todas as respostas para suas eventuais perguntas (que idealmente serão listadas nos pilotos).

Novo Formato, Velhos Problemas

Os especialistas em golpes continuam tentando enganar suas vítimas com velhos golpes atualizados com novos formatos e novos apelos. É o caso do spam enviado convidando a vítima para assistir a um vídeo no YouTube. O resto é o de sempre: a pessoa clica no link do vídeo, que na verdade está hospedado em outro site e não no YouTube, aí aparece uma mensagem dizendo que o vídeo exige um player ou codec ainda não instalado (ou o Flash Player), o usuário aceita e baixa um trojan horse que irá se instalar e provavelmente assumir o controle do computador ou qualquer outra ação mal intencionada.

Há um variante para enganar usuários mais atentos: o vídeo realmente está no YouTube e é real. O golpe é que o vídeo faz propaganda para algum site - em um caso o site era um cassino virtual - que invade a máquina do usuário quando visitado.

RFID é Seguro?

Uma das tendências apontadas para 2008 é o aumento de ocorrências de segurança nos sistemas de identificação por rádio-frequência ou RFID. Analistas já falam de vulnerabilidades nos sistemas de RFID há anos, mas só agora esse problema está chamando atenção, por certo acompanhando o crescimento das implementações de soluções nele baseadas.

Quais as ameaças associadas com sistemas RFID? Se os órgãos de trânsito realmente implementarem controle de veículos por RFID qual ameaças que os condutores estarão sujeitos –além é claro dos criminosos de plantão nas esquinas e sinais de trânsito? Quais as ameaças que uma empresa está sujeita quando controla estoque e logística por RFID? O assunto é extenso, como sempre é em segurança digital.

O primeiro erro de segurança em RFID é pensar que as vulnerabilidades são menores apenas porque o sistema é baseado em hardware (microchips). Como qualquer outro dispositivo de informática os microchips usados também podem ser tão vulneráveis quanto um software. Um fator de preocupação é que a indústria, na busca de chips mais baratos está simplificando-os, o que em conseqüência reduz suas funcionalidades de segurança. Os chips em geral são passíveis de infecção por códigos maliciosos com objetivos diversos, incluindo a invasão do servidor de banco de dados. O invasor para isso teria que possuir um rádio capaz de conectar-se aos chips, o que não é nada complicado de obter. Inclusive um especialista mostrou na RSA Conference que é possível invadir um chip de RFID usando um telefone celular dotado de rádio. Um microchip infectado poderia derrubar sistemas de controle de estoques em indústrias ou em supermercados. Nos Estados Unidos alguns aeroportos utilizam RFID para controle de bagagens ou cargas.

Outro problema é o de espionagem. O microchip pode ser lido por sistemas de rádio intrusos, que podem inclusive estar fora da empresa. Embora irrelevante para a maior parte das pessoas comuns, essa técnica pode ser usada como método eficiente de espionagem industrial.

Outra ameaça interessa diretamente aos usuários: privacidade. Não só os chips podem ser lidos por sistemas intrusos, como os bancos de dados com milhões de informações sobre os portadores de chips – gerando informações valiosíssimas para uso indevido. Imagine o banco de dados do Detran de sua cidade com todo o mapeamento do percurso utilizado por você diariamente.

Mais uma vez a diferença se dá na implementar. Implementar um sistema de RFID sem pensar em segurança desde o início é garantia de dores de cabeça e custos maiore depois, como em qualquer outro sistema de TI.

Mobile Security

Já é lugar comum dizer que telefones celulares são cada vez menos telefones e cada vez mais computadores de mão. Computadores de mão significam transações e negócios, muito além do WAP. Transações e negócios para criminosos digitais significam oportunidade de ganhos, além de dispositivos pouco protegidos. Além dos telefones de nova geração (smartphones) e PDAs, os laptops continuam a ser um ponto de preocupação.

Todos os três tipos de dispositivos já trazem embutidos bluetooth e/ou wi-fi. No caso dos smartphones já temos três sistemas operacionais usados largamente: Symbian, Windows Mobile e PalmOS, com vantagens para os dois primeiros. Padronização facilita muita o trabalho de hackers, que passam a se concentrar no sistema operacional e não em determinada marca. A maior parte dos novos dispositivos também trazem wi-fi e muitos aplicativos irresistíveis, como o Skype e outros clientes VoIP. Isso faria uma pessoa em viagem conectar-se por wi-fi para uma ligação mais barata ao invés de usar a rede de telefonia. Hot spots gratuitos também são a opção número um para conectar-se à Internet ou usar aplicativos como o Google Maps. Como resultado temos mais pessoas conectadas por wi-fi a partir de seus smart-phones ou PDAs. Fones de ouvido, conexão em carros e outros fazem com que muitas pessoas mantenham sua conexão bluetooth sempre ativa, embora nem sempre bem configurada.

Segurança da Web 2.0 - Como Proteger

No último post discuti sobre as vulnerabilidades e riscos na Web 2.0. Para lembrarmos do assunto, o termo “web 2.0” foi criado há cerca de quatro anos por Tim O’Reilly, no que ele chama de revolução na indústria da computação pelo movimento para a Internet como plataforma. Como vimos, os riscos da web 2.0 são inerentes à própria plataforma, caracterizada pela independência das aplicações em relação ao sistema operacional, pelo fato das aplicações serem criadas para executar sobre uma nova camada (WebOS) baseada no browser Internet e pelo usuário executar uma aplicação que “está” na Internet e não em seu computador. Para possibilitar a web 2.0 uma série de tecnologias e protocolos foram criados ou agrupados, como o AJAX, CSS, RSS/Atom, XACML e SOAP. O artigo “Top 10 Web 2.0 Attack Vectors”, disponível em http://www.net-security.org/article.php?id=949&p=1 é uma boa referência sobre os principais problemas.

Nesse post irei abordar a pergunta que vem imediatamente depois: como proteger uma aplicação criada em web 2.0 e como proteger-se de um eventual ataque via uma aplicação em web 2.0. Infelizmente não há uma resposta clara e fácil para isso. Como qualquer outra nova aplicação, os riscos, vulnerabilidades e meios de proteção não estão claros. Não há ainda um pacote definitivo de proteção para a web 2.0 e suas tecnologias, embora muitos dos problemas e vulnerabilidades sejam detectados e evitados por ferramentas de segurança. Isso ocorre porque muitas das tecnologias nas novas aplicações web são tecnologias já conhecidas utilizadas de outra maneira, ou simplesmente reutilizadas. Esse fato também recuperou antigas vulnerabilidades, como o cross-site scripting (para quem quiser conhecer mais: http://www.cgisecurity.com/articles/xss-faq.shtml).

Esssas antigas vulnerabilidades e ataques a elas relacionados podem ser detectados por sistemas tradicionais de proteção. Sistemas IPS de primeira linha, por exemplo, possuem proteção para ataques explorando cross-site scripting. Da mesma forma, sistemas de antivírus tradicionais podem detectar alguns exploits. No entanto é importante lembrar que o conjunto de tecnologias que formam a web 2.0 vão muito mais além dessas tecnologias e protocolos reutilizados, e esse conjunto ainda não é inteiramente protegido. Nesse sentido a web 2.0 é um exemplo perfeito de como novas tecnologias de negócio não são integralmente protegidas por tecnologias de segurança mais antigas. Infelizmente as empresas continuam mais lentos que a indústria do crime em adotar novas tecnologias, e geralmente aceitam soluções “good enough” (boas apenas o suficiente) para aperfeiçoar sua proteção.

Nesse momento é essencial que a proteção comece na fase de planejamento e depois no desenvolvimento da aplicação. Os desenvolvedores devem estar cientes das implicações de segurança e escrever as aplicações com elas em mente. Da mesma forma a empresa deve estar preparada para a necessidade de horas de desenvolvimento dedicadas ao teste e revisão de segurança das aplicações, assim como em treinamento específico. Novamente, todos esses cuidados devem começar na fase de planejamento. Infelizmente muitos se preocupam com segurança depois, e nesses casos o estrago já está feito. Para ajudar nesta parte uma nova categoria de produtos de segurança foi criada, com o intuito de testar as aplicações web e identificar erros de programação. Não é por acaso que duas entre as principais empresas do setor foram recentemente adquiridas: a SPI Dynamics pela HP, e a Watchfire pela IBM. Outras empresas de segurança vem anunciando novos produtos ou extensão de produtos atuais.
Outra camada de segurança deve ser implementada no lado oposto da conexão, ou seja, no computador do usuário. Nesse caso o antivírus tradicional de assinaturas é bastante limitado e nem todas as técnicas são eficientes. Em muitos casos a detecção restringe-se a exploits já conhecidos, o que é completamente inócuo contra exploits montados “on the fly” (um excelente artigo sobre isso está disponível em http://blogs.iss.net/archive/x-MorphicAttackEngin.html). As apostas para a proteção efetiva do usuário estão na tecnologia de detecção de aplicações maliciosas por comportamento.

A base da tecnologia está no comportamento do programa, sobreo qual o software de segurança pode dizer se há um comportamento maligno ou não. Ainda há necessidade, para esses programas, de atualizar os tipos de comportamentos, tal qual as assinaturas de vírus que fazemos hoje, no entanto comportamento é algo muito mais abrangente e eficiente. Pode parecer que a detecção comportamental será a panacéia para a segurança. Não a vejo como panacéia, mas como uma solução possível para um problema que a cada dia se torna mais complicado.

Segurança na Web 2.0

Novas aplicações trazem novas ameaças. Essa é uma verdade universal em segurança da informação, e sempre que algo novo é lançado ela se confirma. Há cerca de quatro anos Tim O’Reilly cunhou o termo “web 2.0” para o que ele chama de revolução na indústria da computação pelo movimento para a Internet como plataforma. Essa última definição pode ser encontrada no link http://radar.oreilly.com/archives/2006/12/web_20_compact.html. Para os usuários, web 2.0 tem outros significados: abertura, colaboração e participação. Para os hackers e invasores de plantão, o significado é outro: oportunidade.

Há hoje alguma polêmica sobre o significado e impacto da web 2.0, mas é fato que um de seus componentes principais já é realidade hoje: a utilização da web, ou melhor, da plataforma web como plataforma para execução de software. É como se o navegador se tornasse o novo sistema operacional sobre o qual os sistemas são executados e com o qual interagem diretamente. Não é por acaso que o nome dado a essa plataforma é justamente Web Operating System, ou só WebOS. Também há muita discussão da definição correta de Web Operating System, no entanto há pontos que claramente definem essa plataforma:

• Independência do sistema operacional (o aplicativo é criado para o WebOS e não para o sistema operacional)
• Os WebOS são executados sobre o navegador, e não interagem diretamente com o hardware e drivers
• O computador do usuário executa uma aplicação que “está na Internet” e não em seu computador.

Os riscos da web 2.0 são inerentes à própria plataforma. Apenas o fato de introduzir uma nova camada já traz um risco potencial, pois os hackers poderão utilizar essa nova camada como meio de acesso aos seus alvos, o que é aliás a maneira como qualquer invasor atua. Muitas pessoas acreditam que os hackers estão a margem da “sociedade digital”, como em uma espécie de submundo na Internet. Grande engano! Os hackers utilizam completamente a Internet e seus infindáveis recursos, assim como toda a tecnologia nela existente. Ou seja, qualquer serviço ou tecnologia existente serve tanto para fins benéficos como para fins maléficos. O correio eletrônico é o melhor exemplo: não precisamos proteger a infraestrutura de email contra tecnologias de invasão. Precisamos protegê-la contra ela mesma, contra suas vulnerabilidades e facilidades que permite o seu uso para o crime e outros propósitos.

Há alguns exemplos de ataques que se utilizaram da plataforma da web 2.0, e já documentados inclusive com plena cobertura da mídia. Um deles foi o worm Yamanner, lançado em junho de 2006. O alvo do ataque eram usuários do Yahoo Mail, que recebiam o worm codificado em Java Script em mensagens HTML. O script mal-intencionado era automaticamente processado e começava a enviar mensagens para os endereços cadastrados pelo usuário, entre outras ações de impacto limitado. Vejam que aqui o worm explorou diretamente uma vulnerabilidade no aplicativo do Yahoo, sem nenhuma dependência de sistema operacional da vítima. Outros foram o Samy e o Spaceflash que tiveram como alvo o MySpace, e atacaram usuários do site alterando o perfil deles e os incluindo como amigos do autor do ataque, entre outros.

Para piorar, mais do que usar a camada WebOS como meio de acesso, hackers vem utilizando os serviços de web 2.0 como ferramentas de trabalho para a criação de malware. O site GNUCITIZEN lista na página ao lado cinco serviços de grande utilidade para hackers. http://www.gnucitizen.org/blog/the-top-5-most-popular-web20-services-hackers-cannot-live-without. O site lista como os hackers estão usando o Yahoo Pipes, Dapper, Feed43, Zoho Creator e Google Reader em benefício próprio. Um exemplo o utilitário Jitko, uma ferramenta de varredura de vulnerabilidades para web sites. A diferença para as ferramentas tradicionais é que o Jitko é executado sobre o navegador, e não sobre o sistema operacional. Ou seja, é uma típica aplicação de web 2.0, baseada em WebOS. Ele pode ser embutido dentro de um web site e executar mesmo contra o desejo do proprietário do computador. Uma descrição da ferramenta está em http://www.zone-h.org/content/view/14660/31.

Um dos principais vetores de ataque é o AJAX, acrônimo para Asynchronous JavaScript and XML. O AJAX é uma das principais tecnologias existentes, e talvez a mais usada, para permitir a colaboração e interação nos web sites. A maneira como as aplicações são executadas no AJAX, com interações diretas entre o navegador, o servidor e outros web sites, permite que código e usos mal-intencionados sejam adicionados sem muita dificuldade, além da vantagem da execução de tais códigos ocorrer longe dos olhos do usuário. Quando é possível o usuário perceber algo, a aplicação já está rodando em seu navegador. Os ataques via AJAX ocorrem através de um velho problema, o cross-site scripting ou XSS. O cross-site scripting era considerada uma vulnerabilidade já equacionada, e a web 2.0 a resgatou dando a ela uma nova dimensão. Via cross-site scripting é possível ao invasor quase tudo, como roubar dados confidenciais, executar código arbitrário e até assumir o controle do computador do usuário.
Mas o AJAX não é infelizmente o único vetor de ataque. Outro bastante utilizado é XML, no que se chama de envenenamento de XML (Extensible Markup Language). A função do XML é justamente facilitar o compartilhamento de dados entre diferentes aplicações, o que inclui é claro as aplicações web. Pelo envenenamento de XML é possível provocar queda de serviço (DoS) ou executar código arbitrário no computador da vítima. Há ainda o chamado RSS Injection. RSS como todos sabemos é uma das coisas mais legais que a web 2.0 trouxe para os usuários: a possibilidade de mantê-los notificados de atualizações de conteúdo em seus sites preferidos. Mas há o lado negro: a possibilidade de embutir código Javascript mal-intencionado e executá-lo arbitrariamente no computador da vítima, permitindo por exemplo roubo de informação. Além destes há ainda riscos em SOAP, WSDL (Web Services Definition Language) e RIA (Rich Internet Applications). Todos são linguagens, protocolos, interfaces ou serviços que permitem a web 2.0 existir.

A existência de tantas vulnerabilidades novas, além do resgate de antigas vulnerabillidades, mostra o maior desafio para a segurança digital: ela sempre vem em segundo plano, seja no desenvolvimento de novas aplicações, seja na implementação dela por empresas usuárias. Depois que é tudo desenvolvido e instalado, e os problemas começam a aparecer, é que todos passam a pensar no assunto, como se não fosse algo possivel de prever com antecipação. É claro que a prevenção não resolve tudo, mas reduz bastante o problema. Depois de tantos anos lidando e sofrendo com ataques e o crime cibernético, poderiamos fazer com que a frase “novas aplicações trazem novas ameaças” deixasse de ser uma verdade inquestionável.

Storm Worm

A praga mais presente de 2007 continua sendo o Storm Worm. A primeira notícia do malware apareceu em Janeiro e ele continua não só ativo como variando seus métodos de infecção. Os autores do ataque mostraram possuir cartas sob a manga para confundir e dificultar a detecção. Uma descrição bem completa do ataque pode ser encontrada em alerta do X-Force na página http://iss.net/threats/W32.Worm.Nuwar.Gen.html. O alerta é do dia 19 de Janeiro porém está atualizado. Há duas reflexões a partir do Storm Worm: a grande quantidade de opções de variação que está nas mãos dos hackers e o incrível poder de fogo das redes bot (ou zumbis). Estatísticas sobre o ataque desde o seu início estão em blog da Websense: http://www.websense.com/securitylabs/blog/blog.php?BlogID=147

A primeira onda de ataque ocorreu exclusivamente por spam em massa, com anexos que infectavam o computador da vítima ao ser executados. Nas ondas adicionais as mensagens de correio eletrônico foram alteradas a fim de iludir suas vítimas. Também desde o inicio os autores do ataque inundaram a Internet com variantes do programa inicial responsável por baixar os programas adicionais que compõem o ataque (o downloader) , assim como variantes dos próprios programas adicionais.

A última onda, ocorrida em Setembro, foi baseada em técnicas de invasão via web. O web site legítimo de um congresso no estado de Wisconsin (USA) foi invadido e nele foi inserido uma linha de código que inicia o download do malware. Eles também criaram um site falso da liga americana de futebel americana para infectar usuários que chegaram a ela a partir de um email de phishing. Um determinado vídeo disponível do YouTube também serviu de isca. Os autores de malware certamente lançarão mão de todas as opções possíveis, alavancados sem dúvida pelos novos fornecedores de kits de invasão.

O Storm Worm criou uma rede bot que continua em expansão. Um artigo na Information Week chegou a comparar o poder de processamento dessa rede com um supercomputador da IBM –http://www.informationweek.com/news/showArticle.jhtml?articleID=201804528&pgno=1&queryText= . A questão é como lidar com essas formidáveis redes com milhares e até milhões de computadores. Ocorrências como a que ocorreu na Estônia em Maio, na qual o país saiu literalmente no ar, nos levam a pensar nas possíveis implicações dessas redes usadas para atacar países (http://www.informationweek.com/news/showArticle.jhtml?articleID=199701774 ).

Previsões para 2008 (pela Universidade Georgia Tech)

Na medida que nos aproximamos de 2008 começam a aparecer análises de tendências para as principais ameaças para o ano. Uma análise apontando as cinco ameaças que seriam as principais para 2008 foi publicado pelo grupo de segurança da Universidade Georgia Tech (Georgia Tech Information Security Center). O relatório está disponível na página http://www.gtisc.gatech.edu/pdf/GTISC%20Cyber%20Threats%20Report.pdf e aponta as seguintes ameaças como tendência para 2008:

• Ataques em web 2.0 e realizados no nível dos clientes
• Ataques via mensagens de eMail
• Botnets
• Ameaças focando na convergência de mobilidade
• Ameaças a sistemas de identificação por rádio-frequência (RFID)

Vale a pena dar uma olhada. Em especial nos próximos posts irei comentar as ameaças, e comparando as conclusões do grupo da Georgia Tech com a de outros analistas.