Como perder o acesso ao sistema ativo, simplesmente atrapalhando o código-fonte

A segurança com exemplos da vida real é sempre mais interessante.

Uma vez que um cliente veio com uma solicitação de teste de penetração. Ele tinha vários motivos de preocupação, entre outros, um foi ouvido: “Alguns meses atrás, um novo desenvolvedor veio até nós, teve acesso ao código-fonte, documentação, um servidor de teste, desapareceu dois dias depois e ainda não responde. Como isso pode me ameaçar? O acesso ao sistema ao vivo não foi dado a ele.

Não falaremos sobre os erros dos desenvolvedores, que podem se tornar sérios buracos no sistema ativo. Tudo é muito mais simples - o próprio código fonte pode conter instruções e acessos diretos.

Dos vários projetos que testamos em termos de segurança, darei exemplos reais quando, apenas com o código-fonte, pudemos penetrar no próprio sistema. Todas essas áreas problemáticas foram corrigidas e qualquer informação extra nas capturas de tela está oculta.

Sistema 1.
O código clonado do gita não é apenas a versão mais recente, mas também o histórico de todas as alterações. Geralmente, executamos o código-fonte para obter informações confidenciais usando gittyleaks .

Neste projeto, encontramos uma chave de criptografia privada que já foi removida do código, mas ainda era usada no sistema ativo. Essa chave foi usada para autenticação e, conhecendo o mecanismo, poderíamos gerar qualquer cookie de autenticação para qualquer usuário, incluindo o administrador.


Figura 1. Saída: gittyleaks --find-everything


Sistema 2.
Você pode usar o utilitário git e pedir para mostrar todos os arquivos já excluídos. Nesse sistema, encontramos um arquivo deployer.pem que costumava estar na raiz do projeto e foi usado para implantar automaticamente o projeto nos servidores por meio do canal SSH. A porta SSH no sistema ativo foi aberta. Por que está aberto? Os desenvolvedores responderam que sua máquina de compilação estava atrás de um endereço IP dinâmico e decidiram não fechar a porta - "de qualquer maneira, ninguém pegará a chave SSH". Gee-gee ...


Figura 2. Saída: git log --diff-filter = D --summary

Sistema 3.
Com esse sistema, tudo ficou ainda mais fácil. Pode valer a pena entrar nos scripts do banco de dados e ver como os usuários são criados por padrão. Normalmente, o primeiro usuário cria um administrador com as permissões mais altas. Nos scripts, encontramos um código que gerava um hash a partir de senhas reais e o escrevia no banco de dados. Surpreendentemente, 5 usuários foram criados, mas a senha do administrador mais importante, para nossa surpresa, passou pelo sistema ao vivo. E esse código não é o primeiro ano, a propósito, e nenhuma pessoa trabalhou com ele.


Figura 3. Como encontrar senhas reais nos scripts do banco de dados

A promessa.

1. Se o seu projeto estiver em um gita, abra-o e execute alguns comandos na pasta raiz:

pip install gittyleaks
gittyleaks --find-qualquer coisa

git log --diff-filter = D - resumo

2. Uma regra de ouro. Um sistema ativo sempre deve ter chaves únicas, senhas de usuário exclusivas e tudo nele deve ser fechado ao máximo.

As informações acima são fornecidas apenas para fins educacionais e educacionais, não é necessário executar seus sistemas.

Denis Koloshko