Como um email supostamente do Google revelou uma imensa brecha de segurança

Era um estranho e-mail, vindo de um recrutador do Google, perguntando à Zachary Harris se ele estava interessado em atuar como engenheiro da confiabilidade.

"Você obviamente tem uma paixão por Linux e programação", dizia o e-mail do Google "Eu queria ver se você está aberto a explorar novas oportunidades junto com a Google?"Harris ficou intrigado, porém cético. O e-mail chegou em dezembro passado, e como um matemático, ele não parecia o candidato mais provável para o trabalho que lhe foi oferecido.

Então, ele se perguntou se o e-mail poderia ter sido falsificado - algo enviado para parecer vir da gigante das buscas. Mas quando Harris examinou as informações de cabeçalho do email, tudo parecia legítimo.

Então ele notou algo estranho. A Google estava usando uma chave de criptografia muito fraca para certificar aos destinatários que sua correspondência veio de um legítimo domínio corporativo do Google. Qualquer pessoa que quebrasse a chave poderia usá-la para se passar por um remetente qualquer de e-mail do Google, incluindo seus fundadores, Sergey Brin e Larry Page.

O problema estava com a chave DKIM (DomainKeys Identified Mail) que a Google havia utilizado para os emails google.com. DKIM envolve uma chave criptográfica que é usada para assinar a origem de domínios de e-mail - ou se passar por eles - para validar a um destinatário que o domínio nas informações de cabeçalho em um e-mail está correto e que a correspondência de fato veio do domínio declarado. Quando o e-mail chega a seu destino, o servidor de recebimento pode procurar a chave pública através de registros DNS do remetente e verificar a validade da assinatura.Por razões de segurança, as chamadas DKIM padrão para utilizar as chaves que são, pelo menos, 1024 bits de comprimento. Mas o Google estava usando uma chave de 512 bits - o que poderia ser facilmente quebrado com um pouco de ajuda de computação nas nuvens.Harris achava que não havia como a Google ter sido tão descuidada, então ele concluiu que devia ser um teste, um recrutamento falso para ver se os candidatos a emprego iria encontrar a vulnerabilidade. Talvez o recrutador criou a "vulnerabilidade", ou talvez tenha sido criado pela equipe de tecnologia do Google, nos bastidores, com os recrutadores como cúmplices involuntários.Harris não estava interessado em trabalhar na Google, mas ele decidiu quebrar a chave e enviar um e-mail para fundadores do Google, Brin e Page, como eles mesmos, só para mostrar-lhes que ele tinha decifrado a brincadeira."Eu amo fatorar números", diz Harris. "Então, eu pensei que isso seria divertido. Eu realmente queria resolver seu quebra-cabeça e provar que eu poderia fazer isso. "No e-mail, ele linkou seu site pessoal:

    Hey Larry,

    Aqui está uma idéia interessante que ainda está sendo desenvolvida:

    http://www.everythingwiki.net/index.php/What_Zach_wants_regarding_wiki_technology

    ou, se o link acima não funcionar, tente:

    http://everythingwiki.sytes.net/index.php/What_Zach_wants_regarding_wiki_technology.

    Acho que devemos analisar se o Google poderia se envolver com esse cara de alguma forma. O que você acha?

    -SergeyHarris fez com que o caminho de resposta para os e-mails fosse a sua conta de e-mail próprio, de modo que Brin e Page poderiam perguntar a ele como ele tinha resolvido seu enigma. Mas Harris nunca teve uma resposta dos fundadores do Google. Em vez disso, dois dias depois, ele percebeu que a chave de criptografia do Google, de repente mudou a 2.048 bits. E ele teve um grande número de acessos repentinos de seu site a partir de endereços IP do Google.Ops, pensou Harris, era uma vulnerabilidade real que tinha encontrado."Eu assumi que o e-mail foi analisado por alguma pessoa influente do setor de tecnologia que olhou para ele e disse: 'Espere um segundo, como isso é obviamente falsificado e ainda assim recebemos esse e-mail?" E eles aparentemente perceberam a vulnerabilidade por conta própria ", diz ele .Harris começou a explorar outros locais e notou o mesmo problema com as chaves DKIM usadas ​​por PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, SBCGlobal, US Bank, HP, Match.com e HSBC. Enviar um e-mail como jeff.bezos @ accounts.amazon.com? Sem problemas. Spoofing como marissa.meyer @ yahoo-inc.com? Muito simples.

Falsificação de e-mails é um dos métodos que os atacantes usam em ataques de phishing que enganam os usuários fazendo-os abrir e-mails que parecem ser mensagens legítimas do eBay, PayPal ou de um banco, a fim de enganar os usuários a divulgar suas credenciais de login de conta.

Além disso, alguns dos ataques mais utilizados nos últimos anos - contra o Google, a RSA e outros - usaram ataques phishing em funcionários específicos de uma empresa, enviando-lhes um e-mail malicioso que parecia vir de um confiável colega ou fonte, a fim de convencer o destinatário a entrar em algum site comprometido onde o malware seria baixado para sua máquina. Um falso e-mail que realmente é assinado com a chave de uma empresa DKIM pode ajudar os atacantes a ter sucesso em seus ataques de phishing visto que essa chave foi criada justamente para detectar ataques desse tipo.Encontrar a vulnerabilidade no próprio domínio Google foi irônico, já que o Google tem inúmeras ferramentas para bloquear e-mails enviados para usuários do Gmail a partir de outros domínios falsificados.Uma porta-voz do Google disse que a empresa Wired levou o problema muito a sério e que implementou a correção tão logo tomou conhecimento do problema. Ela disse que a empresa revogou as chaves para todos os seus domínios afectadas e re-emitiu novas que são maiores que 1.024 bits.Harris encontrou três classes de comprimentos de chaves utilizadas pelos domínios vulneráveis ​​- 384 bits, 512 bits, e 768 bits."Uma chave de 384 bits eu posso fatorar no meu laptop em 24 horas", diz ele. "As chaves de 512 bits eu posso fatorar em cerca de 72 horas com a Amazon Web Services por US$75,00, eu assim como uma série de outras pessoas. Depois, há as chaves de 768 bits. Esse não é possível ser fatorado por uma pessoa normal como eu, com apenas os meus próprios recursos. Mas o governo do Irã, provavelmente, poderia, ou um grande grupo com recursos de computação suficientes poderia. "Além do Google, ele descobriu que eBay, Yahoo, Twitter e Amazon todos usavam chaves de 512 bits. PayPal, LinkedIn, US Bank e HSBC estavam usando chaves de 768 bits."Que bom que o PayPal e os bancos estavam na categoria de 768, mas ainda assim, para domínios que são tão fortemente atacados por phishing como PayPal, 768 não é suficientemente bom", diz Harris. "Eles realmente deveriam ter usado 1024."A maioria das empresas contactadas por Harris ao longo dos últimos meses têm arrumado suas chaves, embora alguns ainda estão fazendo isso muito lentamente, observa ele. Depois de entrar em contato com Centro de Coordenação CERT da Universidade Carnegie Mellon para relatar a vulnerabilidade em agosto, Harris decidiu ir a público para avisar outros domínios sobre a necessidade de verificar suas chaves DKIM.Michael Orlando, analista de vulnerabilidade do CERT, disse que seu grupo planejava lançar um anúncio sobre o assunto nesta semana para espalhar a notícia.A correção é fácil - as empresas simplesmente precisa gerar uma nova chave no comprimento mais forte e colocá-lo em seus registros de DNS. Mas eles também precisam se lembrar de revogar sua chave antiga, diz Harris."Enquanto a antiga ainda estiver no registro DNS, mesmo se você não a estiver usando, um atacante ainda poderá usá-la", diz ele.Harris acha que o problema é que muitas empresas definem suas chaves uma vez e depois esquecem, apesar dos avanços em inovações de criptografia que fazem suas chaves obsoletas."As pessoas que usam ferramentas de criptografia precisa perceber que as configurações locais precisam ser mantidas assim como atualizações de software precisam ser mantidas", diz ele. "Em 1998, foi um avanço acadêmico de enorme esforço quebrar uma chave de 512 bits. Hoje, eu posso fazer isso por mim mesmo em 72 horas no AWS. O campo de criptografia mantém o desenvolvimento como todo o resto, e você não pode simplesmente instalar uma chave privada, ou selecionar um algoritmo de hash, e espera que ele seja bom para sempre. "Mas Harris diz que o problema não é apenas com os domínios do remetente, ele descobriu que os domínios que recebem também apresentam vulnerabilidades em aceitar chaves DKIM que foram claramente marcados como testes. Em alguns casos, domínios de remetentes geraram chaves de teste quando eles montaram seus sistemas, mas nunca revogaram elas. Embora Harris tenha encontrado chaves que eram claramente sinalizadas como sendo chaves de teste, domínios beneficiários que viram essas bandeiras aceitaram os e-mails como sendo legítimos, ao invés de considerá-los sem sinal, como deveriam ter feito."Então isso é um problema em ambos os lados;. Os remetentes estão recebendo estas chaves de testes que estão saindo nos registros de DNS mesmo muito tempo após o período de testes ter sido concluído, e então os verificadores estão ignorando a tag de testes", diz.Harris não é um pesquisador de segurança, e ele não sabia nem mesmo o que era DKIM antes de começar a investigar a autenticidade do e-mail do Google que ele recebeu."O fato de que eu entrei nisto sem saber nem mesmo o que era um cabeçalho DKIM mostar o que alguém com conhecimento técnico suficiente pode acabar fazendo", diz ele.