Pesquisadores da Universidade do Texas em Austin e da Universidade Stanford publicaram os resultados de uma pesquisa que expõe vulnerabilidades críticas no uso de bibliotecas SSL em aplicações "não-browser", antes consideradas altamente seguras. Esses softwares são usados em serviços críticos bancários e SDKs para comércio eletrônico, além de softwares menos críticos como armazenamento na nuvem e mensageria. A pesquisa coloca a culpa nos pobres testes de adversidades, bibliotecas de SSL inseguras, uso programação insegura das bibliotecas SSL, complexidade na resolução de problemas escondidos profundamente na pilha de erros e na prática de desabilitar a validação dos certificados pelos desenvolvedores.
A ameaça modelo usada pelo time é um ataque do tipo man-in-the-middle. O ataque simulado usou três certificados: (1) um auto-assinado com os mesmos nomes usados pelo servidor ao qual o cliente desejava se conectar, (2) um certificado auto-assinado com um nome incorreto; e (3) e um certificado válido emitido por uma autoridade confiável para um domínio chamado AllYourSSLAreBelongTo.us. Os ataques man-in-the-middle focaram na cadeia de verificação de confiança e do nome do servidor mas não testaram a revogação do certificado e as extensões X.509. O código para o modelo de simulação do ataque pode ser baixado aqui.
A pesquisa mostra detalhes relevantes para desenvolvedores que utilizam bibliotecas SSL: OpenSSL e JSSE e bibliotecas de transporte de dados: Apache HttpClient, Weberknecht, cURL, o método fsocketopen do PHP, a técnica de cURL binding e certas bibliotecas do Python: urllib, urllib2 e httplib. A maioria das bibliotecas SSL executam verificação de certificados, mas deixam para o cliente algumas opções abertas quanto à verificação do nome do servidor, que em geral é ignorada pela maioria dos desenvolvedores. Por exemplo, na API de baixo nível do JSSE, a classe SLSocketFactory automaticamente desliga a verificação do nome do servidor se o campo algoritmo for nulo. Maioria dos clientes não implementam seus próprios esquemas de verificação do nome do servidor incluindo o Apache HttpClient, o que traz riscos de segurança. O seguinte trecho de código elucida esse fato:
private void checkTrusted(X509Certificate[] chain, String authType, Socket socket, boolean isClient)
throws CertificateException {
...
String identityAlg = sslSocket.getSSLParameters().
getEndpointIdentificationAlgorithm();
if (identityAlg != null && identityAlg.length != 0)
{
String hostname = session.getPeerHost();
checkIdentity(hostname, chain[0], identityAlg);
}
}
Tais vulnerabilidades infiltram-se em qualquer aplicação não-browser usando essas bibliotecas. Para uma recomendação específica da correta implementação de clientes usando SSL e de biblioteca de transporte de dados vejam a FAQ fornecida pelos autores da pesquisa.
Metade da pesquisa discute os resultados de ataques simulados contra APIs de clientes de nuvem (AWS EC2, e ferramentas de API ELB), Apps (Chase mobile banking, Rackspace IOS, Groupon, TextSecure), SDKs (Amazon Flexible Payments Service, PayPal Payments Standards), middleware de Web Services (Apache Axis, Axis2, CodeHaus XFire e Pusher) e anúncios mobile (AdMob). A pesquisa conclui com as seguintes recomendações aos desenvolvedores de aplicações:
FAÇAM Fuzzing (blackbox, se necessário) e testes de adversidade para ver como a aplicação se comporta quando apresentada a um certificado SSL anormal. Mesmo quando as vulnerabilidades são sutis, os sintomas geralmente não são. Em vários dos nossos casos de estudo, ficou óbvio que o software em questão nunca tinha sido testado com qualquer outro certificado que não do servidor desejado. Quando apresentados a um certificado emitido para AllYourSSLAreBelongTo.us ao invés do certificado esperado da Amazon, PayPal ou Chase, esses servidores estabeleceram conexões SSL e entregaram seus segredos. Essas vulnerabilidades deveriam ter sido observadas durante os testes.
NÃO modifique o código da aplicação ou desabilite a validação do certificado para testar com certificados auto-assinados e/ou não confiáveis. Encontramos, nos nossos casos de estudo, muitos desenvolvedores que esqueceram de reverter essas modificações, mesmo em versões para produção. Em vez disso, crie uma keystore temporária contendo uma chave publica de um CA não confiável. Enquanto testa sua aplicação com seu certificado auto-assinado ou não confiável, use essa keystore como sua keystore confiável.
NÃO dependa dos padrões da biblioteca para configurar uma conexão SSL de maneira segura. Configurações padrão podem e devem mudar entre as bibliotecas diferentes ou mesmo entre versões diferentes da mesma biblioteca; por exemplo, a cURL antes da versão 7.10 não validava os certificados por padrão, mas a partir da versão 7.10 e superior essa ação é realizada. Sempre explicite o conjunto de opções necessárias para estabelecimento de uma conexão segura.
E para os desenvolvedores de bibliotecas SSL:
FAÇAM bibliotecas SSL mais explícitas quanto à semântica de suas APIs. Em muitos casos é óbvio que os desenvolvedores de aplicações não entenderam o significado de várias opções e parâmetros. Por exemplo, as bibliotecas de PHP para a Amazon Flexible Payments Services e a PayPal Payments Standard tentam habilitar a validação do nome do servidor no cURL, mas acidentalmente sobrescrevem o valor padrão correto e o desabilitam (Seções 7.1 e 7.2). Isso mostra que mesmo valores padrão seguros podem ser insuficientes. O Lynx tenta verificar certificados auto-assinados, mas confunde o significado do retorno da validação da função de verificação de certificação do GnuTLS, e o teste nunca é executado (Seção 7.4).
NÃO delegue a responsabilidade pelo gerenciamento das conexões SSL às aplicações. As bibliotecas SSL existentes expõem muitas opções para aplicações de alto nível. Isso é muito perigoso. Os desenvolvedores de aplicações podem não perceber que devem escolher explicitamente certas opções para habilitar a validação dos certificados. Ao mesmo tempo, as bibliotecas devem utilizar opções padrão seguras tanto quanto for possível. Além disso, não devem pular funcionalidades importantes como verificação do nome do servidor como faz o JSSE quando o campo algoritmo é nulo ou uma string vazia. Ao contrário, devem disparar uma Runtime Exception ou informar a aplicação de alguma outra forma.
FAÇAM um desenho claro e consistente da interface de relato de erros. Bibliotecas como OpenSSL e GnuTLS relatam alguns erros via retorno de valores de função, enquanto outros erros da mesma função são relatados por uma flag passada como argumento. Interfaces inconsistentes confundem os desenvolvedores, que então erroneamente omitem algumas checagem de erros nas suas aplicações.
Algumas empresas e organizações estão trabalhando nas falhas apontadas na pesquisa e estão relatando os resultados de volta aos pesquisadores, que os estão publicando na FAQ. Para o benefício dos desenvolvedores que lidam com SSL, a ISec Partners tinha liberado três ferramentas que testam as vulnerabilidades expostas na pesquisa.