Jump to content
  • (Des)protegendo mídias USB

       (0 reviews)

    1. Introdução

    As mídias USB, e em especial os pen drives, são responsáveis por boa parte das infecções por vírus e malwares nas estações de trabalho e até servidores utilizados por usuários incautos. Um simples “espetar” de um pen drive USB pode passar por cima de todas as medidas segurança implementadas no ambiente de rede. Pensando nisso, resolvi buscar uma forma de imunizar uma mídia USB, de forma passiva, de modo que a proteção fique na mídia e não na máquina. Não existe milgare, mas é possível diminuir bastante o risco de infecção com a técnica que apresentarei.

    2. Como a infecção ocorre
    Quando uma mídia USB é inserida numa máquina com Windows, o recurso de autoreprodução é iniciado. Se na raiz da mídia existir um arquivo autorun.inf, este é lido pelo sistema e suas instruções são processadas, tudo de forma automática. A técnica mais eficiente para infectar uma mídia USB é, então, copiar para a mídia o malware em si (geralmente um binário PE) e criar também um autorun.inf na raiz da mídia que execute o malware toda vez que a mídia é inserida numa máquina com Windows. Este processo é explicado no texto “Como remover vírus de pen drive” [1], que escrevi em janeiro de 2010.

    3. A ideia da proteção
    Há várias tentativas de evitar essas infecções, desde programas simples que tentam remover indícios de vírus nas mídias USB até softwares mais complexos, apelidados de “firewalls” USB, que permitem controlar todo o tráfego. O problema é que a máquina é protegida, mas não a mídia USB. Se você usa o pen drive, por exemplo, em outra máquina, ele pode ser infectado e servir de meio de disseminação, pois os softwares que protegem a USB estão na sua máquina e não no pen drive.

    Como todos os malwares que analisei criam um autorun.inf para se autoreproduzir, a ideia é criar um autorun.inf sadio no raíz da mídia USB, que seja “inalterável”, “indeletável”. Dessa forma, o malware não conseguirá sobrescrever o autorun.inf saudável pelo seu malicioso e o executável do malware pode até ser copiado para a mídia, mas não será inicializado quando a mídia for inserida num Windows qualquer, ou seja, ficará simplesmente armazenado na mídia, mas inofensivo (a não ser que algum usuário encontre manualmente o executável e o execute). Mas será possível? Vamos aos testes. Verificando a possibilidade

    Depois de algumas buscas sobre criação de arquivos “indeletáveis”, encontrei o Panda USB Vaccine [2], que promete fazer exatamente o proposto. Ele realmente funciona e cria um autorun.inf “indeletável” no raíz da mídia USB. O inconveniente, para mim, é que ele é um software de código fechado e não há documentação sobre como ele faz isso, além de rodar somente em Windows. Eu estava desenvolvendo o USBForce [3], um software livre para proteção contra pragas em mídias USB quando encontrei o Vaccine. Naturalmente eu gostaria de implementar essa funcionalidade de criação de um autorun.inf “indeletável” no meu software. Além disso, não conseguiria dormir sem saber como (tecnicamente) este arquivo é criado e se era mesmo indeletável.

    4. Revertendo a técnica do Vaccine:

    Utilizei algumas ferramentas para saber como o Vaccine funciona, começando pelo RDG Packer Detector [4], que além de outras funcionalidades, consegue saber qual o compilador utilizado para gerar o binário, informação muito útil antes do debugging: O RDG informa que não há packer e que o software foi escrito no Borland C++. Não se pode tomar tudo como verdade, mas é um bom ponto de partida. Além disso, o RDG detecta uma chamada à função IsDebuggerPresent [5]. Alguns softwares se encerram ao perceberem que estão sendo debugados e esta função é uma das formas de ter essa percepção. Geralmente o compilador coloca algumas informações interessantes na seção .data do executável gerado. Não custa olhar rapidamente o que tem lá. Para isso eu usei o pev [6] com a opção “-s”, para exibir informações sobre as seções do executável:

    > pev -s USBVaccine.exe | more
    Sections:
    Name: .text
    Virtual size: 0xd9000
    Virtual address: 0x1000
    Data size: 0xd8600
    Data offset: 0x600
    Characteristics: 0x60000020 (01100000000000000000000000100000)
    contains executable code
    is executable
    is readable
    Name: .data
    Virtual size: 0x1d000
    Virtual address: 0xda000
    Data size: 0x12c00
    Data offset: 0xd8c00
    Characteristics: 0xc0000040 (11000000000000000000000001000000)
    contains initialized data
    is readable
    is writable

    Sabendo o offset (posição) onde a seção .data começa, usei o hdump [7] para espiar os bytes:
     

    > hdump USBVaccine.exe | findstr “d8c[0-9]0″
    000d8c00 43 6f 64 65 47 65 61 72 20 43 2b 2b 20 2d 20 43|CodeGear C++ –C|
    000d8c10 6f 70 79 72 69 67 68 74 20 32 30 30 38 20 45 6d|opyright 2008Em|
    000d8c20 62 61 72 63 61 64 65 72 6f 20 54 65 63 68 6e 6f|barcaderoTechno|
    000d8c30 6c 6f 67 69 65 73 00 00 00 10 40 00 b2 12 40 00|logies….@…@.|
    000d8c40 b2 12 40 00 22 15 40 00 01 00 00 00 00 00 00 00|..@.”.@………|
    000d8c50 fc 64 40 00 00 00 00 00 00 00 00 00 00 00 00 00|.d@………….|
    000d8c60 30 99 4e 00 4c ad 4e 00 50 ad 4e 00 68 d0 4b 00|0.N.L.N.P.N.h.K.|
    000d8c70 c0 d1 4b 00 50 d2 4b 00 e4 d3 4b 00 b0 93 4e 00|..K.P.K…K…N.|
    000d8c80 00 00 f8 ac 4e 00 74 ad 4e 00 ec aa 4e 00 00 00|….N.t.N…N…|
    000d8c90 00 00 00 00 00 00 00 00 00 00 00 90 00 00 00 00|…………….|

    De fato, parece que o binário foi escrito em Borland C++, mas com uma versão mais atual (a Embarcadero comprou a divisão CodeGear da Borland).
    Vamos à execução do software:

    O que procuramos é o código do evento “click” do botão “Vaccinate USB”, certo? Existem ferramentas específicas para se trabalhar com binários gerados em versões específicas de compiladores. No caso do BC++, há uma ferramenta particularmente interessante chamada E2A (Event To Address), que consegue dizer o endereço de cada evento do software, o que facilita muito a vida:

    O endereço da função que o evento “click” do botão chama é 0x404C58. Agora é debugar. Usei o OllyDbg [8] para isso. A ideia é colocar um breakpoint neste endereço, rodar o Vaccine no debugger, clicar no botão para vacinar a mídia e seguir passo a passo o que o software faz, a partir do breakpoint.

    5. Entendendo a proteção:

    Conforme é mostrado no vídeo, o Vaccine cria um arquivo AUTORUN.INF normal na raíz da mídia, mas depois busca pela entrada deste arquivo na FAT para localizar o byte que controla os atributos. Segundo a documentação [9], é o byte depois da extensão do arquivo. Para facilitar a compreensão, usei o Hex Workshop [10], que tem o recurso de editar discos e volumes lógicos. Além disso, ele permite a criação de estruturas personalizadas para interpretar os bytes visualizados. Criei uma estrutura simples (fat32-directory-table.hsl) para reproduzir a Directory Table da FAT-32.

    O byte em questão é um bitfield, onde cada bit corresponde a um atributo:
    Bit      Máscara Atributo
    0            0x01 Somente leitura
    1            0x02 Oculto
    2            0x04 Sistema
    3            0x08 Nome de volume
    4            0x10 Subdiretório
    5            0x20 Arquivo
    6            0x40 Não usado 1
    7            0x80 Não usado 2

    Lembrando que no vídeo mostrei que o Vaccine grava esse byte como 0x20 (Arquivo) e  depois o busca em disco e altera para 0x42 (Não usado 1 + Oculto). É aí que mora a mágica. Não sei o motivo, mas quando o atributo 0x40 está setado, não é possível ler, executar, modificar ou excluir o arquivo. Fiz testes com os outros atributos mas o comportamento esperado só se dá com este bit 6 setado mesmo. Tentativas de implementação Eu tentei, ingenuamente, implementar o recurso no USBForce, que foi escrito em VBScript, mas a propriedade “Attributes” é um enum de valores pré-definidos e não aceita qualquer valor, portanto não aceitou o 0x42:

    Set objFSO = CreateObject(“Scripting.FileSystemObject”)
    Set objFile = objFSO.GetFile(“F:AUTORUN.INF”)
    objFile.Attributes = &H20 ‘Arquivo
    WScript.Echo “0x” + Hex(objFile.Attributes)
    objFile.Attributes = &H40 ‘Não usado 1
    WScript.Echo “0x” + Hex(objFile.Attributes)

    O código acima prevê que já haja um arquivo autorun.inf no volume F. Ele imprime 0x20 e depois 0x0, ou seja, a tentativa de ativar o atributo não usado falha.

    Tentei também usando a API do Windows diretamente, em ?

    #include <windows.h>
    
    int main(void)
    {
    	HANDLE out = CreateFile(“f:\autorun.inf”, GENERIC_READ | GENERIC_WRITE, 0,
    	NULL, CREATE_ALWAYS, 0x40, NULL);
    	CloseHandle(out);
    	return 0;
    }

    O resultado foi um arquivo criado com 0x20 (Arquivo) e não com o 0x40 que pedi. Por enquanto vou adotar como solução possível a busca diretamente na FAT pela entrada do arquivo e modificação bruta do byte de atributos, como o Vaccine faz.

    6. Prova de Conceito

    Como incentivador do software livre, não poderia deixar de implementar esta técnica em código aberto e para funcionar no GNU/Linux. Por isso escrevi um programa para realizar o trabalho, que batizei de OpenVaccine [11]. Por enquanto ele é só uma prova de conceito e seu uso não é encorajado em ambientes de produção.

    Referências

    [1] https://www.mentebinaria.com.br/artigos/segurança/como-remover-vírus-de-pen-drive-r5/
    [2] http://www.pandasecurity.com/homeusers/downloads/usbvaccine
    [3] https://github.com/merces/usbforce
    [4] http://www.rdgsoft.net
    [5] http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx
    [6] https://github.com/merces/pev
    [7] https://github.com/merces/hdump
    [8] http://www.ollydbg.de
    [9] http://www.nationmaster.com/encyclopedia/VFAT#Directory_Table
    [10] http://www.hexworkshop.com
    [11] http://openvaccine.sf.net

     

     


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Felipe.Silva
      Injeção de código é uma técnica que consiste em adicionar instruções extras em um executável. Essas instruções podem ser adicionadas em vários lugares do programa, inclusive executar antes do entry point original.
      O uso mais comum para injeção de código é para fins maliciosos, onde um shellcode poderia ser inserido no executável e dar acesso remoto para um atacante. Mas um exemplo de uso "justo" para essa técnica é para fins de patching no executável quando você quer que algo seja alterado em tempo de execução no binário.
      Se você já tentou injetar código em um executável manualmente deve saber que não é uma tarefa tão divertida. Pensando neste tipo de impasse, imaginei que seria interessante ter uma ferramenta para automatizar esse tipo de manipulação de um executável. Por esse motivo criei o pei, uma ferramenta para automatizar injeção de código e outros tipos de manipulações em executáveis PE de 32-bit e 64-bit.
      O pei foi programado pensando na automação e por isso é fácil usar a ferramenta a partir de um script. Com ela você pode obter e modificar valores no executável, e é claro, injetar código.
      Antes de qualquer coisa você pode instalar o pei em seu Linux rodando os comandos abaixo:
      git clone https://github.com/Silva97/pei cd pei make sudo make install Nota: Caso use Windows e não esteja usando WSL ou um MSYS2 da vida, você pode compilar o projeto instalando o make e o MinGW (recomendo usar o Chocolatey). No entanto, o “sudo make install” não vai funcionar no Windows, você vai ter que adicionar o executável ao PATH manualmente.
      Se você não estiver a fim de compilar o executável, fiz o favor de adicionar o binário da ferramenta compilado para Windows nos releases dela. Você pode baixá-lo no link https://github.com/Silva97/pei/releases/latest.
      O uso básico da ferramenta segue o seguinte formato:
      pei [opções] <operação> <executável> [argumento] Se você quiser ver mais detalhes de como usar a ferramenta você pode rodar “pei -h”.
      Operações
      As operações são o que determinam o que a ferramenta irá fazer com o executável, indo desde exibir informações sobre ele até modificar campos dos cabeçalhos.
      show
      A operação show serve para exibir informações sobre o executável e campos dos cabeçalhos. Se você não passar argumentos para a operação por padrão ela irá exibir informações básicas do executável:

      Você também pode especificar uma combinação de letras para escolher quais campos serão exibidos, dentre elas: c (COFF header), o (optional header), d (data directories) e s (section). Exemplo:
      $ pei show test.exe co Esse comando, por exemplo, exibe o COFF header e optional header do executável.
      get
      A operação get pega o valor de um campo individual de um dos cabeçalhos (coff, optional ou section) do executável.
      Seguindo uma notação com pontos, semelhante à acessar campos de estruturas em C, você pode especificar o cabeçalho e o nome do campo para ser obtido. Por exemplo, para obter o entry point do executável o comando ficaria:
      $ pei get executavel.exe optional.entry_point '%x' 14f0 Dica: Veja o nome dos campos dos cabeçalhos usando a operação show.
      O argumento após o nome do campo é uma string de formatação idêntica a da função printf() da libc, que aceita quaisquer flags de formatação disponíveis para a função.
      Para acessar os campos de uma seção é necessário especificar o número da seção também, como demonstrado no print abaixo:

      edit
      A operação edit serve para modificar o valor de campos, onde o nome do campo é especificado de maneira idêntica à operação get.
      Você pode utilizar os operadores `=`, `|=` e `&=` que fazem exatamente a mesma coisa que na linguagem C. Exemplos:
      $ pei edit executavel.exe section.0.name = .code $ pei edit executavel.exe optional.entry_point = 0xabcd1234 Esta operação aceita números em decimal, hexadecimal ou octal na hora de definir o valor de campos numéricos.
      zeros
      Esta operação simplesmente exibe uma lista das maiores sequências de bytes nulo em cada seção do executável. É este espaço que é utilizado para injetar o código, tornando a operação útil para você poder escolher em qual seção injetar o código.
      $ pei zeros executavel.exe Section #0 '.text': 0x00000000000022fb of 13 bytes Section #1 '.data': 0x000000000000242c of 1012 bytes Section #2 '.rdata': 0x0000000000002a5b of 37 bytes Section #6 '.idata': 0x0000000000003a26 of 22 bytes Section #7 '.CRT': 0x000000000000420b of 21 bytes Section #9 '/4': 0x0000000000004649 of 23 bytes Section #10 '/19': 0x0000000000004cbe of 10 bytes Section #12 '/45': 0x000000000003e2fc of 5 bytes Section #13 '/57': 0x0000000000041019 of 8 bytes Section #15 '/81': 0x0000000000043c33 of 44 bytes Section #16 '/92': 0x0000000000045509 of 23 bytes inject - A cereja do bolo 🙂
      Esta é a operação que injeta o código. Você pode usar a opção -f para especificar o arquivo contendo o código a ser injetado, que seria um raw binary. Onde esse arquivo deve conter apenas as instruções de código de máquina a ser injetado, como um shellcode por exemplo.
      Opcionalmente, você pode usar a opção -s para especificar o número da seção que você quer injetar o código. Se a opção não for especificada, por padrão o pei vai injetar onde houver mais espaço disponível.
      $ pei -f my_code.bin inject executavel.exe Writed code of 12 bytes on offset 0x0000000000043924 of section #15 '/81' Após o código injetado, o pei insere um jump absoluto para o entry point original do executável, fazendo com que após o código injetado ser executado o fluxo de execução do programa continue normalmente.
      Outra modificação que o pei faz é desabilitar o dynamic base do executável, para evitar que o jump aponte para o endereço errado.
      Dica: Injetando Código Muito Grande
      Se você precisar injetar um código maior do que o espaço disponível apontado pela operação zeros, você pode dividir o código a ser injetado em várias partes e injetar cada parte por vez, seguindo a ordem da última até a primeira parte. Isso funciona porque o pei irá adicionar um jump no final do código para o endereço que está sendo indicado como entry point. Se você já injetou código antes, esse endereço é o endereço do código anteriormente injetado. 🙂
      Dessa forma você pode fazer um chain de saltos da primeira parte até a última e então saltar para o entry point original. Exemplo:
      $ pei inject -f parte-3.bin executavel.exe Writed code of 87 bytes on offset 0x0000000000043833 of section #15 '/81' $ pei inject -f parte-2.bin executavel.exe Writed code of 80 bytes on offset 0x0000000000044924 of section #11 '/23' $ pei inject -f parte-1.bin executavel.exe Writed code of 32 bytes on offset 0x0000000000401a15 of section #1 '.text' Isso irá criar a seguinte ordem de execução: parte-1.bin -> parte-2.bin -> parte-3.bin -> entry point. Onde as setas “->” representam os saltos.
      diff
      Esta operação exibe diferenças entre dois executáveis. Ela compara cada campo dos cabeçalhos do executável e o conteúdo das seções, e depois exibe estas diferenças no terminal. Você pode usar a opção -c (ou --color) para que a saída da operação seja colorida:

      Em vermelho são os valores no executável original que foram modificados e em verde são os valores novos no executável modificado.
      patch
      Essa operação lê um texto de entrada no mesmo formato que a saída da operação diff e replica as mesmas modificações no executável. Exemplo:
      $ pei patch executavel2.exe diff-output.txt Caso você não especifique um patch file, o pei irá ler de stdin. Assim, é possível que você faça um pipe entre uma operação de diff e patch:
      $ pei diff original.exe mod.exe | pei patch outro.exe A diferença de fazer isto e simplesmente fazer uma cópia do executável modificado, é que a ideia é replicar somente as diferenças entre os executáveis. Quaisquer outros campos não são tocados pela operação patch, o que te permite salvar alterações e replicá-las por meio de um script. 🙂
      Se você quiser, também é possível escrever um patch file manualmente, bastando imitar a saída de diff. Uma dica é que os valores dos campos originais (em vermelho) não são necessários para a operação patch, então você pode inserir somente os valores novos. Seguindo o print da saída do diff que utilizamos agora pouco como exemplo:
      optional.entry_point xxx 0x4ca33 section.0.name xxx .code section.15.characteristics xxx 0x62100040 // @O texto não faz diferença, só importa o @ no início da linha // Daqui para baixo qualquer linha que não inicie com + será ignorada. +0x43830 00 30 9f 61 62 63 0a b8 f0 14 40 00 ff e0 00 00 // O formato é: +0xoffset bytes em hexadecimal Nota: Onde há o “xxx” seriam os campos dos valores originais (em vermelho) que não são lidos pelo pei porém são necessários para imitar a saída da operação diff. Você pode colocar qualquer valor aí que não dará erro já que são ignorados.
      Você pode usar a operação patch em scripts para automatizar várias modificações em um executável ao mesmo tempo, inclusive em bytes de um determinado offset.
    • By Leandro Fróes
      Se você é da área de Segurança da Informação ou simplesmente tem interesse pelo assunto já deve ter notado que todo dia temos notícias de novos malwares surgindo, sejam eles malwares completamente novos ou variantes de um malware já conhecido. Com isto em mente, faz algum tempo que as empresas de segurança, inteligência e até mesmo pesquisadores independentes passaram a buscar métodos de automatizar não só a análise destes malwares, mas também a administração e armazenamento do arquivo em si, suas características e relacionamentos com outros arquivos demais entidades (domínios, campanhas, endereços IP, etc). Obviamente a análise automatizada não substitui a análise humana, mas já é uma ajuda e tanto considerando o número de malwares surgindo diariamente.
      Para cada uma destas necessidades descritas anteriormente existe uma ou mais ferramentas/plataformas que podem ser utilizadas para cumprir estes objetivos. Dentre elas estão plataformas de sandboxing  como Hybrid-Analysis e AnyRun, ferramentas de análise estática de arquivos como o DIE (Detect It Easy), pev, yara, capa, e também repositórios de malware como o VirusShare e o Malware Bazaar.
      Não podemos negar que todas estas ferramentas/plataformas ajudam e muito no nosso dia a dia, mas ainda assim não conseguiríamos organizar nossas informações e centralizá-las em um único lugar de forma automática, tendo em vista que as as soluções descritas acima são isoladas e não conectam umas com as outras de forma nativa. A plataforma que chegou mais próximo de atingir as quatro exigências (isto é: análise automatizada, administração, armazenamento, relacionamento com demais entidades) foi uma plataforma chamada Virus Total, também conhecido como VT, atualmente administrado pelo Google.
      Virus Total
      O Virus Total trouxe para a comunidade uma forma simples e rápida de análise de IoCs (Indicator of Compromise) e também uma API bem simples de se utilizar para fins de automação. Dentre as diversas funcionalidades da plataforma estão inclusas análise estática, checagem de assinatura utilizando uma lista gigantesca de Anti-Virus, descrição das características gerais do IoC e comentários da comunidade. Além disso, ele também possui uma versão paga (bem cara por sinal) onde você pode fazer hunting de malwares utilizando regras de Yara, download de arquivos, buscas baseadas em histórico, visualização gráfica e uma API bem mais robusta e permissiva.
      É importante deixar claro que o termo IoC não se refere apenas à arquivos e seus hash, mas também à URL, domínios e IP. Ou seja, o VT realmente acaba se tornando uma opção super viável para começar qualquer tipo de investigação.
      O cenário atual de Segurança da Informação
      Com o passar do tempo não só a comunidade, mas também o mercado de Segurança da Informação no geral passou a notar que a única forma de se posicionar contra os ataques atuais é através de contribuição. Pelo mesmo motivo que gerou a necessidade de se criar formas automatizadas de análise, a contribuição se mostra cada dia mais que necessária pois ela não impõe limites, muito pelo contrário, ela dá liberdade o suficiente para você contribuir da forma que quiser.
      Um ótimo exemplo que mostra o exercício da contribuição e o quão valioso isto pode ser é o próprio Linux, que desde sua primeira versão foi liberado para receber contribuições e hoje é um dos maiores projetos existentes na área de tecnologia, com milhares de contribuidores ao redor do mundo.
      Com isto em mente, podemos notar uma desvantagem no VT: o espaço para contribuição é limitado.
      Desafios
      Como já comentado anteriormente, as principais funcionalidades são suportadas apenas na versão paga e infelizmente não são todos que podem pagar pelo valor do serviço.
      Um dos principais motivos dessa limitação é fato do código não ser aberto, isto é, estamos presos às funcionalidades que o time do VT disponibiliza. Se o código fosse disponível para a comunidade, resolveríamos tanto o problema monetário quanto a limitação de funcionalidades disponíveis.
      Uma outra porta que seria aberta no cenário descrito acima é a seguinte: Imagine que você, sua empresa, seu time ou um grupo de amigos estão com um projeto em mãos que envolve análise, classificação, categorização ou qualquer tipo de manipulação de malware. Com o código em mãos você teria liberdade de fazer a instalação da plataforma localmente ou em um servidor do qual você controla, limitando o acesso à quem você quiser e como quiser.
      A comunidade
      Tendo estes desafios em mente, a comunidade começou a criar alternativas para resolver alguns problemas encontrados no cenário atual. A ideia do artigo não é de forma alguma dizer que uma plataforma é melhor que outra ou que o Virus Total está errado em trabalhar no modelo que trabalha, muito pelo contrário, o objetivo aqui é mostrar as várias formas que temos de se chegar no mesmo objetivo. Uns mais flexíveis, outros com mais conteúdo disponível, mas todos conseguem te ajudar a chegar no mesmo lugar:
      Saferwall: Este é o projeto mais maduro que temos atualmente quando o assunto é análise automatizada e contribuição da comunidade. Robusto e flexível para ser instalado em  diversos ambientes, o Saferwall consegue entregar informações estáticas de arquivos, detecções baseadas em assinaturas de alguns antivírus, identificações de packers e download dos arquivos submetidos anteriormente. Além disso, o Saferwall possui uma plataforma aberta e que aceita colaboração, além de disponibilizar o código para você instalar onde e como bem entender. Dentre as formas de instalação estão inclusas o minikube (indicado para ambientes de testes), em nuvem utilizando AWS e On-Premise.


      Freki: O projeto Freki foi criado por uma única pessoa, mas não deixa a desejar quando o assunto é funcionalidade e fácil instalação. Com possibilidade de ser instalado utilizando Docker, este projeto possui não só análise estática dos arquivos PE submetidos, mas também disponibiliza sua própria API e puxa informações do VT para garantir que não falte nada.


      Aleph: focando bastante na parte de inteligência, o projeto Aleph entrega para você não só informações estáticas dos arquivos submetidos, mas também análise dinâmica utilizando sandbox, visualização gráfica dos resultados e uma saída em JSON formatada para ser utilizada em backends como Elasticsearch, por exemplo. Além disso, o Aleph também consegue mapear as técnicas utilizadas pelo malware utilizando o MITRE ATT&CK Framework. Eu realmente aconselho você dar uma olhada na palestra da MBConf v3 sobre o Aleph para saber mais sobre o projeto.
       


      A tabela à seguir foi criada para facilitar a visualização das funcionalidades descritas acima. É importante deixar claro que a versão do VT utilizada para a criação da tabela é a gratuita:
       
       
      VirusTotal
      Saferwall
      Freki
      Aleph
      Análise Estática
      ✔️
      ✔️
      ✔️
      ✔️
      Análise Dinâmica
       
      X
       
      ✔️
       
      X
       
      ✔️
       
      Suporte à múltiplos SO
      ✔️
       
      ✔️
       
      X
       
      ✔️
       
      Análise de IoC de rede
      ✔️
       
      X
       
      X
       
      X
       
      Código Aberto
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Download de arquivos
       
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Instalação local
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Controle total do backend
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      API
       
      ✔️
       
      ✔️
       
      ✔️
       
      X
      Como podemos ver, todos estes projetos são de código aberto, o que permite a seus usuários livre contribuição. Caso você tenha interesse em contribuir para alguns desses projetos, aqui vai uma dica: nenhum deles possui ainda análise de URL/IP/domínio de forma isolada, isto é, independente do arquivo. Tenho certeza que uma contribuição deste tipo seria bem vinda. ?
      Conclusão
      Ajudando estes projetos nós não só melhoramos a ferramenta/plataforma em si, mas ajudamos todos que a utilizam e também construímos um sistema livre e aberto de análise, inteligência e investigação.
      Se você é da área ou simplesmente curte contribuir, não deixe de dar uma olhada em cada um destes projetos e, se possível, contribuir com eles. Lembrando que quando falamos de contribuição, não há limites. Pode ser um commit, uma ideia, ajuda monetária ou um simples OBRIGADO aos desenvolvedores e contribuidores por disponibilizarem projetos tão úteis para a comunidade.
    • By Leandro Fróes
      ImHex é um editor hexadecimal gráfico multiplataforma e seu principal objetivo é ajudar na engenharia reversa e programação. O editor conta com inúmeras funcionalidades como por exemplo busca por strings, cópia de bytes em diversos formatos (C string, Python, etc), disassembling, hashing e muito mais. Além disso, o editor possibilita a criação das suas próprias templates para serem mapeadas no editor hexa (baseado em um formato de arquivo, por exemplo) através de uma linguagem de patterns:

      Dentre as novas funcionalidades adicionadas na nova release estão alguns itens da linguagem de script como por exemplo "alignTo", que alinha um valor com o que você determinar e "nextAfter", que pega o endereço logo depois de uma variável:

      Esta release também adicionou uma funcionalidade chamada Data Processor, que faz a ferramenta pré-processar os dados do arquivo sendo analisado de forma gráfica antes da análise do visualizador hexadecimal, permitindo a definição de valores e operações em regiões/bytes específicos:

      Lembrando que o ImHex possui suporte à plugins e não só o Data Processing, mas também outras funcionalidades podem ser estendidas do jeito que você quiser!
      Também foram adicionadas algumas outras funcionalidades como cores e utilização do teclado, assim como um conversor de base e habilidade de setar um endereço base no editor hexa:


      A release foi bem grande e com certeza merece uma olhada. Para fazer o download, é só clicar no botão abaixo, que te leva direto para a página de releases do projeto, onde você pode escolher qual versão quer baixar! 😉
       
    • By lucass
      Vou começar agradecendo ao @Fernando Mercês pela oportunidade e por ter sugerido este artigo, que também me motivou bastante a escrevê-lo!
      Introdução
      Não sou conhecido internet a dentro, apenas acompanho alguns canais no Discord (tal como o do Mente Binária). Meu nível de programação e engenharia reversa não é algo admirável ainda. Em um grupo especifico intitulado "Terra do 1337", que é um grupo fechado de amigos com finalidade de estudar engenharia reversa, programação e descontrair, eu surgi com uma idéia de escrever uma ferramenta que iria facilitar a vida de muitos nesta área de engenharia reversa e achei de API Inspector.
      A seguir um spoiler de como foi o início do projeto, para quem se interessar. ?
      O que é o API Inspector
      É uma ferramenta de código-aberto voltada para área de engenharia reversa, que irá auxiliar na análise de funções correspondentes a certas API's do Windows, retornando informações obtidas dos argumentos caso a função seja chamada pela aplicação.
      O que ele faz
      Ele faz um hook (do Inglês "gancho"), que consiste num desvio na função original da API solicitada para nossa própria função e com isso podemos obter os dados (argumentos/parâmetros) que foram passados para tal função.
      Como ele funciona
      O princípio de um hook é simples: você insere no inicio da função um salto que irá levar para a sua função (que é uma cópia da função original) e depois de efetuar o que quiser, irá retornar para a função original prosseguir.
      Talvez mais fácil visualizar o que expliquei com código:
      //Aqui está a função //ZwWriteVirtualMemory | NtWriteVirtualMemory, originada do binário: ntdll.dll //créditos ao https://undocumented.ntinternals.net/ NTSYSAPI NTSTATUS NTAPI //WINAPI NtWriteVirtualMemory( IN HANDLE ProcessHandle, IN PVOID BaseAddress, IN PVOID Buffer, IN ULONG NumberOfBytesToWrite, OUT PULONG NumberOfBytesWritten OPTIONAL ); //Sua versão assembly 777F2110 mov eax,0x3A 777F2115 mov edx,ntdll.77808D30 777F211A call edx 777F211C ret 0x14 //O que nós vamos fazer é criar uma função similar á ela com o nome que decidirmos //Então vamos inserir um jmp no início da função original para nossa função, ficando assim: 777F2110 jmp api inspector.573523EC 777F2115 mov edx,ntdll.77808D30 777F211A call edx 777F211C ret 0x14 //Usei como exemplo minha próprio ferramenta! //Então quando ocorrer a chamada desta função ela será jogada em nossa função! Depois de nós fazermos que desejar vamos retorna-la, porém para uma região que aloquei onde contém //Um buffer dos bytes que foram sobrescritos da função original: 03610000 mov eax,0x3A 03610005 jmp ntdll.777F2115 //Ela irá retornar depois do jmp que existe na função original e continuar o código.... Vantagens de se utilizar o API Inspector ao invés de um debugger
      Imagine que você está visualizando as chamadas intermodulares (para bibliotecas externas, no caso) que um programa faz, utilizando um debugger (o x64dbg por exemplo) e notou que uma certa função que deseja inspecionar é chamada em diversos pontos do programa. Vejo duas opções neste caso: colocar vários breakpoints, um em cada chamada à função, no código do programa ou colocar um único breakpoint função em si, no código dela, na DLL.
      Em ambos os casos, você vai precisar analisar chamada por chamada, parâmetro por parâmetro. E se a função for chamada 20 vezes consecutivamente? O tempo que você levaria para visualizar apenas o primeiro parâmetro da chamada é o tempo que a ferramenta iria levar para exibir todas as 20 chamadas, com os argumentos formatados bonitinhos ao seu dispor. Entende a vantagem? ?
      E as desvantagens?
      Por hora, uma desvantagem é a quantidade de funções e API's suportadas. De fato, a primeira release não possui uma quantidade significativa que vá fazer você utilizar a ferramenta e nem uma quantidade de recursos interessantes na ferramenta. Mas é ai que vem o ponto chave, o fato de deixar ela pública remete ao próprio crescimento da mesma, no primeiro momento é necessário uma orientação da parte de vocês para me ajudar a melhorar o código visual. O segundo passo é eu e vocês começarem a fornecerem mais recursos para ela. Eu irei adicionar todo ou qualquer recurso que seja significativo para a mesma, e para isso eu já tenho mais funcionalidades para implementar na ferramenta que são excelentes.
      Interface gráfica
      Na imagem abaixo, utilizei o API Inspector para hookar a função MessageBoxW() da USER32.DLL. Depois disso, escrevi um texto num novo arquivo no Notepad++ e tentei fechar o programa. Ao fazer isso, o Notepad++ perguntou se eu queria salvar o arquivo e ele faz isso através de uma chamada à MessageBoxW(), que o API Inspector interceptou prontamente.

      Na imagem acima, a janela à esquerda mostra o que está atualmente passando pelas funções hookadas. Na janela a direita, temos um log.
      Como utilizar o API Inspector
      A única coisa que você precisa fazer é anexar a DLL do API Inspector ao processo desejado e para isso existem os softwares chamados "Injetores de DLL" que podem ser achados na internet.
      Você também pode criar o seu próprio injetor. Uma dica é pesquisar sobre injeção com a função LoadLibrary(), mas no exemplo a seguir eu vou mostrar como utilizar o Process Hacker para fazer a injeção.
      1 - Abra o Process Hacker e identifique no mesmo o processo no qual você quer injectar a DLL do API Inspector. No exemplo, usei o processo do Notepad++.

      2 - Clique com o botão direito sobre o processo e escolha Miscellaneous > Inject DLL.

      3 - Selecione a DLL API-Inspector.dll e clique em Abrir.

      4 - Se o Process Hacker possuir privilégios suficientes a ferramenta irá ser carregada, caso contrário, não.

      Após isso você precisa selecionar a API desejada, a função desejada e clicar em GO Hook!
      O step call é uma funcionalidade que vai fazer a ferramenta aguardar o pressionamento da tecla ENTER para retornar para a função original. Pronto, o seu hook está feito e você já poderá inspecionar a função desejada.
      Download e código
      No repositório do API Inspector no Github você pode baixar a versão compilada e ter acesso ao código-fonte também. Contribuições são muito bem vindas!
      Bom, eu nunca tinha escrito um artigo. Se faltou informação ou coloquei informação demais me desculpe. Estou aberto pra ler os comentários. Ah, e participem deste projeto! Eu quero fazer ele crescer muito. Caso precise de referências de como cheguei a este projeto, tem tudo na página inicial do projeto no Github.
      Agradecimentos
      Obrigado novamente ao Fernando Mercês, ao pessoal do Terra 1337 que me incentiva cada vez mais e em especial para o iPower e Luan que são colaboradores do projeto.
      Referências
      Dear ImGui Programming reference for the Win32 API NTAPI Undocumented Functions C++ 3D DirectX Programming
    • By Fernando Mercês
      Apesar de ser um assunto que já foi tratado em muitos sites e fóruns, continuo a observar que alguns usuários do Windows devem ter mais atenção com o tipo de arquivo que aplica o famoso duplo-clique. Identificar se o arquivo é inofensivo ou se é uma ameaça pode ser mais fácil do que se imagina. Este artigo tem como intenção desmistificar as lendas sobre as extensões de arquivos maliciosos e alertar sobre as extensões perigosas.
      O sistema operacional Windows reconhece (deduz o conteúdo) dos arquvios por sua extensão. Mas o que é extensão de arquivo?
      Extensão de arquivo para o MS-Windows, comumente são os três caracteres após o ponto, no nome completo do arquivo. Por exemplo, documento001.txt, é um arquivo com extensão .TXT, logo, o Windows deduzirá que é um documento de texto e associará este documento à um certo programa, que poderá abrí-lo (recebendo seu caminho como parâmetro) mediante um duplo-clique neste documento.
      Confundiu? Bom, em termos práticos, cada extensão de arquivo que mereça, possui um determinado programa responsável por interpretar um duplo-clique num arquivo que possua tal extensão. Essas informações (quais extensões são abertas por qual programa) ficam no registro do Windows.
      Ainda com o exemplo do documento001.txt, vamos analisar sua associação: ao dar um duplo-clique nele, vemos que ele é aberto pelo Bloco de Notas (notepad.exe).
      A chave do registro responsável por armazenar as informações desta associação é, no Windows XP: HKEY_CLASSES_ROOT\txtfile\shell\open\command. Veja a imagem:

      Perceba que na coluna "Dados" há o caminho completo do notepad.exe (usando uma variável de sistema sim, mas não deixa de ser o caminho absoluto), seguido de %1. Já sabemos que é o Bloco de Notas (notepad.exe) que abrirá arquivos de texto, agora vamos entender o parâmetro.
      Eu escrevi mais acima que o caminho do arquivo a ser aberto era passado por parâmetro. É justamente isso que o "%1" faz. Essa variável armazena o caminho absoluto do arquivo que está sendo acessado, no instante do acesso. Portanto, se você clicou no arquivo documento001.txt e ele está em C:\docs\, esta variável conterá o valor C:\docs\documento001.txt. Isso informa ao Bloco de Notas onde está o arquivo.
      Agora que já sabemos o que é e como funciona a extensão, vamos aos riscos.
      Um arquivo executável precisa ter uma extensão de executável para ser executado. As extensões mais comuns de arquivos executáveis são: EXE, COM, BAT, VBS, MSI, SCR, arquivos do Office (porque podem conter macros, que são executáveis).
      Um vírus, obrigatoriamente, tem que ter uma dessas extensões. Ou seja, ele tem que ser um executável.
      O problema é que há certos disfarces utilizados pelos disseminadores de vírus. Um deles é colocar um nome de arquivo do tipo: "arquivo.jpg .exe". Assim mesmo, com vários espaços entre o .jpg e o .exe. A extensão deste arquivo de exemplo é .EXE e ele será executado como tal! Não é .jpg! O texto ".jpg" neste caso faz parte do nome do arquivo e não da extensão. A "técnica" de colocar espaços é para que os programas de email e webmail identifiquem um nome muito grande e exibam reticências após o .jpg, dando a impressão que é um arquivo de imagem.
      Detalhe que o ícone de um executável pode ser facilmente alterado para o ícone de uma imagem, o que aumenta as chances da vítima de ser enganada.
      Os vírus são programas. Logo, repito, são executáveis. Um arquivo de áudio puro, por exemplo, não pode ser vírus! A extensão .mp3 estaria associada ao Windows Media Player, ou Winamp, ou qualquer outro. Esses software não executam rotinas de executáveis. Só entendem fluxo de mídia, portanto, não executam as rotinas virais diretamente. Mas eles podem conter falhas que sejam exploradas através de payloads maliciosos de arquivos de mídia ou playlists (como os .m3u).
      Tenha certeza da extensão do arquivo e de sua procedência, e estará praticamente livre de ser infectado por um vírus anexo à um e-mail ou disponível para download. Mas lembre-se que os arquivos podem também estar zipados (.ZIP) ou compactados com outro compactador (RAR, LZIP, GZIP, LHA, JAR, etc). Dentro deles é que você deve examinar a extensão do arquivo.
×
×
  • Create New...