Um breve Raio-x da Tecnologia da Informação em 1998

Olá, e obrigado por sua visita! Neste terceiro e último artigo da nossa série sobre a Tecnologia da Informação em 1998, vamos tratar sobre a Segurança da Informação nesta época. Vinte anos se passaram e muita coisa evoluiu, e claro, não só em Segurança, mas você verá que houve coisas bem interessantes nesse setor em particular.

Você pode ler os dois artigos anteriores da série aqui:

Estou publicando este post hoje (dia 05 de maio (05)) exatamente às 05:00 PM (da tarde), e diretamente a partir do 5o. Cofforense, promovido pelo meu amigo Marcos Monteiro (@marcosjmonteiro). Então, não há momento mais apropriado para falar de algo que aconteceu há 20 anos, do que esta coincidência cabalística (5 + 5 + 5 + 5 = 20). Mãos à obra! 😉

Vírus/Worms/Trojans

Antes de código malicioso ganhar o termo genérico de “malware“, os tipos de ameaças recebiam mais denominações, como vírus, worm e trojan horse ou trojan (“Cavalo de Troia”). Alguns destes termos continuam em uso, e outros, se misturaram

O vírus tratava-se de um código que, ao ser executado, causava algum dano direto ao computador, como deleção de arquivos, corrupção da tabela de partições ou mesmo travamento do sistema. Além disto, ele normalmente infectava (daí o nome inspirado na Biologia) outros arquivos executáveis. Assim, por mais que você conseguisse apagar o arquivo do vírus, outros componentes do sistema poderiam estar simplesmente “doentes”. Dependendo da impregnação do vírus no executável do sistema, ficava inviável repará-lo, o que demandava uma restauração ou reinstalação completa do software afetado.

Um dos vírus mais famosos do período foi o Win32.CIH (codinome “Chernobyl”). O nome se deve às iniciais de seu criador, o chinês Chen Ing-Hau. O codinome foi atribuído posteriormente, devido a variantes do código malicioso, que causavam um dano gigantesco, apagando os dados do BIOS e o próprio MBR (Master Boot Record). Dependendo da versão da placa-mãe, isso tornava o computador completamente inútil, sendo necessária a substituição do componente.

A imagem abaixo mostra a mensagem de erro que era apresentada quando o vírus se manifestava no Windows 95 ou 98.

Figura 1: Mensagem de erro do CIH – crédito: YouTube

Este vídeo mostra o comportamento de um computador ao ser infectado pelo Chernobyl.

Nos anos seguintes, o mundo ainda presenciaria ocorrências de vírus mais sofisticados, combinando características de worm, que veremos a seguir.

O worm (verme) é uma evolução natural do vírus.  Enquanto o  vírus se limitada a atacar o computador onde era executável e, no máximo, se copiava para discos flexíveis (disquetes), o worm pegava carona no crescente uso de redes de computadores, sendo um verdadeiro pesadelo para empresas dos mais diversos tamanhos. Normalmente, os worms se replicavam usando os próprios protocolos de rede em uso na época, como a família CIFS/SMB, implementada pelo Windows. Ainda considerando este sistema operacional, o código malicioso fazia uso do recurso de RPC (Remote Procedure Call) para realizar uma execução remota.

Em 1998, foi comum ver administradores de sistemas puxando cabos de rede usados por computadores corporativos após noticiarem uma infecção por worm. Isso, claro, nos casos em que a companhia não possuía nenhuma proteção, como os famosos e ainda em uso antivírus.

Neste ano, não houve nenhum worm que tenha ganhado atenção da mídia, mas o ano seguinte (1999) veria o surgimento do Melissa. Apesar de não causar qualquer dano no computador, o Melissa se propagava por e-mail, e a mensagem era originada de um remetente conhecido seu (estava no seu catálogo de endereços do programa de e-mail, na época, normalmente o Microsoft Outlook ou Microsoft Outlook Express). Então, como desconfiar de uma mensagem vinda de alguém conhecido e com um singelo documento do Word?

Figura 2: Worm Melissa – crédito: TecMundo

O detalhe é que não era um arquivo qualquer. O Melissa, na verdade, foi implementado na forma de uma macro do Microsoft Word. As macros (ainda em uso atualmente) nada mais são do que códigos interpretados por algum programa, com instruções para serem executadas. Como não eram escritas numa linguagem de programação tradicional, como o C ou Delphi, muito comuns na época, as macros tinham restrições quanto ao que poderiam causar no computador.

E daí, surge a dúvida:  como o Word pode executar um programa, se ele foi feito para editar textos?  Pois é…  Com a melhor das intenções, a Microsoft decidiu adicionar o recurso de automação de tarefas por meio de macros. Assim, um usuário do Word (ou Excel), poderia criar programas simples que executassem atividades entendiantes e repetitivas, de forma que a produtividade acabaria naturalmente aumentando.

E a história do remetente conhecido?  Afinal, a mensagem vinha de alguém no seu catálogo de endereços. Exatamente! Usando dos recursos de macro, e das conhecidas integrações entre produtos Microsoft, o Melissa lia o catálogo de endereços e se enviava automaticamente para os primeiros 50 endereços da lista. E não parava por aí. Além do comportamento de replicação, o worm abria diversas janelas do browser (os mais comuns eram o Internet Explorer e o Netscape Navigator) em sites de pornografia! Caramba…

Na Computação, o primeiro Trojan Horse de que se tem notícia data da década de 1970, mencionado em um relatório de análises de vulnerabilidades elaborado pela Força Aérea dos Estados Unidos. Posteriormente, em uma apresentação conduzida em 1983 por ninguém menos que Ken Thompson (em Inglês), um dos criadores do UNIX, foram feitos novos relatos de possíveis ocorrências de um cavalo de troia em códigos do Multics (em Inglês), que, por sua vez, foi o sistema operacional que deu origem ao UNIX. 😉

Mas, por que receber este nome?  Simples!  Da mesma como ocorreu na história contada pelo poeta grego Homero, em seu romance Odisseia, o ataque é disfarçado na forma de um presente. No caso da história grega, um cavalo real de madeira de proporções colossais.  Aqui no nosso mundo da Computação, um programa mal intencionado com um visual inocente.  Assim, uma vítima executa o código malicioso achando que está usufruindo de um programa convencional, mas, em segundo plano, todo o estrago está sendo feito no seu próprio computador e/ou na rede onde se encontra.

O ano de 1998 foi “contemplado” com cavalos de troia notáveis, como o NetBus e o Back Orifice. Ambos os programas tinham o propósito de controle remoto não autorizado de sistemas Windows (incluindo NT).

O primeiro, NetBus, foi criado em março por um programador sueco, e possuía uma porção cliente (usada pela pessoa mal intencionada) e uma servidora, que era instalada no computador da vítima. O nome do arquivo executável entregue à vítima era sugestivo (algo como atualização.exe ou patch.exe). Não mostrava absolutamente nada ao ser executado, e se instalava no sistema operacional. Na sequência, diversas operações se tornavam possíveis, como:  abertura e fechamento do drive de CD-ROM, reinício do computador, travamento da tela de login, reprodução de sons, apresentação de imagens, ou mensagens, ou mesmo ativação do microfone para gravação do áudio da vítima.

Figura 3: Trojan NeBus – crédito: TechGenix

O Back Orifice, lançado em agosto, teve este nome como um trocadilho ao nome da suíte de aplicativos servidores da Microsoft, o BackOffice Server (em Inglês). Esta suíte trazia diversos aplicativos para auxiliar nas tarefas de gerenciamento de redes com sistemas Windows, como o Windows NT Server 4.0, o Exchange Server, o SQL Server, entre outros. Em 1998, a versão em uso era a 4.0. Para saber mais sobre alguns destes produtos, visite o primeiro post desta série.

Da mesma forma como acontecia com o NetBus, a instalação do BackOrifice era completamente silenciosa, sem qualquer interação com o usuário, o que lhe permitia ser embarcado em outros softwares legítimos, ou mesmo se passar por algum componente do sistema operacional. Após instalada, a porção servidora do programa ficava esperando por conexões na porta 31337, tanto TCP quanto UDP. A partir daí, a porção cliente poderia ser usada para executar basicamente as mesmas funções do NetBus. A diferença mais notável era que o Back Orifice permitia a criação de uma área de trabalho, organizando as atividades de exploração do computador da vítima.

Figura 4: Trojan Back Orifice – crédito: UMBC

 

Antivírus

Os principais fabricantes de antivírus da época (Symantec, McAfee e F-Secure) rapidamente trataram de atualizar suas bases de dados, classificando ambos os códigos como malware e inserindo-os em suas respectivas quarentenas quando detectados. Aliás, é algo importante de mencionar. As proteções daquela época eram basicamente desta forma:

  • Monitoramento de componentes do sistema operacional;
  • Busca em arquivos do disco rígido à procura de arquivos infectados;
  • Banco de dados com assinatura de vírus conhecidos;
  • Quarentena, para isolar arquivos com comportamentos suspeitos;
  • Atualização por disquete ou, algumas vezes, Internet.

Inclusive, essa dependência do banco de dados era uma desvantagem na época.  Uma corrupção nesse arquivo inviabilizava completamente a operação do antivírus, deixando o sistema praticamente desprotegido. Mesmo nos dias atuais, a maior parte dos antivírus depende desses bancos, mas, o advento da análise heurística (segundo a qual o comportamento do código suspeito é analisado segundo critérios esperados) permitiu um avanço significativo na efetividade dos produtos.

Os fabricantes ainda dispunham de ferramentas de linha de comando, que muitas vezes eram usadas em scripts de logon para garantir uma execução limpa do sistema operacional (normalmente, Windows 95, 98 ou NT Workstation). Tais comandos aceitavam numerosas operações que variavam da simples execução de um procedimento de busca, até notificação do administrador por meio de e-mail, geração de arquivo de relatório ou mesmo impossibilidade de usar o computador numa situação de infecção.

 

E a rede?  Como ficava?

Um ataque que ganhou enorme repercussão nesse ano foi o “Ping da Morte”, ou “Ping of Death”. E um dos motivos de se tornar tão famoso é que ele era extramente fácil de ser perpetrado:  bastava abrir uma janela de comando no Windows, ou em algum sistema UNIX ou Linux, e disparar o envio de pacotes com um tamanho relativamente grande (para a época). Tipicamente, pacotes com mais de 64 KB já eram suficientes para causar pane em um servidor (travamento, reboot, ou dano permanente). Vários sistemas Windows NT Server 4.0 foram afetados pelo problema. O comando seria algo assim, invocado a partir de uma janela MS-DOS.  A chave “-l” permitir especificar o tamanho do pacote:

C:\> ping -l 65535 <endereço IP da vítima>

Foi um dos maiores bugs da época, e afetou vários sistemas operacionais.  Você pode consultar a lista de todos eles neste link (em Inglês).  A figura abaixo mostra o resultado do ping em um Windows NT Server 4.0.

Figura 5: Tela de erro causada pelo Ping da Morte – crédito: YouTube

Como era possível se proteger de ataques assim?  Não era!  Os administradores precisavam simplesmente baixar as atualizações (hotfixes ou service packs no Windows, ou patches no UNIX/Linux) e aplicá-las diretamente nos sistemas afetados.  Lembre que não existia o WSUS (Windows Software Update Services)! Ele só foi criado em 2005.  Para realizar uma distribuição de software em toda a rede, o administrador precisava recorrer a logon scripts.  Um componente do BackOffice 4.0, o SMS (Systems Management Server) 1.2, permitia automação do empacotamento e entrega de software a estações de trabalho, mas as reclamações de falhas eram constantes.

A maior fronteira de proteção eram roteadores configurados com ACLs (Access Control Lists).  No entanto, elas eram bastante limitadas, pois só verificavam endereços IP de origem e destino, protocolos e portas de serviços.  Não havia qualquer espécie de inspeção mais profunda, nem mesmo checagem do estado da conexão, o que é conhecimento como “stateful inspection“.  Assim, os fabricantes de produtos de rede, notadamente a Cisco e a Juniper desempenharam um importante papel neste sentido.

No UNIX e Linux, preocupava-se mais com a proteção relacionada à autorização de se conectar ou não a um determinado servidor ou a possibilidade ou não de executar um comando.  Neste período, utilitários comuns, como rsh, rcp, rlogin, telnet e ftp eram bastante usados.  Cada utilitário era implementado na forma de uma aplicação cliente (em linha de comando) e uma aplicação servidora (daemon). Portanto, cada utilitário tinha sua própria lista, geralmente representada na forma de um arquivo texto, que permitia ou bloqueava conexões a partir de determinados hosts ou endereços IP.  Outros serviços/aplicações como NFS (Network File System) e NIS (Network Information System) se comportavam de maneira análoga. Já se usava o Kerberos como forma de autenticação alternativa à transmissão de senhas em texto limpo.

O Windows NT (Server e Workstation) 4.0 também possuía uma forma rudimentar de filtro de pacotes.  Ao se editar a configuração do adaptador de redes, e escolhendo-se opções avançadas da suíte TCP/IP, era possível definir portas permitidas

Figura 6: Filtro de pacotes do Windows NT – crédito: YouTube

Para controlar e, de certa forma, proteger os acessos dos usuários à Internet, os proxies eram as opções disponíveis. No mundo UNIX/Linux, o Squid (ainda bastante em uso nos dias atuais), era o principal.  No mundo Microsoft, o Proxy Server fazia as vezes de servidor de cache, e controle de acesso (ou URL Filtering, como é chamado nos dias atuais).

Em relação a firewalls, além dos tradicionais filtros de pacotes já explicados, tínhamos o FWTK (Firewall Toolkit), desenvolvido há alguns anos.  O FWTK expandia o conceito de proteção, incrementando uma camada de detecção e análise de protocolos e aplicações.  Entre os serviços detectáveis, estavam o DNS, o FTP e o HTTP.  Em 1998, o conceito de defesa de perímetro era plenamente estabelecido. Assim, era preciso delimitar claramente o perímetro seguro (rede interna) do inseguro (rede de fornecedor ou Internet). Os firewalls eram tipicamente posicionados apenas para este tipo de proteção. O cuidado com aplicações na rede interna, ou mesmo usuários conectados a switches passava completamente despercebido. Em termos de produtos, o PIX (Private Internet Exchange), da Cisco, era uma das ofertas.

Para complementar a proteção estabelecida pelo firewall, os primeiros IDSs (Sistemas de Detecção de Intrusão) também eram empregados. Em 1998, uma das empresas fortes no segmento era a ISS (Internet Security Systems), que acabou sendo comprada pela IBM. O produto que virou um marco do período foi o RealSecure 1.0, lançado para o Windows NT Server 4.0 no ano anterior. A Cisco também  mostrava seu interesse em explorar ainda mais o segmento de cibersegurança, e fez isso através da aquisição da Wheelgroup em fevereiro de 1998, virando a dona do seu produto, NetRanger. Um ano antes (1997), a McAfee já havia anunciado sua fusão com a Network General, dando origem à Network Associates, e uma nova concorrente para explorar tal mercado em franca expansão.

E o restante, a História conta…

E assim, acabamos nossa trilogia sobre a Tecnologia da Informação em 1998. Espero que você tenha apreciado esta nossa viagem no tempo. Gostou de alguma coisa em particular? Sentiu falta de algum item ou evento? Por favor, deixe seus comentários logo abaixo.

Se quiser conferir os outros dois artigos da série, clique no link correspondente:

Até breve! 😉

Compartilhe:

Maurício Harley

Olá! Meu nome é Maurício Harley. Tenho 30 anos de experiência em Tecnologia da Informação. Durante minha carreira, trabalhei em setores diversos, como suporte a usuário final, manutenção de hardware, instalação e suporte a redes de computadores, programação, projetos avançados em Data Center, Cloud Computing, Cyber Security e Redes, incluindo Service Providers.

0 comentário

Deixe um comentário

Avatar placeholder

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Translate

You cannot copy content of this page.