http://www.cic.unb.br/~rezende/sd.htm > Certificados: vulneraçães

Risco no uso de certificados digitais
de chave pública

Análise de Vulnerabilidades nos navegadores com SSL

Trabalho da Disciplina Segurança de Dados 2/01

Alan Neiva Freitas e Hansenclever de França Bassani *
Departamento de Ciência da Computação
Universidade de Brasília
Setembro de 2002

ATENÇÃO:  Os autores e o editor não se responsabilizam pela utilização do conteúdo desse trabalho por terceiros para fins ilícitos. Os objetivos aqui são educacionais.
1. Introdução

Este trabalho visa explorar os mecanismos utilizados pelos browsers web com relação aos certificados auto-assinados. Esse tipo de certificado tem importância chave nas PKIs (Infra-estruturas de chave pública), pois são eles que finalizam as cadeias de autenticação SSL. São tidos como íntegros pelo protocolo, podendo assinar outros certificados. Fica evidente então a importância de se fazer uma análise de falhas sobre o tema, de modo a identificar pontos que eventualmente possam vir a vulnerar as proteções oferecidas ao uso de PKIs através de browsers web.

O estudo aqui apresentado foi desenvolvido no sistema operacional Microsoft Windows 98 SE. Dois browsers web foram analisados: Internet Explorer 5.0 e Opera 5.12. Qualquer outro software utilizado será citado oportunamente no texto.
 

2. Geração de certificados auto-assinados

Para iniciar o nosso estudo era necessário que fôssemos capazes de gerar certificados, auto-assinados ou não. Por meio de pesquisa na WWW encontramos o projeto OpenSSL ( http://www.openssl.org ), cujo um dos objetivos é desenvolver um kit de ferramentas implementando os protocolos SSL e TSL em código aberto. O binário OpenSSL formato Win32 foi baixado para tentarmos a geração dos certificados.

Para a geração dos certificados, criamos duas companhias fictícias: a TruthMaster Certificate Authority, autoridade certificadora, e sua cliente, a Liar&Liar Co. Seus dados foram inseridos quando solicitados pelo OpenSSL.

Após pesquisa na documentação do software e em sites tutoriais, chegamos aos seguintes passos para a criação dos certificados:

1) Criação da chave da TruthMaster (TM)

openssl genrsa -des3 -out chave_ca.key 1024

2) Criação da chave da Liar&Liar (L&L)

openssl genrsa -des3 -out chave_req.key 1024

3) Geração do certificado auto-assinado da TM

openssl req -new -key chave_ca.key -x509 -days 365 -out cert_ca.crt -config openssl.conf

4) Requisição de assinatura de certificado para L&L por TM

openssl req -new -key chave_req.key -out req_cert.csr -config openssl.conf

5) Assinatura da requisição

openssl ca -keyfile chave_ca.key -cert cert_ca.crt -in req_cert.csr -out cert_ass.pen -outdir c:\openssl\newcerts -days 100 -config openssl.conf

6) Conversão para formato crt

openssl x509 -in cert_ass.pen -out cert_ass.crt
 

Ao fim do processo temos os dois arquivos desejados: cert_ca.crt , o certificado auto-assinado da TruthMaster e cert_ass.crt , certificado da Liar&Liar também assinado pela TruthMaster.

O arquivo openssl_proj.exe , arquivo compactado com auto-extração contendo o OpenSSL, assim como todos os arquivos gerados no processo descrito acima pode ser baixado do site do projeto
 

3. Instalação de certificados auto-assinados
 

É oportuno analisar, antes de mais nada, o procedimento da instalação de certificados auto-assinados pelos browsers. Para isso abrimos o arquivo cert_ca.crt nesses aplicativos.

Internet Explorer

Ao abrirmos o certificado auto-assinado no IE é exibida a seguinte janela:
 
 


Podemos verificar que é exibida uma mensagem de alerta, afirmando que o certificado de CA (Autoridade Certificadora) não é confiável, além oferecer a opção de instalar o certificado, "habilitando a confiança". Apesar de ser um alerta inclusive visual (ícone do certificado com cruz vermelha) não é seguro afirmar que ele é suficiente para evitar que o usuário instale o certificado sem saber o que de fato está ocorrendo: a linguagem utilizada talvez seja deveras obscura para o leigo, e não há possibilidade, através dessa janela, de se obter maiores informações. Além disso há a tendência do usuário comum de se clicar rapidamente nos botões das caixas de diálogo, ignorando a leitura das informações. Ao menos o botão que instala o certificado não é o que tem o texto "OK".

Opera

Essa é a janela exibida ao abrirmos o certificado auto-assinado:
 



Pode-se atestar que é um certificado auto-assinado verificando que os campos "Certificado" e "Avalista" estão preenchidos com "TruthMaster Certificate Authority". Entretanto para o leigo isso provavelmente não é suficientemente informativo, e o botão "Ajuda" é completamente inoperante. No Opera o risco do usuário comum instalar o certificado sem saber as conseqüências disso parece ser ainda maior que no IE: não há alerta.
 

4. Investigação sobre o armazenamento dos certificados auto-assinados

Estávamos interessados em saber como os certificados auto-assinados eram armazenados depois de instalados. Baseados na arquitetura do Windows tínhamos como prováveis duas opções:  armazenamento no registro do sistema, ou em um arquivo. Precisávamos então de ferramentas que nos permitissem monitorar os acessos ao registro e ao sistema de arquivos. Dois programas foram utilizados, listados a seguir:

Regsnap (http://lastbit.com/regsnap/default.asp ) : é uma ferramenta que auxilia a análise das alterações feitas no registro do Windows. Podem ser salvos "instantâneos" que posteriormente podem ser comparados uns com os outros, evidenciando as modificações. Ele também gera relatórios em HTML e arquivos .REG utilizados para adicionar e remover chaves do registro.

Filemon (http://www.sysinternals.com/ntw2k/source/filemon.shtml ): monitora e exibe a atividade do sistema de arquivos em tempo real, listando cronologicamente aberturas, leituras, escritas ou deleções.

Salvamos instantâneos do registro antes e depois de instalar o certificado em cada browser, além de monitorarmos os acessos feitos aos arquivos durante o processo. Os resultados são os seguintes:

Internet Explorer

Não foi verificada atividade no sistema de arquivos que pudesse indicar o armazenamento do certificado em outro arquivo além do registro. Analisamos então a comparação feita pelo Regsnap entre o instantâneo prévio e o posterior à instalação do certificado. Geramos então o relatório em HTML que pode ser acessado aqui.

Foi constatada a adição da chave HKEY_USERS\.DEFAULT\Software\Microsoft\SystemCertificates\Root\Certificates\

7301545C2D6EA91327E2FA9ECA9A612EC81A32A1\Blob, do typo REG_BINARY e valor com comprimento de 1135 bytes. É possível identificar na área que exibe os bytes como caracteres ASCII os dados da TruthMaster CA, confirmando que essa chave contém o certificado auto-assinado que instalamos. Verifica-se que o número 7301545C2D6EA91327E2FA9ECA9A612EC81A32A1 presente no caminho da chave é o thumbprint do certificado (algoritmo sha1).

Para testarmos se a inclusão do certificado pode ser feita externamente, primeiramente ele foi excluído via "Opções de Internet" no Painel de Controle. Utilizamos a função de exportar arquivos .REG do Regsnap, gerando o arquivo diferenca.reg, disponível aqui, cuja execução teria como efeito causar no registro as mesmas alterações evidenciadas na comparação entre os instantâneos, ou seja, a instalação do certificado auto-assinado.

Executamos o arquivo diferenca.reg e em seguida verificamos quais os certificados instalados via Painel de Controle. O certificado auto-assinado pareceu ter sido instalado corretamente. Para confirmar executamos o arquivo cert_ass.crt, certificado da Liar&Liar assinado pela TruthMaster. O resultado aparece na figura seguinte:
 



De fato houve reconhecimento da assinatura da TM, o que comprova que o certificado auto-assinado foi instalado com êxito. Está demonstrado que essa instalação pode ocorrer externamente ao browser IE, e de forma sorrateira.

Opera

No caso do Opera a comparação entre instantâneos do RegSnap não revelou nada de relevante. Entretanto o programa Filemon acusou leitura e escrita no arquivo opcacrt5.dat, presente no diretório de instalação do browser. O log que acusa isso está disponível aqui. Abrimos o arquivo opcacrt5.dat no editor hexadecimal AXE 3 (http://www.jbrowse.com/products/axe/), o que está ilustrado na seguinte figura:
 



Ao final do arquivo, na representação ASCII dos bytes pudemos verificar alguns dados do certificado auto-assinado da TruthMaster, o que sugere que o Opera adiciona ao final do arquivo opcacrt5.dat as informações do certificado. Para testarmos essa desconfiança, fizemos o seguinte:

- Excluímos o certificado via opções de segurança do Opera

- Abrimos novamente o arquivo opcacrt5.dat com o AXE 3. Anotamos qual era o offset do último byte do arquivo.
 



- Adicionamos o certificado novamente e mais uma vez abrimos o arquivo no AXE 3. Selecionamos os bytes a partir do offset anotado anteriormente até o final do arquivo.
 



- Copiamos esses bytes e os salvamos em outro arquivo, chamado trailer.dat
 



Os arquivos opcacrt5.dat.1 (versão inicial), opcacrt5.dat.2 (versão após a concatenação) e trailer.dat estão disponibilizáveis em arquivo compactado com auto-extração.

Para de fato testar se o que ocorria era uma mera concatenação de dados ao fim do arquivo opcacrt5.dat, precisávamos concatenar o arquivo trailer.dat ao final de um arquivo opcacrt5.dat SEM certificado TruthMaster instalado. Apagamos novamente o certificado via Opera e executamos o seguinte comando numa janela DOS:

COPY /B opcacrt5.dat + trailer.dat opcacrt5.dat

Que concatena o arquivo trailer.dat ao final de opcacrt5.dat, sobrescrevendo-o.

Restava-nos verificar no Opera se o certificado havia sido instalado com a concatenação de arquivos. Abrindo a janela que exibe os certificados instalados foi encontrado o certificado auto-assinado da TruthMaster. Como último teste abrimos o certificado de Liar&Liar, que resultou na seguinte janela:
 



A assinatura de TruthMaster foi reconhecida com êxito, o que demonstra a instalação sorrateira do certificado auto-assinado.
 

5. Cavalos de Tróia e certificados auto-assinados

Na seção anterior foi demonstrado como um certificado auto-assinado pode ser instalado sorrateiramente no Internet Explorer e no Opera. Nessa seção tentamos instalar um certificado com um programa cavalo de tróia nos aproveitando das fragilidades mostradas.
 

Internet Explorer

No caso do IE precisamos ser capazes de escrever no registro do Windows. Codificamos um aplicativo em Borland C++ Builder 5 que adiciona uma chave no registro com as características que desejamos. O programa tem uma caixa de texto para que a chave seja entrada (poderia ter sido retirada do arquivo diferenca.reg, mas parsear o arquivo não era o objetivo do trabalho), e o valor da mesma é lido do arquivo certificado.dat, que nada mais é do que um arquivo texto com os valores dos bytes da chave, um em cada linha. Na verdade certificado.dat foi criado a partir de rápida edição de diferença.reg. O código-fonte do programa, mais o binário e o arquivo certificado.dat. O programa está ilustrado na figura abaixo:
 



O teste com a chave inserida no registro utilizando o programa codificado por nós se mostrou bem-sucedido, ou seja, o certificado auto-assinado foi instalado, mostrando a viabilidade de se escrever um cavalo de tróia que faça isso de forma invisível ao usuário.

Opera

Para criarmos um cavalo de tróia que instale o certificado auto-assinado no Opera precisamos concatenar o arquivo trailer.dat ao opcacrt5.dat. Isso pode ser feito por um simples arquivo .BAT (que se dá ao luxo de apagar quaisquer rastros e a si próprio), ou por um programa feito por nós que concatena os arquivos(código e executável) .

Utilizando-se tanto o BAT como o programa a instalação do certificado foi bem-sucedida, o que mostra a viabilidade de se escrever um cavalo de troia que faça esse procedimento sem o conhecimento do usuário.
 

6. Conclusão

Pelo exposto pode-se concluir que a proteção oferecida pelo uso de PKIs pelos browsers web analisados é bastante frágil, uma vez que um cavalo de tróia pode instalar certificados auto-assinados sem a anuência do usuário. É importante frisar que ambos os browsers abordados na análise se mostraram vulneráveis, sendo que o Internet Explorer é extremamente popular. Recomenda-se ao usuário então que se preocupe em confirmar a legitimidade dos certificados instalados em sua máquina, assim como evitar a execução de software de  origem duvidosa.



* Alan Neiva Freitas e Hansenclever de França Bassani, Bacharelandos em Ciências da Computação da Universidade de Brasília, alunos da disciplina Segurança dos Dados em 1/02