Originalmente desenvolvido para navegadores, o protocolo SSL / TLS mais tarde se tornou o padrão de fato para todas as comunicações seguras da Internet. Agora é usado para administração remota da infraestrutura virtual implantada na nuvem, para transferir detalhes de pagamento de clientes de servidores de comércio eletrônico para processadores de pagamento como PayPal e Amazon, para enviar dados locais para armazenamento em nuvem, salvar correspondência em mensageiros instantâneos e autenticação de servidor em aplicativos móveis iOS e Android.

A lista de situações em que a troca de informações altamente confidenciais requer segurança máxima é bastante impressionante. Neste artigo, examinaremos como a segurança dessas comunicações é garantida na prática.

- Protocolo SSL / TLS: eles queriam o melhor ...
- ... mas acabou como sempre: exemplos de falha na verificação do certificado SSL / TLS
- Vulnerabilidades lógicas do protocolo SSL / TLS
- Outras vulnerabilidades comuns de implementação de protocolo SSL / TLS
- A causa raiz das vulnerabilidades no protocolo SSL / TLS
- Uma colher de mel em um barril de alcatrão

Protocolo SSL / TLS: queríamos o melhor ...

Em teoria, uma conexão segura de protocolo SSL / TLS deve garantir a confidencialidade, confiabilidade e integridade das comunicações de software de cliente e servidor, mesmo na presença de um invasor avançado ativo da rede: quando a rede é completamente tomada pelo inimigo, o DNS é envenenado e os pontos de acesso e roteadores, switches e o WiFi são controlados por um invasor; um invasor que, entre outras coisas, controla um back-end SSL / TLS. Além disso, quando o software cliente tenta se conectar a um servidor legítimo, um invasor pode alterar o endereço de rede do servidor (por exemplo, através de envenenamento por DNS) e, em vez de um servidor legítimo, redirecionar o cliente para seu servidor malicioso.

A segurança das comunicações em condições tão adversas, como você sabe, depende inteiramente da adequação da verificação do certificado criptográfico fornecido pelo servidor ao estabelecer a conexão. Incluindo a adequação da implementação de um conjunto de cifras (ciphersuite), que o cliente e o servidor usam ao trocar dados. Para que a conexão SSL / TLS seja completamente segura, o software cliente, entre outras coisas, deve verificar cuidadosamente se:

• certificado emitido pelo atual organismo de certificação;
• seu período de validade não expirou (ou o certificado não foi revogado);
• a lista de nomes listados no certificado contém o domínio ao qual você está se conectando.

... mas acabou como sempre: exemplos de falha na verificação do certificado SSL / TLS

No entanto, em muitos aplicativos e bibliotecas para os quais a segurança da comunicação é muito crítica, o procedimento para verificar um certificado SSL / TLS - e até EV-SSL, um certificado de verificação avançado [4] - é completamente malsucedido. Em todos os sistemas operacionais populares: Linux, Windows, Android e iOS. Entre os serviços vulneráveis ​​de software, bibliotecas e middleware, é possível distinguir o seguinte [1]:

• A biblioteca Java EC2 da Amazon e todos os clientes front-end baseados em nuvem criados com base nisso.
• O SDK comercial da Amazon e do PayPal, responsável pela entrega dos detalhes de pagamento dos sites (nos quais a infraestrutura do comércio on-line está implantada) até os gateways de pagamento.
• “Cestas” integradas, como osCommerce, ZenCart, Ubercart e PrestaShop, que não validam certificados.
• Código da AdMob usado pelo software para celular para exibir publicidade contextual.
• Interface dos componentes front-end ElephantDrive e FilesAnywhere, responsáveis ​​por interagir com o armazenamento em nuvem.
• A biblioteca Pusher Android e todo o software que usa a API Pusher para controlar as mensagens instantâneas (por exemplo, Gaug.es do GitHub).
• Apache HttpClient (versão 3.x); Apache Libcloud e todas as conexões do cliente com servidores Apache ActiveMQ, etc.
• Serviços de middleware Java SOAP, incluindo Apache Axis, Axis 2, Codehaus XFire; bem como todo o software criado com base nesses serviços de middleware.
• Ferramentas da API do Elastic Load Balancing
• Weberknecht implementação de WebSockets.
• Assim como todos os softwares móveis criados com base nas bibliotecas e nos serviços de middleware listados acima (para entender o que são os serviços de middleware, consulte a Figura 1); incluindo o cliente iOS do provedor de hospedagem Rackspace.

Figura 1. O que são serviços de middleware

Além disso, em [2] ainda são listadas mais de cem aplicações móveis vulneráveis ​​(veja a Fig. 2). Incluindo: Google Cloud Messaging do Android, senhas da lista Angie da lista de negócios, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (acesso remoto), suporte técnico da Cisco, Cisco Webex, senhas Cisco WebEx, Dominos Pizza, E-Trade, Freelancer , Google Earth, Huntington Mobile (banco), contador online da Intuit Tax, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (cliente VPN), SouthWest Airlines, Uber, banco dos EUA - Access Online, WesternUnion, WordPress, Yahoo! Finanças, Yahoo! Mail

Figura 2. Uma pequena seleção da lista de aplicativos móveis vulneráveis

Vulnerabilidades lógicas SSL / TLS

As conexões SSL / TLS de tudo isso e muitos outros softwares são vulneráveis ​​a uma ampla variedade de ataques MiTM. Ao mesmo tempo, um ataque MiTM pode ser realizado, muitas vezes mesmo sem falsificar certificados e sem roubar as chaves privadas pelas quais os servidores assinam seus certificados. Um ataque MiTM pode ser realizado simplesmente explorando as vulnerabilidades lógicas presentes no procedimento de verificação do certificado SSL / TLS no lado do software cliente. Como resultado, um invasor do MiTM pode, por exemplo, coletar tokens de autorização, números de cartão de crédito, nomes, endereços etc. - de qualquer comerciante que use aplicativos da Web vulneráveis ​​para processamento de pagamentos.

Os fornecedores de software para dispositivos móveis, que usam o código de exemplo da AdMob para conectar seus aplicativos à conta da AdMob, também são vulneráveis ​​- eles permitem que um invasor capture credenciais e obtenha acesso a todos os seus serviços do Google. Por exemplo, devido à verificação incorreta de certificados em mensageiros como Trillian e AIM, um invasor do MiTM pode roubar credenciais de login para todos os serviços do Google (incluindo o Gmail), Yahoo!; e também aos serviços do Windows Live (incluindo o SkyDrive). Outras vulnerabilidades que afetam o software moderno sem navegador da Web incluem: o uso de expressões regulares incorretas ao comparar um nome de host; ignorando resultados de validação de certificado; encerramento acidental ou intencional da verificação. [1]

Outras vulnerabilidades comuns de implementação de protocolo SSL / TLS

E, é claro, não devemos esquecer que, mesmo que não haja erros lógicos na implementação do protocolo SSL / TLS (a menos que alguém ainda acredite nele), a proteção pode ser ignorada roubando a chave privada [12], usando 0 dia- explorações para coisas como teclados, navegadores, sistemas operacionais, utilitários e firmware [3]; comprometendo o roteamento BGP [10]; ou atacar SSL / TLS sobre hardware (veja a Figura 3) [8] e / ou software [9] desviar de canais.

Figura 3. Ataque SSL no desvio de hardware

Além disso, os invasores podem realizar ataques MiTM praticamente invisíveis, abusando do mecanismo de cache de sessão SSL / TLS implementado na classe SSLSessionCache. Esse mecanismo verifica a validade dos certificados somente na conexão inicial; nem é capaz de cancelar adequadamente uma sessão de comunicação após excluir certificados do dispositivo. Além disso, após a reinicialização do dispositivo Android (através das opções "Reiniciar" ou "Desligar"), você pode continuar vendo o tráfego criptografado de alguns aplicativos que não foram iniciados após a reinicialização, mas funcionaram antes da reinicialização. Então, por exemplo, com o Google Maps acontece. Em [2], é descrito como, graças a essas falhas de armazenamento em cache, um invasor pode definir e remover completamente de forma transparente "certificados invisíveis" para o usuário e, em seguida, estabelecer uma conexão de rede com qualquer aplicativo.

Figura 4. Retrospectiva da criptografia vulnerável

Outras vulnerabilidades comuns na implementação do protocolo SSL / TLS incluem criptografia vulnerável (veja a Figura 4) [5], reutilização do GCM (Galois / Counter Mode; contador com autenticação Galois) [6], truque com CNG (CryptoAPI-NG ) no Schannel (consulte a Fig. 5) [7], verificação incorreta da cadeia de confiança [2], verificação incorreta do nome do host [11].

Figura 5. Truque de CNG: extraindo segredos do Schannel

Uma verificação incorreta da cadeia confiável é uma situação em que o aplicativo Web aceita absolutamente qualquer certificado que indique o nome do host correto, sem verificar com que autoridade de certificação foi assinado. Isso permite interceptar e descriptografar senhas e / ou números de cartão de crédito. E, em alguns casos, até injeta código malicioso. No software Android, essa vulnerabilidade penetra, por exemplo, quando é criada uma interface personalizada do X509TrustManger que ignora as exceções do CertificateException. Ou quando um desenvolvedor de software insere uma chamada para o método SslErrorHandler.proceed () no código de um componente WebViews. [2]

Uma verificação incorreta do nome do host é uma situação em que um aplicativo Web aceita um certificado sem garantir que o host do qual este certificado veio esteja na lista de hosts confiáveis. No software Android, essa vulnerabilidade penetra, por exemplo, quando uma interface HostnameVerifier é criada, que retorna VERDADEIRO sob quaisquer condições. Ou quando um desenvolvedor de software insere uma chamada para o método SslErrorHandler.proceed () no código de um componente WebViews. [2]

A causa raiz das vulnerabilidades no protocolo SSL / TLS

A causa raiz da grande maioria dessas vulnerabilidades é o terrível design de API das bibliotecas SSL / TLS (incluindo JSSE, OpenSSL e GnuTLS). Além do design igualmente terrível das bibliotecas de transferência de dados (como cURL, Apache HttpClient e urllib), cada uma delas é um wrapper de alto nível para bibliotecas SSL / TLS. Sem mencionar os serviços de middleware (como Apache Axis, Axis 2 ou Codehaus XFire), que são um invólucro de nível ainda mais alto e que aumentam ainda mais a “bola de neve” do design terrível. Em vez de dialogar com um desenvolvedor de aplicativos (muitas vezes longe da programação do sistema) em um idioma que ele entende (em termos de confidencialidade e autenticação), abstraído dos detalhes de baixo nível da implementação do protocolo SSL / TLS, essas APIs descartam vários parâmetros SSL / TLS de baixo nível sobre o pobre rapaz incompreensível para ele. Eles exigem software de alto nível para expor corretamente as opções de baixo nível; implementa funções de verificação de nome de host e cuida da interpretação dos valores retornados por operações de baixo nível.

Como resultado, os desenvolvedores de aplicativos usam a API SSL / TLS incorretamente: interpretam por engano a variedade de seus parâmetros, opções, efeitos colaterais e valores de retorno. Por exemplo [1]:

• A biblioteca PHP do Serviço de pagamentos flexíveis da Amazon tenta habilitar a validação de nome de host definindo o parâmetro CURLOPT_SSL_VERIFYHOST como TRUE (na biblioteca cURL). No entanto, o valor padrão correto para este parâmetro é 2; se você atribuir a ele um valor TRUE, esse parâmetro será invisível para o desenvolvedor atribuído o valor 1 e assim por diante. a verificação de certificado está desativada.
• Biblioteca PHP PayPal Payments Standard - obteve o mesmo erro; Além disso, no momento em que a implementação anterior vulnerável foi atualizada (ou seja, um erro foi removido, outro foi adicionado).
• Outro exemplo é o Lynx, um navegador orientado a texto. Ele verifica certificados autoassinados - mas somente se a função de verificação de certificado GnuTLS retornar um valor negativo. No entanto, essa função retorna 0 para alguns erros; inclusive nos casos em que os certificados são assinados por um organismo não confiável. Por esse motivo, a cadeia de confiança no Lynx está quebrada.

Além disso, os desenvolvedores de aplicativos geralmente entendem mal que tipo de segurança garante uma determinada biblioteca SSL / TLS. Portanto, na natureza, é possível encontrar casos clínicos em aplicativos que precisam fundamentalmente de comunicações seguras (por exemplo, interagindo com um processador de pagamento), é usada uma biblioteca SSL / TLS que não verifica os certificados SSL / TLS. Casos mais prosaicos, mas ainda mais assassinos, são quando o desenvolvedor de qualquer uma das camadas intermediárias de software desativa silenciosamente o procedimento de verificação de certificados SSL / TLS (ele pode fazer isso, por exemplo, para testar o sistema e, após o teste, esquecer de reativá-lo). Ao mesmo tempo, o código de programa de alto nível usando essa camada intermediária garante que a verificação do certificado seja realizada. T.O. Os erros de SSL / TLS geralmente estão ocultos nas profundezas de uma ou várias camadas intermediárias de bibliotecas ao mesmo tempo - tornando quase impossível detectar esse problema.

Por exemplo, em JSSE (Java Secure Socket Extension), a interface estendida da API SSLSocketFactory ignora silenciosamente a verificação do nome do host se o campo "algoritmo" no cliente SSL estiver definido como NULL ou em uma cadeia vazia e não em HTTPS. Embora esse fato seja mencionado no guia de referência JSSE, muitas implementações de protocolo Java SSL usam SSLSocketFactory sem executar a validação de nome de host ...

Uma colher de mel em um barril de alcatrão

Assim, de fato, verifica-se que na maioria dos softwares da web que não são navegadores, a verificação de certificados SSL / TLS é completamente desativada ou implementada incorretamente. A Figura 7 mostra a classificação das vulnerabilidades atuais do protocolo SSL / TLS. Algumas dessas vulnerabilidades, mas não todas, foram descritas e / ou mencionadas acima. Você pode se familiarizar com as vulnerabilidades mencionadas, mas não descritas, lendo os materiais listados na bibliografia.

Figura 6. Classificação de vulnerabilidades relevantes para SSL / TLS

Bem, para adicionar uma colher de mel ao barril de alcatrão, vale a pena notar que em [1] foi descrito em detalhes / claramente / popularmente / com competência como o SSL deve ser implementado, com referência à RFC. Nunca encontramos uma descrição melhor, que seria tecnicamente precisa e ao mesmo tempo compreensível. Também em [1], as bibliotecas SSL mais comuns são analisadas, com classificação de acordo com o nível de abstração (nível baixo / nível alto). Tudo com diagramas e algoritmos concisos em pseudo-código. As vulnerabilidades de produtos específicos são descritas em detalhes, com códigos e códigos de erro incorretos. Então, se de repente alguém mais uma vez deseja criar essa implementação da estrutura SSL / TLS, que será uma exceção ao ditado "eles queriam o melhor, mas acabou como sempre", então [1] é o começo ideal para isso.