Fabiano Furtado

Pessoal, disponibilizei no meu GitHub o meu primeiro projeto OpenSource, como forma de retornar para a comunidade o que tenho aprendido nestes últimos anos. O projeto se chama LIBCPF (C Plugin Framework - https://github.com/fabianofurtado/libcpf/) e se trata de uma biblioteca/framework pra gerenciamento de Plugins (".so") no Linux, feita em C. Para maiores detalhes, veja a documentação no arquivo README.md. Ela foi lançada utilizando-se a licença GPL v2, uma vez que não entendo muito sobre esse assunto e precisava de uma licença para o projeto. Espero que, de alguma forma, este projeto possa ser útil para você. Mesmo que não exista a necessidade de utilização desta lib em sua aplicação, a mesma pode ser usada para listar os nomes das funções e os offsets que existem dentro de uma shared library, algo que considero bem interessante. Veja no exemplo como isso funciona. Como qualquer programa em C, o desenvolvimento deu muito trabalho pois tentei desenvolvê-la com foco na segurança, tentando evitar possíveis "buffer overflows" ou qualquer outro tipo de vulnerabilidades. Sugestões e críticas serão sempre bem-vindas! Desde já, agradeço.

Pessoal, estou desenvolvendo um pequeno projeto OpenSource em C para o Linux e quero discutir aqui qual é a melhor licença a ser aplicada. Como é o meu primeiro projeto que vou disponibilizar para a comunidade, fico muito perdido quando começo a ler o texto contendo a definição da licença e solicito uma ajudinha para quem tem experiência, no intuito de entender melhor o contexto. Estava pensando na GPL v2, mas a GPL v3 é mais moderna, porém, mais longa e mais difícil de se entender. O que acham? Desde já agradeço.

Excelente artigo! Descreve de forma simples, clara e objetiva o processo de alocação de memória dinâmica. Para quem quiser se aprofundar, recomendo estes 2 links: https://github.com/shellphish/how2heap https://heap-exploitation.dhavalkapil.com/ Valeu!

Primeiramente, parabéns pelo artigo! Aguardo a parte 2! ? Olha... através de caminhos diferentes, cheguei nesse mesmo problema dos "0s" abusivos no meio do binário. No meu caso, estava tentando fazer o menor "hello world" possível em NASM 64bits com a .text sem null chars, mas os "0s" sempre apareciam. Se quiser tornar o seu binário menor, sem esses "0s", utilize a opção "-z noseparate-code" no ld. Isso fará com que ele não coloque esses "0s" entre as sessões do ELF. Dizem que esses "0s" servem para aumentar a segurança... eu queria entender o porque! Sinceramente, uma sessão .text onde há um oceano de null chars sobrando me parece bem mais suscetível a receber um shellcode que um binário mais exuto. Bom... voltando para o "hello world", também fiz algumas alterações na mão nos headers, e coloquei a string do programa lá (incrível como não deu pau!).Se quiser analisar, segue o base64 do binário com apenas 141 bytes! Valeu! f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAcABAAAAAAABAAAAAAAAAAEhlbGxvIFdvcmxkCkAAOAABAEAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAAAAjQAAAAAAAACNAAAAAAAAAEgxwP7ASInHSI01qf///7IMDwVIMcAEPEgx/w8F MD5: fd8ac0bdd57939705e1900dfaa63c74e

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!

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.

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?

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!

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.

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!

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.

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

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!

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.

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.