Boas práticas de segurança para usuários Git
Git é uma das ferramentas mais populares para controles de sistemas SCM (Source Code Management ou, em português, SCV – Sistema de Controle de Versões). O Git já foi usado em alguns projetos open source famosos como Linux e Raspberry Pi, que junto com o apoio de fornecedores como Github e Gilab, ajudaram o Git a ganhar muita fama.
A popularidade do Git, no entanto, torna-o um alvo fácil de ataques, sendo que qualquer alteração não autorizada dentro de algumas linhas de código pode resultar em “metade do mundo” com a mesma vulnerabilidade ou com uma backdoor instalada. Tendo em vista este cenário, a ideia deste artigo é fornecer algumas dicas para o bom e seguro uso do Git.
Identidade
Autorização e identificação de um usuário habilitado é um dos requisitos mais importantes de segurança. Git tenta o melhor para detectar a identidade de um usuário quando são feitas alterações no commit (uma espécie de confirmação de alguma alteração). O problema é que o processo é baseado em obter dados de um sistema operacional com base no nome de usuário e em uma configuração de conta. Na realidade, qualquer pessoa pode criar uma conta de usuário com os dados que simulem a conta de um usuário legal. Essa facilidade requer boas práticas de segurança:
Dica #1: nunca utilize contas compartilhadas ou contas do sistema como root, nobody, www, etc., para mudanças no commit.
Dica #2: nunca utilize conta privilegiada ao desenvolver um código e fazer commit (você pode utilizar o sudo, caso haja necessidade de usar privilégios para alguma tarefa).
Há alguns casos em que o Git não consegue detectar sua identidade ou a detecta de forma errada. Para este tipo de situação (ou no caso de um usuário mal-intencionado), o Git permite forçar a identidade utilizando comandos como os do exemplo:
Git config –global user.name “Joao Carlos.”
Git config –global user.email j.carlos@exemplo.com
O mesmo resultado pode ser arquivado ao editar as configurações do Git, que são em texto puro. Git também permite definir localmente uma identidade de um repositório particular usando “–local option”. Mas este recurso nos leva a outra questão: você deve permitir que usuários usem diferentes identidades/IDs por projeto? A resposta rápida deve ser “não”, mas se você pensar um pouco mais, verá que vai depender do tipo e de quais os requisitos do seu projeto. Por isso, não definimos as permissões como uma sendo uma “boa prática de segurança”, mas sim um ponto a ser abordado de acordo com o seu projeto.
Dica #3: Nunca assuma identidade baseada em nome de usuário/e-mail. Imponha commits assinados.
Tags e commits assinados
Por algum tempo, Git suporta a assinatura criptográfica dos tags e commits. Seguindo a dica #3, você pode usar as duas opções.
Antes de qualquer usuário poder assinar um commit ou tag, ele necessita ter dois pares de PGP privado (http://br.ccm.net/contents/134-pgp-pretty-good-privacy) e chaves públicas. Você pode usar comando gpg para gerar, exemplo:
gpg –gen-key
Dica #4: Não use uma senha curta ao gerar o PGP/GPG
Dica #5: Não confie em uma chave PGP/GPG por default – certifique-se de ter uma chave pública confiável e de uma pessoa confiável.
Dica #6: Proteja sua chave privada. Reporte caso a chave tenha sido comprometida e revogue a chave dos servidores.
Dica #7: Não gere uma chave PGP/GPG com validade infinita. Keys deste tipo são muito difíceis ou até impossíveis de serem revogadas.
Dica #8: Defina uma senha forte para proteger as chaves privadas.
Após a chave ser criada, você deve informar ao Git usando os comandos:
Git config –global user.signingkey [id da chave/key]
Agora você pode assinar cada commit e tag. Para assinar uma commit você pode usar –S, como abaixo:
git commit –S –m “Signed commit message”
Para assinar uma tag, digite:
git –s [tag name] “Signed tag name”
Verificar commits e tags também é muito simples, digite:
git tag –v [tag name]
Para commits:
git log –show-signature
Você pode usar a o mecanismo de assinatura desde a versão 1.8.3 do Git.
Dica #9: Todos os commits devem ser assinados, caso contrário, o mecanismo perde o sentido.
Único repositório
Git pode ter um número ilimitado de repositórios de um projeto, embora seja uma boa perspectiva para um desenvolvedor, não é bom no ponto de vista de segurança.
Dica #10: sempre tenha ao menos uma cópia do repositório que você possa confiar e tratar como segura.
Acesso seguro
Existem diferentes tipos de acesso que você precisa se atentar do ponto de vista de segurança:
- Acesso seguro ao sistema de desenvolvimento: se for remoto, providencie uma autenticação forte (ex: dupla autenticação) e criptografia para conexão SSH.
- Acesso seguro aos protocolos do servidor do Git.
- Acesso seguro aos sistemas de integração continua.
- Nem todo projeto precisa ser público, então atribua direitos de acesso, especialmente quando utilizar serviços como Github ou Gitlab.
Dica #11: Utilize chave de autenticação onde for possível e aplicável.
Dica #12: Utilize apenas o protocolo SSHv2 e desabilite o SSHv1
Dica #13: Use o https ou SSH apenas para acessar os repositórios Git.
Dica #14: Configure direitos de acesso aos seus projetos.
Dica #15: Reveja os direitos de acesso aos seus projetos periodicamente.
Dica #16: Isole uns dos outros: os testes, ambiente de produção e homologação. Também isole a integração contínua (CI) dos outros ambientes.
Dica #17: Faça o deploy remotamente apenas de forma segura.
Serviços como Gitlab e Gihub utilizam conexão https por default em seus sites, entretanto, isto não ocorre quando está fazendo um deploy de um serviço interno (nas versões Enterprise). Portanto, reconfigure as aplicações para usar https, caso contrário, não haverá proteção de senhas de administradores e tokens de CI.
Dica #18: Reforce o acesso HTTPS para o repositório Git.
Prevenção de Malware e vazamento de informação
Usando o .gitignore, é possível dizer quais arquivos devem ser ignorados durante o comando “add”. Esta feature pode ser usada como prevenção de ambos, vazamento de informação e como uma política de proteção contra malware.
A funcionalidade do .gitignote permite desabilitar o rastreamento destes arquivos pelo Git e, também, publicá-los.
Se adicionar um arquivo executável com as extensões *.exe ou *.dll ou Linux ELF que são vetores comuns de infecção por malware, você também estará limitando as chances de uma de uma possível infecção.
Dica #19: Reforce o uso do .gitignore para os projetos atuais e futuros.
Dica #20: Adicione arquivos intermediários, temporários e executáveis ao .gitignore que não serão necessários para o seu projeto.
Mude as senhas e Keys padrões
Alguns serviços e aplicações possuem senhas padrões. Um grande exemplo pode ser GitLab CE com o usuário default como “root” e a senha “5iveL!fe”.
Dica #21: Troque as senhas default, atribuindo senhas fortes e desabilite contas desnecessárias, se possível.
Dica #22: Regenere chaves SSH default deletando as antigas e gerando novas.
Dica #23: Troque as senhas de acordo com sua política de segurança de senhas.
Mantendo as partes críticas da estrutura do seu Git seguras
Não esqueça de aplicar fixes de segurança e patches para o seu repositório. O mínimo a se manter atualizado são os acessos ssh do cliente/servidor e o Git.
Se estiver utilizando ferramentas como Github Desktop, deve mantê-lo atualizado também. É simples verificar o que já foi corrigido no Github Desktop, basta entrar em Settings -> About GitHub Desktop -> Release notes in GitHub Desktop windo, que aparecerá algo parecido com a imagem abaixo:
Se o seu IDE tem integração com Git, certifique-se de incluir na lista de atualizações, a mesma regra deve ser aplicada para todos os tipos de plugins, extensões e serviços usados em todo o seu desenvolvimento, construção e ambientes de teste.
Segue abaixo alguns exemplos de vulnerabilidades no Git, que reforçam a necessidade de manter as ferramentas atualizadas:
CVE-2016-2315 e CVE-2016-2324, essas vulnerabilidades demonstram a importância de manter as ferramentas atualizadas. Essas vulnerabilidades permitem a um atacante executar remotamente um código arbitrário via 1 – arquivo de nome muito longo 2 – buffer overflow.
Outra recente vulnerabilidade, CVE-2016-3115 no OpenSSH, onde é possível fazer um bypass, fazendo um request com X11 forward para fazer injection. Para mitigar essa vulnerabilidade você precisa desabilitar X11 forwarding setando no Linux com o comando X11Forwarding=no em “/etc./ssh/sshd_config”. Todas as versões antes da 7.2p2 estão vulneráveis.
As boas práticas demonstradas neste texto são apenas algumas dicas de segurança, mas são um princípio positivo. O importante é desenvolver as dicas de acordo com a sua política de negócio, mitigando vulnerabilidades e mantendo o código fonte do seu projeto protegido da melhor forma.
Referências:
0 comentários: