Duas âncoras, um ano

Toda arquitetura de segurança se apoia num punhado de coisas que se supõe não falharem. Duas das maiores são o autenticador que prova que uma pessoa é quem diz ser, e a autoridade certificadora que prova que um servidor é o que diz ser. Em 2011 uma de cada foi comprometida, com quatro meses de intervalo, e a sequência vale ser ensinada porque nenhuma das duas falhou do jeito que um profissional esperaria.

Nenhuma foi quebrada criptograficamente. Uma caiu por um e-mail; a outra, por uma rede com uma senha só.

Março de 2011: a RSA e o SecurID

Em 3 de março de 2011 um funcionário da EMC, empresa-mãe da , recebeu uma mensagem dizendo, em substância, que um arquivo estava sendo encaminhado para revisão. O anexo era uma planilha chamada "2011 Recruitment plan.xls". Abri-la disparou um exploit de dia zero no Adobe Flash, que instalou uma porta dos fundos de acesso remoto. Os atacantes então fizeram o que atacantes fazem: tiraram credenciais da memória, usaram-nas para alcançar outras máquinas, colheram mais credenciais, inclusive privilegiadas, e chegaram ao que tinham vindo buscar - dados relativos ao SecurID, o token de hardware então usado por uns 40 milhões de pessoas em 25 mil organizações clientes para provar identidade ao entrar em sistemas.

A RSA chamou a intrusão de ameaça persistente avançada. Críticos chamaram de phishing. A avaliação mais cuidadosa veio de Mikko Hyppönen, da F-Secure, cuja equipe recuperou o e-mail original: a mensagem não era avançada e a porta dos fundos também não, mas o exploit era, e como era um dia zero, a RSA não poderia tê-lo evitado corrigindo sistemas. Essa distinção é a útil, e é desconfortável nas duas direções - recusa o conforto do "deviam ter aplicado o patch" e igualmente o conforto de chamar toda intrusão de sofisticada.

A consequência chegou em maio. A Lockheed Martin - a maior fornecedora de tecnologia da informação ao governo dos Estados Unidos - detectou um ataque ao seu acesso remoto usando informação derivada da brecha na RSA. A L-3 Communications relatou tentativa semelhante; a Northrop Grumman desligou temporariamente o acesso remoto. Em 6 de junho a RSA confirmou o que se suspeitava havia meses e se ofereceu para substituir os tokens de sua base de clientes, a um custo estimado em uns 66 milhões de dólares. Os alvos reais nunca tinham sido a RSA nem as empreiteiras; eram os programas em que as empreiteiras trabalhavam.

A crítica da época que melhor envelheceu não era sobre a intrusão. escreveu em maio, antes da confirmação, que o incidente revelava o perigo de as empresas não serem abertas sobre incidentes de segurança: os clientes que dependiam do SecurID não sabiam dizer se deviam trocar tokens, mudar PINs ou isolar seus servidores administrativos, porque não lhes tinham dito o que fora levado. Esse, disse ele, era o problema de verdade. É o mesmo achado que o verbete da Microsoft registra sobre um deixado errado por seis meses, e o da Fujitsu sobre um registro retido por uma década.

De junho a setembro de 2011: a DigiNotar

A DigiNotar era uma autoridade certificadora holandesa. Sua raiz era confiada por todo navegador de peso, e uma de suas intermediárias emitia certificados para o PKIoverheid, a infraestrutura de chaves públicas do governo holandês - os certificados por trás dos serviços eletrônicos do país.

Os intrusos estavam dentro desde meados de junho. A partir de 10 de julho usaram esse acesso para emitir certificados: 531 certificados fraudulentos para 344 domínios, entre eles Google, Skype, o site de complementos da Mozilla e o Microsoft Update. A DigiNotar começou a revogar em 19 de julho. Não tornou público.

Foi descoberta por um cidadão comum. Em 27 de agosto um usuário iraniano do Gmail postou num fórum de suporte do Google perguntando se o que via era um ataque de intermediário sobre o certificado. Era. Um certificado curinga fraudulento do Google estava sendo usado, no Irã, para ler correio.

O que a Fox-IT então achou, num relatório publicado em 5 de setembro e arquivado como anexo de um registro público de valores mobiliários, é um catálogo de falhas que qualquer auditor deveria ter pegado. Todos os servidores da autoridade certificadora estavam num único domínio Windows, então um usuário e uma senha alcançavam todos - e a senha era fraca o bastante para força bruta. Os servidores mais críticos carregavam malware que um antivírus comum teria detectado. A separação de componentes críticos estava ausente ou não funcionava. Os servidores estavam fisicamente numa sala segura e alcançáveis pela rede. E o número de série do certificado fraudulento do Google não constava dos registros da própria empresa, o que significava que ninguém sabia dizer quantos certificados tinham sido emitidos: o único jeito de estimar o estrago era observar as consultas de revogação que os navegadores fazem - as do Online Certificate Status Protocol (). Essas consultas mostraram cerca de 300 mil endereços únicos, noventa e nove por cento deles no Irã, checando o estado do certificado fraudulento do Google - ou seja, aproximadamente 300 mil pessoas cujo correio estava sendo interceptado, por quase dois meses.

A DigiNotar era auditada anualmente contra a norma europeia para autoridades certificadoras.

Os navegadores removeram a raiz. A Mozilla foi além e acrescentou desconfiança explícita, porque uma raiz removida ainda pode ser honrada se houver assinatura cruzada, e incluiu as intermediárias do PKIoverheid que não encadeavam na raiz da DigiNotar. O governo holandês teve de assumir o controle operacional do negócio de certificados de uma empresa privada para manter os serviços do Estado funcionando, e dizer a dezessete milhões de cidadãos que os certificados por trás de seu governo eletrônico não podiam ser confiados. Promotores abriram inquérito sobre se a demora na divulgação configurava negligência criminosa. Em 19 de setembro de 2011 a DigiNotar pediu falência. Impressões digitais deixadas de propósito nos scripts do ataque batiam com as da invasão à Comodo, outra autoridade certificadora, em março do mesmo ano.

O que o par ensina

A falha nunca foi a criptografia. Os algoritmos da RSA estavam bem; o projeto do SecurID estava bem. Os certificados da DigiNotar eram matematicamente válidos - esse era o problema. Os dois foram derrotados por fraquezas comuns de tecnologia da informação: um e-mail, um domínio plano, uma senha fraca, segmentação ausente. Os ataques nomeados ao TLS tratam de falhas em protocolos; este par trata de tudo em volta deles, e a segunda categoria produziu mais estrago que a primeira.

O comprometimento de uma âncora de confiança é silencioso por construção. Um certificado fraudulento não produz erro. Um token clonado produz um login bem-sucedido. Nenhum gera alerta, porque os dois são o sistema funcionando. É por isso que os registros da própria DigiNotar não podiam responder à pergunta mais básica - quantos certificados você emitiu - e por que a estimativa teve de ser reconstruída do tráfego de revogação. Se a maquinaria de revogação de certificados não existisse, ninguém teria conseguido contar as vítimas.

A detecção veio de fora, nos dois casos. A brecha da RSA ficou visível quando as defesas da Lockheed pegaram o ataque seguinte. A da DigiNotar ficou visível quando um usuário em Teerã fez uma pergunta num fórum. Nenhuma das organizações achou a própria intrusão, e as duas demoraram a falar depois de saber - a DigiNotar mais de um mês depois de começar a revogar.

O momento da divulgação é um controle de segurança. Esta é a parte que os profissionais subestimam. As duas organizações tinham clientes que poderiam ter agido - reemitir tokens, fixar certificados, olhar os próprios registros - e que não puderam, porque não sabiam. A engenharia já estava perdida a essa altura; o que restava decidir era quanto a perda custaria a todo mundo rio abaixo, e isso foi decidido por uma escolha de comunicação.

E as auditorias passaram. A DigiNotar era avaliada periodicamente contra a norma reconhecida do seu setor enquanto os servidores da sua autoridade certificadora dividiam uma senha. A conformidade media o que podia ser documentado, e a coisa que importava - uma credencial alcança todo servidor de assinatura? - não estava na lista. Essa distância entre uma auditoria aprovada e uma rede defensável é a coisa mais útil a levar de 2011 para qualquer conversa sobre um regime de conformidade.

Fontes