Segurança do Browser

Os browsers quando foram lançados exibiam apenas textos (ASCII e HTML) e imagens (GIF e JPEG). Devido às limitações da linguagem HTML (Hyper-Text Markup Language), logo surgiram alternativas para ampliar a capacidade do browser para torná-lo mais dinâmico e interativo. Uma das primeiras iniciativas neste sentido foi a adoção dos helpers (aplicativos auxiliares) que evoluiram para os atuais plug-ins.

Os plug-ins são programas executáveis que permitem ao browser executar arquivos em formatos diferentes de HTML, como áudio, animações e acesso a banco de dados. Dois exemplos de plug-in bastante populares são o Abode Acrobat Reader e Macromidia Shockwave.

O grande problema dos plug-ins é que sua segurança está baseada na confiança em quem desenvolveu o aplicativo. Como o plug-in tem acesso irrestrito ao seu sistema, é possível ter acesso a informações no disco local, abrir conexões de rede ou introduzuir um Cavalo de Tróia. Neste caso, não só a estação poderá fircar comprometida, mas também sua rede interna.

Com a introdução de linguagens/tecnologias como Java, JavaScript, VBscript e ActiveX, o browser passou a receber código ativo pela rede, ou seja, o simples fato de se visitar um site na Internet já é o suficiente para receber um código malicioso que possa ter acesso a qualquer parte do seu sistema (processador, memória, discos e rede) e, até mesmo, desligar sua estação.

Os browsers, como Internet Explorer (IE) e Netscape Navigator (NN), possuem parâmetros de configuração que impedem que códigos deste tipo sejam executados, mas, por default, os browsers são configurados para permitir que qualquer código seja carregado e executado.

A seguir apresentamos os problemas de segurança em quatro tecnologias que permitem a implementação de código ativo: JavaScript, Java e ActiveX.

JavaScript

JavaScript, apesar do nome, não tem relação com a liguagem Java. A linguagem JavaScript é semelhante a C/C++ e foi desenvolvida pela Netscape, incorporada ao Navigator e, posteriormente, ao IE. JavaScript é uma linguagem interpretada, ou seja, o código é incluído dentro do próprio arquivo HTML, interpretado pelo browser e depois executado.

JavaScript possui limitações que garantem alguma segurança, como não permitir acesso a arquivos no disco da estação e impedir abrir conexões de rede com outros sistemas. Apesar destas limitações, JavaScript pode ser utilizada para ataques do tipo engenharia social e Denial of Service (DoS). A seguir, apresentamos alguns exemplos bastante simples de ataques utilizando JavaScript:

• O primeiro exemplo é conhecido como engenharia social. Neste tipo de ataque, a página solicita ao usuário que entre com sua senha. Na grande maioria dos casos, o usuário irá fornecer a senha pensando que a solicitação está vindo da rede interna, o que pode não ser verdade. Com uma senha válida é possível ao invasor começar o processo de rastreamento da rede interna. Veja o exemplo.
• O próximo exemplo realiza um ataque de Denial of Service (DoS) em seu browser. Depois de executado, a única maneira de encerra-lo é através de um [Ctrl-Alt-Del] e o término do aplicativo. Veja o exemplo.
• O código do último exemplo realiza um outro tipo de ataque de Denial of Service (DoS), agora em sua estação. Depois de executado, a única maneira de livrar-se do ataque é reinicializando o computador. Nem mesmo um [Ctrl-Alt-Del] vai livrá-lo do ataque. Veja o exemplo, mas lembre-se que sua máquina vai precisar de um reboot!

Applets Java

Java, desenvolvida pela Sun Microsystems, é uma linguagem poderosa, orientada a objetos e similar ao C++. Um programa escrito em Java deve ser compilado para gerar um código intermediário, independente de plataforma, conhecido como bytecode. De forma simplificada, quando uma applet Java chega ao seu browser, deve existir uma máquina virtual Java (Java Virtual Machine - JVM) que interprete o bytecode e traduza-o para o ambiente onde o browser está sendo executado. Tando o IE quanto o NN oferecem suporte a Java.

A preocupação com a segurança em Java começa pela própria linguagem que foi desenvolvida para reduzir as chances de erros por parte dos desenvolvedores, comuns em programas em C e C++. Mecanismos de alocação/desalocação de memória, manipulação de ponteiros e arrays foram implementados de forma a reduzir a chances de bugs nos programas desenvolvidos.

Para garantir a segurança do ambiente onde a applet é carregada, Java cria uma sandbox (caixa de areia), onde o código é executado de forma a ter acesso restrito e controlado aos recursos do ambiente onde está sendo processado. Além da sandbox, a segurança do Java envolve mais três componentes: Java Class Loader, Bytecode Verifier e Java Security Manager.

Em geral, applets Java não têm permissão de ler, gravar, alterar ou eliminar qualquer arquivo no disco da estação onde o código está sendo executado. Além disto, applets não podem abrir conexões de rede, ter acesso direto ao hardware ou iniciar outros aplicativos no cliente.

Apesar do mecanismo de sandbox, uma applet Java pode causar diferentes ataques do tipo Denial of Service (DoS) no browser, como loop infinito, alocação de grandes áreas de memória, problemas no arquivo de paginação e/ou swap, criação de inúmeras janelas levando o sistema a problemas de pilha etc. O maior problema na segurança do Java surge da complexidade da implementação da sandbox. Inúmeros bugs já foram encontrados e documentados, como podemos observar no site "A Collection of Increasingly Hostile Applets".

ActiveX

Componentes ActiveX são programas executáveis, desenvolvidos em uma linguagem de programação qualquer, como C, C++ ou Visual Basic, e encapsulados em um arquivo OCX. Um componente ActiveX, depois de carregado pelo browser, tem acesso irrestrito a qualquer recurso do seu sistema operacional e, até mesmo, ao hardware. Um controle ActiveX hostil pode infectar sua estação com um vírus, eliminar seus arquivos e desligar seu computador. A seguir apresentamos alguns exemplos de vulnerabilidades oferecidas pelo ActiveX:

• O site "The ActiveX Hard Disk Explorer" permite que se execute um código que varre seu disco e analisa os arquivos de configuração do seu sistema operacional.
• A página "Password Theft Using ActiveX Control" executa um controle que obtem a senha do Windows de sua estação, a senha do screen saver e, se disponível, senhas que estejam armazenadas no cache do sistema. Neste último caso, se estação tem acesso a serviços de arquivos oferecidos por servidores da rede privada, abre-se a possibilidade de acesso a informações que estão além da máquina invadida.
• O Exploder, uma paródia com o Internet Explorer da Microsoft, é um componente ActiveX que, quando executado, desliga sua estação, como se a opção de shutdown fosse selecionada. Seu autor, Fred McLain, foi processado pela Microsoft e Verisign, que autenticou o código do Exploder.

O grande problema de segurança do ActiveX é seu mecanismo de autenticação, baseado no Autenticode. Qualquer desenvolvedor pode criar um componente ActiveX e solicitar uma assinatura digital para seu código. A assinatura é uma garantia dada por uma autoridade de certificação (Verisign por exemplo), que o código foi escrito realmente por seu autor e que não foi alterado. A assinatura garante a autencidade e a integridade do código, mas não garante segurança. Um código pode ser autêntico e íntegro e mesmo assim conter um vírus ou desligar sua máquina.

Quando o ActiveX é carregado, o browser verifica a assinatura do código e abre uma janela informando o nome de seu autor. Depois disto existem duas opções: aceitar o programa ou recusá-lo. A segurança do ActiveX está baseada inteiramente na decisão correta do usuário em aceitar  ou não código. Se a escolha for errada, é possível que sua estação e toda a rede privada fiquem comprometidas.

Como reduzir os riscos?

• Antes de permitir a execução de qualquer código ativo em sua estação, verifique a origem e a assinatura do código.
• Os browsers, como qualquer software, possuem bugs. Utilize, sempre que possível, a última versão do browser, com as devidas correções atualizadas.
• Evite navegar na Internet em sites desconhecidos.
• Evite navegar na Internet em uma estação que contenha informações confidenciais.
• Evite navegar na Internet em estações que estejam logadas na rede interna com direitos de administrador (root).
• Tenha backup de seus dados em disco.
• Evite o uso de plug-ins, principalmente em ambientes corporativos.
• Verifique se o firewall permite algum tipo de filtro para código ativo.
• Eduque os usuários sobre os riscos do uso do browser.

Este artigo foi escrito por Luiz Paulo Maia e pode ser contatado pelo email: lpmaia@training.com.br

Referências:

Exploder
http://www.halcyon.com/mclain/ActiveX/

Password Theft Using ActiveX Control
http://www2.axent.com/swat/swat/1attacks/win95/craigs/passgrab.htm

The ActiveX Hard Disk Explorer
http://www.iseran.com/ActiveX/filesearch.html

A Comparison between Java and ActiveX Security
http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html

Java Security FAQ
http://www.cs.princeton.edu/sip/faq/java-faq.php3

FAQ about Applet Security
http://java.sun.com/sfaq/

A Collection of Increasingly Hostile Applets
http://www.rstcorp.com/hostile-applets/index.html

CERT, FAQ About Malicilous Web Scripts Redirected by Web Sites
http://www.cert.org/tech_tips/malicious_code_FAQ.html

CERT Advisory CA-2000-02, Malicius HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html

CERT Understanding Malicious Content Mitigation for Web Developers
http://www.cert.org/tech_tips/malicious_code_mitigation.html

Security Tradeoffs: Java vs. ActiveX
http://www.cs.princeton.edu/sip/faq/java-vs-activex.html

A Comparison between Java and ActiveX Security
http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html