Imagine um cenário em que para se identificar os membros de uma família bastaria um Bilhete de Identidade (ou Cartão de Cidadão) para cada grupo etário. Ou seja, em média, numa família teríamos 3 Bilhetes de Identidade: o das Crianças – com os dados de todas as crianças, o dos Jovens – com os dados de todos os jovens, e o dos Adultos – com os dados de todos os adultos. Seria um documento estranho, mas bastaria estar lá o nome do membro e ele teria o direito de receber uma cópia e usá-la. Agora, acrescente o detalhe de que os Bilhetes de Identidade possuiriam uma Chave que daria acesso a zonas da casa de acordo com o grau de maturidade do grupo etário. Por exemplo, uma criança teria acesso ao quarto de brincar, mas não ao escritório aonde se encontra o cofre das jóias. Com esse cenário em mente, concordaria que seria perigoso se uma criança tivesse os seus dados no Bilhete de Identidade dos adultos, recebesse a sua cópia e, por descuido e imaturidade, a deixasse cair nas mãos de um bandido?

Pois é, assim também podem funcionar os Certificados Digitais, no seu duplo papel de garantir a Identidade de um Sujeito (ou grupo de sujeitos) e a Distribuição da sua Chave Criptográfica, exigindo por essa razão um tratamento seguro para se evitar dissabores. Caso tenha concordado com a questão no final da analogia, então poderá compreender a minha inquietação ao ver os detalhes do Certificado Digital de um dos portais web de uma proeminente instituição angolana.

Em resumo, o próprio Certificado Digital, apesar de válido e funcional, representava um Risco à Segurança. Nos detalhes, a lista de SANs (Subject Alternative Name – nomes alternativos do sujeito) continha não só os dados dos portais web do ambiente de Produção (PRD = Adultos), como também dos ambientes de Homologação (HML = Jovens) e Desenvolvimento (DEV = Crianças), num total de 23 portais web. Esse facto representava as seguintes vulnerabilidades: (1) a divulgação dos ambientes de desenvolvimento adoptados pela instituição; (2) a fácil enumeração (colecta de informação) sobre os outros activos tecnológicos; (3) a exposição de activos tecnológicos com políticas de segurança menos rigorosas (HML e DEV); e por último, sendo o mais crítico, (4) a reutilização do mesmo Par de Chaves Criptográficas do ambiente de Produção nos outros ambientes (HML e DEV) – acção que foi confirmada a sua ocorrência conforme demonstrado mais abaixo.

Bilhete de Identidade dos adultos com dados de jovens e crianças.

Antes de avançar para os detalhes, vale relembrar que no caso das ligações HTTPS (“com o cadeado no navegador”), os Certificados Digitais têm dois propósitos: conferir credibilidade à identidade do servidor e difundir a sua Chave Pública que será sempre usada no processo de estabelecimento do canal de comunicação seguro entre o servidor e os seus visitantes. Essa chave pública tem o seu par, a Chave Privada, que deve permanecer protegida no servidor e ser manipulada com segurança respeitando os princípios, políticas e procedimentos da Gestão de Chaves [Criptográficas] (Key Management) para que nunca seja comprometida enquanto ainda estiver dentro do seu tempo de uso (criptoperíodo).

Assim, considerando os princípios da Gestão de Chaves [Criptográficas] e o pilar da Confidencialidade, apesar de estarmos perante um certificado SSL/TLS fidedigno do tipo Wildcard, daqueles que permitem a protecção de um domínio e de todos os seus subdomínios (*.meusite.com), uma observação minuciosa revelou os seguintes aspectos:

1. Divulgação dos Ambientes de Desenvolvimento

Apesar de aparentemente inofensivo, a divulgação de detalhes sobre os ambientes de desenvolvimento definidos pela organização pode ser usada durante a fase preparatória de um ataque. A expectativa da existência de uma vasta superfície de ataque poderá alimentar o empenho de um potencial agente malicioso.

2. Enumeração (colecta de informação) dos activos

A lista de SAN é também um elemento usado na primeira fase de um ataque cibernético: a enumeração ou colecta de informação. Nessa fase, o agente malicioso colecta o maior número de informações sobre a potencial vítima para traçar a sua estratégia inicial de ataque.

3. Exposição de activos com políticas de segurança pouco rigorosas

Pela natureza das acções realizadas nos Ambientes de Teste e Homologação, é esperado que estejam activas configurações úteis para os desenvolvedores, como o debuggin e a exibição de mensagens de erros sem tratamento. O problema surgirá se um agente malicioso tiver acesso a esses ambientes e aproveitar-se das potenciais vulnerabilidades, tal como a de Divulgação de Informação (Information Disclosure), para aplicar os métodos e ferramentas de intrusão mais eficazes no ambiente alvo.

Por esse motivo, o nível de exposição desses ambientes deve ser reduzido ao mínimo necessário para viabilizar o negócio, salvaguardando sempre a segurança.

4. Reutilização do Par de Chaves Criptográficas entre ambientes

Apesar de ter sido possível identificar a existência de outros dois certificados dedicados aos respectivos Ambientes de Teste e Homologação, o que reforça o facto da instituição seguir o princípio da segregação de ambientes, foi possível identificar em 3 ocasiões o uso do Certificado do ambiente de Produção no ambiente de Homologação, ou seja, 3 jovens receberam e puderam usar o Bilhete de Identidade de adulto porque os seus dados lá constavam por descuido.

Tendo em conta o rigor exigido na actividade de Gestão de Chaves [Criptográficas], esse facto já representava um incidente de segurança que culminaria com a Revogação da Chave e respectivo Certificado por comprometimento, sendo necessária a geração do novo par de chaves e certificado e a devida substituição para a continuidade do negócio.

A entidade foi notificada e prontamente deu início ao tratamento da ocorrência. A principal recomendação de resolução passou pela geração do novo Par de Chaves Criptográficas e emissão do novo Certificado Digital, retirando os SANs desnecessários, principalmente os dos 12 portais web dos ambientes de Homologação e Desenvolvimento.

HTTPS não é sinónimo de total segurança!

O HTTPS não é uma super capa protectora! Devemos estar conscientes que poderão existir várias pontas soltas, inclusive no próprio Certificado Digital, que poderão ser exploradas pelos malfeitores. Sem que os outros procedimentos e controlos de segurança sejam garantidos e se realizem testes periódicos, todo o esforço dedicado à segurança poderá ser anulado.

Adicionalmente, as equipas técnicas deverão sempre garantir o rigor e segurança na Gestão de Chaves [Criptográficas] principalmente se estiverem a actuar em indústrias mais exigentes como a Financeira, Telecomunicações e Defesa e Segurança. Mesmo que recorram a Certification Authorities (CA) externas ou façam a gestão de uma PKI (Public Key Infrastructure) interna, deverá sempre existir um racional quando estiverem a lidar com a Gestão de Certificados Digitais.