OpenJS e OpenSSF emitem alerta sobre o risco de ataques de engenharia social a projetos de código aberto
- A recente tentativa de backdoor no XZ Utils (CVE-2024-3094) pode não ter sido um incidente isolado
- A OpenJS Foundation parece ter bloqueado tentativas de takeover semelhantes de partes que pareciam confiáveis, portanto isso pode não ser um caso isolado
- OpenSSF e OpenJS Foundation pedem que todos os mantenedores de código aberto fiquem atentos a tentativas de engenharia social, reconheçam padrões iniciais de ameaça e adotem medidas para proteger os projetos de código aberto
Tentativas de takeover malsucedidas
- O Cross Project Council da OpenJS Foundation recebeu uma série de e-mails suspeitos com mensagens semelhantes
- O remetente dos e-mails pressionava a OpenJS para que tomasse providências a fim de atualizar um dos projetos JavaScript mais populares para "corrigir uma vulnerabilidade importante", sem mencionar detalhes específicos
- O remetente queria ser nomeado novo mantenedor do projeto, apesar de ter tido pouquíssimo envolvimento com código anteriormente
- Essa abordagem é muito semelhante à forma como “Jia Tan” se posicionou no caso do backdoor do XZ/liblzma
- Esses indivíduos não receberam acesso aos projetos hospedados pela OpenJS
- O projeto dispõe de políticas de segurança, incluindo uma visão geral descrita pelo grupo de práticas de segurança da fundação
- A equipe da OpenJS também identificou padrões suspeitos semelhantes em dois outros projetos JavaScript populares fora do escopo de hospedagem da fundação e avisou imediatamente os líderes de cada projeto da OpenJS e a CISA, que integra o DHS
Padrões suspeitos de takeover por engenharia social
- Padrões
- Um membro da comunidade relativamente desconhecido solicita, de forma amigável mas persistente e agressiva, que seja nomeado mantenedor ou que a entidade hospedeira (fundação ou empresa) intervenha
- É pedido para promover uma pessoa nova ou desconhecida ao cargo de mantenedor
- Recebe apoio de outro membro da comunidade também desconhecido, possivelmente usando identidade falsa (o chamado "sock puppet")
- PRs com Blob incluído em artefatos
- Código-fonte propositalmente ofuscado ou de difícil compreensão
- Problemas de segurança que se agravam gradualmente
- Inserção de payload malicioso externo em artefatos binários (Blob, Zip ou outros) fora das práticas padrão de compilação, build e distribuição do projeto
- Isso tende a ocorrer especialmente quando há urgência para reduzir a profundidade da revisão ou forçar a evasão de controles
- Esses ataques de engenharia social exploram o senso de dever que os mantenedores têm com o projeto e a comunidade para manipulá-los
- Fique atento à impressão que a interação passa
- Interações que induzem dúvida sobre si mesmo, sensação de inadequação ou de não contribuir o suficiente para o projeto podem fazer parte de um ataque de engenharia social
- Ataques de engenharia social como os observados no XZ/liblzma foram evitados com sucesso pela comunidade OpenJS
- Esse tipo de ataque explora quebra de confiança por engenharia social, por isso é difícil de detectar ou defender por meios programáticos
- No curto prazo, compartilhar atividades suspeitas como as citadas acima, de forma transparente e clara, ajudará outras comunidades a manter a vigilância
- Apoiar bem os mantenedores é a principal medida para reduzir esses ataques de engenharia social
Etapas para segurança de projetos de código aberto
- Considere seguir práticas padrão da indústria de segurança, como o OpenSSF Guide
- Use autenticação forte: 2FA, gerenciador de senhas, guarde códigos de recuperação em lugar seguro, não reutilize senha/credenciais em serviços diferentes
- Elabore política de segurança que inclua o processo de divulgação coordenada
- Aplique boas práticas ao mesclar código novo
- Ative proteção de branch e commits assinados
- Sempre que possível, faça com que um segundo desenvolvedor revise o código antes de mesclar, mesmo se o PR vier de um mantenedor
- Aplique requisitos de legibilidade para evitar PRs ofuscados e reduzir ao máximo o uso de binários opacos
- Limite quem pode ter permissão para publicar no npm
- Identifique committers e mantenedores e revise periodicamente. Por exemplo: você os conheceu em reuniões de grupos de trabalho ou os encontrou em eventos?
- Se você opera um repositório de pacotes de código aberto, considere adotar os princípios do Package Repository Security
- Verifique os guias da CISA sobre evitar ataques de engenharia social e phishing e/ou da ENISA sobre o que é engenharia social
Ações da indústria e do governo para a segurança da infraestrutura de código aberto essencial
- A pressão para manter projetos de código aberto estáveis e seguros também pressiona os mantenedores
- É necessária cooperação internacional entre setores privado e público para mobilizar recursos em grande escala
- Instituições como Open Source Foundations, Sovereign Tech Fund e várias outras já realizam excelente trabalho
- É necessário o esforço de organizações semelhantes à família de fundações da Linux Foundation para oferecer uma rede de proteção aos projetos de código aberto
- É encorajador ver o investimento do governo alemão, por meio da iniciativa Sovereign Tech Fund, em infraestrutura crítica de código aberto
- Apoiamos maior investimento público global em iniciativas como o Sovereign Tech Fund da Alemanha para ampliar investimentos públicos globais
Opinião GN⁺
- Os atacantes estão explorando habilmente o senso de responsabilidade dos mantenedores e confundindo desenvolvedores. Por isso, também vale atenção às mudanças emocionais que os administradores apresentam em relação ao projeto.
- Concordamos que é preciso investir mais em segurança, mas, em essência, a cultura de desenvolvimento precisa mudar para priorizar segurança; a segurança deve permear todo o processo de desenvolvimento.
- Como os atacantes aproveitam a confiança da comunidade, projetos de código aberto devem desenvolver continuamente o esforço de construir e fortalecer a confiança entre os membros. A comunicação presencial pode ser o início disso.
- Projetos que investem em melhorias reais de vulnerabilidades, como o projeto Alpha-Omega, precisam ser criados em maior número e receber mais apoio. Só assim a segurança dos projetos de código aberto poderá subir de fato.
1 comentários
Opinião do Hacker News
Resumo: