Jump to content
  • Como criar um pacote deb “na unha”

       (0 reviews)

    Aproveitando que farei uma apresentação sobre pacotes deb na comemoração do 18º aniversário do Debian GNU/Linux, decidi escrever este artigo, para mostrar o que é um pacote deb e como ele pode ser gerado de forma quase artesanal.

    O objetivo deste artigo é mostrar o que é um pacote deb e como ele se comporta. Mostrarei como olhar o conteúdo de um pacote deb a fim de copiar sua estrutura para gerar um novo, coisa que fiz quando comecei a me interessar pelo assunto.

    Este artigo faz parte de um objetivo maior, que é atrair colaboradores para a comunidade Debian. Um pacote “caseiro” não será aceito nos repositórios oficiais, mas iniciará o leitor no mundo do empacotamento e, quem sabe, despertará o Debian Maintainer que há em você.:)

    1. Introdução

     

    Imagine um mundo sem pacotes deb. Todos os softwares livres seriam distribuídos em código-fonte. Você seria obrigado a baixar, compilar e instalar. Fácil? Nem sempre. Os programas possuem dependências de bibliotecas que o desenvolvedor usou. Na máquina dele essas bibliotecas estão instaladas, na sua provavelmente não. Então seria preciso instalá-las antes de compilar o programa que você quer.

    Claro que os jargões utilizados aqui só fazem sentido para usuários avançados. O Linux não teria conquistado a popularidade que tem hoje se os usuários leigos tivessem que compilar o Firefox para navegar na internet. Os pacotes supriram esta necessidade e hoje um software inteiro com suas dezenas de dependências pode ser instalado graficamente ou com uma curta e simples linha de comando. Cabe aqui um viva ao software livre. o/

    Este artigo não é para leigos, mas para quem gostaria de entender como o pacote deb funciona.

     

    2. Pacote “caseiro” x pacote oficial

     

    Para fazer um pacote e submetê-lo ao repositório oficial, você precisa ler, compreender e seguir rígidas regras de qualidade, que podem ser encontradas nos documentos oficiais [1]. No entanto, creio que o modo mais fácil é começar por um pacote “caseiro”, que não segue a política, para entender o funcionamento e então partir para o estudo dos documentos. Foi assim que deu certo comigo e hoje mantenho o pacote do pev [2] no repositório oficial (testing).

    A comunidade Debian oferece uma série de ferramentas para criação de pacotes, sempre com foco nos pacotes oficiais. Neste artigo evitarei usar tais ferramentas, mas vou comentar, para que o leitor já se ambiente.

     

    3. Do que é feito o pacote deb

     

    Se você der uma olhada em no diretório /var/cache/apt/archives provavelmente vai encontrar vários pacotes deb. Eles estão lá porque foram baixados por você seja via Synaptic, apt-get, aptitude ou outro gerenciador de pacotes que use o dpkg.

    Antes de usar o dpkg (a ferramenta oficial) para analisar um pacote deb, vamos ver do que um pacote deb é feito. Escolhi como exemplo o pacote do wget.

    $ ls -lh wget*
    -rw-r–r– 1 fernando fernando 717K Aug 17 00:26 wget_1.12-5_amd64.deb 

    Vamos copiar o pacote para o /tmp, para manter o cache intacto:

    $ cp wget_1.12-5_amd64.deb /tmp 

    No diretório /tmp, podemos usar o comando file para ver o tipo de arquivo do pacote deb:

    $ cd /tmp
    $ file wget_1.12-5_amd64.deb
    wget_1.12-5_amd64.deb: Debian binary package (format 2.0)

    A libmagic (usada pelo file) reconhece o pacote corretamente. Mas será que os desenvolvedores criaram realmente um tipo de arquivo completamente novo para armazenar o conteúdo de um programa? Sabemos que dentro de um pacote deb há os arquivos executáveis do programa, documentação, ícones etc. Não seria viávei utilizar um agrupador de arquivos com compressão ou coisa do tipo?

    Eric Raymond, um dos hackers mais respeitados do mundo detém a seguinte crença, escrita em seu documento “How to become a hacker” [3]: “No problem should ever have to be solved twice” (Nenhum problema deve ser resolvido duas vezes). Ou seja, não é preciso “reinventar a roda”, como dizemos popularmente. Com base nesta inteligente frase, os desenvolvedores do dpkg e do formato deb usaram sim o que já exitia para atingir seus objetivos, o que foi brilhante.

    Na página de manual do formato deb(5), podemos ler:

    “The file is an ar archive with a magic value of !<arch>.”

    Para conferir, comande:
     

    $ man deb

    Então estamos falando de um arquivo ar [4]. Conforme você pode ver na referência, ar é um utilitário do conjunto binutils, do projeto GNU, para criar, modificar e extrair arquivos. É um agrupador, assim como o tar.

    Vamos conferir o magic value como disse o man?

    $ hd -n 64 wget*
    00000000  21 3c 61 72 63 68 3e 0a  64 65 62 69 61 6e 2d 62  |!<arch>.debian-b|
    00000010  69 6e 61 72 79 20 20 20  31 33 31 31 34 35 31 34  |inary   13114514|
    00000020  35 31 20 20 30 20 20 20  20 20 30 20 20 20 20 20  |51  0     0     |
    00000030  31 30 30 36 34 34 20 20  34 20 20 20 20 20 20 20  |100644  4       |

    Certinho. O tal “!<arch>” esta no início do arquivo, o que sugere ser o seu magic number. Vamos listar o conteúdo deste arquivo com a ferramenta ar então:

    $ ar tv wget*
    rw-r–r– 0/0      4 Jul 23 17:04 2011 debian-binary
    rw-r–r– 0/0   2432 Jul 23 17:04 2011 control.tar.gz
    rw-r–r– 0/0 731281 Jul 23 17:04 2011 data.tar.gz

    Então temos um arquivo ar com três arquivos. E se criarmos um ar com um arquivo qualquer, o que será que o file retorna?

    $ echo “meu texto” > texto.txt
    
    $ ar r teste.deb texto.txt
    ar: creating teste.deb

    O comando acima criou um arquivo ar chamado teste.deb (lembre-se que o Linux despreza extensões) e adicionou o arquivo texto.txt nele.

    $ file teste.deb
    teste.deb: current ar archive

    O file retorna que é um arquivo ar, corretamente.

    Mas por que o file reconhece como pacote do wget corretamente como binário do debian? A resposta está no código-fonte do file [5], que identifica um pacote binário se depois do magic number do ar, o arquivo contiver a string “debian-binary”. De fato, o formato ar define o magic e o nome do primeiro arquivo agrupado em seguida. Então bastaria que criássemos um arquivo ar com um arquivo debian-binary qualquer para o “enganar” o file.

    $ echo 2011 > debian-binary
    
    $ ar r fake.deb debian-binary
    ar: creating fake.deb $ file fake.deb
    fake.deb: Debian binary package (format 2011) 

    Agora sim. O file não faz nenhuma verificação adicional (e nem deveria). Mas a intenção aqui não é hackear o file (até porque estamos falando de um formato livre, com extensa documentação), e sim criar um deb “na mão”. Perceba que o formato apareceu como “2011”. Claro que é um pacote inválido e se você tentar instalar o dpkg vai gerar um erro. Nem perca seu tempo.;)

    4. Extraindo um pacote deb

     

    Voltando ao que interessa, vamos extrair o conteúdo do pacote deb do wget para conferir o que há de interessante:

    $ mkdir wget
    $ cd wget
    $ ar xv ../wget*
    x – debian-binary
    x – control.tar.gz
    x – data.tar.gz $ cat debian-binary
    2.0

    Exatamente o que o file informou. Versão 2.0 do formato deb. Beleza.

    $ tar tvzf control.tar.gz
    drwxr-xr-x root/root         0 2011-07-23 17:04 ./
    -rw-r–r– root/root      3832 2011-07-23 17:04 ./md5sums
    -rw-r–r– root/root        12 2011-07-23 17:04 ./conffiles
    -rw-r–r– root/root      1327 2011-07-23 17:04 ./control

    Acima vemos alguns arquivos de controle do pacote. O interesse maior é no arquivo “control”, necessário para um pacote funcionar. O md5sums também é legal de se ter.

    $ tar tvzf data.tar.gz
    <saída suprimida=””>
    -rw-r–r– root/root       651 2009-09-21 23:52
    ./usr/share/doc/wget/ChangeLog.README
    drwxr-xr-x root/root         0 2011-07-23 17:04 ./usr/bin/
    -rwxr-xr-x root/root    353824 2011-07-23 17:04 ./usr/bin/wget

    Já o data.tar.gz contém os dados do pacote em si, incluindo binários executáveis e documentação, todos numa estrutura bem definida. Aliás, é esta estrutura que o pacote cria ao ser instalado.

    Estou mais interessado no control.tar.gz. Vamos extraí-lo:

    $ tar xvzf control.tar.gz
    ./
    ./md5sums
    ./conffiles
    ./control $ head -5 md5sums
    1b2acae8540b64a3170dc4ce0200809e  usr/bin/wget
    d62b0aafbbacf1d54031ded4d1a5f232  usr/share/doc/wget/AUTHORS
    2f58d6d92cabcf358718a564d3e132d4  usr/share/doc/wget/ChangeLog.README
    2b95a82f1c7499025d67ff86af2d7ecd  usr/share/doc/wget/MAILING-LIST
    9e83cee67a496f5eb62aecf283e14367  usr/share/doc/wget/NEWS.gz

    Certo, vemos no arquivo md5sums, o hash MD5 de cada arquivo incluso no data.tar.gz (no entanto só imprimi 5 linhas com o head). Não seria difícil gerar isso para o nosso pacote “artesenal”.

    $ cat control
    Package: wget
    Version: 1.12-5
    Architecture: amd64
    Maintainer: Noël Köthe
    Installed-Size: 2344
    Depends: libc6 (>= 2.3), libidn11 (>= 1.13), libssl1.0.0 (>= 1.0.0), dpkg (>=
    1.15.4) | install-info
    Conflicts: wget-ssl
    Section: web
    Priority: important
    Multi-Arch: foreign
    Homepage: http://www.gnu.org/software/wget/
    Description: retrieves files from the web
    Wget is a network utility to retrieve files from the web
    using HTTP(S) and FTP, the two most widely used internet
    protocols. It works non-interactively, so it will work in
    the background, after having logged off. The program supports
    recursive retrieval of web-authoring pages as well as ftp
    sites — you can use wget to make mirrors of archives and
    home pages or to travel the web like a WWW robot.
    .
    Wget works particularly well with slow or unstable connections
    by continuing to retrieve a document until the document is fully
    downloaded. Re-getting files from where it left off works on
    servers (both HTTP and FTP) that support it. Both HTTP and FTP
    retrievals can be time stamped, so wget can see if the remote
    file has changed since the last retrieval and automatically
    retrieve the new version if it has.
    .
    Wget supports proxy servers; this can lighten the network load,
    speed up retrieval, and provide access behind firewalls.

    Este é o arquivo que descreve o pacote. A referência deste arquivo é tratada na Debian Policy [6], mas os campos mais comumente usados para pacotes simples são:

    • Package  – Nome do pacote
    • Version  – Versão do programa-versão do pacote
    • Architecture– Arquitetura para qual o programa foi compilado. Pode ser i386, amd64, dentre outras. Pode ser “all” para scripts, por exemplo.
    • Maintainer  – Aqui vai o seu nome e e-mail. O criador do pacote (não do programa a ser empacotado).
    • Installed-Size – O espaço estimado, em bytes, requerido para instalar o pacote.
    • Depends  – Os pacotes dos quais seu pacote depende. Se for um programa em Python, vai depender do interpretador python, por exemplo.
    • Homepage  – O site do programa empacotado
    • Description-A descrição do pacote. Uma linha para a descrição curta e demais para descrição longa, onde todas devem começar com um espaço e as linhas em branco devem possuir um ponto (.), que não vai aparecer no final das contas.

    Agora que já explicamos a estrutura de um pacote deb básico, vamos ver como criar um.

     

    5. Criando um pacote “artesanal”

     

    Precisamos ter o que empcotar. Então vamos criar um software de teste.

    $ mkdir /tmp/nada-1.0
    $ cd /tmp/nada-1.0
    
    $ echo -e “#include <stdio.h>nnint main()n{ntputs(“nada…”);ntreturn 0;n}” > nada.c

    Os comandos acima devem criar um arquivo nada.c, no diretório /tmp/nada-1.0, com o seguinte conteúdo:

    #include <stdio.h>
    
    int main()
    {
    	puts(“nada…”);
    	return 0;
    }

    Agora precisamos compilar o programa:

    $ gcc -o nada nada.c

    O binário “nada” precisa de uma estrutura. Então vamos colocá-lo num usr/bin:

    $ mkdir -p usr/bin
    $ mv nada usr/bin/

    NOTA: Cuidado para não tentar mover o “nada” para o /usr/bin do sistema.

    Agora temos a seguinte estrutura:

    $ find .
    . ./usr
    ./usr/bin
    ./usr/bin/nada
    ./nada.c

    Precisamos do arquivo de controle. Que tal este?

    Package: nada
    Version: 1.0
    Architecture: amd64
    Maintainer: Você <seu@email.com.br>
    Homepage: http://www.tacomnada.com
    Installed-Size: 6560
    Depends: libc6 (>= 2.2.5)
    Description: program that does nothing
    Na realidade o nada conseguie imprimir a string “nada…” na tela. Claro que
    pode servir para algo, mas nao saberia dizer para que. Talvez para aprender
    a empacotar no Debian, ou para nao fazer nada.
    .
    Depois de falar tanto, nao vou dizer mais nada.

    Basta salvar como control (sem extensão mesmo).

    Para o campo Installed-Size, eu contei os bytes do binário “nada”:

    $ wc -c nada
    6560 nada

    Já no campo Depends, é interessante avaliar a saída do ldd:

    $ ldd nada
    linux-vdso.so.1 => (0x00007fffea5ff000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcebbf5d000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcebc2fe000)

    A primeira entrada é a uma biblioteca virtual para interface com o kernel. Ela sempre existirá e também pode aparecer como linux-gate.so.1.

    Em seguida temos duas bibliotecas reais. Supondo que não saibamos em qual pacote elas se encontram, podemos usar o apt-file:

    $ apt-file search libc.so.6
    libc6: /lib/x86_64-linux-gnu/libc.so.6
    libc6-i386: /lib32/libc.so.6

    O pacote de nosso interece é o libc6. Agora, a versão da biblioteca requerida vai depender das funções que o programador utilizou. Isto consultado ser pego no site do projeto ou diretamente com o desenvolvedor. Usei 2.2.5.

    Vamos buscar a última lib que o ldd detectou:

    $ apt-file search ld-linux-x86-64.so.2
    libc6: /lib/ld-linux-x86-64.so.2
    libc6: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

    Também está no pacote libc6. Beleza, então só temos esta dependência.

    Agora precisamos gerar os arquivos control.tar.gz (com o control dentro), data.tar.gz (com toda a árvode usr dentro) e debian-binary (com a string 2.0 dentro):

    $ tar cvzf data.tar.gz usr/
    usr/
    usr/bin/
    usr/bin/nada $ tar cvzf control.tar.gz control
    control
    
    $ echo 2.0 > debian-binary
    
    $ ar r nada-1.0_amd64.deb debian-binary control.tar.gz data.tar.gz
    ar: creating nada-1.0_amd64.deb
    fernando@localhost:/tmp/wget/nada-1.0$ file nada-1.0_amd64.deb
    nada-1.0_amd64.deb: Debian binary package (format 2.0)

    Perceba que o primeiro arquivo a ser adicionado no ar é o debian-binary.

    E agora vamos testar.

    $ sudo dpkg -i nada-1.0_amd64.deb
    Selecting previously deselected package nada.
    (Reading database … 146331 files and directories currently installed.)
    Unpacking nada (from nada-1.0_amd64.deb) …
    Setting up nada (1.0) … $ nada
    nada… $ sudo dpkg -P nada
    (Reading database … 146332 files and directories currently installed.)
    Removing nada …

     

    6. Conclusão

     

    O pacote funciona. Inclusive eu fiz um script (makedeb_v2.sh) para empacotar [quase que] desta forma o Evan’s Debugger [7]. Vale a pena dar uma olhada, pois tem outros arquivos e comandos que não mencionei aqui. No entanto, ressalto que a preferência deve ser para pacotes com alta qualidade.

    Provavelmente escreverei um outro artigo sobre a forma correta de se criar pacotes, com base na política do Debian e com as ferramentas providas pela comunidade. Não é fácil fazer um pacote de qualidade, mas o primeiro passo, na minha opinião, é entender com o que estamos lidando e espero que este artigo tenha atingido este objetivo.

    [1] http://www.debian.org/doc/#manuals
    [2] http://packages.debian.org/wheezy/pev
    [3] http://catb.org/~esr/faqs/hacker-howto.html#believe2
    [4] http://www.gnu.org/s/binutils/
    [5] ftp://ftp.astron.com/pub/file/
    [6] http://www.debian.org/doc/debian-policy/ch-controlfields.html
    [7] http://codef00.com/projects#debugger


    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 Bruna Chieco
      O Cisco Talos, grupo global de inteligência de ameaças de cibersegurança da Cisco, descobriu uma vulnerabilidade de divulgação de informações no kernel do Linux.
      A vulnerabilidade, rastreada como CVE-2020-28588, pode permitir que um invasor visualize a pilha de memória do kernel, o que significa que dados ou informações que não deveriam ser vistas possam ser acessadas. O problema foi visto pela primeira vez pelo Cisco Talos em um dispositivo Azure Sphere (versão 20.10), um dispositivo ARM de 32 bits que executa um kernel do Linux corrigido.
      O kernel do Linux é o núcleo livre e de código aberto dos sistemas operacionais do tipo Unix. A vulnerabilidade existe especificamente na funcionalidade /proc/pid/syscall de dispositivos ARM de 32 bits executando Linux.
      Um invasor pode explorá-la lendo /proc/<pid>/syscall, um arquivo legítimo do sistema operacional Linux, podendo aproveitar esse vazamento de informações para explorar com êxito vulnerabilidades adicionais não corrigidas.
      O Cisco Talos trabalhou com o Linux para garantir que esse problema seja resolvido e uma atualização já está disponível para os clientes afetados. Os usuários são incentivados a atualizar esses produtos afetados o mais rápido possível para o Kernel Linux versões 5.10-rc4, 5.4.66 e 5.9.8.
    • 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 Bruna Chieco
      Três vulnerabilidades foram encontradas no subsistema iSCSI do kernel do Linux, permitindo que invasores locais com privilégios básicos de usuário obtenham privilégios de root em sistemas Linux sem patch. Segundo o BleepingComputer, os bugs de segurança só podem ser explorados localmente, o que significa que invasores em potencial terão que obter acesso a dispositivos vulneráveis explorando outra vulnerabilidade ou usando um vetor de ataque alternativo.
      O mais impressionante é que essas vulnerabilidades já existem há 15 anos. A descoberta foi feita por pesquisadores do GRIMM. "Ao contrário da maioria das coisas que encontramos acumulando poeira, esses bugs revelaram-se ainda bons, e um acabou sendo utilizável como um escalonamento de privilégio local (LPE) em vários ambientes Linux", diz publicação feita no blog do GRIMM.
      De acordo com o pesquisador de segurança do GRIMM, Adam Nichols, as falhas afetam todas as distribuições Linux, mas felizmente o módulo de kernel scsi_transport_iscsi vulnerável não é carregado por padrão. No entanto, dependendo da distribuição do Linux que os atacantes estejam focando, o módulo pode ser carregado e explorado para escalonamento de privilégios.
      Saiba mais sobre as vulnerabilidades: 
      CVE-2021-27363: vazamento do ponteiro do kernel (vazamento de informações) CVE-2021-27364: leitura fora dos limites (vazamento de informações, negação de serviço) CVE-2021-27365: estouro de buffer de heap (escalonamento de privilégio local, vazamento de informações, negação de serviço)
    • By Fernando Mercês
      Batizado com nome herdado da estrela binária VV Cephei, o Linux.Cephei é provavelmente o primeiro file infector para executáveis ELF (utilizados nos sistemas baseados em Linux, entre outros) escrito na linguagem Nim. Isso mesmo, o autor é um tanto excêntrico e disse em seu blog que o Linux.Cephei é inofensivo (por enquanto) e fez somente para participar de um concurso de programação.
      O vírus é do tipo que chamamos de prepender, ou seja, ele adiciona algo "antes" da execução de um programa saudável, no caso, de um binário ELF. A técnica para isso é a alteração de seu entrypoint. 
      Nos testes que fizemos aqui, o Linux.Cephei só funcionou com binários compilados estaticamente: 
      $ uname -a Linux malinux 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux $ cat /etc/debian_version 9.2 $ cat h.c #include <stdio.h> int main(void) { printf("ola mundo do bem!\n"); return 0; } $ gcc -static -o hello h.c $ ./hello ola mundo do bem! $ chmod +x linux.cephei $ ./linux.cephei $ ./hello Did you know that VV Cephei, also known as HD 208816, is an eclipsing binary star system located in the constellation Cepheus, approximately 5,000 light years from Earth? It is both a B[e] star and shell star. Awesome! https://en.wikipedia.org/wiki/VV_Cephei The more you know... :) ola mundo do bem! $ gcc -o hello h.c $ ./linux.cephei $ ./hello ola mundo do bem!  Perceba que ele injetou seu código com sucesso no binário hello, mas somente quando foi compilado estaticamente.  
      Além da linguagem exótica, ultimamente não se vê muitos file infectors já que a moda de infectar executáveis passou. De qualquer forma, é bom ficar de olho. Com códigos como o do Linux.Ceiphei, vírus podem permanecer ocultos num sistema por muito tempo. E pouca gente usa antivírus no Linux, mesmo tendo uma alternativa livre como o ClamAV.
    • 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.
×
×
  • Create New...