Não é todo dia que você pode aplicar as lições da criptoanálise da Segunda Guerra Mundial aos seus próprios aplicativos Web. Mas, hoje, é exatamente isso que faremos. Na verdade, veremos como até mesmo uma das mais poderosas ferramentas criptográficas modernas pode ser derrotada pelo mesmo método que Alan Turing usou para quebrar a máquina Enigma - que era a ferramenta criptográfica mais poderosa de sua época - se os implementadores cometerem os mesmos erros na transmissão de mensagens que Turing encontrou.
Vamos dar uma olhada em uma API que avaliei recentemente, para ver como ela evitou o problema que ajudou os Aliados a vencer as potências do Eixo na Segunda Guerra Mundial.
Uma API de comércio eletrônico: Um pote de mel bem doce
O exemplo que analisarei hoje é a API de uma empresa de comércio eletrônico para aceitar pagamentos. No que diz respeito a alvos de ataque, não há muitos mais valiosos para os agentes mal-intencionados atacarem do que uma API de pagamento com cartão de crédito. É por isso que essa empresa decidiu expor ao mundo uma chave pública por meio da qual os consumidores da API poderiam criptografar todas as informações de cartão de crédito enviadas para processamento de pagamento.
É isso mesmo, todos os dados enviados por esse formulário seriam criptografados e nunca enviados em texto simples. Isso ocorre porque é importante proteger todos os dados contra ataques, não apenas o número do cartão. A data de validade e o CVV fazem parte do pacote que torna único qualquer método de pagamento específico, portanto, essa empresa tinha tudo criptografado. A empresa nunca enviaria nenhum desses dados em texto simples.
Veja a seguir a aparência de uma solicitação de amostra ao atravessar o fio, usando um Charles Proxy para capturar o tráfego como um man-in-the-middle:
Observe neste exemplo que há dois valores com hash: paymentHash e cvvHash. Vamos pensar nos dados que estão contidos nesses dois valores.
Para paymentHash, temos o número do cartão de crédito de 16 dígitos, criptografado usando a chave pública publicada para uso nesta API. Obviamente, haverá muita variação nos valores disponíveis para a criptografia.
Para cvvHash, não temos a mesma situação! Os CVVs têm apenas 3 dígitos. Se você criptografar apenas combinações de três dígitos, um invasor poderá criar um dicionário completo de apenas 1.000 valores diferentes (10 valores para cada um dos 3 dígitos). Com esse dicionário, ele pode encontrar o CVV de qualquer cartão enviado por essa API. Felizmente, meu cliente sabia como evitar ataques conhecidos de texto simples e já havia implementado o preenchimento aleatório para evitar o mesmo ataque que derrubou os nazistas.
Desvendando o enigma
Em parte, a máquina Enigma era tão difícil de decifrar porque tinha uma estrutura muito complexa para criptografar mensagens e as configurações eram alteradas com frequência. No entanto, como a máquina era usada para mensagens militares, a equipe de Turing em Bletchley Park começou a procurar um texto que poderia ser esperado em muitas das mensagens.
Um tipo de mensagem enviada com frequência pelos militares alemães era um boletim meteorológico, e esses boletins incluíam a palavra alemã para "clima" no mesmo local em todas as mensagens, seguida das condições meteorológicas conhecidas. Outro exemplo foi o fato de que muitas mensagens terminavam com "Heil Hitler" e alguns operadores usavam saudações padrão. Essas ocorrências também permitiram determinar alguns dos textos simples e configurações de cada dia.
Esse tipo de vulnerabilidade de criptografia é o que poderia estar presente se essa empresa de comércio eletrônico não tivesse usado preenchimento aleatório para o CVV, porque o número de valores possíveis é muito pequeno.
Evitando o mesmo erro
Ao usar um pad aleatório, a empresa garantiu que dois métodos de pagamento com o mesmo CVV não revelariam nada sobre o que estava sendo transmitido. Aqui estão alguns exemplos de como o mesmo valor de "777" poderia ser criptografado para ter valores diferentes com o uso de um pad:
$ echo -n 777 | openssl rsautl -inkey public_key.pem -pubin -pkcs |
Como você pode ver, os comandos executados acima são todos iguais, mas, devido aos padrões em vigor na criptografia RSA, os valores gerados são completamente diferentes.
Bons algoritmos de criptografia não são suficientes
Esse exemplo deve ajudá-lo a entender que não basta apenas implementar um bom esquema de criptografia. Mesmo com algoritmos de criptografia altamente sofisticados, se a mesma entrada for usada várias vezes, é possível que isso exponha os dados que você está tentando transmitir com segurança. É muito importante, especialmente ao lidar com informações de pagamento, certificar-se de que não seja fácil adivinhar os valores que estão sendo enviados pelo cabo.
Outro exemplo em que o preenchimento é importante é o armazenamento de senhas. Os desenvolvedores sabem que precisam usar uma boa função de hash unidirecional para garantir que nem mesmo eles consigam ler as senhas que seus usuários estão enviando. Para isso, os desenvolvedores devem adicionar uma string aleatória (chamada salt ) a qualquer senha antes de fazer o hash.
Conclusão
Criar segurança em seus aplicativos da Web é uma tarefa extremamente importante. Certificar-se de que os dados confidenciais dos seus usuários não sejam facilmente descriptografados gera a confiança do cliente e garante a longevidade da sua empresa. Afinal de contas, ninguém quer a cobertura da mídia de que seu site vazou informações de pagamento dos clientes. Se você conseguir garantir que não criptografe exatamente os mesmos valores repetidas vezes, evitará um erro muito básico e também manterá os dados de seus clientes seguros.
Para saber mais sobre as práticas recomendadas de segurança, confira o extenso conjunto de guias de segurança da Linode!
Comentários