Github sendo hackeado? Para a maioria, isso não parece muito irracional, já que grandes e pequenas empresas de tecnologia já foram hackeadas antes. No entanto, isso não significa que a probabilidade de o Github ser hackeado seja alta. Por que é que? O Github é o principal repositório de código aberto para todos na indústria de TI.
Independente do subsetor. Mesmo que alguém faça sistemas incorporados, desenvolvimento Web3, desenvolvimento Web2, ciência de dados, etc., a maioria usaria o Github para armazenar seu código. É por isso que a segurança do Github sempre foi extremamente alta. Não apenas porque eles queriam ter a confiança de seus usuários, mas também porque o código nos repositórios do Github de seus usuários é preenchido com chaves privadas criptográficas, chaves privadas de API, credenciais financeiras e até mesmo software proprietário de várias empresas do setor de TI globalmente. É por esta razão que o Github sempre foi rígido com sua segurança e acessibilidade do usuário, é por isso que seu hacking, embora não seja totalmente surpreendente, é muito surpreendente e preocupante.
Contexto do Githack:
Que tipo de ataque de hack foi? É um ataque de malware. Portanto, não seria um ataque tradicional de DDoS ou penetração forçada que se esperaria, mas potencialmente mais letal. O hacker/hackers carregou um malware generalizado para diferentes repositórios na plataforma.
O que o Malware faz? ele copia qualquer informação financeira, informação de autenticação e chaves criptográficas privadas, essencialmente o ENV do script. Então, quando aceito no repositório e executado localmente nos computadores afetados, ele copia e envia as informações ao invasor. Portanto, não é um hack no sentido tradicional, mas definitivamente um hack, pois as informações ainda foram extraídas por meios não consensuais de violação de dados.
Qual é a amplitude do ataque de hack? essa tentativa de hack em particular atingiu não mais e nada menos que 35.000 repositórios do Github. Ele se infiltrou em repositórios como o repositório python, o repositório golang, o repositório docker e o repositório bash. Alguns dos repositórios afetados foram arquivados e não utilizados. Alguns até foram vistos com o malware dentro deles desde 2015. Isso indica que o hack foi bem documentado e planejado.
Como ele se infiltra nos repositórios do Github? Ele é adicionado aos repositórios do Github por meio de um commit e no commit por meio de scripts npm ou diferentes classificações de imagens docker. Portanto, você só ficaria vulnerável principalmente se seu projeto utilizasse javascript de alguma forma ou docker. Então, se o commit for aceito e for clonado e usado no repositório principal, os usuários que o clonaram serão afetados.
Como evitar isso?
Enquanto escrevo sobre este incidente, todas as partes envolvidas na limpeza, os proprietários do repositório e o Github, já estão no processo de controle de danos e garantindo que isso não aconteça novamente. Podemos apenas especular e imaginar quais são as diferentes técnicas de segurança e defesas que o Github usará para se proteger de ataques futuros. Como tal, devemos nos concentrar em nós mesmos como indivíduos ou grupos. O que podemos fazer em nossa própria capacidade para impedir futuros roubos de dados como esse?
- Não aceite solicitações push de pessoas aleatórias para o seu repositório. Eu sei que isso pode ser mais difícil para a maioria dos grandes projetos de código aberto. No entanto, seja cauteloso ao aceitar solicitações de push, especialmente se as solicitações de push editarem as variáveis ambientais do seu aplicativo.
- Sempre verifique o que exatamente você está clonando de um repositório git. Eu sei que a maioria de nós não faz isso ativamente. Simplesmente porque os repositórios contêm tantos arquivos e pastas que acompanhá-los e analisá-los um por um será cansativo. Portanto, seria sensato verificar os arquivos mais importantes, como os arquivos readme e .env.
- Use testes de segurança em solicitações push. Na verdade, o Github possui uma estrutura de segurança, conduzida pelo Githook, que permite enviar solicitações de postagem HTTP quando determinados eventos são atendidos durante a solicitação push. Existem diferentes tecnologias que podem analisar sua solicitação push ou pull em busca de vulnerabilidades de segurança, vírus comuns e outros tipos de brechas de segurança em seu código.
No geral, que isso seja uma lição para todos nós. Os ataques que organizações/pessoas nefastas podem fazer não são apenas rudimentares, mas também avançados e muito incondicionais, bem como planejados a longo prazo. Como desenvolvedores, precisamos estar mais atentos às vulnerabilidades de nosso código, repositórios, computadores e até de nós mesmos e que, se alguém deseja informações, pode encontrar maneiras muito diferentes de obtê-las. Mesmo que a internet deva ser segura, isso não significa que seja. Cabe a todos fazer sua parte para tornar seus próprios dados seguros e, se puder, encontre maneiras de ajudar outras pessoas a manter seus dados seguros.
Para ler mais sobre a situação, acesse: https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/
