Jump to content
  • Sign in to follow this  

    (Des)protegendo mídias USB

       (0 reviews)

    Fernando Mercês

    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

     

     

    Sign in to follow this  


    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.

    Guest

  • Similar Content

    • 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.
    • By Fernando Mercês
      A maioria dos vírus e pragas virtuais compartilham de certos métodos de auto-inicialização com o SO. Isto inclui os spywares e seus similares.
      Os sistemas Windows possuem métodos para inicializar programas junto ao seu carregamento limitados. Na maioria das vezes os vírus iniciam justamente por eles e daí a importância de conhecê-los e saber gerenciá-los. Desta forma, o técnico pode remover manualmente muitas pragas, o que economizará tempo com scans de softwares antivírus e anti-spys, além de ser extremamente útil quando o vírus ataca estes softwares de proteção, impedindo sua inicialização.
      Primeiro vamos ver de que jeito um aplicativo pode ser iniciado junto ao Windows. A maior parte dos vírus age deste jeito.
      Em sistemas baseados em Windows NT, o que inclui os Windows 2000, XP e 2003, os métodos de inicialização de programas são:
      Através da pasta Inicializar do Menu Iniciar. No registro do sitema. Por serviço de sistema (o que inclui certa parte do registro). Na primeira maneira, basta colocar um atalho para o programa que se deseja executar na pasta Inicializar do Menu Iniciar. Por exemplo, na imagem abaixo, a cada inicialização do Windows, inicializaremos a Calculadora junto.

      Obviamente um vírus pode se aproveitar deste recurso e colocar um atalho para si neta pasta mas não é comum isso acontecer pois o vírus ficaria facilmente visível e uma das intenções de vírus complexos é passar despercebido ao usuário/técnico. De qualquer forma, não custa conferir.
      Agora vamos ao método mais usado, o registro do sistema. Aqui precisaremos explicar resumidamente como o registro destas versões do Windows funciona.
      O registro é um banco de dados que armazena informações essenciais sobre diversos softwares instalados no Windows, além de informações pertinentes ao próprio sistema. Por conta disto, é comum apelidar o registro de “alma do sistema”.
      Esse banco de dados possui, além de outros dados, chaves, sub-chaves e valores numa organização hierárquica (similar ao Windows Explorer).
      Para o artigo, precisaremos conhecer essas três chaves:
      HKEY_LOCAL_MACHINE – Esta é a chave mais importante do registro. Nela estão contidas informações sobre o PC (hardware instalado, softwares com sua opções e configurações e outros itens). Inclusive veremos que um programa pode ser inicializado por uma sub-chave desta chave. HKEY_USER – Nesta chave são definidas configurações personalizadas para cada usuário do sistema, já que as versões do Windows mais novas permitem logon simultâneo ou não de usuários diferentes. De maneira similar à chave anterior, um vírus pode inicializar-se junto ao SO somente para um usuário específico, usando uma sub-chave desta chave. HKEY_CURRENT_USER – Como o nome sugere, mantém informações sobre o usuário que está atualmente logado no sistema. Todo o registro é dinâmico mas esta chave merece uma definição de dinamismo especial pois muda os valores de suas sub-chaves completamente quando logamos com outro usuário no Windows. Não é difícil de deduzir que ela é um atalho para uma sub-chave de HKEY_USER, já que esta última mantém uma sub-chave para cada usuário cadastrado no sistema. Por exemplo, se logarmos com o usuário “Fernando”, esta chave será uma cópia da sub-chave HKEY_USER. SID (Security Identifier) é uma identificação única que cada usuário tem e o SO conhece os usuários através deste SID. Abaixo, o utilitário “regedit” (Registry Editor), usado para visualizar o conteúdo do registro do sitema.

      Perceba a igualdade entre as áreas destacadas em vermelho. É justamente o que falamos na explicação da chave HKEY_CURRENT_USER. Note o SID do meu suário também.
      Depois desta breve introdução ao registro do sistema, podemos partir para as sub-chaves que realmente importam na questão da remoção manual de vírus.
      São elas:
      HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx HKEY_USERS\SOFTWAREMicrosoftWindowsCurrentVersionRun HKEY_USERS\SOFTWAREMicrosoftWindowsCurrentVersionRunOnce As duas últimas chaves acima dependem do SID do usuário mas se a suspeita de vírus for no usuário que está logado, você pode acessá-las pelo atalho como comentamos acima.
      Tudo o que estiver nestas chaves será inicializado junto ao sistema. Faça o teste: verifique o que tem nas sub-chaves de seu PC e veja os caminhos para os arquivos que incializam. No exemplo HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun da máquina que usei, está assim.

      Como podemos ver, só há três valores, que são os caminhos absolutos dos executáveis que inicializam junto à máquina usada. Esta é uma máquina virtual. Numa máquina real, os valores normais são outros.
      Para remover programas da inicialização, basta remover os valores desejados.
      É importante salientar que muitos arquivos presentes nestas sub-chaves são essenciais ao sistema e não devem ser removidos. Cabe ao técnico saber identificar caminhos e nomes de executáveis suspeitos. Se você tiver dúvida quando à procedência de algum arquivo, pode digitar seu nome no site Process Library, que mantém uma lista atualizadas de processos (programas em execução) para nos ajudar a identificar se são do sistema ou não.
      Há ainda o método de serviços que podem ser utilizado por alguns vírus mais complexos. A tela de serviços você tem acesso indo no menu Iniciar > Executar, digitando services.msc e clicando no botão OK. Eis a da máquina que usamos para o artigo.

      Esses serviços são na verdade processos (programas) inicializados que recebem este nome pela capacidade de poderem ser muito melhor gerenciados pelo sistema operacional que um processo comum. Perceba a coluna “Status” na imagem. Um serviço pode ser iniciado, reiniciado, pausado ou parado e seu método de inicialização pode ser manual (quando clicado), automático (a cada inicialização do sistema) ou desativado. Um vírus obviamente se aproveitaria do método automático e poderíamos pará-lo e depois desativá-lo numa remoação manual.
      Assim como os processos comuns, a maioria dos serviços é essencial ao sistema, portanto, é bom que se faça uma pesquisa sobre ele (no Google e sites similares) antes de parar ou desativar um serviço suspeito ou não.
      Ao entrarmos nas propriedades de um serviço, vemos o caminho do executável ao qual ele se refere além de uma caixa drop-down para alterar o tipo de inicialização, como mostra a imagem abaixo.

      Com este básico conhecimento, muitos vírus podem ser removidos mas é claro que não basta. Recomendamos sempre um scan com um bom antivírus atualizado e com um anti-spy, mesmo após a remoção manual.
      Existem alguns programas que podem ajudar na identificação de vírus e na remoção manual. Abaixo segue uma lista com descrição:
      Process Explorer – monitora os processos em execuçao em tempo real, o que permite identificarmos se algum processo suspeito está sendo executado. O Process Explorer também mostra o que o processo está fazendo ou tentou fazer (quando bloqueado pelo SO). HiJackThis – gera uma lista e um arquivo de log com todos os processos que inicializam junto ao sistema, podendo ser utlizado inclusive para remover o que sejam julgados suspeitos (muito cuidado com seu julgamento). NOTA: O projeto original foi descontinuado, mas o usuário Polshyn Stanislav da Ucrânia o continuou. Gmer - uma aplicação que detecta e remove rootkits (dentro de um limite, claro). A ideia é procurar por uma lista de coisas escondidas, tais como processos, threads, serviços, arquivos etc. MSCONFIG – utilitário presente no Windows XP mas que pode ser copiado a partir do arquivo msconfig.exe para outros sitemas Windows. Ele mostra de forma interativa o que está sendo inicializado junto ao sistema além de permitir a consulta de outras informações. Você pode chamá-lo a partir do menu executar.
    • By Leandro Fróes
      Após ver sobre o comando find no nosso canal Papo Binário decidi estudar um pouco mais sobre o mesmo. Revisando estas anotações pensei que seria interessante compartilhá-las, tendo em vista que o find é um comando extremamente poderoso. Alguns dos parâmetros já foram abordados no vídeo, mas vou repassar alguns aqui, não custa nada, não é mesmo?!
      Este comando pode ser útil para diversas tarefas, dentre elas investigação, administração ou mesmo aprendizado sobre o sistema.
      Indo direto ao ponto, o find é um comando para procurar itens no filesystem (arquivos, links, diretórios, etc). O que o difere de outros programas que fazem isto é a quantidade de opções que a ferramenta possui e o fato de não depender da variável $PATH para encontrar um binário. O comando leva como principal parâmetro um path, ou seja, um caminho para procurar algo. Se não passarmos nada ele entenderá que o path é o diretório atual:
      find find /etc Se não especificarmos exatamente o que queremos buscar o find simplesmente nos mostra tudo o que achar pois ele varre o filesystem recursivamente na hora de procurar algo, mas não queremos isso tudo, até porque não seria muito útil. 🙄
      Vamos tentar entender alguns filtros interessantes... Imagine que você é um administrador e precisa verificar todos os arquivos que pertencem a um usuário em específico:
      find / -type f -user leandro O que fizemos aqui? Utilizamos 2 tipos de filtros, um deles foi o -user, que busca arquivos que pertencem apenas à aquele usuário. O -type filtra pelo tipo de item no filesystem e suporta os seguintes tipos:
      d -> diretório f -> arquivo regular l -> link simbólico s -> socket     Procurando por arquivos perdidos:   Imagine agora que seu sistema está uma bagunça e você não faz ideia onde está um arquivo em específico, pense que você tem no mínimo 8 subdiretórios lotados de arquivos e você não lembra onde está o que você está procurando, só lembra que existe a palavra "mentebinaria" no nome dele. Além disso, você também sabe que não está nos primeiros 2 subdiretórios. Podemos resolver com: find . -mindepth 2 -name "*mentebinaria*" -type f A primeira coisa que fizemos foi utilizar a opção -mindepth, que especifica quantos níveis na hierarquia o find deve olhar no mínimo (a opção -maxdepth especifica o máximo). A outra opção foi a -name, que procura por um nome completo ou parte dele como fizemos no exemplo utilizando o wildcard * (asterisco) para bater com qualquer string antes de depois da palavra "mentebinaria".   Executando comandos:
      Na minha opinião uma das opções mais interessantes do find é a -exec, que praticamente executa comandos em cima do que o find encontrar. Não entendeu? Vamos lá... supondo que queiramos ver qual o tipo de arquivo de todos os arquivo que encontrarmos em um diretório em específico com o comando file:
      find . -type f -exec file {} \; Temos muita coisa pra entender nesta linha. Primeiro, o -exec trabalha com o conceito de targets (as chaves {} ) e isto significa: coloque tudo o que o find devolver no local da chave. Para cada arquivo que o find achar ele rodará o comando file naquele arquivo. Incrível, não?
      Sim, mas com isto estaremos executanto o mesmo comandos múltiplas vezes, por exemplo:
      leandro@teste:~$ find . -type f | wc -l 295 Imagine rodar isto 295 vezes, muita coisa, não? Se notarmos no primeiro exemplo do -exec vemos que no fim da linha tem um ponto de vírgula e este indica o fim do -exec para o find (e não para o shell). Temos que usar a contra barra para escapar e o shell não pensar que é para ele.
      Ok, mas até agora não vimos como melhorar isto. Concordam que o comando file aceita mais de um parâmetro?
      file arq1 arq2 arq3 E se pudéssemos pegar tudo que o find achar e, ao invés de rodar um comando do -exec por vez passamos tudo um atrás do outro? É exatamente isto o que o + faz e para ele não precisamos escapar:
      find . -type f -exec file {} + Este exemplo é a mesma coisa do anterior, mas de forma mais automatizada. Vamos medir a velocidade dos dois comandos:
      root@teste:~# time find / -type l -exec file {} \; ... real 0m15,127s user 0m0,336s sys 0m1,640s root@teste:~# time find / -type l -exec file {} + ... real 0m1,119s user 0m0,212s sys 0m0,396s Bem mais rápido com o +, não acham? 😉
       
      Investigando o sistema:
      Seu servidor foi atacado, você não sabe exatamente o que aconteceu e como aconteceu, só sabe que nem tudo está funcionando do jeito que deveria. Uma coisa interessante à se fazer é tentar olhar para o que exatamente foi alterado desde o ataque. Imagine que isto ocorreu à 2 dias: find / -mtime -2 Aqui estamos dizendo que a partir da hora que rodarmos o comando olhar para tudo que foi modificado 48 horas atrás. Podemos também verificar se algo foi acessado com -atime.
      E se você não sabe exatamente quando foi o ataque? A única coisa que você sabe é que a última coisa que você fez foi adicionar novas funcionalidades à um script que você tem. Podemos procurar por tudo que foi modificado após este arquivo com a opção -newer:
      find /etc -newer <arquivo_velho> Mas como isto? O Linux guarda um tipo de informação chamada MAC no inode de cada arquivo, resumindo é simplesmente a data da última modificação, acesso e criação do arquivo ao qual aquele inode se refere. Apenas como curiosidade, o comando stat lê essas informações também. 😋
       
      Mais algumas informações:
      Ok, agora você não teve nenhum problema, só quer algumas informações sobre os arquivos que o find encontrar. A opção -size <n> pode ajudar a procurar por arquivos maiores (+) ou menores (-) que o especificado:
      find /var -size +20k Podemos trabalhar com os seguintes formatos:
      c -> bytes k -> KB 0 ou -empty -> vazio find . -empty Não está satisfeito? Ok, a opção -ls ti da muito mais informações (praticamente aplica um ls -lids em cima de tudo que o find achar)
      find . -user leandro -type d -ls  
      Facilitando o parsing:
      Achou as opções de informações fracas? De fato a saída fica bem poluída. E se você precisasse todo dia monitorar informações específicas sobre arquivos específicos e criasse um script para isso, como você faria para obter estas informações? O find ti ajuda nisso também!!! Se você está familiarizado com a linguagem C (se não está veja isto) a função printf do C pode imprimir uma saída formatada de acordo com o que você escolher (string, inteiro, inteiro sem sinal, etc).
      Assim como em C, a opção -printf possui uma série de diretivas para formatarmos a saída do find como quisermos, algumas delas são:
      %f -> nome do arquivo %p -> path completo %i -> inode %M -> permissões %n -> número de hard links find / -type f -atime -1 -printf '%p %i %M \n' O único detalhe aqui é que por padrão o -printf não coloca um caractere de nova linha, devemos adicionar como no exemplo. Com isto a saída fica bem mais interesante para um script ler, não acham?! Aqui está o exemplo de uma saída:
      file1 262295 -rw-r--r-- file2 262283 -rw-r--r-- file3 262296 -rw-r--r-- Estas foram algumas dicas sobre o comando find. Com certeza informações mais completas podem ser encontradas no manual do comando, este tutorial tem como objetivo simplesmente compartilhar minhas anotações sobre o que acho bem interessante e usual sobre o comando find.
      Qualquer dúvida, crítica ou sugestão, por favor, sinta-se à vontade para comentar e obrigado! 😄
    • By njrizzo
      IV BSDDAY em Seropédica
      Devido a greve dos caminhoneiros na semana da data anterior (26/05)
      o evento foi reagendado para a data de 30/05
      Façam suas inscrições e doações via vakinha ou paypal
       
      www.bsdday.com.br
×
×
  • Create New...