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
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.
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\
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