Jump to content

  • Articles

    Show all categories
    Lucas Lab
    Downloads via torrent são feitos desde 2001. Como resultado, pessoas ao redor do mundo começaram a compartilhar seus arquivos favoritos, como músicas, filmes, imagens e vídeos, mesmo estando em locais distantes. Isso acabou abalando a indústria da música nos anos 2000, pois já não era mais necessário pagar para ter acesso a qualquer música, álbum, CD ou imagem, que antes só podiam ser obtidos mediante pagamento.
    Esses compartilhamentos de arquivos de músicas, vídeos, imagens, etc., são feitos por meio da arquitetura de rede P2P (peer-to-peer / ponto-a-ponto).
    Para realizar um download por P2P, basta baixar um arquivo torrent, por exemplo, “ubuntu-23.04-desktop-amd64.iso.torrent”, e adicioná-lo a um aplicativo como o uTorrent. Em seguida, o download começará.
    Os arquivos “.torrent” contêm informações sobre o arquivo a ser baixado, como nome, tamanho, metadados adicionais (data de criação, informações do criador, descrição, hash, etc.).
    De forma simplificada, conectamos ao IP do fornecedor do arquivo para iniciar o download. O fornecedor precisa saber nosso IP para saber para onde enviar o arquivo compartilhado. No entanto, isso pode ser um problema…
    Aplicativos como BitTorrent, uTorrent e qBittorrent, por exemplo, usam o protocolo BitTorrent, que faz parte da arquitetura de rede P2P. Nessa rede descentralizada, todos os usuários são servidores e clientes ao mesmo tempo, expondo seus IPs “obrigatoriamente” para que outros usuários saibam para qual computador deva ser realizado o upload ou download de um arquivo.
    O conhecimento do IP por si só pode não ser um problema tão grande em termos de segurança da informação, a menos que se envolva em downloads ilegais, como pirataria ou pornografia ilegal.
    No entanto, é desconfortável que outras pessoas saibam seu IP, pois a privacidade é importante, e ninguém deseja que outros conheçam sua localização geográfica.
    Assim, se alguém sabe seu IP para enviar um arquivo, e você sabe o IP dessa pessoa para receber o arquivo, o que poderia ser feito com essas informações?
    Qualquer pessoa pode consultar um histórico de downloads torrent feito por outro usuário, desde a pessoa mais leiga em informática até a mais experiente pode fazer isso.
    Um desses serviços de rastreamento de downloads via torrent é o iknowwhatyoudownload.com, que, traduzido, significa “eu sei o que você baixa”.
    Ao informar um IP aleatório da faixa de IPs de uma VPN, por exemplo, é possível ver todos os downloads feitos pelo usuário desse IP.
    O site lista o histórico de downloads do IP informado, incluindo o nome do arquivo baixado, a data e o horário completos, o tamanho do arquivo, o IP do usuário que baixou e outras informações.

    A página retorna colunas com as datas dos arquivos, categoria, título e tamanho.
    Observação: Na captura de tela, até mesmo um download de um vídeo pornô, um arquivo “XXX”, é mencionado na última linha.
    O site oferece uma API na guia “API”. Ao criar uma conta gratuita, é possível até mesmo saber, por meio da resposta JSON da API, se um determinado IP baixou pornografia infantil ou pornografia legalizada. No exemplo fornecido, consta que não houve download de pornografia infantil, mas houve download de pornografia pelo IP informado.
    Observação: O IP informado é de uma VPN, portanto, não é o IP “real” de um usuário.

    A resposta JSON da API também fornece dados completos sobre os downloads torrent do IP informado.

    Na guia “About”, o site informa o seguinte:

    Confira o texto original em: https://iknowwhatyoudownload.com/en/contacts/
    Em “Track downloads”, você pode gerar um link e enviá-lo para alguém. Quando essa pessoa clicar no link gerado, você poderá ver os downloads feitos por ela.


    Lembre-se de que um ISP (provedor de internet, por exemplo) pode atribuir um único IP para mais de um usuário.
    Outros sites oferecem serviços semelhantes. Além disso, é possível criar um bot capaz de pesquisar sites de filmes piratas por meio do Google, baixar torrents, ler informações como título do arquivo, data, hash, etc., iniciar o download para rastrear as conexões de upload e download e identificar os participantes desses downloads. O bot também pode interagir com peers, que são usuários que compartilham e recebem dados em aplicativos P2P como o uTorrent, permitindo obter seus endereços IP e descobrir o que cada usuário está baixando. Dessa forma, não seria necessário consultar um site como o iknowwhatyoudownload.com. Existem também técnicas mais avançadas que poderíamos abordar em outro artigo, caso você tenha interesse.
    Observação: É importante ressaltar que o uso desses sites de monitoramento de torrents pode levantar questões de privacidade, pois eles obtêm informações sobre downloads de torrents e endereços IP. Sempre considere as leis e regulamentos locais ao utilizar esses serviços e tome as medidas necessárias para proteger sua privacidade online.
    Tempest Security Intelligence
    A corrida tecnológica dos últimos anos continua trazendo benefícios para as operações das empresas mas, ao mesmo tempo, potencializando os prejuízos com ataques cibernéticos por uma série de motivos que incluem, de forma especial, o aumento das fronteiras dos negócios e da complexidade das operações neste novo cenário de adoção de ambientes em nuvem e outras tecnologias, novas conexões com clientes e fornecedores e outros fatores.
    Um relatório divulgado recentemente - o Cost of a Data Breach, produzido pelo Ponemom Institute - dá uma ideia do tamanho dos prejuízos enfrentados pelas empresas atualmente; segundo o report, em 2022 o custo médio por incidente envolvendo o vazamento de dados de organizações - custo este que inclui questões legais, regulatórias, técnicas e danos à marca - foi de US$ 4,35 mi. Trata-se de uma média 2,6% maior do que a média do ano anterior.
    Como consequência deste cenário, os investimentos em cibersegurança devem ultrapassar os US$ 219 bi em 2023, aumento de cerca de 12% em relação a 2022. No entanto, mesmo com o aumento dos investimentos, não são poucas as empresas que enfrentam uma grande dificuldade em obter visibilidade aos riscos a que estão expostas.
    Visibilidade é questão essencial para a cibersegurança
    Ter visibilidade do ponto de vista da segurança da informação significa, entre outras coisas, saber que dispositivos estão conectados ao ambiente e quais os riscos a que estes dispositivos estão expostos, além de saber quais vulnerabilidades estão afetando minha estrutura, que dados estão trafegando, etc. 
    Existe uma série de serviços de consultoria de segurança que permitem obter, de forma ágil, uma maior visibilidade das vulnerabilidades afetando sistemas e aplicativos que podem ser exploradas por atacantes, sejam elas brechas na segurança da rede, erros de configuração, falhas de software, entre tantas outras.
    Dentre estes serviços estão os testes automatizados de segurança, as auditorias/testes de compliance e pentests. Cada um destes serviços, no entanto, possui características e objetivos próprios. 
    Neste blogpost traremos um pouco das particularidades destes serviços.
    Testes de Auditoria ou Compliance
    Com o aumento de regulamentações destinadas à proteção dos dados de cidadãos e clientes de empresas, sejam elas leis aplicadas pelos governos como a LGPD no Brasil ou a GDPR na Europa, sejam normas regulatórias criadas por setores específicos da economia para regular e normatizar seus mercados, empresas de todos os setores precisam estar atentas ao fluxo de dados e informações trafegando nos seus ambientes, evitando acesso não autorizado, exfiltração de dados e outras violações.
    Testes de Auditoria e de Compliance verificam o nível de segurança das tecnologias envolvidas na operação, bem como das rotinas de coleta, processamento e armazenamento de dados a partir de um checklist. Importante destacar que este checklist se restringe ao escopo da auditoria em questão. 
    Por exemplo: uma auditoria que irá verificar a aderência das operações a uma regulação específica de um setor não irá garantir que a empresa esteja em conformidade com outras leis ou regulamentações, nem mesmo irá medir o grau de maturidade da organização. Ou seja, trata-se de um teste cujo objetivo é basicamente checar se as regras determinadas pela regulação estão sendo seguidas.
    Testes Automatizados ou scans de vulnerabilidades
    Testes automatizados utilizam uma série de ferramentas capazes de verificar falhas e vulnerabilidades no ambiente, seja em endpoints, seja na infraestrutura de rede, servidores, etc. Estes testes vem ganhando popularidade por oferecerem uma série de benefícios que incluem: 
    Eficiência: o uso de ferramentas automatizadas permite identificar uma série de vulnerabilidades em uma ampla gama de dispositivos em um curto espaço de tempo.
    Custo-benefício e continuidade: o custo reduzido destes testes permite manter uma rotina de scans a baixos custos.
    Escala: mesmo com o aumento de estrutura e com a adoção de novas tecnologias, testes automatizados podem ser facilmente conduzidos.
    Mas apesar dos benefícios é preciso deixar claro que testes automatizados não representam uma solução completa para identificar todas as falhas e vulnerabilidades  presentes no negócio.
    Testes automatizados não conseguem identificar, por exemplo, se existe algum gap de segurança nas regras do negócio - se em um processo de compra de um e-commerce há problemas no processo de validação de dados de pagamento, por exemplo. Da mesma forma não são capazes de identificar cenários de fraude
    A título de exemplo, neste contexto de fraude, vamos considerar as falhas humanas. 
    O relatório Data Breach Investigation Report, produzido pela Verizon, coloca entre os principais vetores para as violações o uso de credenciais roubadas (BEC), o phishing e a exploração de vulnerabilidades, nessa ordem - 74% de todas as violações incluem o elemento humano, com pessoas envolvidas por meio de erro, uso indevido de privilégios, uso de credenciais roubadas ou engenharia social.   
    Identificar falhas que envolvam a operação depende de um entendimento do negócio, seu contexto e as relações e conexões entre pessoas, processos e tecnologias. Testes automatizados não são capazes de fazer esta avaliação ou conduzir simulações de ataques de engenharia social que poderiam identificar gaps de conhecimento entre os colaboradores.
    Pentests ou Testes de Intrusão
    Pentests, ou testes de intrusão, consistem em simular um ataque em uma rede, aplicação ou sistema para identificar vulnerabilidades e avaliar a efetividade das medidas de segurança existentes na organização. 
    São aplicados por profissionais qualificados e fazem uso de táticas, técnicas e ferramentas similares às que atacantes reais usariam contra o negócio, ou seja, buscam simular cenários de ataque que irão considerar não apenas as vulnerabilidades na estrutura tecnológica, mas também no escopo único de cada empresa, sua operação, as pessoas envolvidas e, claro, as tecnologias usadas.
    Pentests possuem uma série de modalidades e aplicações que incluem mas não se limitam a:
    External – tem como objetivo entrar no ambiente corporativo de TI ou obter acesso a dados ou sistemas críticos a partir da Internet
    Internal – avalia as proteções do ambiente corporativo de TI sob o ponto de vista da rede interna
    Mobile Application – visa encontrar vulnerabilidades ou discrepâncias de programação que possam ser usadas em um ataque
    Web Application – avalia resiliência de aplicações web
    Wi-Fi – verifica a possibilidade de comprometer ambientes corporativos a partir de redes Wi-Fi
    Testes no Ambiente de Rede – verifica vulnerabilidades neste ambiente e em seus dispositivos
    Testes de Software ou aplicação de desktop – identifica falhas que possam levar ao controle do dispositivo, injeção ou interceptação de dados, etc.
    Testes de Hardware – verifica vulnerabilidades diretamente ao hardware do dispositivo alvo. 
    Em conclusão…
    Testes de compliance, automatizados ou pentest possuem, cada um, a devida importância. Sua aplicação deve ser guiada pelo contexto específico de cada companhia.
    Metaforicamente, assim como ir a um médico e realizar um exame específico quando aparece um dado sintoma não reduz a importância de realizar check ups completos e periódicos para avaliar a saúde como um todo, cada um dos testes que apresentamos neste artigo cumprem um papel importante na saúde da segurança de uma empresa. 
    Diferenciais do Pentest da Tempest
    Com início das operações em 2001, o Pentest da Tempest conta com a experiência e conhecimento do maior time técnico da América Latina  (SOC, Threat Hunting, Incident Response, Software Engineering, Red Team,  Vulnerability Management e  Threat Intelligence) para entregar um serviço de alta profundidade, com resultados robustos, tecnicamente sofisticados e efetivamente aderentes  aos desafios e necessidades dos nossos clientes. 
    Recentemente produzimos o Guia do Comprador de Pentest da Tempest, onde você conhece melhor cada um dos tipos de pentest disponíveis atualmente e também tem acesso a uma série de dicas. Nele também apresentamos os seis elementos essenciais que irão ajudar a avaliar um fornecedor  para encontrar a solução mais adequada para sua situação.
    Download do guia completo
    Contar com o parceiro certo faz a diferença na proteção dos dados em qualquer ambiente
    A Tempest Security Intelligence é uma empresa brasileira com atuação global. É a maior companhia brasileira especializada em cibersegurança e prevenção a fraudes digitais. 
    Sediada no Recife, a Tempest conta também com escritórios em São Paulo e Londres, com mais de 600 colaboradores. 
    Ao longo de seus 23 anos, a Tempest ajudou a proteger mais de 600 empresas de todos os portes e setores, dentre elas companhias do setor financeiro, varejo, e-commerce, indústria e healthcare, atuando em clientes nacionais e internacionais atendidos tanto pelo time no Brasil quanto no Reino Unido. 
    Em 2020, a Tempest conquistou um parceiro de peso para continuar na vanguarda da cibersegurança, recebendo um grande aporte da Embraer, companhia brasileira de engenharia aeroespacial, o qual resultou em um dos maiores investimentos já realizados na história do setor de cibersegurança na América Latina. 

     
    Fernando Mercês
    Você conhece o pev, nosso kit de ferramentas para análise de binários PE (usados no Windows)? Se conhece, acho que vai se identificar com essa história. Se não conhece, vai conhecê-lo muito bem agora. Nesse artigo vou passear brevemente sobre a inspiração que deu origem ao projeto, o que foi feito desde então e o que vem por aí. De modo cronolagicamente organizado, começamos por um passado de mais de uma década. Partiu embarcar nessa viagem no tempo? ⌛
    Passado 💭
    Lá em 2010 eu queria fazer um programa que lesse a string de versão “File version” de executáveis PE. Essa que aparece quando você vai nas Propriedades de um executável .exe no Windows:

    Essa informação só poderia estar no arquivo .exe, mas eu não sabia exatamente onde. Depois de muito estudo, consegui entender que essa informação fica numa estrutura chamada VS_FIXEDFILEINFO que, por sua vez, pertence a uma estrutura chamada VS_VERSIONINFO. Dava para encontrar essa estrutura por nome no binário em uma string UTF-16-LE na seção de recursos .rsrc:
    $ strings -tx -el putty.exe | grep VS_VERSION_INFO 15a2c6 VS_VERSION_INFO $ hd -s 0x15a2c6 -n64 putty.exe 0015a2c6 56 00 53 00 5f 00 56 00 45 00 52 00 53 00 49 00 |V.S._.V.E.R.S.I.| 0015a2d6 4f 00 4e 00 5f 00 49 00 4e 00 46 00 4f 00 00 00 |O.N._.I.N.F.O...| 0015a2e6 00 00 bd 04 ef fe 00 00 01 00 4d 00 0a 00 00 00 |..........M.....| 0015a2f6 00 00 4d 00 00 00 00 00 00 00 0b 00 00 00 00 00 |..M.............| 0015a306 Mas onde estava o 0.77.0.0 ninguém me contava... Bem, segundo a documentação, a estrutura é definida assim:
    typedef struct tagVS_FIXEDFILEINFO { DWORD dwSignature; DWORD dwStrucVersion; DWORD dwFileVersionMS; DWORD dwFileVersionLS; DWORD dwProductVersionMS; DWORD dwProductVersionLS; DWORD dwFileFlagsMask; DWORD dwFileFlags; DWORD dwFileOS; DWORD dwFileType; DWORD dwFileSubtype; DWORD dwFileDateMS; DWORD dwFileDateLS; } VS_FIXEDFILEINFO; Para facilitar a visualização dos campos de interesse dessa estrutura no dump hexa, coloquei comentários nela usando o rehex (parte integrante do nosso retoolkit) :

    De acordo a documentação, o primeiro membro, chamado dwSignature, deve conter o valor 0xfeef04bd. Considerando o ensianness em little-endian, essa assinatura tá no dump hexa em 0x15a2e8, logo após a string VS_VERSION_INFO em UTF-16-LE. A missão então era achar como o número de “File version” era gerado, no exemplo aqui, a string 0.77.0.0. Vamos em frente.
    Logo depois da dwSignature tem a dwStrucVersion de quatro bytes, seguida da dwFileVersionMS, que também é uma DWORD (Double WORD) de quatro bytes. Nesta última, temos os bytes 4D 00 (destacados em verde) e 00 00 (laranja). Lendo a documentação, descobri que A WORD mais significativa, tomando este número em little-endian, é o nosso primeiro zero da string "0.77.0.0", destacado em laranja. Já a WORD menos significativa é o 77 (0x4D), destacado em verde. O próximo membro é a dwFileVersionLS (amarelo e rosa), que segue a mesma lógica, formando o "0.0" final.
    Na época, fiz um script em Python para buscar esse número de versão e chamei de pev.py (pev vem de “PE Version”). Não tenho mais o script, mas hoje seria algo nessa linha:
    import sys if len(sys.argv) < 2: print("Usage: pev.py <pefile>") sys.exit(1) with open(sys.argv[1], "rb") as f: d = f.read() vinfo = "VS_VERSION_INFO".encode("utf-16-le") # Busca a string nos conteúdo do arquivo pos = d.find(vinfo) # Avança para depois da string vinfo + 4 pos += len(vinfo) + 4 sig = int.from_bytes(d[pos:pos+4], "little") if sig != 0xfeef04bd: print(f"Signature not found at {pos:#x}") sys.exit(1) pos += 8 # Avança para o dwFileVersionMS # Lê a word mais significativa major1 = int.from_bytes(d[pos+2:pos+2], "little") # Lê a word menos significativa major2 = int.from_bytes(d[pos:pos+2], "little") # Avança para o dwFileVersionLS pos += 4 # Lê a word mais significativa minor1 = int.from_bytes(d[pos+2:pos+2], "little") # Lê a word menos significativa minor2 = int.from_bytes(d[pos:pos+2], "little") print(f"{major1}.{major2}.{minor1}.{minor2}") Assim como o script da época, este script funciona:
    $ python pev.py putty.exe 0.77.0.0 Mas sem dúvida, pode ser melhor por vários motivos. O principal, é que ele é lento, especialmente para arquivos grandes pois ele busca a string VS_VERSION_INFO no binário inteiro. É a famosa “marretada” em programação...

    Era lento, não tinha jeito. Resolvi então estudar a documentação do PE e cheguei num código muito maior, mas que rodava muito mais rápido, porque eu lia todos os cabeçalhos do PE necessários para encontrar a posição no arquivo da estrutura VS_VERSION_INFO e, por consequência, da VS_FIXEDFILEINFO. O código não envolvia busca. Ao contrário, ele ia direto ao ponto. O pev 0.22 implementava esse algoritmo em aproximadamente 300 linhas de código em C. Lançado em 2010 no extinto Google Code, era assinado pelo Coding 40º, um grupo de programação que criei na faculdade com mais três amigos (@Francivan Bezerra, Thiago e Eduardo). No ano seguinte, o Coding 40º teve uma breve vida como hackerspace na Tijuca, no Rio de Janeiro, onde inclusive o @julio neves foi nos visitar. 💚
    O projeto andou, mas em algum momento pensei: se eu passo por todos os cabeçalhos do PE, por que não imprimir os valores dos campos também? Isso transformaria o pev num parser de PE completo! E foi o que fizemos. Aí o projeto cresceu mais, ganhou relevância na área de segurança (era o único parser de PE livre e multiplataforma do planeta) e atraiu colaboradores do Brasil e de fora. A ponto do meu empregador na época ficar preocupado de eu estar recebendo dinheiro de outra empresa por conta do pev (como sempre, a p***a do capitalismo na nossa cola). Mas eu estava só aprendendo mesmo.
    Na versão 0.50 eu segui a dica do @bsdaemon de “quebrar” o pev em programas menores, onde cada um cumpriria uma função. Assim, o pev virou um kit de ferramentas. E tivemos que aprender a lidar com tanto código, depois veio o Git e o GitHub e tivemos até uma sessão presencial onde vários colaboradores do projeto se uniram para estudar Git:

    (Da esquerda para a direita, Álvaro Justen, Renato Augusto, Álvaro Rios, Thiago Bordini, @Felipe Esposito, Jan Seidl, Igor Rincon, @l0gan, @Gustavo Roberto, Slayer, @Fernando Mercês, Rogy e unk)
    Dentre as muitas pessoas que colaboraram, teve o @jweyrich que reescreveu a libpe (na qual o pev se baseia) quase toda, corrigiu muito código, adicionou recursos e levou o projeto para outro nível. Junto com várias pessoas que reportaram e corrigiram bugs, implementaram recursos e testaram o pev, lançamos várias versões até chegarmos na atual 0.8x. 🙃
    Presente 🎁
    Hoje com aproximamente 30.000 linhas de código, o pev está estabelecido. Está presente em vários tutorias sobre análise de malware, e forense e em praticamente todas as distribuições Linux, incluindo Debian, Kali, Ubuntu, etc. Tem builds para Windows também. Veja alguns dos lugares onde você encontra o pev:
    Pacote no Debian (eu fui o primeiro mantenedor, depois deixei o pacote órfão e o time do Debian assumiu! 💗):
    Pacote no Ubuntu:
    Incluso no Kali Linux por padrão:
    Incluso no REMnux por padrão:
    Incluso no Tsurugi Linux por padrão:
    Paper Process Injection Techniques and Detection using the Volatility Framework no vx-underground:

    Tem também pev no Arch Linux, Void Linux, vários tutoriais em português, inglês, chinês.. Em algum ponto eu até parei de monitorar. 😄 
    Neste ínterim, tive a oportunidade de aprender com programadores incírveis que puseram código no pev. Só para citar alguns: @jweyrich, @Jan Seidl, Marcelo Fleury, @fredericopissarra e muitos outros que não conseguiria nomear aqui (mas estão todos na lista de colaboradores do projeto no GitHub). Muito obrigado! 💚
    Muito tempo passou e muitos projetos livres similares surgiram, sendo o principal deles a pefile, que habilitou programadores e programadoras em Python a "parsear" binários PE facilmente. O mundo mudou, minhas prioridades mudaram, as prioridades dos colaboradores do pev mudaram também. Decidi então passar o bastão para quem tivesse interesse e em 28 de janeiro de 2022 comuniquei a comunidade que o projeto precisava de uma nova pessoa para mantê-lo. Surgiram algumas perguntas, alguns e-mails, até que em dezembro do mesmo ano, uma programadora da Alemanha entrou em contato informando do seu interesse em manter o projeto.
    Conversa vai, conversa vem e é isso. O pev tem uma nova mantenedora! 🥳
    Futuro 🔮
    A nova mantenedora usa o apelido GoGoOtaku. Embora eu não a conheça, ela se mostrou bastante confiável e corrigiu vários bugs no pev já. Penso que é quase mágico o fato de alguém, bem longe de mim física e socialmente, tenha encontrado o pev e tenha tido o interesse em mantê-lo. São coisas que só o software livre, aliado a linguagens universais como C, idiomas universais como o inglês, e redes sociais como o GitHub, conseguem realizar. Acho isso muito incrível! 🙌
    Em conversas com a nova mantenedora, expressei meu desejo que de o que pev voltasse a ser um programa só, mas com sub-comandos. Sugeri que usássemos o nome readpe, já que este é o programa mais usado do toolkit do pev e sugere um belo contraste com a ferramenta readelf do GNU Binutils. Ela gostou da ideia, afinal, o pev não tem mais nada a ver com “PE Version”. O mantenedor do pacote no Debian nos alertou  que mudar de nome é um processo delicado, especialmente porque o pev já é bastante conhecido, mas eu insisti. Minha ideia é que o readpe tenha sub-comandos que implementam a função dos programas separados hoje. Algo nessa linha:
    Exibir a ajuda:
    readpe help Imprimir os campos e valores dos cabeçalhos do PE (funcionalidade provida pelo readpe que seria dividida em sub-comandos):
    readpe headers <pefile>          # todos os cabeçalhos readpe headers dos <pefile>      # somente o cabeçalho do DOS Exibir strings no PE (funcionalidade provida pelo pestr, que viraria um sub-comando do readpe):
    readpe strings <pefile> # todas as strings readpe strings ascii -s <pefile> # somente strings ASCII exibindo as seções às quais elas pertencem readpe strings unicode <pefile> # somente strings UNICODE E por aí vai. Por hora, movi o pev para um repositório “embaixo” da Mente Binária, que chamei de readpe e dei todas as permissões para a nova mantenedora nele. Ela que vai decidir sobre o futuro do projeto. Talvez ela aceite minha sugestão de transformar o pev num único programa readpe. Talvez não. A mágica disso é que agora a decisão dela, afinal, filho a gente cria pro mundo e não pra gente né? 😄
    Estou muito feliz que o pev tenha encontrado uma nova mantenedora (que já lançou a versão 0.82 com várias correções de bugs!). E que ele tem ajudado pessoas interessadas em "parsear" PEs pelo mundo afora durante seus 13 anos de existência.
    Vou seguir acompanhando o projeto de perto e, quem sabe, até programando um pouquinho (se a nova mantenedora aceitar meus patches), mas acima de tudo, sou grato a todo mundo que contribuiu, usou e apoiou o pev durante todos esses anos. Ele continua sendo um dos poucos parsers livres de PE de linha de comando, multiplataforma, super versátil (com saídas em XML, JSON, HTML, etc), com recursos únicos (é o único livre que extrai certificados do PE, por exemplo) e claro, com raízes brasileiras. Foi o maior projeto de software livre da minha vida e eu continuo vibrando a cada commit que vejo nele. 😭
     
    Tempest Security Intelligence
    Introdução
    No vasto glossário de termos associados à segurança da informação o SOC - acrônimo em inglês para Centro de Operações de Segurança - talvez seja um dos mais mencionados, especialmente quando empresas se encontram diante de algum desafio relacionado com a proteção de sua estrutura.
    Afinal, os SOCs representam, no imaginário de muitos, a solução definitiva para as mais complexas questões relacionadas à cibersegurança; algo muito próximo a uma bala de prata que combina profissionais altamente treinados e tecnologia de ponta para criar uma barreira de proteção intransponível pelo mais competente dos adversários.
    E aqui começam os equívocos relacionados ao SOC. É verdade que os SOCs, quando bem estruturados e bem conduzidos, representam uma combinação dos pilares fundamentais da segurança: pessoas, processos e tecnologias. 
    No entanto, um SOC só é tão eficiente quanto a soma das suas partes. 
    Fatores que contribuem para seu sucesso incluem seu correto dimensionamento, decisões sobre quais tecnologias serão usadas, se haverá terceirização ou não de parte da operação e, principalmente, um conhecimento profundo do negócio por parte do time envolvido e a correta adequação do SOC à realidade da operação.
    Um SOC, no fim das contas, não é um plugin, um serviço “one size fits all”. 
    Tirar o máximo proveito deste tipo de estrutura depende em primeiríssimo lugar do entendimento do que é um SOC (e o que ele não é) e o que exatamente se espera dele.
    Neste post você conhecerá alguns conceitos básicos envolvendo o SOC.
    O que é e para que serve um SOC
    Em uma definição generalista, SOCs, ou Centros de Operações de Segurança, são estruturas centralizadas compostas de tecnologias, pessoas e processos com o objetivo de monitorar e incrementar a postura de segurança de uma organização de forma contínua. Suas atribuições gerais são: prevenir, detectar, analisar e responder a incidentes de segurança cibernética.
    Não é incomum os SOCs serem confundidos com monitoração de ameaça que é apenas um dos seus aspectos. Na verdade, o foco do SOC é mais amplo: a própria defesa do negócio. Segundo o diretor de MSS da Tempest, Renato Bezerra, “em uma operação bem sucedida do SOC não se quantifica apenas quantas ameaças foram detectadas, mas o quão eficazmente elas foram respondidas”.
    Tão importante quanto monitorar e detectar anomalias é saber o que fazer após a revelação de uma ameaça/incidente. O sucesso da operação de um SOC depende de quão ágil a operação é na contenção, mitigação e erradicação do incidente cibernético detectado.
    Elementos do SOC
    Nesse sentido, e de forma bastante resumida, os SOCs operam segundo uma série de disciplinas que incluem, como vimos, a monitoração, identificação e resposta a ameaças e incidentes. E estas disciplinas são executadas com base em três elementos: 
    Pessoas: A operação de um SOC depende de diferentes perfis de profissionais sem os quais os sistemas mais sofisticados não serão capazes de entregar os resultados esperados de um Centro de Operações de Segurança. Como visto, o exercício do SOC passa por monitorar, detectar e responder ameaças e, para isto, uma equipe multidisciplinar é essencial, desde profissionais especialistas em red team, blue team, até especialistas em cloud security, engenharia de detecção e engenharia de software, especialistas em resposta a incidentes e computação forense, inteligência de ameaças, entre outros.
    Processos: O funcionamento do SOC depende de processos pré-definidos que servirão de guia para os seus operadores. Tais processos definem que ações serão tomadas, seja na rotina seja em situações de incidente cibernético. Processos incluem rotinas de monitoramento de redes e assets, de vulnerabilidades, de logs, gerenciamento de dados sensíveis da empresa e de clientes, políticas e procedimentos de resposta a incidentes, entre outros.
    Tecnologias: a escolha das tecnologias dependerá da estrutura do negócio; mas além disso é fundamental que haja uma perfeita integração entre elas a fim de oferecer aos operadores uma visão completa dos riscos ao negócio. Algumas das tecnologias envolvidas em um SOC dizem respeito à segurança de estrutura e dados em nuvem, scanners de vulnerabilidade, firewalls, proteção de endpoints (EPP ou EDR) e de aplicações, entre outras.
    Funções do SOC
    O atual cenário de alta complexidade tecnológica coloca uma crescente gama de organizações diante da necessidade de contar com soluções de segurança integradas, capazes de lidar com desafios que envolvem desde a detecção precoce até a resposta efetiva e ágil a ameaças cibernéticas. 
    Nesse sentido, o SOC se apresenta como uma solução robusta que envolve duas funções básicas:
    Monitoramento e detecção de ameaças: Os SOCs contam com ferramentas e especialistas capazes de varrer a estrutura, buscando atividades suspeitas e rastreando vulnerabilidades que possam representar riscos ao negócio. Essa função envolve ainda o tratamento de um incidente dentro de parâmetros pré-estabelecidos, sua tratativa e mitigação, análise de malwares, etc.
    Resposta a incidentes: uma das principais funções de um SOC, responder a um eventual incidente de forma ágil e efetiva (contenção, mitigação, resposta e erradicação), é a garantia de que um ataque não se tornará um evento fatal para o negócio. Mais do que isso, a resposta a um incidente envolve a recuperação dos assets envolvidos para que a operação volte à normalidade. A cada resposta a incidente também é trabalho do SOC aprender e registrar os processos tomados durante todas as suas fases, a fim de que eles possam ser aplicados nas melhorias necessárias para que este incidente não se repita, pelo menos não com o mesmo impacto, fechando o ciclo de resposta.
    Um SOC não é um NOC (mas NOCs são importantes para os SOCs)
    Um equívoco que ainda é comum é a confusão entre os papéis de um SOC e de um NOC. Um SOC não é um NOC, no entanto um NOC tem papel importante na operação de um SOC.
    Enquanto o SOC se ocupa da monitoração, detecção e resposta a incidentes, NOCs, ou Centros de Operação de Rede, são estruturas pelas quais os administradores de TI supervisionam, monitoram e mantêm suas redes de comunicações, ou seja, as informações geradas por um NOC são integralmente consumidas por um SOC e podem determinar se um incidente está em curso ou não.
    Dimensionamento do SOC é uma decisão de negócios
    Como vimos, a operação de um SOC envolve uma combinação complexa de pessoas, processos e tecnologias e ao possibilitar essa combinação os SOCs surgem como um aliado poderoso tanto do ponto de vista tático – oferecendo o instrumental para enfrentar novas e mais complexas ameaças –  quanto do ponto de vista estratégico – possibilitando conectar a segurança da informação às prioridades e à visão estratégica da empresa. 
    E aqui chegamos a um ponto vital para o sucesso do SOC.
    Para ser realmente efetivo, o SOC deve ser dimensionado sempre de forma estratégica com foco no negócio. Os times envolvidos, a escolha das tecnologias e os processos que guiarão as operações precisam estar orientados pelo Mapa Estratégico e de Riscos da companhia, de modo que as prioridades dos seus projetos correspondam às prioridades do negócio.
    Refletir sobre isso é fundamental inclusive para a decisão sobre terceirização (ou não) das operações do SOC, em parte ou em sua totalidade.
    Quando terceirizar o SOC (ou partes dele)
    Como vimos, o dimensionamento de um SOC (as pessoas, processos e tecnologias que dele farão parte) é uma decisão de negócios. Passa por uma análise profunda do negócio, sua operação e deve ser guiado por seu Mapa Estratégico e de Riscos. 
    Inicialmente é preciso ter uma visão clara dos riscos ao negócio: seu tamanho, seu mercado, suas operações são cruciais para identificar quais os riscos a que ele está exposto. Um exemplo simples: a operação de uma padaria certamente não é tão complexa, do ponto de vista dos riscos de cibersegurança, quanto a operação de um grande escritório de advocacia. Essa reflexão é crucial para definir o escopo do SOC.
    Uma vez definido o escopo do SOC é possível identificar quais elementos poderão (ou mesmo preferencialmente serão) terceirizados e quais farão parte de uma operação interna - lembrando que não há uma resposta correta aqui, trata-se de uma decisão que depende da realidade do negócio.
    Em boa parte dos casos, o Orçamento é um fator determinante para essa decisão. Além das tecnologias necessárias para sua operação, os SOCs devem funcionar em um regime 24x7 operado por uma equipe multidisciplinar. Montar esse time depende de uma grande capacidade de retenção de profissionais (em um cenário de escassez de mão de obra especializada em segurança).
    A terceirização pode trazer uma série de vantagens como:
    Aumento na eficácia na detecção e resposta a incidentes: empresas que fornecem serviços terceirizados de SOC contam com profissionais altamente treinados e experientes nesta operação.
    Redução nos Custos: terceirizar parte ou a totalidade da operação significa evitar os custos envolvidos na manutenção do SOC
    Reduz a carga das equipes de segurança internas: se sua empresa já conta com um time de segurança, terceirizar a operação do SOC pode reduzir o tempo gasto com monitoração e gerenciamento de incidentes, permitindo seu time focar em outras tarefas. 
     Em contrapartida, montar uma estrutura de SOC internalizada em sua totalidade garante que a operação seja completamente voltada à realidade da corporação.
    Ter a real noção do dimensionamento do SOC, seus objetivos e a capacidade de investimento neste segmento tornará mais clara a resposta para o "quando (ou quanto) terceirizar".
    Conheça o Intelligence Driven SOC da Tempest
    A fim de ajudar as organizações a lidar com os desafios apresentados neste artigo, a Tempest desenvolveu o Intelligence Driven SOC, oferecendo às empresas a oportunidade de contar com um Centro de Operações de Segurança completo que combina, entre outras características: 
    Conexão com o mapa de riscos existente, trazendo contexto de negócio; A mais avançada Engenharia de Detecção de Ameaças, fornecendo  indicadores de cobertura através do mapeamento com base no MITRE ATT&CK™; Governança e acompanhamento com base em indicadores de desempenho ligados a casos de uso extraídos a partir da compreensão do mapa de riscos; A mais alta tecnologia e inteligência voltada para Cibersegurança, aliando equipe capacitada, plataforma de compartilhamento e bases de informação geolocalizadas.
    Para saber mais sobre o Intelligence Driven SOC baixe o ebook Um novo SOC para os novos desafios de segurança.
    Contar com o parceiro certo faz a diferença na proteção dos dados em qualquer ambiente
    A Tempest Security Intelligence é uma empresa brasileira com atuação global. É a maior companhia brasileira especializada em cibersegurança e prevenção a fraudes digitais. 
    Sediada no Recife, a Tempest conta também com escritórios em São Paulo e Londres, com mais de 600 colaboradores. 
    Ao longo de seus 23 anos, a Tempest ajudou a proteger mais de 600 empresas de todos os portes e setores, dentre elas companhias do setor financeiro, varejo, e-commerce, indústria e healthcare, atuando em clientes nacionais e internacionais atendidos tanto pelo time no Brasil quanto no Reino Unido. 
    Em 2020, a Tempest conquistou um parceiro de peso para continuar na vanguarda da cibersegurança, recebendo um grande aporte da Embraer, companhia brasileira de engenharia aeroespacial, o qual resultou em um dos maiores investimentos já realizados na história do setor de cibersegurança na América Latina.
    vrechson

    Segurança de sistemas OAuth 2.0

    By vrechson, in Tudo,

    Você acessa o portal mente binária e, ao invés de preencher aqueles formulários gigantescos de login apenas pressiona logar-se com a sua conta Google. Escolhe seu nome de usuário e, sem inserir nenhuma senha ou outra informação você está logado na plataforma. A tecnologia utilizada para essa integração geralmente é o padrão OAuth 2.0, que permite que uma aplicação tenha acesso a alguns dados de um usuário registrado em sistemas terceiros, como o Google, sem a necessidade de conhecer as credenciais desse usuário.
    É justamente essa possibilidade de não compartilhar credenciais para obter acesso à informação que contribui para a popularização da tecnologia. Imagine ter acesso a todas as informações necessárias do usuário e deixar que plataformas muito mais consolidadas cuidem da autorização, parece um caminho muito mais seguro, né?
    A resposta é: depende. Como tudo na área de tecnologia, é muito importante configurar as soluções a serem utilizadas de maneira correta para evitar problemas que coloquem em risco a segurança da aplicação. Para entender alguns dos problemas que podem resultar de uma configuração insegura deste protocolo, vamos dar um passo atrás e entender como essa tecnologia funciona. Caso queira dar mais um passo para trás e ler um pouco sobre autenticação primeiro, aqui mesmo na Mente Binária tem o artigo Autenticação e Ataques Relacionados, do @Andre Smaira.
    Conhecendo o protocolo OAuth 2.0
    OAuth 2.0 é um protocolo de autorização que permite não só o compartilhamento de dados com aplicações de terceiros mas também o controle de quais informações serão compartilhadas. Dessa forma, após o usuário conceder a uma aplicação (como o portal Mente Binária) algumas de suas informações (nesse caso, as disponíveis em sua conta Google), é possível interagir com o portal sem a necessidade de se autenticar na aplicação.
    A figura a seguir demonstra uma visão geral de como esse processo acontece, conforme apresentada na RFC 6749:

    Na figura acima, é possível perceber a existência de três agentes no funcionamento desse protocolo:
    O cliente (Client). Representado em cinza na figura, representa a Mente Binária ou a aplicação que estamos utilizando, e que deseja utilizar mais informações do usuário. O usuário que possui os dados (Resource Owner). Esse é você, que possui o poder de compartilhar ou não as suas informações. A aplicação que possui seus dados (Authorization Server e Resource Server). Embora em alguns casos a aplicação tenha um sistema de autenticação separado do servidor que possui esses dados (por isso a divisão na imagem), é essa aplicação que possui a informação que será compartilhada através do protocolo OAuth 2.0. Embora essa imagem represente bem como essa comunicação ocorre de maneira geral, deixa um pouco a desejar em caráter mais técnico, visto que abstrai demais o funcionamento do protocolo. Inspirado no excelente artigo da Salt Labs sobre o tema, construí a seguinte imagem para auxiliar no entendimento do processo:

    A primeira etapa ocorre quando o usuário Breno decide se cadastrar ou se autenticar no site (caso já esteja cadastrado). O site, no entanto, necessita de uma prova de que Breno é quem diz ser, e pede para que ele solicite ao Google um token aleatório que o identifique na aplicação OAuth 2.0. Isso ocorre no momento em que o usuário pressiona o botão, quando uma nova janela é aberta com uma URL análoga à seguinte:
    https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?access_type=offline&client_id=152067940327-ma5q9tjenci55tfs3mck9fe7npphvek4.apps.googleusercontent.com&response_type=code&redirect_uri=https%3A%2F%2Fwww.mentebinaria.com.br%2Foauth%2Fcallback%2F&state=STATE&code_challenge=CODE_CHALLENGE&code_challenge_method=CODE_CHALLENGE_METHOD&scope=profile%20email&service=lso&o2v=2&flowName=GeneralOAuthFlow Nessa URL, alguns valores são essenciais para o funcionamento do OAuth:
    client_id: Este parâmetro identifica o cliente que solicita a informação. Na URL compartilhada, esse valor corresponde ao identificador atrelado ao portal Mente Binária. response_type: Define o conteúdo que será retornado na resposta. Esse valor é relevante para sabermos quais problemas de segurança podem ocorrer na aplicação. redirect_uri: Após a autenticação, o token gerado será enviado por meio de um redirecionamento à página informada neste parâmetro. A forma como essa página é configurada também é relevante para a segurança da aplicação. state: Salva um estado da aplicação. Geralmente é usado como uma medida de segurança secundária. Dessa forma, se um token é devolvido à aplicação com um estado que não é conhecido por ela, ela pode considerar que algo de errado aconteceu e interromper o processo sem obter as informações do usuário. scope: Este campo especifica quais informações serão compartilhadas através do protocolo OAuth. Após se autenticar e autorizar a aplicação a obter acesso a essa página, o usuário recebe um código complexo (etapas 3 e 4), identificado como authorization grant na primeira figura. Esse valor é então enviado diretamente à Google pela aplicação, que valida o usuário e as permissões aos quais esse token está atrelado, retornando esses dados a aplicação solicitante (etapas 6 e 7).
    Após todo esse processo, a aplicação pode atrelar esse valores à sessão do usuário e até armazená-los no banco de dados, possibilitando a autenticação de um visitante na página sem a necessidade de digitar, ou até mesmo possuir, uma senha para a aplicação.
    Problemas de segurança associados ao uso de OAuth 2.0
    A ideia é muito boa, mas deve ser implementada com cuidado, visto que a utilização errada da aplicação pode levar a graves incidentes de segurança. A seguir, eu listo alguns problemas associado ao uso ou configuração insegura da tecnologia.
    Pre-account Takeover
    Embora a prática de se utilizar o OAuth para se autenticar nas aplicações tenha se difundido, ela raramente substitui por completo a existência de uma autenticação oferecida pela aplicação. Dessa forma, é preciso dobrar também a cautela durante a implementação. A imagem a seguir demonstra como o portal Mente Binária permite ambas as formas de se registrar:

    O aumento na complexidade de uma aplicação também resulta em mais cuidados de segurança. Para este cenário, suponha que você se registrou no portal utilizando o e-mail de um conhecido, que ainda não se registrou no ambiente, usando uma senha de sua escolha. No entanto, como você não tem acesso ao conteúdo do endereço de e-mail, você é incapaz de confirmar a identidade (através do recurso de confirmação de e-mail) e começar a utilizar a plataforma. Caso a aplicação não tenha sido configurada de maneira correta, como demonstra esse report da HackerOne, se a vítima um dia decidir se autenticar no ambiente utilizando o OAuth como opção, o ambiente automaticamente irá validar o acesso criado usando o endereço de email, possibilitando que o atacante consiga acessar a conta da vítima através da senha que foi previamente configurada. Portanto, é necessário sempre ter atenção sobre as diferenças e implicações dos dois mecanismos paralelos de registro e autenticação na plataforma para garantir que o ambiente fique realmente seguro.
    Open Redirects
    Outro fator que pode levar a diversos problemas de segurança na aplicação é a configuração insegura das validações do parâmetro redirect_uri. Conforme comentado durante a explicação do protocolo, após se registrar com sucesso na aplicação, o usuário é redirecionado para a página presente neste parâmetro e, junto com esse redirecionamento, o token de acesso é enviado através do fragmento de hash presente na URL.
    Se não houver validações suficientemente seguras desse parâmetro, um atacante pode enviar à vítima um link da página de login OAuth porém substituindo o conteúdo do parâmetro por um endereço controlado pelo atacante. Dessa forma, ao realizar o login, o token de authorization grant será enviado à uma página controlada pelo atacante e não à página que espera este parâmetro na aplicação. Este cenário pode ser observado nesse report. É preciso se atentar também ao fato de que, mesmo que haja validação do domínio da URL no parâmetro, o diretório para o qual essa URL aponta também deve ser validado, visto que se a página possuir um open redirect em algum outro diretório, um atacante poderá abusar desse comportamento para substituir o parâmetro para uma página em que ele é capaz de forçar um redirecionamento e, assim, obter também acesso ao conteúdo do token. O artigo da Salt Labs mencionando anteriormente demonstra de maneira muito bem explicada como esse ataque pôde ser realizado na aplicação do Booking. Já neste outro report da HackerOne, é possível visualizar que permitir o uso de outros subdomínios do site principal nesse parâmetro também pode facilitar que um atacante encontre e abuse de um open redirect para roubar tokens válidos no ambiente. Por fim, neste report super bem explicado, outro membro do ELT, @caioluders (twitter.com/caioluders), demonstra como é preciso estar atento a forma como essa validação é feita, para que o atacante não encontre uma forma de evadir esse mecanismo de segurança.
    Leakando a URL
    Mesmo que não haja possibilidade de se obter o token de acesso através do abuso do parâmetro redirect_uri, um atacante pode encontrar outras formas de obtê-lo diretamente através da URL. Neste report, por exemplo, o pesquisador utilizou do próprio design da aplicação para roubar tokens, visto que um usuário poderia criar uma página com seu próprio Google Analytics, que registra o conteúdo da página. Vale lembrar que, conforme descrito durante a explicação do protocolo, embora muitas vezes esse token tenha funcionamento único, o atacante pode utilizar um valor que não será aceito como parâmetro state. Dessa forma, ao receber o token, a aplicação tentará validar seu estado e o recusará devido ao valor inesperado. Assim, o atacante será capaz de, através do meio encontrado para vazar esse valor, utilizá-lo de maneira válida.
    PostMessage
    Versões mais recentes do OAuth 2.0 utilizam o método postMessage() como uma forma considerada segura de realizar o envio e recebimento dos tokens de uma aplicação. Neste report, um pesquisador demonstra que se deve tomar cuidado ao se designar a qual página será enviado o token obtido pelo OAuth. Ainda no mesmo report, o pesquisador percebe que o token é sempre enviado ao opener desse endereço e abusa desse comportamento genérico para tornar sua página o opener através da chamada windows.open() para o endereço vulnerável.
    Além disso, Frans Rosén escreveu um excelente artigo sobre como alguns métodos postMessage() de bibliotecas de terceiros podem resultar no vazamento do token OAuth.
    Cookie Bomb
    Esta é uma vulnerabilidade que ocorre quando o atacante descobre uma forma de inserir cookies arbitrários no navegador de um usuário. Dessa forma, um atacante é capaz de inserir cookies muito grandes para um usuário, resultando em uma negação de serviço temporária deste usuário à aplicação devido ao envio de um conteúdo muito grande nas requisições. Nesta publicação, o pesquisador filedescriptor discute como essa vulnerabilidade pode ser abusada através de um XSS para impedir que a página presente no parâmetro redirect_uri de uma autenticação OAuth seja acessada e, dessa forma, o atacante possa obter acesso a esse token através do XSS, visto que o cookie bomb impediu o uso do token pela aplicação.
    Para se aprofundar mais
    Para ir além no assunto, veja esse artigo de um pesquisador contando como explorou o OAuth do facebook para conseguir roubar contas de usuários e confira também os write-ups de exploração de vulnerabilidades em OAuth neste repositório no GitHub. 😉
     
    Tempest Security Intelligence
    Seja para tornar suas operações mais eficientes, seja para atender novas demandas de clientes ou fornecedores,, a adoção de novas tecnologias pelas organizações, acelerada nos últimos 3 anos, colaborou para o aumento da complexidade do ambiente corporativo. 
    Dentre as muitas consequências destes processos - que incluem a migração de processos e aplicações para a nuvem, adoção de novos regimes de trabalho, entre outros -  destacam-se o aumento sem precedentes das fronteiras do negócio e a dificuldade de se obter visibilidade absoluta dos riscos a que ele está exposto. 
    Esta visibilidade depende, entre outras coisas, de saber que dispositivos estão conectados ao ambiente e quais os riscos a que estes dispositivos estão expostos, além de saber quais vulnerabilidades estão afetando minha estrutura, que dados estão trafegando, etc. 
    Neste cenário, os serviços de consultoria de segurança (security consulting), mais especificamente o Pentest, ajudam as empresas a identificar vulnerabilidades em seus sistemas e aplicativos que podem ser exploradas por cibercriminosos, sejam elas brechas na segurança da rede, erros de configuração, falhas de software, entre tantas outras. 
    Mas nem todo pentest é igual; existem inúmeras aplicações para estes testes, e para ajudar as empresas a encontrar a solução ideal para cada caso a Tempest desenvolveu o Guia do Comprador de Pentest.
    Pentest, ou Teste de Intrusão: o que é e como escolher o melhor para cada situação
    Pentest, ou teste de intrusão, consiste em simular um ataque em uma rede, aplicação ou sistema para identificar vulnerabilidades e avaliar a efetividade das medidas de segurança existentes na organização, permitindo que as empresas aprimorem suas estratégias e garantam maior visibilidade no que estão protegendo.
    Eles são de extrema utilidade seja para avaliar o compliance de uma empresa frente a regras de mercado ou regulamentações, seja para avaliar se um software ou aplicação está sendo desenvolvido com segurança.
    Porém, há muitos tipos de pentest no mercado de diferentes fornecedores, cada um com um escopo e descrição, proporcionando ao comprador diversas possibilidades de escolha. Neste cenário, é preciso avaliar um conjunto de recursos para poder qualificar uma solução aderente ao negócio.
    No Guia do Comprador de Pentest da Tempest você conhece melhor cada um dos tipos de pentest disponíveis atualmente, também tem acesso a uma série de dicas e conhece os seis elementos essenciais que irão ajudar a avaliar um fornecedor  para encontrar a solução mais adequada para sua situação.
    Faça o download do Guia
    Diferenciais do Pentest da Tempest
    Com início das operações em 2001, o Pentest da Tempest conta com a experiência e conhecimento do maior time técnico da América Latina  (SOC, Threat Hunting, Incident Response, Software Engineering, Red Team,  Vulnerability Management e  Threat Intelligence) para entregar um serviço de alta profundidade, com resultados robustos, tecnicamente sofisticados e efetivamente aderentes  aos desafios e necessidades dos nossos clientes. 
    Toda essa expertise é aplicada a diversas modalidades de pentest que incluem testes aplicados a aplicações web, dispositivos IoT, redes wi-fi ou até mesmo testes de estruturas físicas.
    Contar com o parceiro certo faz a diferença na proteção dos dados em qualquer ambiente
    A Tempest Security Intelligence é uma empresa brasileira com atuação global. É a maior companhia brasileira especializada em cibersegurança e prevenção a fraudes digitais. Sediada no Recife, a Tempest conta também com escritórios em São Paulo e Londres, com mais de 600 colaboradores. 
    Ao longo de seus 23 anos, a Tempest ajudou a proteger mais de 600 empresas de todos os portes e setores, dentre elas companhias do setor financeiro, varejo, e-commerce, indústria e healthcare, atuando em clientes nacionais e internacionais atendidos tanto pelo time no Brasil quanto no Reino Unido. 
    Em 2020, a Tempest conquistou um parceiro de peso para continuar na vanguarda da cibersegurança, recebendo um grande aporte da Embraer, companhia brasileira de engenharia aeroespacial, o qual resultou em um dos maiores investimentos já realizados na história do setor de cibersegurança na América Latina.
    Chinchila

    Criptografia de curvas elípticas

    By Chinchila, in Tudo,

    Neste artigo vamos descrever como funciona a criptografia de curvas elípticas. Para isso é preciso saber como funciona aritmética modular. O artigo Introdução ao RSA, do @c4v0k, tem tudo que precisamos saber, então dá um pulo lá se não entender muito sobre a operação mod. Ao invés de estudar como implementar um esquema de curvas elípticas de forma segura e sua matemática por trás, vamos entender neste artigo a essência do assunto. 🙂
    Curvas Elípticas
    Uma curva elíptica é definida por uma equação cúbica. Exemplos de curvas incluem Weierstrass, Montgomery e Edwards. Essas três têm uma relação chamada equivalência birracional, então existe uma forma de transformar uma curva e todas as suas propriedades de um tipo para outro. Vamos usar a curva de Weierstrass na forma curta como exemplo pois é a mais simples de entender. A equação da curva é definida como:
    y² = x³ + ax + b
    Ao plotar a curva no plano cartesiano com a = -2 e b = 4, temos esse gráfico:

    Curva definida pela equação y² = x³ - 2x + 4
    Um grupo, em matemática, é uma estrutura algébrica que tem uma operação binária (no sentido de dois operadores). Nossa curva vai ser um grupo, então precisamos definir uma operação nela: a operação de soma. Peguemos dois pontos A e B da curva, totalmente aleatórios. Se traçarmos uma reta entre esses dois pontos, teremos um terceiro ponto que a reta vai cruzar. Esse terceiro ponto vai ser o espelho (no eixo x) do ponto que representa A + B. Veja a imagem para entender melhor:

    Soma dos pontos A e B
    Se repetirmos essa operação de soma com pontos da curva várias vezes, sempre teremos um ponto diferente como resultado. Mas, e se acontecer de aleatoriamente termos os pontos A e B iguais, como fica a soma de A + A? Para resolver essa soma, traçamos a reta tangente ao ponto A e o segundo ponto que a reta tocar na curva será o espelho de A + A:

    Duplicação de um ponto A
    Achou complicado esse negócio de tangente? Na verdade, é só imaginar que o ponto B está muito pertinho do ponto A, então a operação de soma acaba sendo a mesma essencialmente, só o cálculo dela que muda. Para terminar a definição do grupo na nossa curva, precisamos também de um inverso da soma. Vamos chamar de "menos" com o sinal "-", então o ponto -A será o inverso do ponto A. O inverso é mais tranquilo: só espelhar o ponto na coordenada x, logo se o ponto A é (x, y) o ponto -A é (x, -y).
    Para facilitar a notação, quando somarmos dois pontos iguais, vamos chamar de 2A. Assim, se somarmos mais um A, teremos 3A e assim sucessivamente. Imagine agora que somemos A "n" vezes. Cada vez que a gente soma A, o resultado é um ponto diferente na nossa curva, logo seria complicado sabermos quantas vezes somamos A. Nosso "n" pode ser então um segredo, já que é difícil descobri-lo. Olhe a imagem abaixo e tente descobrir o "n":

    Tente descobrir o valor de "n" na imagem
    Só de olhar a imagem é difícil saber né? Eu sei que "n" é 17 porque fui eu que escolhi esse número. Mas quem vê de fora não descobre sem eu contar. Logo, "n" vai será a chave privada da nossa criptografia e "nA" será a chave pública. Mas tem um problema aí: se usarmos ponto flutuante, vai acabar acumulando erros na hora de somar todas essas vezes. Por isso, vamos tirar o mod de um primo p grandão, aí nossa equação da curva vai ficar assim:
    y² = x³ + ax + b mod p
    Com esse mod p grandão, teremos muitos pontos possíveis para somar! Eu garanto que a operação de soma e inverso funcionam muito bem nessa equação também. Além disso, será melhor para armazenar nossas chaves, pois todos os números são inteiros e conseguimos representá-los sem precisar de bits extras de precisão.
    Um outro problema...
    Imagina que eu escolha o número 17 para minha chave privada. Seria muito fácil qualquer um encontrá-la... Só tentar 1, 2, 3… até 17. Então, como p é um número grande, também podemos escolher nossa chave privada como um número grande, deixando-a mais difícil de ser descoberta! Vamos supor que o número tenha 256 bits, isso dá 78 dígitos. Para calcular nossa chave privada vamos precisar somar A o mesmo número de vezes que alguém que quer descobrir nossa chave precisa. Então, precisamos pensar numa forma de somar A "n" vezes rápido.
    Lembra quando eu falei de grupo na matemática? Então, além da definição de soma, também temos as seguintes leis neste grupo:
    Quando somamos qualquer dois pontos A + B = C, então C sempre vai estar no grupo também. O grupo tem associatividade, ou seja, a soma (A + B) + C para quaisquer pontos vai ser igual a A + (B + C). Existe um elemento neutro O, de forma que A - A = O. Provar que isso é verdade para curvas elípticas é um pouco complicado, no entanto. Se quiser saber mais sobre, veja no livro "Introdução à Criptografia com Curvas Elípticas", na seção 4.1.2, escrito por Sally Andria, Rodrigo Gondim e Rodrigo Salomão e publicado pelo IMPA.
    Tá bom, mas o que isso tem a ver com somar A "n" vezes rápido? Bom, por causa dessa associatividade, A + 3A é igual a 2A + 2A. Então dá para representar nosso "n" em binário e aí duplicamos o ponto A várias vezes. Isso vai trocar a complexidade do problema para quantos bits o "n" tem e não para quanto ele vale em decimal. Vamos ver um exemplo com "n" sendo 315. A representação desse número em binário é 100111011, nessa tabela abaixo podemos ver as potências de 2 referente a cada posição:
     

    Então podemos somar A 315 vezes como se fosse dessa forma:
    28A + 25A + 24A + 23A + 21A + 20A
    Com isso, vamos usar bem menos operações que 315.
    Já sobre o elemento neutro O, imagine o que acontece quando somamos um ponto com o inverso dele, ou seja A + (-A). Ao traçar a reta entre esses dois pontos, teremos uma reta vertical, ou seja, paralela ao eixo y e que não corta a curva em nenhum outro ponto. Existe uma outra lei da geometria projetiva, aliás essa é a geometria que a gente tá vendo aqui, que diz que duas retas paralelas se encontram no infinito. Dito isso, vamos chamar esse ponto O de ponto no infinito e ele sempre será o elemento neutro, como o 0 (zero) na soma ou o 1 (um) na multiplicação.

    A representado na nossa curva definida anteriormente
    Troca de chaves
    Um dos principais usos da criptografia de curvas elípticas é na troca de chaves. No protocolo TLS, a primeira coisa que acontece, criptograficamente falando (na maioria das vezes) é uma troca de chaves antes de o protocolo prosseguir com um esquema de criptografia simétrica para troca de dados segura entre o servidor e o cliente. Veremos agora como funciona um esquema de troca de chaves aplicável a qualquer grupo matemático. O esquema se chama Diffie-Hellman.
    Vamos pensar em duas pessoas que querem ter uma chave secreta em comum. Chamaremo-os de Aline e Bernardo. Aline vai criar uma chave privada "n" e Bernardo vai criar uma chave privada "m", então os dois vão estabelecer um ponto de partida, que é o ponto A que vimos anteriormente. Já que os dois têm um mesmo ponto de partida, eles podem enviar a chave pública um para o outro, então Aline vai enviar "nA" para Bernardo e Bernardo envia "mA" para Aline. Já que os dois possuem as chaves públicas, então eles podem chegar em um acordo de chave multiplicando a chave privada na chave recebida.
    Aline recebe "mA" e soma esse ponto "n" vezes, então ela vai ter "nmA". Já Bernardo recebe "nA" e soma esse ponto "m" vezes, então ele vai ter "nmA". A chave compartilhada vai ser "nmA" e eles podem seguir um canal secreto de comunicação. Veja a imagem para tentar entender melhor, nela eu usei "n" igual a 5 e "m" igual a 3.

    Esquema Diffie-Hellman de troca de chaves, usando ECC
    Criptografia
    O mais comum de se ver no dia a dia, entre duas entidades, é primeiro um esquema de troca de chaves e depois a troca de dados por meio de um esquema simétrico de criptografia, como por exemplo o AES. Mesmo assim, veremos na prática um esquema um pouco diferente que não depende da troca de chaves. Esse esquema chama-se El Gamal. Aline e Bernardo serão os protagonistas de novo. 🙂
    Aline será a pessoa que receberá a mensagem de Bernardo. Então ela precisa enviar a chave pública para Bernardo encriptar a mensagem que ele quer enviar, logo, Aline cria uma chave privada "n" e uma chave pública "P = nA". Ela envia a chave pública e o ponto de partida A para Bernardo. Bernardo tem uma mensagem "M" que quer enviar para Aline, então precisará gerar um número aleatório "k" e criar a sua própria chave "K = kA". Não só isso, Bernardo também vai enviar "C = kP + M" para Aline. Quando Alice receber esses dois pontos (C, K), basta que ela compute "C - nK" para recuperar a mensagem. Veja a imagem com a prova para tentar entender melhor:

    Esquema Elgamal de criptografia usando ECC
    Se gostou desse assunto você pode ver meu writeup de um desafio de CTF que envolve curvas elípticas. O CryptoHack também é um ótimo site para aprender sobre criptografia de curva elíptica (ECC, no acrônimo em inglês). Bons estudos!
    b4ct3r14

    Abuso de fluxo de dados alternativos (ADS)

    By b4ct3r14, in Tudo,

    Prefácio
    Este artigo abordará um recurso do sistema de arquivos NTFS, muito pouco conhecido e mal documentado, que leva o nome de Alternate Data Stream ou simplesmente ADS. O artigo apresenta conceitos, usos, formas de identificação e maneiras de lapidar a técnica. Embora essa técnica de ocultação de cargas maliciosas em sistemas de arquivos seja considerada antiga, seu uso ainda é muito relevante nos dias atuais.
    O que é Alternate Data Stream (ADS)?
    O Alternate Data Stream (ADS) é um recurso do sistema de arquivos NTFS, implementado pela primeira vez no Windows NT 3.1, com o intuito de permitir a compatibilidade com os sistemas de arquivos MAC HFS (Macintosh Hierarchical File System). De maneira sucinta, esse recurso permite que os arquivos contenham mais de um fluxo de dados. 
    Os arquivos em NTFS têm ao menos um fluxo de dados visível. Em ambientes Windows, esse fluxo de dados padrão é chamado de atributo MFT :$DATA ou fluxo de dados sem nome.
    Experimentação
    Para entendermos melhor como funciona esse fluxo de dados, vamos abrir o Prompt de Comando para fazer alguns testes. Primeiramente, vamos começar criando um arquivo de texto com a string Mente Binária:

    Observe o tamanho do arquivo gerado. Como segundo passo, vamos inserir um segundo fluxo de dados dentro desse arquivo:

    Note que ao realizar o processo de listagem, o arquivo mentbin.txt permanece com 18 bytes, não sendo possível notar qualquer diferença aparente. Para verificar a existência de um ADS precisamos utilizar da flag /r para exibir o fluxo de dados alternados, como help do programa sugere:

    Agora sim parece que acendemos a luz e conseguimos ver o hf.txt  dentro do arquivo mentbin.txt:

    Ao abrir o arquivo com o Bloco de Notas, com o comando type ou Windows Explorer apenas o fluxo de dados principal é exibido em tela. 
    Para ler o conteúdo de um fluxo, podemos utilizar os comandos more ou sort:

    Caso de uso
    Mas agora surge a pergunta, porque bulhufas isso é utilizado? Bom, acredito que conseguimos responder essa pergunta com uma demonstração prática. Quando baixamos arquivos da internet usando um browser por exemplo é criado um $DATA para identificar de onde esse arquivo foi baixado.
    Demonstração
    Vamos baixar a imagem do gatinho do post de Detectando overlays em executáveis ELF do @Fernando Mercês:

    Salvamos a imagem:


    Só pra garantir, verificamos o tipo de arquivo com o comando file:

    Ao listar os arquivos com dir /r, é possível ver a existência de um ADS chamado Zone.Identifier:

    Verificando seu conteúdo conseguimos extrair a informação de onde essa imagem foi baixada. Legal né?

    Ocultando binários no fluxo de dados
    Com esse recurso podemos esconder qualquer tipo de dado usando o ADS, então que tal começarmos escondendo o binário da calculadora? Analise:

    Utilizando do wmic vamos executar o binário oculto.
    A ferramenta Windows Management Instrumentation Command-line (WMIC) é uma interface de script e linha de comando que simplifica o uso do Windows Management Instrumentation (WMI) e dos sistemas gerenciados através do WMI. Embora no site da Microsoft exista um aviso informando que esse recurso foi preterido a partir do Windows 10 versão 21H1, sendo substituído pelo utilitário Windows PowerShell para WMI, ele continua presente em versões mais atuais do sistema. Vamos usá-lo:

    calc.mp4 Mágicaaaaaa! 🪄
    Relevância Forense 
    Do ponto de vista forense, os fluxos de dados alternativos do NTFS têm implicações graves para a anti-forense, uma vez que invasores podem ocultar arquivos incriminadores ou cargas maliciosas por meio de fluxos de dados ocultos em outros arquivos além da possibilidade de utilizar dessa técnica para exfiltração de dados. Demonstrarei agora como é feito o processo de identificação.
    Identificação
    Como mencionado no prefácio, essa técnica de esconder dados usando ADS já é bem manjada, de modo que o Windows Defender e vários antivírus já conseguem fazer esse mapeamento. Além disso,  um administrador de sistemas ou um analista forense poderiam facilmente achar esses arquivos usando simples linhas de comando. Por exemplo:

    Explicação da sintaxe
    % implementa um foreach ? coloca uma condição where gi forma curta de Get-Item gci forma curta Get-Childitem ne Not Equal (Não é Igual) Lapidando a técnica
    E se eu te falar que existe uma forma de lapidar essa técnica dificultando sua identificação, com o uso de nomes reservados no Windows? 🙂
    Alguns nomes de uso reservado no Windows são: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LP6, LPT7, LPT8 e LPT9.
    Vamos olhar o que acontece quando tentamos criar qualquer tipo de arquivo, usando algum desses nomes reservados:

    O arquivo não é criado. 😟
    Pulo do 🐈 
    Existe uma forma de realizar o bypass da verificação de nomes reservados. Utilizando os prefixos "\\?\" ou "\\.\"  é possível informar às APIs do Windows para desabilitar toda a análise de cadeia de caracteres enviado a cadeia que a segue diretamente para o sistema de arquivo possibilitando dessa forma criar arquivos com esses nomes.
    Demonstração

    Opa, opa, olha só, conseguimos criar o arquivo.
    Agora vamos analisar o que acontece quando colocamos um fluxo de dados dentro de um arquivo com nome reservado.

    Espera ai, cadê o ADS do arquivo COM.TXT?

    Esse é o pulo do gato, o Windows não consegue mais detectar o ADS do arquivo, apenas quem criou o arquivo e sabe o nome pode ver/executar seu conteúdo.

    Olha o que acontece quando tentamos buscar por esse arquivo usando os comandos demonstrados anteriormente:

    Observação
    Existe uma única solução chamada LADS que consegue identificar o fluxo de arquivo em nomes reservados, no entanto essa ferramenta não recebe mais atualização desde 2015.

    Referências
    https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file https://www.sans.org/blog/alternate-data-streams-overview/ https://owasp.org/www-community/attacks/Windows_alternate_data_stream https://www.deepinstinct.com/blog/the-abuse-of-alternate-data-stream-hasnt-disappeared https://github.com/codejanus/ToolSuite/blob/master/lads.exe
    paulosgf

    Flags de Depuração: NtGlobalFlag

    By paulosgf, in Reverse Engineering,

    Introdução 
    Olá pessoal! Este é mais um artigo da série onde falo sobre técnicas de anti-engenharia reversa. Neles compartilho um pouco dos tutoriais práticos que desenvolvi ao longo das minhas pesquisas e estudos. No primeiro artigo, falei sobre a categoria de anti-debugging TLS Callback. Agora vou falar um pouco sobre as técnicas da categoria que utilizam flags de depuração do próprio processo para detectar o debugger. Antes de mais nada, vale entender o que são essas flags. 
     
    O que são flags de depuração?
    Estas flags são valores presentes dentro do espaço de endereço do processo, permanecendo na memória até o encerramento deste programa. A presença e/ou determinado valor destes bits podem indicar que o processo está em um ambiente de depurador. Como estas técnicas são válidas apenas para o ambiente Windows, seu significado e valores são definidos na documentação oficial do SO (WinAPI) [1], entretanto algumas flags podem não ser documentadas e, neste caso, somente se encontra informação em livros como o Windows Internals [2].
    A primeira que vamos analisar é a NtGlobalFlag, desenvolvida na época do antigo Windows NT. Esta flag é definida no cabeçalho do Process Environment Block (PEB) de todos processos no sistema e é usada especificamente para indicar se o processo está executando ou não em depurador.
    Antes de aprofundar nas particularidades desta flag, precisamos entender o que é a PEB, que foi citada anteriormente. De forma resumida, é uma estrutura que existe em cada processo do Windows e é apontada por outra estrutura chamada TEB (Thread Environment Block), que por sua vez contém informações em relação às threads do processo.
    O código da PEB é composto por uma struct e sua versão para 32 bits no header windows.h ou winternl.h é a seguinte:
    typedef struct _PEB {    BYTE                          Reserved1[2];    BYTE                          BeingDebugged;    BYTE                          Reserved2[1];    PVOID                         Reserved3[2];    PPEB_LDR_DATA          Ldr;    PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;    PVOID                         Reserved4[3];    PVOID                         AtlThunkSListPtr;    PVOID                         Reserved5;    ULONG                         Reserved6;    PVOID                         Reserved7;    ULONG                         Reserved8;    ULONG                         AtlThunkSListPtr32;    PVOID                         Reserved9[45];    BYTE                          Reserved10[96];    PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;    BYTE                          Reserved11[128];    PVOID                         Reserved12[1];    ULONG                         SessionId;  } PEB, *PPEB; *O 3º byte desta estrutura é o campo BeingDebugged e este é definido pelo Windows para todo binário que está sendo executado, sendo 0 (padrão) para indicar que o processo não está sendo depurado e 1 para depurado. Este byte é avaliado na técnica abordada no Curso de Engenharia Reversa Online (CERO) através da função IsDebuggerPresent() e por conta disto esta técnica não será abordada neste artigo.
    A Aula 24 - Anti-debug, do CERO, aborda a PEB de forma prática. Uma referência completa sobre a PEB também pode ser acessada em [3].
    NtGlobalFlag
    Esta flag também é um campo da PEB e se encontra no offset 0x68 em ambientes 32 bits, ou offset 0xBC em 64 bits, contados a partir do seu início. Esta flag é usada para rastreamento e depuração de programas. Seu valor é 0 por padrão, indicando que não há depurador no ambiente.
    Caso se inicie o programa primeiro e depois de já iniciado, se analise seu processo no depurador, os campos da NtGlobalFlag não são alterados, deixando esta abordagem sem efeito. No entanto, caso se execute o programa diretamente  em um depurador, as seguintes flags serão definidas:    
    FLG_HEAP_ENABLE_TAIL_CHECK    (0x10)     FLG_HEAP_ENABLE_FREE_CHECK    (0x20)     FLG_HEAP_VALIDATE_PARAMETERS  (0x40)  
    A presença de um depurador no ambiente é confirmada ao se verificar o valor 0x70 resultante da operação OR entre estas flags.
    Disassemble de processo 32 Bits:
    mov eax, fs:[30h]     // acessa a PEB no registrador de segmento mov al, [eax+68h]    // a partir da PEB acessa a flag NtGlobalFlag and al, 70h           // soma as flags FLG_HEAP_* cmp al, 70h           // verifica se o valor da soma é 0x70 call  being_debugged  // caso positivo, avisa sobre depuração  
    Disassemble de processo 64 Bits:
    mov rax, gs:[60h]     // acessa a PEB no registrador de segmento mov al, [rax+BCh]     // a partir da PEB acessa a flag NtGlobalFlag and al, 70h cmp al, 70h call  being_debugged Disassemble de processo WOW64 (64 Bits que aceita também 32 bits):
    mov eax, fs:[30h]     // acessa a PEB no registrador de segmento mov al, [eax+10BCh]   // a partir da PEB acessa a flag NtGlobalFlag and al, 70h cmp al, 70h call  being_debugged  
    Código de exemplo:
    #include <windows.h> #include <iostream> using namespace std; // define o valor das flags #define FLG_HEAP_ENABLE_TAIL_CHECK   0x10 #define FLG_HEAP_ENABLE_FREE_CHECK   0x20 #define FLG_HEAP_VALIDATE_PARAMETERS 0x40 // executa a operação OR entre o valor de todas as flags #define NT_GLOBAL_FLAG_DEBUGGED (FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS) // se não for 64 bits #ifndef _WIN64 PVOID pPeb = (PVOID)__readfsdword(0x30);    // PEB DWORD dwNtGlobalFlag = *(PDWORD)((PBYTE) pPeb + 0x68); // flag #else // o mesmo procedimento para 64 bits PVOID pPeb = (PVOID)__readgsqword(0x60); DWORD dwNtGlobalFlag = *(PDWORD)((PBYTE)pPeb + 0xBC); #endif // _WIN64 // função que acusa depurador e sai void being_debugged() {     std::cout << "Stop debugging program!" << std::endl;     exit(-1); } int main() { // se em ambiente de depurador chama função de saída     if (dwNtGlobalFlag & NT_GLOBAL_FLAG_DEBUGGED)         being_debugged();     eles  // senão segue normalmente         std::cout << "Hello World!\n";     return 0; } Desabilitando a Técnica
    Para desviar desta verificação, basta definir o campo NtGlobalFlag da estrutura PEB com 0 antes que este valor seja verificado pela proteção anti-depuração. Abaixo são alguns exemplos de como zerar esta flag:
    No x64dgb com o plugin ScyllaHide: 
    Plugins → ScyllaHide → Options -> NtGlobalFlag  [x]
     
    Manualmente no x64dbg:
    1. Ctrl+G → peb()+0x68 (32 bits) ou Ctrl+G → peb()+0xBC (64 bits)
    2. Trocar o valor do byte de 0x70 para zero
     
    No OllyDbg com o plugin Command Line:
    1. Plugins → Command Line →  Command Line
    2. dump fs:[30]+0x68 (32 bits) ou dump gs:[60]+0xBC (64 bits)
    3. No painel dump de memória selecionar o 1º byte → Binary → Fill with 00's
    *Também é possível usar o plugin Olly-Advanced 
     
    Bom, iniciei aqui uma nova categoria de técnicas Anti-Debug, a das flags de depuração, iniciando com a flag NtGlobalFlag. No próximo artigo vou falar sobre uma técnica que usa 2 flags em conjunto, a Heap Flags e a ForceFlags.
     
    Espero que tenham gostado. 
    Forte abraço & até o próximo!
     
    Referências:
    [1] https://docs.microsoft.com/en-us/windows/win32/apiindex/windows-api-list
    [2] https://docs.microsoft.com/en-us/sysinternals/resources/windows-internals
    [3] https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/pebteb/peb/index.htm
     
    Andre Smaira

    O Projeto Paranoid

    By Andre Smaira, in Tudo,

    Paranoia - Fonte: www.clipartguide.com
     
    No último dia 24 de agosto (2022), funcionários da empresa Google anunciaram através dessa postagem, dos autores Pedro Barbosa, Engenheiro de Segurança da Google e Vice-Capitão do time de CTF Epic Leet Team (ELT), e Daniel Bleichenbacher, Engenheiro de Software da Google, seu novo projeto de criptografia chamado Paranoid (paranoia em tradução livre para o português).
    Ela cita o repositório GitHub do projeto. É importante dizer que apesar de a biblioteca ter sido criada e ser mantida por membros do time de Segurança da Informação da Google, ele não é um produto oficial da Google.
    Nesse artigo vamos verificar o que é e para que serve esse projeto através de uma tradução comentada da postagem acima citada.
     
    O que é o Projeto Paranoid ?

    Fonte: istockphoto.com
     
    Paranoid é um projeto usado para detecção de vulnerabilidades conhecidas em artefatos criptográficos, como chaves públicas e assinaturas digitais. Isso é importante pois tais artefatos às vezes são gerados por implementações desconhecidas e/ou que não tenham código aberto para inspeção, as chamadas "caixas pretas" (ou do inglês black Boxes).

    Black Box - Fonte: www.nsoftware.com
     
    Em 2019, pensando na vunerabilidade ROCA, os autores da Paranoid se perguntaram se outras fraquezas não poderiam existir em artefatos gerados por caixas pretas e o que eles poderiam fazer para detectá-los e mitigá-los. Foi daí que surgiu a ideia de criar a Paranoid, uma biblioteca capaz de checar uma grande quantidade de artefatos criptográficos.
    Ela foi criada baseando-se na literatura preexistente, que mostra que a geração de artefatos nem sempre é perfeita. A seguir temos quatro dessas referências:
    Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and Christophe Wachter. (2012). Ron was wrong, Whit is right. Cryptology ePrint Archive, Paper 2012/064; Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. USENIX Associations; Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja Lange, and Nicko van Someren. (2013). Factoring RSA keys from certified smart cards: Coppersmith in the wild. Cryptology ePrint Archive, Paper 2013/599; Joachim Breitner and Nadia Heninger. (2019). Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies. Cryptology ePrint Archive, Paper 2019/023. Um exemplo mais recente, de 2022, é a CVE-2022-26320, encontrada por Hanno Böck, que evidencia ainda mais a necessidade de se detectar tais fraquezas. A Paranoid inclusive já encontrou de forma independente chaves fracas a partir do teste de Fermat. Os autores preveem que o projeto ainda tenha potencial para encontrar novas vulnerabilidades, já que estão generalizando as detecções ao máximo.
     
    Chamada para contribuições

    Fonte: opensource.guide
     
    Abrindo o código da Paranoid, os autores objetivam aumentar sua transparência, permitindo que ela seja utilizada também por outros tipos de usuários como Autoridades de Certificação - CAs que precisam fazer checagens semelhantes) e, é claro, receber contribuição de pesquisadores externos. Então, estão fazendo uma chamada para tal, com a esperança de que ao encontrar uma nova vulnerabilidade, depois de reportá-la, incluam as checagens na Paranoid. Dessa forma, não só a Google, mas também o resto do mundo poderá responder de forma rápida às novas ameaças.
    A biblioteca foi construída para ser leve computacionalmente falando, de forma que, mesmo trabalhando com números extremamente grandes, ainda faça sentido no contexto de produção do mundo real. Existem projetos com menos restrições para outros casos de aplicação, como o RsaCtfTool, geralmente usado em competições de segurança da informação do tipo CTF.
    Os autores destacam que além de contribuições de novas checagens, também são muito bem-vindas eventuais melhorias nas checagens já existentes na biblioteca, cujo código está disponível no repositório do GitHub. Um dos exemplos que fornecidos é o das assinaturas ECDSA, cujos segredos são gerados por java.util.random, para as quais a biblioteca tem um modelo pré-computado capaz de detectar a vulnerabilidade na maioria dos casos dadas duas assinaturas secp256r1, mas que para curvas maiores como secp384r1, não foi possível pré-computar um modelo com efetividade tão significante.
    Também foram implementadas checagens para chaves públicas RSA e EC, e fluxos de bits pseudo aleatórios, para o qual foram feitas algumas melhorias em relação ao teste NIST SP 800-22e incluídos alguns testes adicionais usando técnicas de redução de lattice.
     
    Resultados preliminares

    Resultados - Fonte: casadeimagem.com
     
    Em caráter de teste, foram analisados artefatos criptográficos da Certificate Transparency (CT), que registra certificação de sites desde 2013 com o objetivo de torná-los transparentes e verificáveis, e cujo banco de dados possui mais de 7 bilhões de certificados.
    No caso das checagens de chaves públicas EC e assinaturas ECDSA, não foram achados artefatos fracos no CT. Para as checagens de chaves públicas RSA com gravidades ALTA ou CRÍTICA, foram encontrados os seguintes resultados:
     
    |            Teste                        |         CVEs relacionada       |    Gravidade    | Número de artefatos afetados|
     
    |   CheckOpensslDenylist     |            CVE-2008-0166         |     CRÍTICA      |                    3989                         |
    |         CheckROCA                 |            CVE-2017-15361       |       ALTA          |                    2875                          |
    |        CheckGCD                    |                          -                    |     CRÍTICA      |                    1860                          |
    |        CheckFermat                |            CVE-2022-26320      |     CRÍTICA      |                      36                            |
    |  CheckContinuedFractions |                        -                      |     CRÍTICA      |                       16                            |
    |     CheckBitPatterns             |                        -                      |     CRÍTICA      |                        6                            |
    | CheckPermutedBitPatterns |                      -                        |     CRÍTICA      |                        6                            |
    |   CheckKeypairDenylist         |           CVE-2021-41117        |     CRÍTICA      |                        4                            |
    |      CheckPollardpm1              |                    -                         |     CRÍTICA      |                        1                             |
     

    Fonte: nakedsecurity.sophos.com
     
    Alguns desses certificados já expiraram ou foram revogados. Os que ainda estão ativos (a maioria dos que falharam no CheckGCD), foram imediatamente reportados, de forma a manter a internet segura, conforme as políticas das Autoridades Certificadoras, como a do Let's Encrypt. Temos abaixo o trecho exemplo da Digicert:
    > Certificate revocation and certificate problem reporting are an important part of online trust. Certificate revocation is used to prevent the use of certificates with compromised private keys, reduce the threat of malicious websites, and address system-wide attacks and vulnerabilities. As a member of the online community, you play an important role in helping maintain online trust by requesting certificate revocations when needed.
    Ou em português:
    > A revogação de certificados e a notificação de problemas em certificados são partes importantes da confiança na internet. A revogação de certificados é usada para evitar o uso de certificados com chaves privadas comprometidas, reduzir a ameaça de sites mal-intencionados e abordar ataques e vulnerabilidades. Como membro da comunidade web, você desempenha um papel importante ao ajudar a manter a confiança na internet solicitando revogações de certificados quando necessário.
     
    Próximos passos

    Próximos Passos - Fonte: sindipetro.org.br
     
    Os autores planejam continuar analisando o CT, e, agora com ajuda de contribuição externa, criar novas checagens e otimizar as já existentes. Estão também acompanhando de perto o processo Post-Quantum Cryptography Standardization do NIST para novos algoritmos que possam fazer sentido a implementação de checagens.
    Novas implementações de criptografia trazem a possibilidade de novas falhas, portanto é importante que a Paranoid seja capaz de detectá-las, evoluindo sempre.
     
     
×
×
  • Create New...