O Github está lutando para acompanhar uma campanha de malware que é uma nova reviravolta no typosquatting. A jogada é simples: clonar repositórios populares, adicionar malware e anunciar os forks como originais. Alguns desenvolvedores confundem os forks com projetos reais e executam o malware sem querer. A escolha óbvia de nomenclatura é forksquatting, mas o pesquisadores da apiiro escolheram o nome mais seguro de “Repo Confusion”.

A campanha é automatizada e o GitHub está ciente disso, com a grande maioria desses repositórios maliciosos sendo removidos imediatamente. Por alguma razão, o algoritmo do GitHub não está capturando todos os novos repositórios. A campanha atual parece publicar milhões de forks, usando código de mais de 100,000 projetos legítimos. Começa a parecer que a família de ataques invasores veio para ficar.

RustDesk e certificados ímpares

O software de acesso remoto RustDesk é interessante, pois é de código aberto, permite auto-hospedagem e é escrito em Rust. Há muito tempo que exploro o RustDesk como um item de tarefa, mas um pouco de drama preocupante acabou de acontecer. Um usuário apontou em novembro que um certificado raiz de teste foi instalado como parte da instalação do RustDesk. Esse certificado raiz é autoassinado com SHA1. Também existe a preocupação de que os binários do RustDesk sejam assinados com um certificado diferente.

Houve novos eventos desde então. Primeiro, houve um tópico do Hacker News sobre o assunto no início deste mês. No dia seguinte, CVE-2024-25140 foi registrado no NIST, classificando um CVE 9.8 CVSS insano. Vamos cortar um pouco do FUD e conversar sobre o que realmente está acontecendo.

Primeiro, os certificados raiz devem ser assinados com uma função de hashing mais segura que o SHA1. Mas não pelo motivo que você pensa, e neste caso não importa. Os certificados raiz são autoassinados por definição, e a única razão pela qual são assinados é porque esses certificados devem ser assinados para serem válidos. Os certificados filhos não são protegidos pela assinatura do root. A função importante que depende dessa assinatura raiz é a capacidade de emitir uma solicitação de revogação. Isso seria muito ruim para um dos certificados raiz amplamente confiáveis, e não seria um problema para um certificado não confiável como este.

Em seguida, RustDesk possui um certificado válido e assinado para os executáveis. O certificado raiz autoassinado serve estritamente para assinar um driver de kernel, que requer um certificado de Validação Estendida (EV). É um pouco desconcertante que esse requisito possa ser facilmente contornado com a instalação de um certificado raiz durante a instalação do aplicativo, mas isso é da Microsoft, não do RustDesk.

A preocupação final aqui é que este certificado está sendo instalado como uma Autoridade de Certificação (CA) de todo o sistema. Esse é o elemento mais preocupante desta saga, mas os certificados possuem um campo especificando seu uso de chave (KU) e uso de chave estendido (EKU). O RustDesk CA é estritamente para assinatura de código. Isso não permite que RustDesk ou qualquer pessoa que possua essa chave quebre TLS ou falsifique sites. Ele permite a assinatura de código, o que pode ser uma preocupação válida, mas não é a situação complicada que parece à primeira vista.

RustDesk retirou essa chave de sua instalação, o que desativa o driver de vídeo virtual. Essa era a funcionalidade que exigia um driver de kernel assinado. A última notícia é que os desenvolvedores do RustDesk estão recebendo assistência e buscando um certificado de assinatura de código EV, e esperam ter esse processo concluído em cerca de um mês. E aquele CVE, com pontuação de gravidade 9.8? Parece completamente falso.

Injeção de SQL de membro final

O plugin Ultimate Member WordPress foi atualizado para a versão 2.8.3, corrigindo uma falha de injeção de SQL que estava acessível como um usuário não autenticado. Com base na diferença de atualização, a questão principal provavelmente é uma falta prepare() na linha 704. Ah, e aparentemente está sendo investigado e potencialmente explorado na natureza, então vá corrigir.

Este é provavelmente um bom momento para conversar sobre por que existem tantos ataques de injeção de SQL no WordPress. Primeiro, a injeção de SQL ocorre quando os dados fornecidos pelo usuário são interpretados como parte do comando SQL a ser executado. Isso é feito incluindo um personagem inesperado. Por exemplo, um ponto e vírgula indica o fim de uma instrução e pode ser usado para iniciar a próxima. Então, onde um programa ingênuo espera um número, uma entrada de 15; DROP TABLE Students irá satisfazer uma instrução SQL e injetar uma segunda instrução para ser executada no banco de dados.

Em termos gerais, existem duas abordagens para evitar a injeção de SQL: limpeza de entrada e instruções preparadas. E ambos também são bons! Primeiro, limpe a entrada do usuário. Certifique-se de que o número inteiro seja realmente um número inteiro e apenas um número inteiro. Retire aspas, ponto e vírgula e outros caracteres potencialmente perigosos.

A segunda abordagem é usar declarações preparadas. Isso separa o comando SQL dos dados de uma forma fundamental. É algo como $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); para enviar os comandos SQL. Então é seguido por $database->bind_param("si", $name, $age); para definir os valores a serem usados. E finalmente um $database->execute(); realmente executa a consulta. Não há injeção possível devido à separação estrita entre o código e os valores.

Agora chegamos ao WordPress, que tem seu próprio wpdb classe para chamadas de banco de dados. Isso inclui uma função útil, wpdb::prepare() isso parece quase uma declaração preparada, conforme mostrado acima.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Exceto que não é de todo. O prepare() função faz estritamente uma passagem de higienização e um sprintf() substituição de valor. O prepare() na verdade, a função não produz uma instrução de banco de dados preparada. O WordPress não fornece uma maneira de realmente usar instruções preparadas. Falta um dos paradigmas básicos para manter os desenvolvedores longe de problemas com injeções de SQL.

Os M&Ms estão assistindo

Eu tenho uma espécie de hobby. Acho divertido detectar máquinas que se comportam mal e tentar descobrir qual sistema operacional está sendo executado sob a GUI brilhante. O dispositivo incorporado mais estranho que encontrei é um scanner de páginas que executava uma cópia completa do Windows. Os scanners de preços em sua grande loja local podem rodar apenas o Windows CE. Os centros de infoentretenimento nos assentos dos aviões rodam um Linux muito antigo. E aparentemente as máquinas de venda automática de M&M da Universidade de Waterloo funcionam Windows com o aplicativo Invenda.Vending.FacialRecognition.App.exe.

Sabemos disso porque [SquidKid47] detectou uma exceção de software desconhecida na tela da máquina de venda automática e a compartilhou no Reddit. A o jornal da escola publicou a história (pdf) e determinou que a máquina de venda automática usa uma câmera e detecção facial como uma combinação de sensor de movimento inteligente e detector demográfico para publicidade direcionada. Sim, essas máquinas de venda automática veiculam anúncios direcionados. Pelo menos eles fizeram. Estas máquinas de venda automática têm conheci seu Waterloo na Universidade de Waterloo, com a escola solicitando formalmente sua remoção.

Bits e bytes

Toque a campainha para Pwn: Acontece que algumas campainhas inteligentes não são tão inteligentes. Não é surpreendente que exista um processo para redefinir uma campainha inteligente e associá-la a outra conta. É bastante surpreendente que este processo seja tão fácil quanto segurar o botão grande da campainha por 8 segundos. No mínimo, o legítimo proprietário receberá um email sobre a alteração.

A insegurança da impressora não é novidade, mas a segurança da impressora 3D ainda é uma ideia de nicho. Isso pode estar mudando, agora que o equivalente a um arquivo “greetings.txt” foi descartado em um monte de impressoras Anycubic. Aparentemente, Anycubic usa um servidor MQTT que realmente não possui controles de acesso suficientes.

É aquela hora novamente, quando uma correção de vulnerabilidade foi lançada para GitLab, e é hora de atualizar. O destaque desta vez é uma falha Cross Site Scripting (XSS) ao visitar a página de perfil de um usuário. Deixo como exercício para o leitor produzir um código de exemplo que copie “samy é meu herói” para a página de perfil de cada visitante.

E finalmente, no departamento da ironia, Avast foi multado por usar um plugin de privacidade do navegador como plataforma para coletar e vender dados do usuário. Isso aconteceu de 2014 a 2020, utilizando a plataforma Jumpshot para a venda propriamente dita de dados. Os dados foram nominalmente anonimizados, mas a quantidade e os detalhes das informações disponíveis são um pouco surpreendentes. Vale ressaltar que o Jumpshot não existe mais e o Avast agora é propriedade de outra empresa. Esperançosamente, sem coletar informações do usuário.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://hackaday.com/2024/03/01/this-week-in-security-forksquatting-rustdesk-and-mms/