Jump to content

Fabiano Furtado

Apoiador Nibble
  • Content Count

    46
  • Joined

  • Last visited

  • Country

    Brazil

Posts posted by Fabiano Furtado


  1. Primeiramente parabéns pela MBConf! Estes eventos estão sendo sensacionais!

    Gostaria de assistir palestras sobre técnicas para ofuscação de binários e também alguns tipos de ataques como ret2libc, ROP e suas mitigações.

    Outra palestra interessante seria sobre algum pesquisador com alguma experiência prática em descobertas de BUGs/vulnerabilidades em sistemas... (de preferência sem ser sistema Web) pudesse contar pra gente como descobriu e explorou essa vuln.

    Outros assuntos interessantes: como fazer o bypass de sistemas do tipo IDS/IPS? Como detectar Shellcodes polimórficos/metamórficos? Uso de fuzzing para descobrir Bugs/Vulns....

    Ah... tem muito assunto legal pra colocar na pauta dessa conf...

    Valeu!


  2. 52 minutos atrás, rmarinho disse:

    Oi Fabiano, 

    Botnets como esta são utilizadas em ataques - sobretudo nos ataques DDoS. Talvez um dos maiores tenha sido o da Mirai em 2016. Algumas notícias recentes envolvendo o assunto: https://www.techrepublic.com/article/new-botnet-attack-puts-other-iot-botnets-to-shame/https://www.cpomagazine.com/cyber-security/nation-state-ddos-attacks-may-be-the-new-normal-leaked-documents-reveal-russias-fsb-is-seeking-to-build-a-massive-iot-botnet/

    Para obter os logs do SSH, na verdade, apliquei um patch no openssh server para fazer com que o serviço gerasse um arquivo com os comandos executados pelos clientes. 

    O paper da pesquisa está disponível em: https://journal.cecyf.fr/ojs/index.php/cybin/article/view/16/22

    Obrigado pelas perguntas.

    Abraço.

    Renato Marinho

    Renato... primeiramente, obrigado pelo retorno.

    Cara... achei muito legal esse estudo! Vou tentar fazer esse patch no openssh para monitorar os comandos enviados. Muito interessante e útil esse patch!!!!!

    Vou ler o seu paper. Parabéns pela pesquisa!

    Obrigado mais uma vez.


  3. Pessoal... boa tarde. Seguem as minhas perguntas sobre a palestra. Agradeço desde já.

       * Esse tipo de BOT P2P não deveria estar predominando neste mundo dos ataques? Pq não está?

       * Quais ferramentas foram usadas para fazer essa pesquisa? Achei interessante como foi obtido o tráfego SSH e consequentemente o certificado utilizado na BOT.

      * Tem algum paper sobre essa pesquisa?


  4. Pessoal..

    li um artigo hoje e achei muito interessante a técnica de ofuscação apresentada.

    https://www.d00rt.eus/2020/04/ebfuscation-abusing-system-errors-for.html

    No meio do artigo, o autor cita outras técnicas de ofuscação de código:

    "Here are other transformations that can be applied:
    - Virtualization
    - Control Flow Flattening
    - Encode literals
    - Opaque predicates
    - Encode Arithmetic
    ..."

    Fiquei intrigado em como usar Virtualização para se fazer ofuscação em código. Pesquisei um pouco sobre o assunto e achei uma palestra do Alexandre Borges na DEFCON China 2019, 

    Acho que fiquei com mais dúvidas ainda! (rs)

    Alguém pode me explicar sobre o assunto?

    Valeu!


  5. Em 03/04/2020 em 15:55, fredericopissarra disse:

    Manda ver... mas, ainda não vejo muita utilidade em adicionar payloads no T50...
    Como o Nelson insiste: Acho que seria mais útil adicionar protocolos...
    Aliás... algo que dará trabalho para fazer: Adicionar suporte a IPv6!

    Fred... tudo bem? Achei interessante a idéia do IPv6! Quem sabe depois da implementação do payload?

    Bem, estou começando a estudar o código para implementar o payload nos protocolos e acredito que tenha encontrado um bug no ICMP...

    Comecei pelo ICMP por se tratar do menor código existente no T50, ou seja, mais fácil de se entender e modificar.

    Executei um

    # t50 --protocol ICMP --threshold 2 127.0.0.1

    e capturei os pacotes no Wireshark. No Wireshark, o campo do checksum estava errado, e o mesmo mostrava os bytes invertidos.

    Mensagem do WS: "Checksum: 0xbbaa incorrect, should be 0xaabb"

    Retirei a função htons no checksum do módulo icmp.c e funcionou.

    /* Computing the checksum. */
      icmp->checksum = co->bogus_csum ? RANDOM() :
                      cksum ( icmp, sizeof ( struct icmphdr ) );

    Isso é um bug?

    Desde já, agradeço.


  6. Em 23/04/2019 em 17:38, fredericopissarra disse:

    PS: Estou, ainda, pensando se coloco um payload nos protocolos, mas esse não é o objetivo do injetor...

    Em 24/04/2019 em 03:47, Fernando Mercês disse:

    Você diz um payload pronto seu ou suporte a payloads do usuário? Se for o último, bem, acho interessante. 🙂

    Frederico e Fernando... será que eu poderia me aventurar a implementar esse suporte a payload de usuário no T50?

    Para mim seria um bom desafio em C... acho que aprenderia muito nessa implementação. Claro, preciso do apoio de vocês durante o desenvolvimento pois certamente terei dúvidas.

    Sou aberto a críticas e sugestões.

    O que vcs acham?

    Valeu!


  7. Em 07/10/2019 em 14:48, fredericopissarra disse:

    Algumas coisas podem ser retiradas... Eis um makefile para seu hello.c:
    .....

    Como demonstração da alegação do executável ser um shared object:

    .....

    Cara... vc é o mestre!!!! Achei muito legal esse make! Depois vou testar...

    Em tempo, já que vc usou o objcopy para diminuir o tamanho do binário (aliás, achei bem legal isso), reparei que os meus binários estavam ficando MUITO grandes (mesmo os mais simples) e descobri o motivo.

    A partir da versão 2.30 (ou 2.31.. não sei ao certo) do LD, há um novo parâmetro para fazer a link edição chamado "-z noseparate-code". O default passa a ser "-z separate-code" e isso faz com que o linker preencha o binário com vários Null Bytes entre as seções.

    Eu li sobre esse parâmetro e o motivo da existência seria uma maior segurança contra ataques, em prol de um binário maior e relativamente mais lento.

    Você sabe me dizer mais sobre o uso desse parâmetro? Eu particularmente prefiro um binário menor.


  8. Em 30/09/2019 em 11:51, Fernando Mercês disse:

    Posta aí como, vai! :D

    Fiquei curioso hehehehe

    Opa...

    Segue a linha...

    $ ld --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -o hello /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../.. -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o hello.o

    • l33t 1

  9. 16 horas atrás, fredericopissarra disse:

    Não há necessidade de usar -save-temps para compilar o fonte apenas para o objeto, basta fazer:

    
    $ gcc -O3 -c -o hello.o hello.c   # Compila para o objeto hello.o
    

    A opção -c faz isso. Quanto ao ld, qual a linha de comando você está usando? Note que código em C exige a linkagem de uma série de outros objetos (Scrt0.o, crti.o, crtn.o), bem como outras libs além da libc (libgcc, por exemplo). O GCC toma conta disso sozinho, o ld, não.

    Veja algumas linhas de comando usadas pelo GCC adicionando a opção -v

    Oi Frederico... agora sim! Usando alguns parâmetros que a opção -v me mostrou, eu consegui fazer o hello world funcionar e entender o problema. Muito obrigado!


  10. Em 27/09/2019 em 12:36, fredericopissarra disse:

    Provavelmente seu GCC está instalado errado. Não consigo reproduzir o erro com o simples código de um "hello world":

    
    #include <stdio.h>
    
    int main( void ) { puts( "Hello, world!" ); }

    Por que você está mantendo os arquivos temporários (-save-temps)?
     

    PS: Que /usr/lib64/  é esse? Normalmente esse diretório não existe em distros Linux...

    Bom... o GCC não está instalado errado. Isso eu posso te garantir.

    Eu uso o Arch Linux e nele há links simbólicos apontando para /lib64/ld-2.29.so e /usr/lib64/ld-2.29.so, que são arquivos idênticos.

    Eu mantive os arquivos temporários para poder utilizar o hello.o no ld e usar o ld para fazer a link edição, e não o GCC.

    Utilizando-se o GCC, o erro não ocorre, mas usando o ld, sim.


  11. Pessoal...

    fiz um "Hello World!" em C para testes e estou tendo um "Segmentation fault". Vou reproduzir os passos que fiz.

    Primeiramente, compilei com "gcc -Wall -O3 -save-temps hello.c -o hello". Até aí, tudo certo. Execução sem erros.

    Como queria fazer a link edição "na mão", dei um "ldd hello" e...

            linux-vdso.so.1 (0x00007fffb3558000)
            libc.so.6 => /usr/lib/libc.so.6 (0x00007fc34bbc7000)
            /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc34bde6000)

    Após isso, link editei o arquivo com o comando "ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/libc.so.6  hello.o -o hello", recebi um "ld: warning: cannot find entry symbol _start; defaulting to 0000000000401020" e executei...

    $ ./hello
    Hello World!
    Segmentation fault (core dumped)


    Fiz um debug no GDB e no ret da main() o RIP apresenta um valor esquisito!

    O que estou fazendo de errado nesta link edição?

    Desde já, agradeço.


  12. Pessoal...

    Para cada sistema que fazemos, normalmente, precisamos ler algum arquivo de configuração ou carregar dinamicamente algum plugin no momento da execução.

    Alguém tem alguma idéia/dica sobre como fazer isso de maneira mais fácil? Alguém já desenvolveu algo assim? Há algum artigo que descreva isso?

    Cada um implementa isso de uma maneira e não queria ficar perdendo tempo em algo tão básico.

    Sei que a libconfig pode ajudar, mas não queria utilizar nenhuma lib.

    Obrigado.

     


  13. Em 12/06/2019 em 13:39, Fernando Mercês disse:

    É nóis.

    Aproveitando, eu tive a ideia de extender o PEDA pra já tratar esses casos. Você - e quem mais quiser - poderia testar antes de eu enviar um possível patch pros caras? Meu fork tá em https://github.com/merces/peda

    Basicamente é carregar o binário, mesmo com símbolos removidos, e comandar start. Tem que parar na main() automagicamente. hehe

    Abraço!

    Fiz o teste com o seu PEDA, copiando o peda.py para o diretório do meu peda. Não deu muito certo.

    O resultado foi esse:

    $ gdb ./helloworld
    GNU gdb (GDB) 8.3
    Copyright (C) 2019 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from ./helloworld...
    (No debugging symbols found in ./helloworld)
    gdb-peda$ start
    No unwaited-for children left.
    Display various information of current execution context
    Usage:
        context [reg,code,stack,all] [code/stack length]

    gdb-peda$

     

    O que estou fazendo de errado?

    Valeu.


  14. Oi Fernando... vou testar sim, mas tem que ser amanhã. Legal essa iniciativa! Vou lhe dar um retorno em breve.

    Bom... testei esse comando "info files" que você mencionou no video e deu certo, mas deu errado😞

    "Stripando" o binário com o strip, funciona, mas com o sstrip, não.

    O sstrip é um utilitário que vem no pacote elfkickers (http://www.muppetlabs.com/~breadbox/software/elfkickers.html). Enfim... parece que ele retira mais coisas do binário e o "info files" não consegue identificar o entry point. Usei o "readelf -a" para comparar e analisar os dois binários e não há nehhuma informação sobre os Section Headers no arquivo gerado pelo sstrip.

    Só para efeito comparativo, com o strip, o meu binário ficou com 6160 bytes. Com o sstrip ficou com 4144!

    Neste caso, há algum outro comando que possa ser usado no GDB?

    Valeu!


  15. Pessoal,

    preciso de uma ajuda com o GDB depurando arquivos binários stripped.

    Fiz um "Hello World!" básico em C, compilei ele com "gcc -Wall -z noseparate-code hw64.c -o hw64" e logo em seguida executei um sstrip em cima do binário.

    O parâmetro "-z noseparate-code" foi usado pra deixar o binário menor (leia o man deste parâmetro). Em tempo, o gcc compilou o binário com PIE habilitado, ou seja, a cada execução o SO aloca o programa em um endereço de memória diferente.

    Eu consegui fazer a depuração no GDB, mas precisei usar o Ghidra para descobrir os offsets do binário, uma vez que o objdump com o binário sstrip não mostra nada.

    Para isso, executei o GDB (estou usando a versão 8.3 com o peda 1.1):

       * starti --> ele executa a primeira instrução, no caso, uma instrução da lib ld-linux

       * info proc mappings --> para saber qual endereço de memória o programa foi alocado devido ao ASLR

       * breakpoint na main() --> depois de ter obtido o offset desta função com o Ghidra + informação do endereço de memória

       * continue --> fim da depuração

    Alguém conhece alguma técnica melhor que não precise do Ghidra (ou outro disassembly) para obtermos os offsets das funções?

    Desde já, agradeço.


  16. 23 horas atrás, Fernando Mercês disse:

    Beleza e você? Com funções naked? Não. 😕

    Tudo bem!

    Não precisa utilizar funções naked. Pode ser ofuscação utilizando outros métodos. Por exemplo, me lembro uma vez que você postou um artigo/comentário sobre substituição de uma insrtução call por outras equivalentes (push e jmp) para enganar o decompiler.... enfim... acho que você deve ter algum material bom sobre isso.

    Valeu!!!!


  17. Em 26/03/2019 em 05:01, Fernando Mercês disse:

    Interessante mesmo! Muito obrigado pelo post!

    Eu busquei por exemplos de uso do atributo naked, tipo de quando usar, sabe? Encontrei um caso no RTOS pra evitar salvar o contexto duas vezes, um exemplo de ofuscação meio fraco e alguns outros. Por acaso você tem alguns exemplos práticos de uso deste atributo? Tipo, em que situação eu usaria uma função pelada? 🤓

    Abraço!

    Fernando.... blza? Vc tem mais exemplos de ofuscação? Eu achei bem interessante, apesar de ser "meio fraco". :)


  18. 11 horas atrás, Fernando Mercês disse:

    Acho que por treino sim, pois realmente não vejo benefício prático do programa em si, mas posso estar perdendo algo também.

    Os compiladores inserem padding, em geral 0x00 ou 0x90 (NOP no x86) mesmo. O legal de fazer algo assim é que você vai precisar parsear o ELF, enumerar as funções e fazer seus patches. #include <elf.h> e segue o jogo. hehe

    Se fizer, posta os desenvolvimentos aqui pra gente acompanhar. 😀

    Abraço e boa sorte!

    Blza.... vou pesquisar sobre o assunto. Se sair algo, eu divulgo aqui. Obrigado!

×
×
  • Create New...