Por paradoxal que pareça, a Internet, concebida nos tempos da guerra fria para garantir a comunicação entre unidades das forças armadas americanas em caso de ataque nuclear, não incluiu a segurança entre suas prioridades. Talvez porque, embora idealizada por militares, foi desenvolvida por membros do meio acadêmico ávidos por uma forma rápida e eficiente de trocar informações científicas. Gente de boa fé que acreditava na natureza humana e nunca imaginou que estavam na realidade criando um monstro que se expandiria, passaria a ter um caráter predominantemente comercial e seria usado como veículo de disseminação de vírus, vermes, cavalos de Tróia e outras desgraças afins. Por isso a segurança da Internet é fraca.
Um sistema operacional é um negócio complicado. Trata-se de um programa que, além de gerenciar o funcionamento do computador, se responsabiliza pela comunicação com os periféricos. E, quando surgiram os microprocessadores dotados da capacidade de multitarefa (executar diversos programas concomitantemente), tornaram-se ainda mais complexos, já que passaram a coordenar a comunicação entre esses programas. E, mais tarde, com a disseminação das redes, tiveram ainda que controlar a comunicação entre programas rodando em diferentes máquinas interligadas em rede. Um negócio complicado como esse haveria de ter suas vulnerabilidades. E Windows as tem de sobra.
Da combinação de uma rede pouco segura com um sistema operacional vulnerável não podia resultar boa coisa. E não resultou.
Controles ActiveX
Lembra do OLE? Ninguém fala mais nele, mas quando surgiu era uma novidade e tanto. É o acrônimo de “Object Linking and Embedding”, ou “vinculação e incorporação de objetos” e permitia que programas trocassem dados. Com o OLE você podia, por exemplo, criar no editor de textos um documento com uma tabela que exibia os resultados calculados por uma planilha eletrônica. Se a tabela fosse vinculada à planilha e incorporada ao documento, toda a vez que se alterasse a planilha o documento automaticamente espelharia essa alteração. Ou seja: através do OLE, os programas se comunicavam.
Mais se o OLE era assim tão maravilhoso, por que não se fala mais nele? Bem, é que ele evoluiu e mudou de nome. Foi incorporado ao sistema operacional quando Windows aderiu à “arquitetura” denominada COM (Component Object Model). E os velhos “Controles OLE”, revistos e melhorados, foram incorporados à nova arquitetura e passaram a ser conhecidos por “Controles ActiveX”. Que, esses sim, aposto que você conhece pelo menos de ouvir falar. Pois se ouvia falar e não sabia o que era, agora sabe: um controle ActiveX é um controle OLE aperfeiçoado e com novo nome. Uma rotina que permite a comunicação entre diferentes programas rodando na mesma máquina.
Com o advento da Internet a coisa complicou mais um pouquinho e a arquitetura COM evoluiu para DCOM, de Distributed COM, ou COM distribuído. Mas distribuído onde? Ora, na rede, evidentemente. Da mesma forma que a arquitetura COM permite a programas rodando na mesma máquina interagirem, a DCOM permite a interação de programas rodando na mesma rede, estejam ou não na mesma máquina. Ou seja: um controle ActiveX cujo código está sendo executado em uma máquina pode interagir com programas rodando em quaisquer outras máquinas da rede e com eles trocar dados. Essa interação se faz usando um conjunto de controles ActiveX fornecidos pela própria MS em uma “biblioteca” denominada ADO, de ActiveX Data Objects.
Um desses controles, o “ADODB.stream”, serve para transferir um “fluxo” de bytes entre programas e grava-lo no disco rígido. Esse fluxo pode ser um arquivo de texto, por exemplo. Mas também pode ser um arquivo binário (ou seja, que contém código executável). Pois bem: a integração entre o Internet Explorer e Windows (em todas as versões) é tão profunda que o controle ActiveX “ADODB.stream” de Windows pode ser usado no IE. E o IE serve para exibir páginas da Internet. Que podem conter controles ActiveX, ou seja, trechos de código que abrigam rotinas executadas quando a página é visitada. E podem se comunicar com outros programas rodando em outras máquinas conectadas à rede. E permitir, através do “ADODB.stream”, que código seja gravado no disco rígido das máquinas remotas.
Você certamente percebeu que essaa combinação é um desastre esperando para acontecer. Ou não?
Se não, eu explico. Aliás, faço melhor: dou um exemplo. E recente.
Download.Ject
No final de junho, alguns usuários relataram um estranho comportamento de suas máquinas após visitar certos sítios. E olhe que não se tratava do sítio do botequim da esquina ou do salão de beleza de Tia Mariquinha. Ao contrário, eram respeitáveis corporações, incluindo bancos conhecidos e renomadas empresas. Em suma: sítios classificados como “confiáveis”. E o comportamento estranho era nada menos que a instalação de um RAT (Remote Access Trojan horse, um programa que permite que a máquina seja controlada à distância sem o conhecimento do usuário). Esse programa, mais tarde identificado como “Download.Ject”, abria uma “backdoor” (porta dos fundos) denominada W32/Berbew, que permite acessos não autorizados à máquina através de uma das “portas” de comunicação do sistema operacional, e instalava um “keylogger”, um programa que registra em um arquivo cada tecla premida pelo usuário e periodicamente envia o arquivo a terceiros através da “porta dos fundos” previamente aberta. Tudo isso sem o conhecimento da vítima. No caso em questão, os dados eram enviados a um determinado servidor localizado na Rússia.
Como eu disse, isso ocorria após visitas a sítios confiáveis. Pode, um negócio desses?
Pode. Basta uma bem engendrada combinação de controles ActiveX ardilosamente concebidos com vulnerabilidades do sistema operacional e do Internet Explorer.
A coisa funcionava assim: o malfadado servidor russo estabelecia contato com os tais sítios confiáveis em busca de algum que usasse o IIS (Internet Information Server, o componente de Windows que administra os servidores Internet) e apresentasse uma certa vulnerabilidade. No caso, uma vulnerabilidade para a qual a Microsoft já havia desenvolvido um “patch”, ou correção, em 13 de abril último (veja o Boletim de Segurança Microsoft MS04-11 em <www.microsoft.com/technet/security/bulletin/MS04-011.mspx>). Infelizmente, para eliminar uma vulnerabilidade, não basta a MS desenvolver a correção, é preciso que o administrador da rede a aplique em seu sistema. E você se surpreenderia com o número de sistemas tidos como confiáveis que apresentam vulnerabilidades apenas porque seus administradores não mantêm em dia as “security updates”, ou atualizações de segurança. Pois bem: encontrando um desses sistemas, o servidor mal intencionado aproveitava-se da vulnerabilidade para fazer uma alteração sutil na página inicial do sítio: incluía nela o código de um controle ActiveX que redirecionava o usuário para o servidor russo. Como o código não aparece na página do sítio visitado, a vítima não fazia idéia do que estava ocorrendo.
Duas novas vulnerabilidades
Estabelecida a conexão, o servidor russo aproveitava-se de duas outras vulnerabilidades, essas recentemente descobertas e para as quais a MS ainda não havia desenvolvido correções, e instalava na máquina do usuário o já citado Download.Ject, que por sua vez abria a porta dos fundos e instalava o keylogger. A partir desse momento não apenas a máquina contaminada podia ser controlada remotamente como tudo o que fosse inserido através do teclado (senhas de contas bancárias, por exemplo) seria enviado subrepticiamente ao malfeitor. Pior: usando a intercomunicação entre janelas abertas do IE, o sacripanta solicitava informações confidenciais que pareciam partir do sítio confiável previamente contaminado. E dificilmente alguém negaria dados a seu banco depois de haver estabelecido uma conexão garantida por senha.
As novas vulnerabilidades eram do Internet Explorer. Uma delas permitia que qualquer código ActiveX executado a partir de um sitio classificado como “confiável” fosse igualmente considerada confiável, mesmo em uma nova janela aberta pela ação do próprio controle ActiveX, uma vulnerabilidade conhecida como “cross domain”, ou seja, passar de um domínio (ou sítio) confiável para um sítio não confiável mantendo os privilégios.
Quando o problema se tornou conhecido a primeira atitude da MS foi tomar providências para fechar servidor russo, o que foi feito em poucos dias (veja artigo de Robert Lemos em <http://zdnet.com.com/2100-1105_2-5248279.html>). A segunda foi divulgar o artigo “What you Should Know About Download.Ject”, em <www.microsoft.com/security/incident/download_ject.mspx>, no qual, além de informações sobre a ação do programa, há um botão que, ao ser clicado, executa uma verificação na máquina do visitante e remove o Download.Ject caso seja encontrado (sugiro veementemente uma visita; eu já fiz a minha e verifiquei, com alívio, que esta máquina que vos fala está segura). A terceira foi recomendar a todos os usuários aumentar o nível de segurança do IE e do Outlook (veja artigo “Increase Your Browsing and E-Mail Safety”, em <www.microsoft.com/security/incident/settings.mspx>. E, finalmente, a quarta foi sugerir que o usuário desabilitasse o controle ActiveX “ADODB.stream” para impedir a gravação do código nefasto no disco da vítima (veja artigo da US-CERT “Internet Explorer Update to Disable ADODB.Stream ActiveX Control”, que explica como fazer isso, em <www.us-cert.gov/cas/techalerts/TA04-184A.html>). Pena que todas fossem soluções paliativas: impediam a propagação do vírus mas não corrigiam a vulnerabilidade.
A solução final
A solução definitiva veio, enfim, em 30 de julho passado, quando a MS distribuiu a “Atualização de segurança cumulativa para o Internet Explorer 6 Service Pack 1 (KB867801)” descrita no “Microsoft Security Bulletin MS04-025” em
<www.microsoft.com/technet/security/bulletin/ms04-025.mspx>.
Que, além de corrigir a malfadada vulnerabilidade “cross domain”, elimina duas outras relativas à exibição de elementos gráficos no IE. Todas consideradas “críticas” pela MS. E, com isso, liquidou definitivamente a possibilidade de um safardana se aproveitar delas (evidentemente, quem instalar essa atualização não precisa recorrer a nenhuma das medidas anteriormente citadas, já que ela corrige definitivamente a vulnerabilidade explorada pelo Download.Ject).
Se você chegou até aqui embora achando tudo isso meio complicado, parabéns. Além de uma paciência admirável tem um grande interesse em manter seu sistema seguro. Então, já que é assim, corra até a página de atualizações de Windows, em <http://v4.windowsupdate.microsoft.com/ptbr/default.asp> e mande examinar seu sistema em busca de atualizações disponíveis para a sua versão. Se você não usa a atualização automática de Windows ou se não freqüenta essa página regularmente, certamente encontrará uma relação de atualizações disponíveis. Sugiro que instale no mínimo as classificadas como “Atualizações críticas e Service Packs”, particularmente a mencionada no parágrafo anterior.
Afinal, se a Internet tem segurança fraca e Windows apresenta vulnerabilidades, cabe ao usuário ficar alerta, mantendo seus dados confidenciais tão protegidos quanto possível. Porque você não faz idéia da quantidade de pilantras que estão de olho neles...
