O Nimda foi identificado pela primeira vez a 18 de Setembro de 2001, um ano particularmente ativo em vários contextos.
O worm Code Red surgiu em Julho do mesmo ano, apanhando todos de surpresa com os seus danos colaterais: volumes massivos de tráfego de rede, dedicados apenas à redistribuição do worm.
O projeto "Whistler" da Microsoft preparava-se para dar origem ao Windows XP, em Agosto desse ano.
A 11 de Setembro o mundo assistiu em direto aos ataques terroristas que destruíram as torres do World Trade Center.
E apesar dos voos de e para os EUA terem sido cancelados no seguimento deste ataque, por precaução, a Austrália sofria a sua própria crise aeronáutica com a paragem abrupta dos serviços da segunda maior companhia aérea do país, a Ansett, deixando à toa passageiros em todo o território, incluindo parte da equipa da Sophos em Sydney, que tiveram que acampar no aeroporto de Melbourne com bilhetes para nenhures.
O Nimda aterrorizou a Internet
O Nimda não fez questão de ser discreto. Não só conseguia propagar-se por todo e qualquer lugar, como assim o fazia: enviava-se para os contactos de e-mail dos utilizadores infetados, infiltrava-se em servidores Web infetando ficheiros por todo o website, distribuía-se automaticamente através das redes, e infetava os programas existentes no disco rígido, paralisando-os.
Como resultado, um só ficheiro infetado destinado à sua organização que fosse executado, poderia provocar infeções em centenas ou milhares de computadores na sua rede. E cada computador comprometido, fosse PC ou servidor, poderia conter centenas ou milhares de ficheiros infetados, modificados ou danificados.
Surgido apenas uma semana após o atentado de 11 de Setembro, o Nimda atraiu muita especulação no sentido de se tratar de uma forma de ciberterrorismo.
O código do vírus incluía o seguinte texto:
Concept Virus(CV) V.5, Copyright(C)2001 R.P.China
Visto que no idioma Inglês os adjetivos surgem antes dos substantivos, a China é conhecida como PRC (People's Republic of China), e não RPC, conforme o texto indica. O que significará isto? Será um erro do autor de origem Chinesa, que não domina o idioma Inglês? Será um Francês a fazer-se passar por um Chinês que não domine o idioma Inglês? Ou um Russo a fazer-se passar por um Francês que finge ser um Chinês que não domina o idioma Inglês?
A resposta correta, à semelhança do que frequentemente ocorre com o malware e os cibercriminosos, é que simplesmente não conseguimos saber. Não conseguimos saber há doze anos atrás, quando o Nimda surgiu, e até hoje não temos como sabê-lo.
O Nimda como ciberterrorista
Mais de uma década após o aparecimento do Nimda, talvez tenhamos aprendido a baixar um pouco o "dedo acusador". É sabido que determinados Governos um pouco por todo o mundo, se envolvem naquilo que os tabloides costumam chamar de ciberespionagem (o que significa que existem hackers pagos pelos serviços de inteligência de determinados países).
Mas se nos focarmos demasiado no âmbito da ciberguerra e do ciberterrorismo, as atenções afastam-se do perigo óbvio e atual que é o cibercrime (e que certamente nos custa biliões de euros por ano), por torná-lo aparentemente menos importante em comparação. As coisas podem ser simples e importantes. De facto, a simplicidade é muitas vezes a chave da significância.
O Nimda como prova de que não existem bons vírus
Um dos aspetos mais intrigantes do Nimda, é a sua natureza parasita: o mecanismo que utiliza para infetar outros ficheiros.
O malware parasita básico daquela altura, normalmente carregava o ficheiro hospedeiro original juntamente com o vírus. Os vírus mais sofisticados inseriam o seu conteúdo como uma nova secção de código, ou mesmo em partes não utilizadas do executável, como o famoso vírus CIH, ou Chernobyl.
O Nimda adotou a abordagem simplista: carregar o hospedeiro original consigo mas de uma forma complicada, injetando-o em si mesmo como um recurso do Windows. E a complexidade desnecessária é por vezes inimiga de um comportamento correto (se é que algum tipo de comportamento por parte de um vírus possa ser chamado de "correto").
O Nimda, de facto, reinfectava ficheiros que já tinha comprometido. Como tal, era perfeitamente possível acabarmos por ficar com o Bloco de Notas do Windows injetado no Nimda, assim como outros recursos.
Não se tratava de algo ad infinitum, obviamente, já que só a máquina de Turing é capaz de proporcionar uma quantidade de memória potencialmente infinita. Mas a injeção podia ser muito aprofundada: na Sophos chegámos a lidar com amostras que tinham sido reinfectadas 250 vezes cada, ao testarmos o nosso código de desinfeção antivírus.
Este tipo de efeito colateral não intencional é outro fator que nos faz recordar que não existem vírus inofensivos, já que mesmo um vírus supostamente desenvolvido por "diversão" pode ter bugs inesperados. Assim que um vírus se encontra em propagação, não é possível recuperá-lo para corrigir o seu código.
Isto recorda-nos ainda que os criadores de vírus nem sempre são os génios da programação que se imagina, e que as empresas de segurança informática decentes não fazem filas para contratá-los. Mesmo que estejam dispostas a sobrepor ao seu negócio e às questões morais, a contratação de um cibercriminoso.
O Nimda recorda que ainda cometemos erros antigos
Outro dos fatores de interesse do Nimda, era a sua técnica de propagação em rede. Um dos problemas de enfrentar um vírus propagável através da rede, é o modo como incentiva os utilizadores em qualquer ponto dessa rede a executarem os ficheiros que acabam de ser adicionados.
O Nimda fazia-o distribuindo DLLs infetados por toda a rede, com o nome RICHED20.DLL. Um DLL com este mesmo nome, é carregado conforme necessário por uma variedade de programas do Windows quando lida com documentos mais complexos do que apenas texto simples.
Ao colocar um ficheiro infetado com o nome RICHED20.DLL em diretorias contendo ficheiros.DOC, por exemplo, o DLL do Nimda era carregado em vez do DLL legítimo, caso o utilizador acedesse a essa pasta e examinasse um documento. Isso devia-se ao facto do Windows carregar os DLLs da diretoria atual por defeito, (a menos que o programador indique explicitamente o contrário).
E é neste ponto que, doze anos depois, ainda escrevemos software de forma descuidada relativamente ao modo como este escolhe as suas bibliotecas de código adicional.
O Nimda recorda-nos sobre a importância das atualizações de segurança
Outra lição importante a aprender com o Nimda é quão vital se torna corrigirmos falhas conhecidas dentro da nossa rede rapidamente, para que caso o malware consiga contornar os primeiros níveis de defesa, não se infiltre ainda mais internamente.
O Nimda acelerou bastante a sua propagação invadindo e infetando websites, utilizando uma vulnerabilidade conhecida como "directory traversal" em servidores Web IIS. Não é suposto que estes servidores permitam aceder aos ficheiros fora da sua própria diretoria de dados, e por isso devem identificar sequências de caracteres como "../../..", mesmo que disfarçadas.

O elemento ".." num caminho de rede representa a subida de um nível, e se isso for permitido num URI pode também permitir que alguém externo aceda a ficheiros que não é suposto serem sequer visíveis.
Um mês após o Nimda, a Microsoft publicou o boletim de segurança microsoft MS01-078 intitulado "Patch Available for 'Web Server Folder Traversal' Vulnerability".
Mas este boletim não anunciava a chegada de uma nova correção, servindo apenas para recordar os utilizadores de que essa correção já fora divulgada no boletim MS01-057, quase um mês antes do Nimda surgir pela primeira vez.
Uma vez mais apercebemo-nos... Doze anos depois, e muitos de nós ainda não alterámos o hábito de ignorar por semanas a aplicação dos pacotes de correção disponibilizados.
O Nimda mostra-nos que a prevenção é melhor do que a cura
Está dito... E voltamos a repeti-lo: "A prevenção é melhor do que a cura".
Mantenha-se a par de outros artigos sobre segurança da Sophos seguindo-os no Facebook, Twitter e LinkedIn.