(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... =)

BBC aluga botnet para Spam e DDOS

Os canais tradicionais de comunicação tem dado cada vez mais atenção à questões relacionadas à segurança na internet. Um exemplo foi a ação protagonizada pelo blogger de segurança Brian Krebs, do Washington Post em novembro de 2008, que desembocou na desativação de uma infra-estrutura construída para prática de cyber-crime - especialmente SPAM (McColo) - esta ação derrubou o nível de spam mundial em quase 33%, diminuindo sensivelmente o volume de spam mundial por um tempo considerável.

Hoje, a rede de TV inglesa BBC nos brinda com a divulgação de um experimento arriscado que foi recentemente praticado com o objetivo de expor a maneira que os spams chegam às caixas postais dos usuários, demonstrar a facilidade de efetuar ataques de phishing e negação de serviço na internet.

A intenção era chamar a atenção dos usuários para o perigo e gerar conscientização, mas muitos especialistas têm se oposto aos métodos utilizados e alguns levantam questões éticas e legais (Computer Misuse Act) do experimento.

O que eles fizeram: arrendaram uma parte de uma botnet em um forum underground (22 mil computadores) e a utilizaram para envio de spam para duas caixas previamente criadas (hotmail e gmail) para demonstrar a facilidade do uso, além disto eles também (com conhecimento da empresa) fizeram um ataque de DDOS (negação de serviço distribuído) em um site backup da PrevX (apenas 60 máquinas foram necessárias para derrubar o site). Para complicar, a BBC trocou o fundo de tela (desktop) das máquinas envolvidas - mais detalhes aqui. Ao final do experimento, a BBC desinstalou o botnet das máquinas envolvidas.

Mais informações:

http://blogs.zdnet.com/security/?p=2868

http://www.theinquirer.net/inquirer/news/387/1051387/the-bbc-hacked

http://www.pogowasright.org/article.php?story=20090312080107414

http://www.h-online.com/security/The-BBC-acquired-a-botnet-but-was-it-legal--/news/112834/from/rss

http://www.out-law.com/default.aspx?page=9863

http://www.virusbtn.com/news/2009/03_12.xml?rss

CyberWar Russia vs Estônia : a confirmação

O conceito de CyberWar existe há muitos anos, e é crescente a preocupação dos governos com a fragilidade de infra-estruturas críticas, mas ainda não havia uma confirmação de envolvimento de governos nos ataques que objetivam desabilitar as capacidades de comunicação de outros países.

Isto mudou. Há dois dias um deputado russo (Sergei Markov) admitiu sua responsabilidade e de um de seus subordinados pelos ataques direcionados à Estônia em Abril de 2007 - estes ataques tiraram do ar e desfiguraram sites de organizações deste país, incluindo o parlamento, bancos, ministérios, jornais e redes de TV.

Até recentemente, muitos analistas acreditaram que os ataques fossem uma reação do povo russo, que tiveram ajuda de hackers que forneceram kits de ataque como ferramentas de negação de serviço (DDOS).

Outros movimentos internacionais relacionados à CyberWar têm ocorrido, como:

• Os ataques da Russia à Georgia
  
• O eternos conflitos Israel-Palestina
• O envolvimento do governo chinês em ataques ao ocidente (Update: report)
• A divulgação do governo alemão sobre a criação de uma unidade de CyberWar

Mais informações sobre a "confissão" da Rússia sobre o envolvimento nos ataques à Estônia:

http://www.rferl.org/Content/Behind_The_Estonia_Cyberattacks/1505613.html

http://isc.sans.org/diary.html?storyid=5974

http://blogs.zdnet.com/security/?p=2828

Dicas para Gerenciar Segurança durante a Recessão

[ 18/02/2009 - Update ]

O assunto de priorização de esforços em segurança devido à crise está em alta: desta vez um artigo na SearchSecurity de Eric Ogren aponta 4 maneiras de priorizar programas de segurança em uma ecnonomia ruim - abaixo uma tradução livre dos pontos e meus comentários:

I. Apoie projetos que tragam novas fontes de receitas

Na área de Segurança isto é difícil de acontecer, mas é possível - alguns exemplos são vendas de produtos/serviços de segurança para usuários (no caso de empresas como Provedores de Acesso e Conteúdo). O Eirc Ogren cita serviços de segurança que apoiam iniciativas de serviços on-the-cloud.

II. Proporcione uma maior economia através da tecnologia

O autor cita serviços de Controle de Configuração e Auditoria de uso de Máquinas Virtuais, mas achei este ponto um pouco forçado no que diz respeito à segurança de informações.

III. Atenda aos requerimentos mandatórios de compliance

Se sua empresa está sujeita à regras de compliance (SOX, Basiléia, PCI, etc..) - é claro que você tem que priorizar estas demandas, pois o efeito de não se validar neste tipo de auditoria externa pode ser devastador para uma empresa, ainda mais em tempos de crise.

IV. Substitua produtos que não estão atendendo (performance baixa)

Na minha opinião deveria ser o ítem "I" , assim como a lista que a CSO publicou (reproduzido no post original abaixo) possui como primeiro ítem "Priorize baseado em risco/recompensa". Aqui mais uma vez o candidato é a sua solução possivelmente ineficaz de IDS/IPS.


Alguns dos pontos colocados podem levantar discussões sobre métricas em segurança, e retorno de investimento ("ROI") em segurança.

É um desafio que se enfrentado apoiará as decisões em épocas de crise: como medir a efetividade de um controle de segurança? O sucesso atual da solução de segurança é suficiente para garantir um (re)investimento?

[ 10/02/2009 - Post Original]

Depois de alguns meses de agonia, parece que chegamos à um concenso sobre o declínio da taxa de crescimento econômico mundial - ou seja, estamos em recessão e o Brasil será atingido - talvez não por um tsunami, mas certamente também não por uma "marolinha", como disse o presidente.

Nestes tempos de vacas magras, é necessário priorizar os gastos e medir bem os esforços em novos investimentos. Na área de Segurança da Informação, a realidade não é diferente.

Alguns estudos recentes mostraram que:

1. Os ataques utilizando a internet devem aumentar devido à crise.

2. O prejuízo associado ao abuso interno por parte de funcionários/terceiros tem crescido substancialmente.

3. Os empregos de segurança foram pouco afetados até o momento. Alguns detalhes no último report do SANS sobre o o assunto.

Os itens acima certamente têm motivações e efeitos relacionados. Boa parte dos alertas relacionados no item 1. pode ser interpretada como FUD (Fear, Uncertainty & Doubt) - para garantir um bom quinhão de investimentos em tecnologias de segurança.

Hoje um artigo da CSOOnline traz 5 dicas para Gerenciamento de Segurança em uma recessão - seguem os pontos e meus comentários:

I - Priorize baseado em risco/recompensa.

Do que vale uma solução antiquada e milhonária de prevenção que só gera falsos positivos por default, e se bem configurada, começa a produzir mais falso negativos que alertas reais (i.e: eu NÃO DISSE IDS/IPS .. =)

II - Tenha o mix certo de pessoas/especialidades no seu time

Os seus Analistas Senior não podem estar executando tarefas repetitivas, eles precisam automatizar o que já existe e pensar em novas formas de combater as ameaças de negócio que tiram o sono de todos os seus chefes.

III - Construa processos passíveis de repetição

Aqui as vantagens são óbvias, a capacidade de gerar métricas, facilidade de treinamento - trata-se de eficiência.

IV - Crie uma estratégia de custos compartilhados otimizada

Existem soluções que resolvem problemas de várias áreas, e por isto estas podem trabalhar juntas para implementá-las. Alguns exemplos de cabeça são: SIEM - correlação de eventos de segurança e DLP - Prevenção de vazamentos de dados (de Host e Rede).

Tanto SIEM quanto DLP atendem à várias necessidades das áreas de Auditoria, Anti-Fraude, Compliance, Risco, Governança, Segurança de Rede, Segurança da Informação e Segurança Patrimonial.

V - Automatize e terceirize sabiamente

O corte de despesas em T.I. inclui sempre programas de outsourcing, fábricas de softwares e outras contratações para diminuir os custos internos e "manter a atenção da empresa em seu core business". Certamente isto inclui riscos que precisam ser considerados e monitorados, ao preço de ganhar eficiência e perder conhecimento / vantagens competitivas (vazamento de informações) ou dinheiro (fraudes).

Fases de um Ataque: Stealth

[ 17/02/2009 - Update: ]

O Bruce Schneier se pronunciou sobre o tema, baseado também no caso da Logic Bomb da Fannie Mae. (Obrigado ao Marcelo e Lucas pelo link).

[ 12/02/2009 - Update: ]

O blog sobre forensics do Sans Institute publicou um artigo sobre "Logic Bombs", citando o caso da Fannie Mae, dentre outros, vale a pena conferir. Eles também fizeram algumas colocações interessantes para evitar ser vítima deste tipo de ataque - resumindo:

- Conheça, controle e revise os acessos aos seus sistemas de informação
- Utilize o princípio do mínimo privilégio - como base para a distribuição de acessos.
- Garanta que a revogação de privilégios seja um processo rápido e automatizado.
- Leve a sério ameaças de empregados insatisfeitos

Eu acrescentaria à esta lista:

- Monitore e audite os acessos administrativos ( não conte com a sorte =)

[ 03/02/2009 ]

Em 1998 um artigo de Alan Boulanger chamado "Catapults and Grappling Hooks, The Tools and Techniques of Information Warfare" apresentou uma divisão até então inédita das fases comumente utilizadas durante um ataque computacional. São elas: 1. reconnaissance, 2. probe, 3. toehold, 4. advancement, 5. stealth, 6. listening post, and 7. takeover.

Cada uma das fases descritas é proporcionada ou auxiliada pela fase anterior e de forma direta ou indireta prepara o atacante para a execução da próxima.

Onze anos depois, as fases conceituais não mudaram muito, mas certamente a motivação dos atacantes e a importância das diferentes fases para que estes alcancem seus objetivos são sempre variáveis.

Neste post pretendo apresentar três casos em que a fase stealth de ataques publicamente conhecidos foi fundamental, deixando claro os perigos inerentes ao não reconhecimento tempestivo das fases anteriores, o que acarreta invariavelmente em grandes perdas financeiras diante de atacantes bem preparados e motivados.

1) Em 2005, um ataque extremamente sofisticado culminou no escândalo com roteiro de filme - incluindo suicídio de um engenheiro envolvido na trama - ocorrido com a operadora GSM grega Vodafone-Panafon. A bem executada fase stealth do ataque permitiu que os perpetradores grampeassem o celular de mais de 100 figuras públicas da Grécia durante vários meses.

2) A HeartLand - empresa que recentemente divulgou ser vítima de um ataque stealth elaborado que possibilitou o maior vazamento de dados de cartão de créditos da história, ocorrido em 2008 - precisou de 3 equipes de investigação e mais de 2 meses depois de um alerta da Visa para descobrir que o sniffer responsável pela captura dos dados estava escondido em espaço não alocado do disco de seus servidores.

3) Na Fannie Mae - empresa de hipotecas sob administração do governo americano desde setembro de 2008 - um ex-administrador de sistemas contratado implantou em 4000 de seus servidores UNIX uma bomba relógio que iria remover o acesso dos demais administradores e apagar (wipe) vários terabytes de dados críticos da empresa, em 31/01/2009. Por sorte, o plano foi descoberto antes porque o esforço stealth deste atacante interno foi baixo, ele apenas incluiu várias linhas em branco dos scripts de manutenção dos servidores antes de digitar seus comandos maliciosos. Se a mesma sofisticação dos casos 1) e 2) tivesse sido utilizada, o impacto seria altíssimo.

Windows7 UserAssist - Microsoft troca de ROT13 para Vigènere

[ 29/01/2009 ] - Update:

A Microsoft anunciou que a cifra Vignère está sendo utilizada apenas na versão beta do Windows 7, na versão final, o ROT13 voltará a ser utilizado.

[ 19/01/2009 ]

Do ponto de vista forense, uma das informações interessantes presentes no registro de uma máquina Windows (9x a Vista) são os dados relacionados à utilização de programas / abertura de documentos.

Nos Windows 95,98,ME,2000,XP,2003,Vista e 2008, esta informação está codificada em ROT13 (ref: http://en.wikipedia.org/wiki/Rot13 ) em arquivo por usuário (NTUSER.DAT ) - a chave correspondente é a "Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist" ou no Registro "Live" localizado em "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist"

Na versão beta do Windows7 - recém lançado em beta - isto foi modificado, por uma cifra um pouco mais complexa - a Vigènere (ref: http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher ), com a seguinte chave de descriptografia (por enquanto fixa) : BWHQNKTEZYFSLMRGXADUJOPIVC.

Por mais que existam críticas à maneira de guardar esta informação - mesmo que a Microsoft mude da cifra de Vigenère para algo melhor, a descriptografia será sempre possível, pois o Windows precisa acessar esta informação todo o tempo - para compilar a lista de programas mais usados, por exemplo...

Crédito: Didier Stevens -> http://blog.didierstevens.com/2009/01/18/quickpost-windows-7-beta-rot13-replaced-with-vigenere-great-joke/

Projeto de Lei - Crimes Eletrônicos (PL 84/99)

A importância do combate aos Crimes Digitais é cada vez mais clara, e no Brasil há alguma evolução neste sentido. Naturalmente vem aumentando a cobrança de uma priorização adequada por parte dos agentes públicos envolvidos.

O Tratado de Budapeste - "Convention on Cybercrime" (pdf), de 2001, foi assinado por 46 países (para detalhamento e restrições, veja aqui) . Ele possui em sua introdução um trecho que encerra a urgência de possuirmos uma legislação adequada nesta área:

"Convictos da necessidade de prosseguir, com carácter prioritário, uma política criminal comum, com o objectivo de proteger a sociedade contra a criminalidade no ciberespaço, designadamente, através da adopção de legislação adequada e da melhoria da cooperação internacional" - mais informaçôes atualizadas sobre a Convenção aqui.

O Brasil não é signatário (já existe alguma movimentação no sentido), e apesar de existirem lei específicas sobre assuntos correlatos (pirataria, invasão de bancos de dados do governo, lei geral das telecomunicações, etc.. ), até o momento o projeto mais importante, PL 84/99, continua em trâmite e sem previsão de virar lei - acompanhe aqui o status do projeto de lei.

Têm havido consultas públicas sobre o texto - eu tive a oportunidade de participar na Anatel de reuniões com interessantes discussões técnicas e jurídicas, no Âmbito da Comissão Brasileira de Comunicações, Tema 1 Segurança. Várias outras sugestões/críticas sobre o projeto foram feitas durante todos estes anos (1,2,3,4,5) . Hoje um post na ISTF me proporcionou conhecer o que considero a melhor contribuição feita até o momento, proposta pela Escola de Direito da Fundação Getulio Vargas - leitura recomendada:

Comentários e Sugestões sobre o Projeto de Lei de Crimes Eletrônicos (PL n. 84/99) (pdf)

TOP 25 CWE/SANS - Problemas de Segurança em Programação (Prós e Contras)

Programar é uma tarefa relativamente simples, mas desenvolver produtos complexos de forma segura e garantir que sua implementação/configuração não irá incluir riscos associados tem se mostrado uma tarefa dificílima de se conseguir. Não é a toa que recentemente o tema de Segurança em Desenvolvimento tem crescido fortemente dentro da comunidade de Segurança da Informação.

Recentemente, o CWE e o SANS Institute divulgaram uma lista dos 25 erros piores erros de programação do ponto de vista da segurança.

A iniciativa não é nova (vide OWASP Top 10, 19 Sins book, e as específicas de linguagens como Java, C, Perl, PHP, ...) , mas claro que é bastante válida - desde que usada com critério.

Algumas críticas interessantes (obrigado, Lucas) foram colocadas por alguns especialistas na área de desenvolvimento seguro, como Gary McGraw - que compilou uma interessante lista de 11 principais motivos do porque listas de "top 10" (ou 25) devem ser avaliadas com cautela.

Alguns pontos interessantes da crítica de McCgraw (tradução livre):

• 1 - Executivos não dão a mínima para erros técnicos
• 3 - Listas de Vulnerabilidades ajudam mais aos auditores do que aos desenvolvedores
• 6 - Listas de erros se modificam de acordo com a mudança da tecnologia
• 9 - Métricas construídas sobre listas "Top N" são enganadoras.

16/01/2009 Update - a OWASP acusa o SANS Institute de plágio.

pdymail - Forense de Memória para o Yahoo Mail

Em outubro eu postei sobre o pdgmail, uma ferramenta desenvolvida em python e disponibilizada por Jeff Bryner, que auxilia em muito a análise de dumps de memória de browsers por informações relacionadas ao uso do Gmail.

Pois bem, o mesmo autor publicou hoje o pdymail, uma ferramenta análoga para a nova interface do Yahoo! Mail, que como o Gmail utiliza JSON/AJAX/XML para manter várias informações em memória e deixa poucos vestígios de seu uso em disco.

O mais importante é definir antecipadamente a forma que você coletará o dump de memória (full ou do processo do browser em execução) - depois disto feito - o uso do pdymail é bastante simples (em linux ou cygwin):

$ strings -el pid1234.dump| ./pdymail -f -

Trocando em miúdos, este tipo de ferramenta é muito útil na fase de análise de investigações que envolvam interfaces modernas de WebMail como o Gmail e o Yahoo! Mail, pois não será muito útil utilizar o processo tradicional de vasculhar o disco por artefatos de Webmail (incluindo espaço não alocado/arquivos deletados).

Uma informação adicional, o dump terá informações úteis desde que o browser tenha sido utilizado anteriormente (naquela execução) para acesso a interface do Yahoo! Mail / Gmail. Ou seja, não é necessário que o usuário esteja logado do Webmail no momento do dump.

Forjando certificados SSL que utilizam o MD5

O tema da virada do ano foi o ataque demonstrado por Alexander Sotirov et al que mostra a necessidade de se deixar de utilizar o algorítimo de hashes criptográficos MD5 em mais uma aplicação: PKI, ou Public Key Infrastructure (slides PDF) / (site SSL prova de conceito)

A implicação mais óbvia é a utilização desta vulnerabilidade em ataques de phishing/pharming mais sofisticados (combinados com ataques de DNS possibilitariam a um atacante a falsificação quase perfeita (e talvez o tunelamento do acesso do cliente através de um site forjado) de instituições de comércio eletrônico e personal banking (https://)

Há quem argumente que não é de grande impacto a notícia, porque o usuário comum simplesmente clicaria em "Add Exception" no Browser quando um ataque similar é feito com um certificado SSL não forjado, mas as implicações são ainda mais sérias neste caso, tanto é que a Verisign estará substituindo gratuitamente para seus clientes os certificados que ainda utilizam o MD5...

Segundo os pesquisadores, além da aplicação da colisão de hashes MD5, o ataque foi possível porque a Verisign e outras (RapidSSL, FreeSSL, TrustCenter, RSA Data Security, Thawte, verisign.co.jp):

• ainda utilizavam (até dias atrás) certificados com assinaturas criadas utilizando MD5 (caso você seja responsável por certificados SSL em uma PKI interna, verifique também... )
  
• automatizam as solicitações de certificados
• não verificam solicitações anômalas
  
• permitem a previsão da combinação entre número de série e validade do certificado
• não limitam o tamanho da cadeia de certificados

Ou seja, uma melhor aplicação do velho e bom conceito de "segurança em profundidade" teria evitado o sucesso do ataque demonstrado, mesmo que a vulnerabilidade existisse.

Vale lembrar que o MD5 tem um crescente histórico de identificações de vulnerabilidades que possibilitaram esta prova de conceito.

Segundo a Netcraft, 14% dos sites que usam SSL utilizam o MD5 como algoritimo de hash.

Estas duas extensões para Firefox podem auxiliá-lo a detectar se o site HTTPS que você está acessando usa certificados que utilizam MD5:

• SSL BlackList
• Perspectives

Além disto, recentemente foi disponibilizado um módulo para o metasploit framework que pode varrer o endereçamente interno da sua empresa e identificar se existem certificados que precisam ser trocados:

Uma lista de referências sobre o assunto segue abaixo:

• http://www.win.tue.nl/hashclash/rogue-ca/
• http://www.phreedom.org/research/rogue-ca/
• http://www.rsa.com/blog/blog_entry.aspx?id=1411
• http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
  
• http://www.microsoft.com/technet/security/advisory/961509.mspx
• http://doggdot.us/security/Free_SSL_Certificates_?FC=PRCK0
• http://feeds.feedburner.com/~r/SecuritySoapbox/~3/501614128/broken-md5-cracked-ssl-and-end-of-all.html

Um outro detalhe interessante é que para parte da computação necessária para o sucesso do ataque, foram utilizados os cores SPU do processador "Cell" de um cluster de mais de 200 videogames Playstation 3.