• Worm "Fanny", Equation Group e Stuxnet

    Durante a Virus Bulletin Conference em 2010, os pesquisadores da Kaspersky Lab em parceria com a Microsoft apresentaram as conclusões relacionadas com o worm Stuxnet. A apresentação conjunta inclui slides que tratam de várias partes do Stuxnet, como as falhas 0-day que foram utilizadas no ataque. Talvez o mais interessante exploit zero-day do Stuxnet tenha sido o LNK exploit (CVE-2010-2568). Isso permitiu que o Stuxnet pudesse ter sido propagado através de drives USB e infectar até mesmo máquinas que tiveram Autorun desabilitado. Ele foi descoberto durante uma investigação sobre Stuxnet no ano de 2010, em que o LNK exploit já havia anteriormente sido usado em outro malware, supostamente um Zlob PE, que apontava para "fanny.bmp". De volta a 2010, poucas pessoas prestaram atenção a uma amostra de malware que usou a LNK antes mesmo do Stuxnet. Para quem não sabe, "Zlob" é uma grande família de malwares e estes tipos de amostras de crimeware raramente são de interesse para os investigadores que busca por falhas 0-day e por operações patrocinadas por estados-nação. No entanto, durante a pesquisa realizada em 2014 envolvendo o Equation Group, a equipe da Kaspersky Lab criou um método de detecção especial para a library exploitation, de codinome "PrivLib". Para a surpresa de todos, essa detecção desencadeou um worm oriundo de 2008, que usou o Stuxnet LNK exploit para promover a replicação: o worm em questão vem sob o codinome Fanny.


    Mas, o que é "Fanny"?

    Este Worm potencializado com a bibliotecaPrivLib, que se espalha utilizando o Stuxnet LNK exploit e o nome do arquivo "fanny.bmp", foi compilado em 28 de julho às 11:11:35. Ele chgou para a equipe da Kaspersky Lab em Dezembro de 2008 em estado selvagem, por isso a compilação pode muito tre sido feita de maneira correta.



    O Worm "Fanny.bmp" 2008, é detectado por produtos da Kaspersky Lab como Trojan-Downloader.Win32.Agent.bjqt. O malware inclui o LNK exploit, o que significa que é uma amostra de software malicioso que usou o Stuxnet LNK exploit antes do Stuxnet.


    O Segundo Stuxnet Exploit (MS09-025)

    Se uma amostra de software malicioso que usou um exploit do Stuxnet antes do próprio Stuxnet é um bom indício, um segundo Stuxnet o torna ainda mais interessante. O segunda exploit foi utilizado para ser um 0-day quando Fanny estava em processo operacional. Isto significa que Fanny utilizou dois exploits 0-day para replicação, ambos os quais foram posteriormente utilizados pelo Stuxnet. A vulnerabilidade específica utilizada para aumento de privilégios foi corrigida com MS09-025:

    A atualização de segurança elimina todas essas vulnerabilidades, corrigindo os métodos utilizados para a validação de uma mudança de objetos específicos do kernel, para validar a entrada transmitida a partir do modo de usuário para o kernel, e para validar o argumento transmitido à chamada de sistema. Assim, a atualização de segurança também elimina a vulnerabilidade existente, garantindo que o kernel do Windows limpa pointers sob condições de erro. Vale lembrar que o mesmo exploit foi usado posteriormente em um módulo Stuxnet a partir de 2009, e que foi incorporado em um grande binário construído utilizando a plataforma "Flame". Esse módulo do Stuxnet, também conhecido como "atmpsvcn.ocx" ou Resource 207 foi o nexo técnico entre as pragas Stuxnet e Flame.


    Stuxnet, Flame e Fanny

    Enquanto a vulnerabilidade explorada tanto pelo módulo Stuxnet / Flame e Fanny é a mesma, o método de aplicação da exploração é diferente. O exploit no Stuxnet tem como alvo uma versão específica do sistema operacional, enquanto Fanny é projetado para ser universal, além de ter a plena capacidade de ser executado em múltiplas plataformas. Tem um shellcode único e procedures para o exploit-triggering para:

    - Windows NT 4.0
    - Windows 2000
    - Windows XP
    - Windows 2003
    - Windows Vista, 2008 e, possivelmente, outros da família NT6.x

    A implementação do exploit em Fanny é muito mais complexa do que no Stuxnet: isso porque ao invés de executar apenas um payload, os autores criaram uma estrutura para executar tantos payloads quanto eles quiserem, substituindo uma chamada de serviço do sistema nt NtShutdownSystem com seu próprio pointer personalizado de theuser-space. Isso permite um "trampoline" persistente a ártir de um user-mode para kernel-mode. Esta característica não estava presente no módulo Stuxnet, mas existem outras semelhanças. Por exemplo, parece que ambos os desenvolvedores, tanto do Stuxnet quanto do Fanny seguem algumas orientações de codificação, tais como o uso de números mágicos originais de cada chamada de função. A maioria dos resultados retornados são simplesmente eliminados, mas eles ainda são parte componente do código. Estes poderiam ser os restos de uma versão de depuração do código, que poderia potencialmente gravar todas as etapas do código para facilitar o rastreamento de um erro durante o teste. Em sistemas mais complexos, onde kernel e user-space code estão sendo executados sem a interação necessária, isto parece um método lógico e até mesmo essencial. Mais uma vez, ele é implementado tanto no código do Stuxnet quanto do Fanny.


    O Malware Fanny

    Então, o que vem a ser, essencialmente, Fanny? Trata-se de um Worm USB com um backdoor altamente sofisticado, que utiliza o chamado "Stuxnet Vulnerability LNK" para executar automaticamente a partir da unidade USB, mesmo que o Autorun tenha sido desativado. Ele pode elevar privilégios para o sistema local, explorar o uso do kernel e registra módulos adicionais. Além do mais, ele tenta se conectar a um servidor C & C e implanta componentes adicionais se a conexão estiver disponível. Se não, ele usa o drive USB como um carrier para enviar/receber as solicitações "de" e "para" o operador através de uma área de armazenamento escondida criada na estrutura FAT. Assim, normalmente uma vítima se conectará em um novo drive USB e irá abri-lo com o Windows Explorer. Esta situação torna possível observar, visualmente, as duas fases da infecção a partir do USB, que levam questão de segundos para serem executadas.

    Existe um arquivo DLL com dois "exports" (para instalar e desinstalar o malware). Ele contém uma configuração xor-encrypted em recurso binário com o número 101. A configuração determina o comportamento do malware: existe um comando para implantar malware no sistema atual, URLs para o servidor C & C e nomes de arquivos e paths que são usados para instalar componentes de malware embutidos localmente.




    Processo de Infecção

    As buscas de módulos para fanny.bmp no root das unidades de disco rígido a partir da unidade D: e cópia para os seguintes locais:

    % Windir%\system32\comhost.dll
    % Windir%\system32\mscorwin.dll

    E vem a pergunta: por que Fanny faz duas cópias de si mesmo? Na verdade, existe uma pequena diferença entre estes dois arquivos. Fanny corrigiu sua configuração na secção de recursos de um dos arquivos (comhost.dll). Os dados ajustados correspondem ao valor do comprimento máximo que restava do killchain Fanny. Além disso, "mscorwin.dll" é o arquivo original copiado a partir da unidade removível. Até agora, uma cópia está sendo usada com a intenção de infectar outros drives USB, e o outro é carregado na inicialização do sistema. Na sequência de suas atividades, ele também copia todos os arquivos *.lnk a partir da unidade USB para "% windir%\system32\", a fim de reutilizá-los quando infectam outros drives USB conectados. Assim, é possível notar que pode haver mais de um arquivo LNK, porque cada um deles contém um path distinto para a DLL que é carregada. Quanto à "letter" de uma nova unidade no sistema de destino ser desconhecida, Fanny usa vários lnks para as "letters" de unidade mais comuns. Este método foi aperfeiçoado mais tarde, no Stuxnet, que utilizou um path DeviceID-dependent com relação ao drive USB. No entanto, mesmo que o método tenha exigido vários arquivos LNK (até quatro) por causa de diferentes paths relativos em diferentes versões do Windows; porém, isso é muito menos relevante do que um conjunto quase completo de letras do alfabeto latino.


    Worm USB

    O código real do worm é parte do %windir%\system32\comhost.dll com ordinal 4 (nome do export é "dll_installer_4"). A DLL é um worm de próxima geração, modificado, e que foi copiado para cada unidade USB conectada com todos os arquivos LNK relacionados e armazenados no diretório Windows\System32. Este módulo é distribuído pela mscorwin.dll, que é parte do processo de sistema lsass.


    Windows Explorer Rootkit

    A funcionalidade rootkit é fornecida por um arquivo shelldoc.dll, arquivo este que é carregado no processo do Windows Explorer. Ele esconde alguns arquivos relacionados com Fanny (LNK-files e fanny.bmp) no Windows Explorer, removendo-os da lista de itens na janela de primeiro plano que usa controle SysListView32 (normalmente janela do Windows Explorer).


    Backdoor USB

    Um dos módulos, agentcpd.dll, é um backdoor que foi projetado para funcionar como uma ferramenta de reconhecimento avançado para computadores air-gapped, que são normalmente utilizados em instalações de alta segurança. O backdoor aguarda que uma unidade USB seja conectada, e se isso trata-se de um novo disco, ele aloca instantaneamente algum espaço para um recipiente oculto, usando seu próprio driver de sistema de arquivos FAT16 / FAT32.


    Saiba Mais:

    [1] Secure List http://securelist.com/blog/research/...ather-stuxnet/