Esta semana em segurança: Git Deep Dive, Mailchimp e SPF

Primeiro, git foi auditado. Este foi um esforço patrocinado pelo Open Source Technology Improvement Fund (OSTIF), uma organização sem fins lucrativos que trabalha para melhorar a segurança de projetos de código aberto. A auditoria em si foi feita por pesquisadores do X41 e GitLab, e duas vulnerabilidades críticas foram encontradas, ambos causados ​​pelo mesmo mau hábito de codificação - usar um int para armazenar comprimentos de buffer.

Nos sistemas modernos, um size_t é sempre sem sinal e tem o mesmo comprimento de bits que a largura de bits da arquitetura. Este é o tipo de dados adequado para comprimentos de string e buffer, pois é garantido que não transbordará ao manipular comprimentos até a memória endereçável máxima no sistema. Por outro lado, um int geralmente tem quatro bytes de comprimento e está assinado, com um valor máximo de 2 ^ 31-1 ou 2147483647 - cerca de 2 GB. Um grande buffer, mas não uma quantidade inédita de dados. Jogue algo tão grande no git e ele quebrará de maneiras inesperadas.

Nosso primeiro exemplo é CVE-2022-23521, uma gravação fora dos limites causada por um int transbordando para negativo. A .gitattributes arquivo pode ser confirmado em um repositório com um cliente git modificado e, em seguida, verificar esse repositório fará com que o num_attrs variável para estourar. Empurre o overflow até um pequeno número negativo e o git subalocará enormemente o buffer de atributos e gravará todos os dados após o final do buffer alocado.

CVE-2022-41903 é outro estouro de número inteiro assinado, desta vez quando um formato de impressão bonito é abusado para fazer algo inesperado. Dê uma olhada neste bloco de código:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

O formato de exploração seria algo como %>(2147483647)%a%>(2147483646)%x41, onde o código acima é executado para cada instância de preenchimento (o %>(#) blocos) encontrados no formato. A primeira vez que esse código adiciona (2 ^ 31) -1 espaços à frente da string de saída. Acontece que esse número é o valor máximo de um número inteiro assinado de quatro bytes. Mas o bloco de código acima é executado outra vez e, mais uma vez, o texto é adicionado ao buffer, ultrapassando seu comprimento acima do valor inteiro máximo. A primeira linha desse bloco faz uma conversão implícita de size_t para int, configuração sb_len para um valor negativo.

Então, no memcpy() ligar, sb->buf é um ponteiro para o início do buffer, sb_len é nosso grande número negativo transbordado e offset será um valor controlado pelo usuário. Isto significa a localização do destino enviado para memcpy() pode ser definido involuntariamente para um local de memória inferior ao início do buffer pretendido. Gravações controladas pelo invasor. Adicionei algumas instruções printf() de depuração a este bloco de texto e executei um caso de teste:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

O primeiro quarteto de saídas é a configuração, preparando a linha de log com preenchimento para ter max int long. O segundo quarteto é o buffer overrun, onde sb_len é definido como negativo e, em seguida, adicionado ao deslocamento para nos fornecer uma localização 56 bytes à esquerda do início do buffer. O conteúdo que é impresso nesse local é, neste caso, %s, que é substituído pela linha de assunto do commit — 44 bytes de comprimento. Os autores sugerem que isso poderia ser usado como arma contra uma “forja git”, também conhecida como GitHub e GitLab, já que esses pacotes de software executam o comando git archive, que pode invocar uma string bonita controlada pelo usuário.

As correções foram enviadas para o código-fonte do git em 8 de dezembro, mas novos lançamentos contendo essas correções só estão disponíveis agora. Existem aproximadamente 2200 instâncias do bruto int problema, e eles vão demorar um pouco para serem limpos, mesmo com alguns hacks divertidos como cast_size_t_to_int(), uma função embutida que apenas mata o programa se um 2 GB+ size_t É tratado. Então vá atualizar!

Mailchimp - de novo

Parece que o pessoal do Mailchimp não consegue fazer uma pausa, já que suas ferramentas de administração interna foram acessadas mais uma vez por invasores, levando à exposição de 133 contas de clientes, incluindo WooCommerce. Esta é a terceira vez que o Mailchimp sofre um ataque de engenharia social ou phishing no ano passado, e cada vez resultou em e-mails de spear-phishing enviados aos usuários finais. Portanto, se você estiver em alguma lista de e-mail do Mailchimp, lembre-se dessa violação na próxima vez que um e-mail relacionado chegar. (Nota do editor: os dois boletins informativos do Hackaday usam Mailchimp e não fomos notificados, por isso acreditamos que estamos bem.)

Royal Mail Ransomware

Em uma história que pode ter grandes consequências, o Royal Mail do Reino Unido sofreu um ataque de ransomware em seu sistema para lidar com correio internacional. O ataque usa o ransomware Lockbit, um grupo suspeito de ser uma gangue de ransomware de língua russa. Isto pode ser significativo, já que um ataque a uma agência governamental real é muito mais sério do que um ataque a uma empresa. Como o Lockbit funciona como ransomware como serviço, será muito difícil determinar exatamente quem realmente realizou o ataque. Por enquanto, a recomendação é simples: não envie nenhuma correspondência internacional. Ufa.

Verificando registros SPF

[Sebastian Salla] tem o que pode ser considerado um hobby estranho, na forma de verificando registros SPF em busca de configurações incorretas estranhas. Em sua última aventura, essa varredura atingiu os 3 milhões de domínios mais visitados. E a configuração incorreta foi encontrada.

Mas espere, o que é um FPS e por que nos importamos? Sender Policy Framework é um registro txt que faz parte dos registros DNS de um domínio. E especifica quais endereços IP estão realmente autorizados a enviar e-mails para esse domínio. Portanto, se um e-mail recebido afirma ser de um domínio com um registro SPF válido e o endereço IP de envio não está nesse registro, claramente não é do domínio reivindicado.

E ter os e-mails do seu domínio rejeitados devido a um problema de SPF é uma das maneiras mais seguras de ser criticado. Portanto, é tentador tornar o registro do SPF um pouco mais... *liberal* do que talvez devesse ser. E a iteração mais extrema disso é simplesmente dar um tapa +all em seu registro SPF e pronto. Claro, isso diz ao mundo que todo spammer em qualquer lugar que usa seu domínio está na verdade enviando e-mails reais, mas pelo menos faz com que os e-mails enviados do chefe voltem a funcionar. Com mais de mil domínios configurados para SPF +all, aparentemente essa é uma falha mais comum do que o previsto.

A parte realmente interessante é quem é quem nesses domínios mal configurados, como diversas agências governamentais dos EUA, outros domínios governamentais ao redor do mundo e diversas universidades. O mais interessante foi o do Ministério da Defesa da Ucrânia, onde o registo do SPF foi recortado de um -all para +all cerca de 4 meses atrás.

Bits e bytes

Tailscale descobriu um problema potencialmente sério, onde saber o ID do nó de outro cliente permitiria que um invasor adicionasse o nó à sua própria rede traseira. Isso colocaria um invasor dentro da sua VPN, o que é definitivamente um cenário ruim. Mas antes de você pegar seus forcados, o código vulnerável foi implantado por menos de quatro meses antes de ser corrigido. Foi noticiado de forma privada no dia 11 deste mês e corrigido no dia 12. E para começar, o ataque deixa uma assinatura de log que o Tailscale foi capaz de verificar e concluiu que foi isolado para o teste de prova de conceito. Você pode verificar em seu próprio painel se há nós compartilhados em sua própria rede traseira para confirmação. E embora seja uma vulnerabilidade desagradável, é bom para o Tailscale divulgá-la. Muitos fornecedores teriam aceitado este e nunca o tornado público.

A O kernel do Linux teve um buffer overflow em seu código Netfilter, onde um buffer overflow pode resultar em vazamento de dados e execução de código. Não há um caminho para a exploração remota, mas o e-mail vinculado acima contém um PoC completo para um escalonamento de privilégios local. E se você gosta de explorar o kernel, o Project Zero do Google tem um novo artigo sobre o assunto, tudo sobre desreferenciação nula.

E se você usa o ManageEngine da Zoho, hoje seu cabelo pode estar pegando fogo, se você não atualizou para a versão que corrige CVE-2022-47966. Pesquisadores em Horizon3 fez engenharia reversa do patch, e revelou tudo neste RCE. É um problema na forma como o logon único SAML é implementado, em parte devido a uma biblioteca extremamente antiga empacotada como parte do produto. É uma exploração muito fácil de realizar, então é hora de verificar essas instalações!

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf/