Fernando Mercês

A NSA, agência de espionagem norte-americana, acaba de publicar um documento de 45 páginas detalhando o funcionamento de um malware chamado Drovorub, a quem atribuiu o desenvolvimento ao governo Russo. Segundo o relatório, o malware é composto por 4 partes: Cliente, usado como implante. Módulo de kernel que é o rootkit. Agente que faz o redirecionamento de portas e transfere arquivos entre vítima e C2. Servidor que tem o software do C2. O diagrama geral de funcionamento do malware é mostrado na figura abaixo: O cliente recebe comandos do servidor, pode transferir arquivos e abrir uma shell remota. Além disso, ele também instala o rootkit, que é capaz de ocultar processos (fazendo com que não apareçam na listagem de comandos como ps e top do Linux), arquivos, sockets abertos e até mesmo pacotes recebidos pelo Netfilter. Em resumo, o atacante tem total controle de seu servidor Linux. Talvez até mais controle que você. ?? Pra saber se seu servidor está infectado, a NSA recomenda buscar pelas strings "sc!^2a", "do_fork" e "net_list_request" num dump de memória. Recomendações adicionais, incluindo regras para detectar o tráfego de rede Snort e Yara para encontrar os arquivos podem ser encontradas no documento. Sinistro. O.o

O Mente Binária foi criado pelo @Fernando Mercês em 2007 como um blog, já com a intenção de compartilhar técnicas para resolver problemas comuns no dia a dia técnico de um profissional de TI. De lá para cá, foram várias mudanças. Passamos de blog a fórum, empresa de treinamentos, até que chegamos ao formato atual de uma instituição sem fins lucrativos suportada pela comunidade. Nosso objetivo é de integrar profissionais de segurança, ajudando, principalmente os iniciantes, a estruturarem suas carreiras, aumentarem seu conhecimento técnico de base e com isso melhorarem suas vidas. Parece difícil? Acreditamos que não. Milhares de pessoas consomem nosso conteúdo mensalmente, que entregamos através de vários projetos na área. Alguns deles são: O portal que você está acessando agora, com mais de 5300 membros, onde publicamos artigos, dicas e mantemos um fórum de discussões para a comunidade. O nosso canal no YouTube Papo Binário, com mais de 30000 inscritos onde já publicamos mais de 400 vídeos de conteúdo sobre segurança, Linux, engenharia reversa, carreira e entrevistas com profissionais da área. Nosso livro Fundamentos de Engenharia Reversa, que você encontra sempre atualizado. Os softwares que fazemos, todos livres e publicados de forma colaborativa, com código e comentários. Os treinamentos que publicamos, todos gratuitos. Para tudo isso ser possível, contamos com uma empenhada equipe de 6 pessoas. Projetos como o Papo Binário têm um custo elevado com viagens para entrevistas, equipamento, edição e produção de áudio e vídeo. O portal também tem custos de hospedagem, domínio e da plataforma. Não conseguimos arcar com tudo sozinhos. Para continuar oferecendo este conteúdo de maneira isenta, livre de influências patrocinadas, precisamos de doações e por isso lançamos mão desta campanha para você, que curte nosso trabalho, se tornar um apoiador do projeto, no estilo patrono. É bem simples: você nos ajuda a continuar e passa a fazer parte do núcleo da nossa comunidade. Olha só as vantagens que você recebe ao doar: Badge de apoiador aqui no portal. Acesso à área Núcleo, onde você será consultado sobre decisões importantes e novos projetos. Após 3 meses de apoio, você passa a ter descontos/vantagens e até gratuidades em ingressos dos seguintes eventos parceiros: BHack BSides Roadsec Desconto de 10% nos treinamentos de C/C++ e C++ com Qt da Agit Informática. Relatório de transparência financeira, postado mensalmente na nossa área Núcleo. Afinal, você tem direito de saber como sua doação está sendo utilizada! Outras vantagens que lançaremos no futuro, sempre pensando em você! Nosso eterno e verdadeiro agradecimento por ajudar a levar conteúdo de qualidade para milhares de brasileiros, incluindo você! ? Quero apoiar! Legal, agora é só escolher um dos métodos abaixo. Lembrando que cada nível de apoiador tem acessos diferentes que você pode conferir aqui. Já doei. Como acesso a área Núcleo? Basta enviar uma mensagem para nós pelo formulário de contato informando seu nome de usuário aqui no site e o e-mail utilizado para a doação. A @Gabrielle Alves vai ter o maior prazer em te responder! Tenho uma empresa, como posso apoiar? Se você tem uma empresa pode ajudar a tornar este sonho realidade com uma doação maior. Em troca podemos colocar seu logotipo nos vídeos do canal Papo Binário, além de te oferecermos as vantagens de membro Apoiador. Outra ajuda é enviar esta página para seu mailing de clientes ou participantes de eventos! Por favor, entre contato com a gente!

Ano passado eu assisti à uma palestra sobre esse novo utilitário da suíte GNU chamado poke. Ele é um editor de dados binários de linha de comando bem diferente dos que costumo usar (HT Editor, Hiew, etc). Hoje decidi testá-lo e curti bastante. Tá em mega beta, então não tá nem perto de ter pacote disponível nos repositórios oficiais das distros Linux, mas consegui compilar e neste artigo vou dar as instruções, que podem variar em cada ambiente, até porque o poke está em constante desenvolvimento. Usei um ambiente Debian testing aqui. Instalando as dependências A dependência mais chatinha de instalar foi a gettext, porque o pacote pronto dela não foi suficiente. Então tive que clonar e compilar: $ sudo apt install perf fp-compiler fp-units-fcl groff build-essential git $ git clone https://git.savannah.gnu.org/git/gettext.git $ cd gettext $ ./gitsub.sh pull $ ./autogen.sh $ ./configure $ make $ sudo make install Com a gettext instalada, agora podemos partir para as demais dependências do poke: $ sudo apt install build-essential libgc-dev libreadline-dev flex libnbd-dev help2man texinfo Só então podemos seguir para a compilação do poke. Compilando o poke $ git clone git://git.savannah.gnu.org/poke.git $ cd poke $ ./bootstrap $ ./configure $ make $ sudo make install Criando links para as bibliotecas Como instalei as bibliotecas do poke em /usr/local e o meu sistema não tinha este diretório configurado para que o loader busque as bibliotecas, precisei criar dois links para elas em /usr/lib: $ sudo ln -s /usr/local/lib/libpoke.so.0 /usr/lib/libpoke.so.0 $ sudo ln -s /usr/local/lib/libtextstyle.so.0 /usr/lib/libtextstyle.so.0 Sei que há outras maneiras de resolver isso, mas fiz assim pra acelerar, afinal eu queria mexer no poke logo! ? Abrindo um binário PE no poke Baixei o executável do PuTTY para brincar um pouco e abri assim: $ poke putty.exe _____ ---' __\_______ ______) GNU poke 0.1-beta __) __) ---._______) Copyright (C) 2019, 2020 Jose E. Marchesi. 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. Powered by Jitter 0.9.212. Perpetrated by Jose E. Marchesi. hserver listening in port 47209. For help, type ".help". Type ".exit" to leave the program. (poke) Gerenciando os arquivos abertos O poke permite trabalhar com múltiplos arquivos de uma vez. Você pode ver a lista de arquivos abertos com o seguinte comando: (poke) .info ios Id Mode Size Name * #0 rw 0x0010b990#B ./putty.exe ios signifca "IO Spaces". Não tem nada a ver com o SO da Cisco ou com o da Apple. hehe Se quiser abrir outro arquivo, pode usar o comando .file <arquivo> e aí pode selecionar em qual você quer trabalhar com o comando .ios #n onde n é o número que identifica o arquivo, mas vou seguir o artigo com somente um arquivo aberto mesmo, então só teremos a tag #0. Dumpando dados Um dos principais comandos do poke é o dump (perceba este não começa com um ponto) que basicamente visualiza o conteúdo do arquivo, mas este tem várias opções. Vamos à mais básica: A primeira linha na saída acima é só uma régua pra te ajudar a encontrar os bytes. Fiz questão de colar uma captura de tela aí acima pra você ver que o poke colore a saída, mas nos exemplos seguintes vou colar a saída em texto pelo bem da sua largura de banda. ? Por padrão, o dump exibe 128 bytes do arquivo, começando do seu primeiro byte. O número de bytes pode ser alterado na própria linha de comando: (poke) dump :size 64#B 76543210 0011 2233 4455 6677 8899 aabb ccdd eeff 0123456789ABCDEF 00000000: 4d5a 7800 0100 0000 0400 0000 0000 0000 MZx............. 00000010: 0000 0000 0000 0000 4000 0000 0000 0000 ........@....... 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 7800 0000 ............x... A sintaxe pode parecer um pouco estranha no início, mas você acostuma rápido. O sufixo #B diz que a unidade usada é bytes. Você pode testar outros valores como 2#KB ou 1#MB por exemplo. ? Dumpando a partir de posições específicas Para dumpar a partir de uma posição específica, podemos usar a opção :from do comando dump: (poke) dump :from 0x30#B :size 32#B 76543210 0011 2233 4455 6677 8899 aabb ccdd eeff 0123456789ABCDEF 00000030: 0000 0000 0000 0000 0000 0000 7800 0000 ............x... 00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 7468 ........!..L.!th No comando acima eu pedi para o poke me mostrar 32 bytes a partir da posição 0x30. Seria o equivalente a fazer hd -n 32 -s 0x30 <arquivo>. O poke mantém um ponteiro de leitura no arquivo, por isso se você comandar somente dump novamente, o dump ocorrerá a partir da última posição lida (no caso, 0x30). Se quiser voltar o ponteiro para a posição zero, é a mesma sintaxe: dump :from 0#B. Interpretando dados O dump sempre te entrega uma saída em hexadecimal, mas e se quisermos interpretar os dados e exibi-los de maneiras diferentes? Para isso a gente larga de mão o comando dump e começa a operar com o jeito do poke de ler e interpretar especificamente, assim: (poke) byte @ 0#B 77UB O sufixo UB significa Unsigned Byte. Se eu quiser a saída em hexa por exemplo, basta eu setar a variável obase (output base): (poke) .set obase 16 (poke) byte @ 0#B 0x4dUB Eu poderia querer ler 2 bytes. Tranquilo: (poke) byte[2] @ 0#B [0x4dUB,0x5aUB] Posso interpretar o conteúdo como número também: (poke) uint16 @ 0#B 0x4d5aUH O prefixo UH significa Unsigned Half (Integer). Perceba que o poke sabe que um uint16 tem 2 bytes e por isso os lê sem a necessidade que especifiquemos o número de bytes a serem lidos. À essa altura você já sacou que equivalentes aos tipos padrão da linguagem C (da inttypes.h na real) estão disponíveis para uso né? Fique à vontade pra testar off64, int64, int32, etc. Lendo strings Além dos tipos numéricos, o poke tem o tipo string, onde ele lê até encontrar um nullbyte: (poke) dump 76543210 0011 2233 4455 6677 8899 aabb ccdd eeff 0123456789ABCDEF 00000000: 4d5a 7800 0100 0000 0400 0000 0000 0000 MZx............. 00000010: 0000 0000 0000 0000 4000 0000 0000 0000 ........@....... 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 7800 0000 ............x... 00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ........!..L.!Th 00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f is program canno 00000060: 7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS 00000070: 6d6f 6465 2e24 0000 5045 0000 4c01 0700 mode.$..PE..L... (poke) string @ 0x4d#B "!This program cannot be run in DOS mode.$" Patch simples Vamos fazer um patch simples: alterar o "T" desta string acima de maiúsculo para minúsculo. Basicamente é só colocar à esquerda o jeito que acessamos uma determinada posição do arquivo e igualar ao que a gente quer. Sabendo que para converter maiúsculo para minúsculo na tabela ASCII basta somar 32 (0x20), podemos fazer: (poke) byte @ 0x4e#B = 0x74 Perceba que fui na posição 0x4e, porque na 0x4d temos o '!' e não o 'T'. Só pra checar se funcionou: (poke) string @ 0x4d#B "!this program cannot be run in DOS mode.$" (poke) Legal né? Mas dá pra ficar melhor. O poke suporta char, então podemos meter direto: (poke) char @ 0x4e#B = 't' (poke) string @ 0x4d#B "!this program cannot be run in DOS mode.$" Por hora é só. Fica ligado aí que postarei a parte 2 em breve, onde vou mostrar mais recursos do poke que tô achando bem úteis para engenharia reversa. Até lá! ?

Comecei a estudar a linguagem Go há alguns dias e fiquei muito impressionado com seus recursos. A facilidade para programação paralela, o fato de ter ponteiros, funções que retornam mais de um valor, código enxuto (se você declarar uma variável e não usar, o programa nem compila!) e outros realmente me encantaram. Recentemente precisei disassemblar um trecho de código de um binário PE para um projeto que está escrito em Go. Vi que existem algumas bibliotecas prontas para serem usadas, como gapstone (bindings da Capstone) e go-zydis (bindings da Zydis) mas não encontrei uma nativa. No entanto, vi que existe uma ferramenta nativa no toolset da linguagem similar ao objdump do GNU binutils: $ go doc cmd/objdump Objdump disassembles executable files. Usage: go tool objdump [-s symregexp] binary Objdump prints a disassembly of all text symbols (code) in the binary. If the -s option is present, objdump only disassembles symbols with names matching the regular expression. Compilei um "hello, world" em Go só pra ver: ~/hello $ cat main.go package main import "fmt" func main() { fmt.Println("menteb.in") } ~/hello $ go build E de fato o objdump da Go funciona: ~/hello $ go tool objdump hello | head TEXT go.buildid(SB) :-134217728 0x1001000 ff20 JMP 0(AX) :-134217728 0x1001002 476f OUTSD DS:0(SI), DX :-134217728 0x1001004 206275 ANDB AH, 0x75(DX) :-134217728 0x1001007 696c642049443a20 IMULL $0x203a4449, 0x20(SP), BP :-1 0x100100f 226d35 ANDB 0x35(BP), CH :-1 0x1001012 4c6f OUTSD DS:0(SI), DX :-1 0x1001014 6a52 PUSHL $0x52 :-1 0x1001016 436e OUTSB DS:0(SI), DX :-1 0x1001018 4a31794f XORQ DI, 0x4f(CX) Mas ao tentar com o um PE compilado pra 64-bits, descobri que só funciona com binários feito em Go. ? $ go tool objdump putty.exe objdump: disassemble putty.exe: no runtime.pclntab symbol found De qualquer forma, resolvi olhar o código-fonte deste objdump interno da linguagem pra ver qual é dessa mandinga. Na linha 43 do main.go do objdump tem um import pra uma biblioteca chamada objfile. Pensei: Wow, deve ser uma biblioteca de disassembly, talvez eu possa alterar ! E na hora já criei um projeto tentando usá-la mas fui surpreendido com um errão! kkkk ~hello $ cat main.go package main import "fmt" import "cmd/internal/objfile" func main() { fmt.Println("menteb.in") } ~hello $ go build main.go:4:8: use of internal package cmd/internal/objfile not allowed Não pesquisei muito sobre essa história sobre eu não poder usar um pacote interno (por quê o objdump pode e eu não posso?!), mas fui olhar esta objfile e terminei encontrando seu fonte. Para minha alegria, neste arquivos disasm.go vi os seguintes imports: "golang.org/x/arch/arm/armasm" "golang.org/x/arch/arm64/arm64asm" "golang.org/x/arch/ppc64/ppc64asm" "golang.org/x/arch/x86/x86asm" Agora sim, carái! É tudo público e posso usar. Desculpe o desabafo.. hehe o artigo na verdade começa aqui mas quis contar como cheguei porque né. ? Cada uma dessas bibliotecas possui uma função Decode() justamente pra decodificar uma instrução (tipo Inst). Testei com um NOP em 64-bits, só pra ver: package main import ( "fmt" "log" "golang.org/x/arch/x86/x86asm" ) func main() { dados := []byte{0x90} ins, err := x86asm.Decode(dados, 64) if err != nil { log.Fatalln(err) } fmt.Println(ins) } A saída foi exatamente a esperada: $ ./hello NOP Show. Agora é abrir um PE, ler de onde quero e daí disassemblar usado essa x86asm.Decode() num loop, mas vou deixar esse exercício aí pra quem quiser treinar Go. Ou se acharem útil posso postar um aqui mais tarde. Aqui já funcionou mas precisa de uma polida. ? Perceba também que há bibliotecas para ARM e PowerPC. Achei bem maneiro. Talvez em breve o time da Go adicione suporte a mais arquiteturas. Amém! ?

O time de desenvolvimento do Ghidra anunciou a versão 9.1 do software, agora com suporte aos processadores SH1/2/2a, Tricore, HCS12X, HCS08, SH4 e MCS-48. Podem parecer muito exóticos, mas SH4 por exemplo é uma das plataformas alvejadas por malwares para IoT como Mirai e outras botnets. Dentre os novos recursos, tem o suporte à edição de estruturas (structs) e uniões (unions) nos Data Types, assunto que cobrimos na aula 08 do treinamento de Ghidra aqui do Mente Binária. ? Lista completa das alterações e links para download no site oficial.

O pesquisador Fermín J. Serna, keynote speaker na H2HC este ano, iniciou sua palestra intitulada OSS Security: Here be dragons falando sobre a lendária edição da H2HC em Cancún realizada há 10 anos. "Eram umas 25 pessoas, sendo que 10 eram palestrantes", brincou. ? Fermín foi o principal desenvolvedor do já descontinuado EMET e sua paixão por segurança defensiva é notória. Hoje, CSO na Semmle, empresa agora parte do Github, ele afirmou que o software livre venceu e hoje 90% dos softwares utilizam outros, de código aberto. Fermín lembra que software livre é gratuito do ponto de vista monetário, mas não vem com segurança grátis. "Software livre de segurança vem com desafios. Você consome, mas precisa investir". Vários exemplos de vulnerabilidades foram mostrados durante a palestra, inclusive uma tentativa de se colocar uma backdoor no kernel Linux que aconteceu em 2003. Tudo isso antes de apresentar o projeto CodeQL, que consiste num esforço de criar uma linguagem de query para encontrar bugs (principalmente de segurança, mas expansível a quaisquer outros tipos) em códigos-fonte. O projeto já encontrou vulnerabilidades em softwares de código aberto, incluindo o U-Boot e o próprio kernel Linux. "Dá trabalho confirmar as vulnerabilidades, mas só de atribuições indevidas, já encontramos umas 1300 no kernel Linux", contou. Apesar de tantos bugs, Fermín fez questão de dizer que isso não é culpa dos programadores: "software de código aberto é ótimo e está aqui pra ficar. Não devemos culpar os desenvolverdes. Devemos nos culpar, porque não os ajudamos", reiterou. Parabéns, Fermín! ?

Se você é nosso leitor há algum tempo, já deve ter visto a @barbieauglend por aqui. O que talvez você não soubesse, é que ela se juntou com o Gustavo Scotti para dar uma palestra que ocupou dois slots na H2HC este ano. Com a sala lotada, Gustavo e Thais mostraram como escreveram um exploit confiável para uma vulnerabilidade no kernel Linux, registrada sob o CVE-2017-11176. A palestra começou com a Thais falando sobre seu passado em análise de malware e os desafios da migração para computação ofensiva. Já o Gustavo, experiente pesquisador na área, se mostrou extremamente solícito tanto em ajudá-la com este exploit quanto com o público: "Se vocês tiverem qualquer dúvida, podem perguntar a qualquer momento. Quem for tímido pode falar comigo individualmente depois da palestra. Vou ficar por aí no evento hoje e amanhã". Ele comentou que muitas vezes as pessoas ficam "travadas" em algum lugar e precisam de ajuda para seguir seus estudos. Ajuda esta que ele oferece a quem procurá-lo. A dupla tomou como base de estudo a publicação da vulnerabilidade num blog francês, mas rapidamente verificaram que o texto se referia a uma versão diferente do kernel da especificada no artigo. O desafio foi entender a falha e escrever o exploit corretamente, de forma confiável. Os pontos altos da palestra foram justamente como fizeram isso. Gustavo recomendou automatizar tudo o que é possível para reduzir o tempo de iteração e atentou para o fato de que, em kernel land, é necessária muita estabilidade. "A Thais conseguiu explorar a falha com sucesso mas depois de 10 minutos ao ganhar root, o kernel travava", comenta. Foi preciso corrigir os ponteiros usados nas estruturas utilizadas pelo exploit e fazer uma série de ajustes para que o exploit ficasse de fato confiável. "Eu achei massa porque eles fizeram bypass de SMEP (Supervisor Mode Execution Prevention), que impede que código de kernel execute código em user space", comenta @Ygor Da Rocha Parreira, pesquisador da área e parte da organização do evento. "Antigamente quando explorando um bug de kernel, como o espaço de endereçamento é compartilhado entre kernel e user space dentro do processo corrente, era mais fácil a partir dele, acessar dados e executar código em user space. O SMEP/SMAP impede isso, mas eles burlaram com ROP (Return Oriented Programming) em kernel land", adiciona. "O objetivo da nossa palestra era, como o nome sugere, de levar o conhecimento e não só mostrar o exploit funcionando. Por isso a gente mostrou desde o básico, como decodificar memória, até como as estruturas funcionavam para que as pessoas realmente se motivassem e entendessem que é um processo que não precisa intimidar. Não é necessário saber tudo. Pode-se aprender durante a pesquisa.", falou Gustavo pra gente. Ele insiste que o contacte no Twitter para eventuais dúvidas. Valeu, Gustavo! ? O público aplaudiu e achamos que o Gustavo e a Thais conseguiram despertar na audiência o interesse de estudar computação ofensiva e apresentar um caminho, que é o de seguir blogs, textos escritos por pesquisadores, pesquisar com falhas antigas e, como o Gustavo oferta, se tiver qualquer dúvida, pode falar com ele. ?

Segundo o Valor Econômico, a empresa Chinesa Baidu vai encerrar suas operações no Brasil até setembro. Desde 2013 o antivírus e a toolbar desta empresa tem gerado opiniões não muito felizes e memes, tudo isso porque a empresa escolheu investir no formato que chamam de bundle, onde basicamente injetam seus softwares no sistema operacional do usuário quase que sem o seu consentimento: sites de downloads como o Baixaki e até o Sound Forge ofereciam os softwares da Baidu junto com o download de outros softwares que nada tinham a ver com segurança. Eu mesmo tive a experiência de baixar o Audacity para editar um arquivo de áudio e ao final da instalação percebi um ícone me avisando que meu PC estava agora protegido pelo Baidu. E já tinha um antivírus instalado! Foi um espanto e na hora de remover o Baidu praticamente implorou que eu não o fizesse, afirmando poder coexistir com outros antivírus sem nenhum problema. Haja petulância viu?! Outro problema enfrentado por usuários forçados do Baidu era remover o antivírus do computador. Em algumas versões, era quase impossível sozinho. Não é à toa que uma busca por "remover baidu" no Google Brasil retorna mais de 350.000 resultados, com tutoriais de como desinstalar, vídeos no YouTube ensinando e até softwares para realizar árdua tarefa. Segundo a empresa, ainda há uma base de 20 milhões de usuários de seus produtos no Brasil, que vão continuar sendo atendidos. Não é o fim do software, tampouco da empresa, apenas as operações (funcionários, escritórios, etc) no Brasil cessarão. Um amigo resumiu: o Baidu saiu do Brasil, mas não dos computadores dos brasileiros. ? E na sua experiência? Conta aí pra gente! ?

O CEO da Crown Sterling, uma startup na área de criptografia, fez um anúncio em uma palestra publicada no YouTube incluindo uma demonstração de quebra da criptografia RSA em menos de um minuto. A apresentação gerou vários comentários na comunidade de segurança da informação mundial, mas acontece que na prática as coisas não são tão simples assim. Pedimos ao Bruno Trevizan (@trevizan), especialista em criptografia e colaborador do Mente Binária, para comentar o assunto. "Um parâmetro importante para o criptosistema RSA é o tamanho (em bits) do módulo público n, principal elemento da chave pública, sendo esse o produto de dois números inteiros primos (p e q) também utilizados no cálculo da chave privada. O ataque demonstrado lança mão da abordagem de fatoração de inteiros, que consiste em encontrar um divisor não trivial de um número composto, ou seja, encontrar um dos inteiros primos p ou q, tal que n = p x q, onde n é informado como elemento da chave pública. Obtendo sucesso na recuperação desses fatores, o atacante é capaz de calcular a chave privada. Contudo, apesar do ataque demonstrado ter sido bem-sucedido, o exemplo contido na demonstração utiliza o módulo público de 256 bits, tamanho de chave não recomendado para nenhum caso", explica. A notícia também foi criticada pelo criptógrafo Bruce Schneier, que lembrou que 256 bits é um tamanho de chave que nunca foi considerado seguro, ou seja, é "quebrável" mesmo. Além disso, o CEO da Crown Sterling, Robert Grant, diz na palestra que uma chave de 512 bits poderia ser quebrada em aproximadamente 5 horas, mas não demonstra. "Contudo, o parâmetro em questão é reconhecidamente inseguro desde 1999, sendo que seu uso não é recomendado nem para sistemas legados. Sendo o tamanho mínimo tolerado para suportar a sobrevida de sistemas legados de 1024 bits, é recomendável o uso 2048 bits ou mais", adiciona Bruno. Outros nomes na área de segurança da informação acreditam se tratar mais um sales pitch do que qualquer outra coisa. No Twitter, Nicholas Weaver, PhD em Berkeley, sugeriu que a ferramenta apresentada pela Crown Sterling seja na verdade uma cópia da CADO-NFS, uma ferramenta de código aberto desenvolvida por pesquisadores na França que consiste na implementação do algoritmo de Number Field Sieve (NFS) para fatoração de números inteiros. Waver nota que a mensagem de saída apresentada no vídeo da Crown Sterling é exatamente a mesma da ferramenta CADO-NFS, o que sugere seu reuso. Victor Mello, Especialista em Segurança Sênior na Neoway, quando soube da notícia fez um script simples em Perl para o mesmo propósito: "para quem tiver interesse, testei aqui e levou em torno de 8 minutos usando GMP num laptop de 8 núcleos (cores). Utilizei o mesmo n que o pessoal da Crown Sterling usou na demonstração", comenta. Victor compartilhou conosco o código-fonte do seu script: use Math::Prime::Util::GMP ':all'; use bigint; # Find prime factors of big numbers @factors = factor(shift); for my $i (@factors) { print $i . "\n"; } Resumindo, quebraram o que já era quebrável. Não precisa fugir para as colinas ainda. ?