Como os hackers roubam chaves e senhas?

Estou procurando vulnerabilidades em vários sistemas de segurança. A certa altura, ficou claro para mim que meus clientes não estavam suficientemente familiarizados (se é que estavam familiarizados) com as técnicas básicas de "hacking". Chaves API, senhas, chaves SSH, certificados são todos excelentes mecanismos de segurança. Mas isso é verdade, desde que sejam mantidos em segredo. Depois que esses dados estão disponíveis para aqueles que não deveriam ter acesso a eles, verifica-se que a complexidade das senhas e o grau de avanço dos algoritmos de hash não importam mais. Neste post, quero falar sobre os conceitos, métodos e ferramentas usados ​​por pesquisadores de segurança para encontrar dados secretos. Esses dados são usados ​​para hackear sistemas. Também fornecerei alguns fluxos de trabalho simples aqui que podem ajudar a reduzir o risco de um ataque de hacker bem-sucedido.







É importante notar que o “jogo” de ataque e defesa, que é praticado por hackers e proprietários de sistemas de computador, é um jogo desonesto. Basta que o atacante penetre no sistema para vencer apenas uma vez. E quem defende só pode vencer vencendo sempre. A principal dificuldade aqui é saber em que você precisa prestar atenção. Mas depois que o defensor sabe que tipo de “portas” virtuais um hacker pode entrar em seu sistema, essas “portas” podem ser protegidas usando mecanismos bastante simples. Acredito que a simplicidade desses mecanismos às vezes diminui sua importância e é a razão pela qual muitos defensores de sistemas de computador ignoram esses mecanismos.



Aqui estão as regras básicas para proteção de sistemas que vou divulgar neste artigo. Eles são simples, mas isso não significa que você pode esquecê-los impunemente:



  • (multi-factor authentication, MFA) , . Google GitHub, , VPN-. MFA — .
  • , .
  • , . .
  • . , .


No que se refere a evitar vazamentos de informações classificadas e evitar o surgimento de "brechas" nos sistemas de segurança, atua o princípio de Pareto , segundo o qual 20% dos esforços rendem 80% do resultado.



Como os hackers trabalham quando encontram senhas e chaves secretas? Quais ferramentas eles usam?



Hackers encontram dados secretos em arquivos JavaScript



As chaves API estão espalhadas por toda a Internet. Qualquer um pode usá-los. É um fato. Freqüentemente, não há um motivo específico para as chaves estarem disponíveis publicamente. Os desenvolvedores simplesmente os esquecem em todos os lugares. Por exemplo, as chaves entram no código pelos seguintes motivos:



  • Para fins de depuração.
  • Para fins de desenvolvimento local.
  • Na forma de comentários destinados a quem apoiará o projeto posteriormente.


Blocos de código semelhantes aos seguintes podem ser encontrados com bastante frequência na Internet:



// DEBUG ONLY
// TODO: remove -->
API_KEY=t0psecr3tkey00237948


Embora muitos hackers leiam os próprios arquivos JavaScript, eles procuram esses arquivos principalmente usando ferramentas como meg e, em seguida, verificam o que encontram para encontrar padrões correspondentes.



Como eles fazem isso? Depois de usar o scanner, megeles parecem procurar strings nos arquivos encontrados que correspondam a vários padrões. Aquele que criou meg, escreveu outro excelente programa, e é exatamente isso que se pretende. É denominado gf e é uma versão melhorada grep. Nesse caso, usar a gfopção na inicialização truffleHogou, em outra variante de sua escrita trufflehog, permite que a ferramenta encontre strings de alta entropia que são chaves para a API. O mesmo vale para pesquisa de stringAPI_KEY... Os resultados da pesquisa para essa string são frequentemente (com muita frequência) bem-sucedidos.



Freqüentemente, há razões completamente normais para o fato de que as chaves aparecem no código, mas essas chaves não são protegidas de estranhos. Deixe-me lhe dar um exemplo. Um cliente com quem trabalhei usava um serviço externo de informações de mapas. Isso é feito em muitos projetos. Para carregar as informações do mapa e trabalhar com elas, era necessário fazer chamadas à API correspondente por meio de uma chave. Mas meu cliente se esqueceu de configurar o serviço que estava usando para restringir as fontes das quais o serviço poderia receber solicitações usando aquela chave específica. Não é difícil imaginar um ataque simples, que consiste em esgotar a cota de uso de recursos de um serviço de mapas, enviando muitas solicitações a ele. Isso pode custar muito dinheiro ao usuário de tal serviço. Ou,mesmo "melhor" (do ponto de vista de um atacante), tal ataque pode levar ao fato de que as partes do projeto do cliente que estão vinculadas às cartas, simplesmente "caem".



Os arquivos JS são usados ​​por hackers para mais do que apenas encontrar dados secretos. Afinal, tais arquivos são o código da sua aplicação, que pode ser visto por qualquer pessoa interessada neste código. Um bom hacker pode, depois de ler cuidadosamente o código, entender a abordagem de nomenclatura de entidade usada nele, descobrir os caminhos para a API e encontrar comentários valiosos. Achados como esses são formatados como uma lista de palavras que são enviadas para scanners automáticos. É o que chamamos de "varredura automatizada inteligente", em que um hacker combina ferramentas automatizadas e as informações que coletou sobre um projeto específico.



Aqui está um comentário real da página inicial de um projeto, que fala em texto simples sobre APIs inseguras das quais qualquer pessoa pode obter dados:



/* Debug ->
domain.com/api/v3 not yet in production 
and therefore not using auth guards yet 
use only for debugging purposes until approved */


“O que fazer?



  • . . , , .
  • API. , . , .
  • , , . , , , , , , . , .
  • , . . , . grep gf . . , , .
  • -. , - . 100% . - — .


, -



O Internet Archive (também conhecido como "Wayback Machine") armazena instantâneos periódicos de sites. Este projeto permite que você veja como era a Internet há muitos anos. Os dados do arquivo são de considerável interesse para hackers que precisam coletar informações sobre um determinado projeto. Você pode verificar arquivos em busca de variantes antigas de sites usando ferramentas como waybackurls (com base em waybackurls.py ). Isso significa que mesmo se você encontrar uma chave no código do site e removê-la de lá, mas não girar as chaves, os hackers podem encontrar essa chave na versão antiga do site e usar essa chave para hackear o sistema.



Veja o que fazer se você encontrar uma chave onde ela não deveria estar:



  1. Crie uma chave projetada para substituir a chave comprometida.
  2. Libere uma nova versão do código que usa a nova chave. Este código deve ser reescrito para que não haja linhas que facilitam a identificação da chave.
  3. Remova ou desative a chave antiga.


▍ O Internet Archive não é o único lugar para encontrar as chaves



O código antigo oferece aos invasores uma ampla variedade de informações de interesse.



  • Caminhos secretos da API. Estamos falando sobre endpoints de API inseguros que o desenvolvedor pensou que nunca seriam compartilhados. Embora os caminhos que um hacker descobre possam não ser úteis para eles, esses caminhos podem ajudar a entender o design da API de um projeto e suas convenções de API. Depois que o código do site entra em produção, o desenvolvedor não tem como esconder esse código de olhos curiosos. É muito importante lembrar disso.
  • -. , API, . , . , , . , -. , , . , , . , s https.


GitHub



O GitHub é uma mina de ouro para hackers. Se você souber onde procurar, poderá encontrar muitas coisas interessantes usando ferramentas de pesquisa simples. Se a conta do GitHub de sua organização não estiver protegida por autenticação multifator, todos os funcionários da organização, sem exceção, estarão enfrentando falhas de segurança. É bem possível que alguns dos funcionários usem a mesma senha em todos os lugares, e que essa senha já tenha sido roubada deles por algum outro sistema. Um hacker que está interessado em uma determinada organização pode automatizar facilmente a busca por senhas comprometidas, mas o que posso dizer, ele pode encontrar essas senhas manualmente.



A lista de funcionários de uma organização pode ser criada usando técnicas de inteligência de código aberto (OSINT). O LinkedIn ou uma lista pública de funcionários da empresa do GitHub pode ajudar o invasor nisso.



Se, por exemplo, alguém decidiu hackear o Tesla, então ele pode começar a estudar a empresa a partir desta página:



https://api.github.com/orgs/teslamotors/members


E mesmo que uma empresa não use o GitHub como plataforma git, ainda há algo valioso para encontrar no GitHub. Basta que pelo menos um dos funcionários da empresa utilize esta plataforma, por exemplo, para um projeto de casa. Se algo secreto sobre uma empresa aparecer no código deste projeto (ou na história do git), isso será suficiente para penetrar nos sistemas dessa empresa.



Manter o controle do histórico completo de mudanças feitas em cada projeto é a natureza do git. À luz dos problemas de segurança, esse fato desempenha um papel importante. Em outras palavras, toda alteração feita no código por qualquer pessoa que tenha acesso a qualquer um dos sistemas de uma organização coloca essa organização em risco.



“Por que isso está acontecendo?



  • As empresas não verificam vulnerabilidades em seus sistemas.
  • , , .
  • , , ( , , 1%), ( — git, , , ).
  • , . .


▍ GitHub



Existem coisas como "idiotas" - consultas de pesquisa especiais que usam recursos diferentes dos mecanismos de pesquisa para encontrar o que está relacionado a certos dados. Aqui está uma lista interessante de pesquisas semelhantes para o Google por exploit-db.com.



Se você quiser se aprofundar neste tópico, e eu recomendo que o faça, antes de fornecer uma pequena lista de strings usadas para encontrar chaves e senhas no GitHub, sugiro que você leia este valioso material, escrito por um talentoso pesquisador de segurança de sistema. Ele fala sobre como, o quê e onde pesquisar no GitHub, como usar idiotas e descreve em detalhes o processo manual de localização de dados secretos.



As estradas usadas no GitHub não são tão complexas quanto as usadas no Google. A questão é que o GitHub simplesmente não oferece ao usuário os mesmos recursos de pesquisa avançada que o Google oferece. Independentemente disso, pesquisar os repositórios GitHub corretamente pode fazer maravilhas. Tente pesquisar as seguintes linhas no repositório de seu interesse:



password
dbpassword
dbuser
access_key
secret_access_key
bucket_password
redis_password
root_password


E se você tentar pesquisar arquivos específicos usando consultas como filename:.npmrc _authou filename:.htpasswd, poderá filtrar os resultados da pesquisa por tipos de vazamento de dados. Aqui está outra boa peça sobre esse assunto.



▍ Medidas de mitigação de risco associadas ao GitHub



  • Faça a varredura de seu código em busca de vulnerabilidades parte do processo de CI. A excelente ferramenta GitRob pode ajudá-lo com isso .
  • . GitRob . , no-expand-orgs.
  • . GitRob, , 500 , , -commit-depth <#number>.
  • GitHub !
  • , , , , . G Suite Active Directory. , .


Após a publicação desse material, alguns de seus leitores fizeram comentários valiosos sobre a complexidade das senhas e sua rotação, bem como sobre o uso de hardware de proteção das informações.



Aqui estão os comentários de @ codemouse92 :



Use senhas complexas e exclusivas sempre que o logon com senha for usado. Mas lembre-se de que uma senha complexa não é necessariamente aquela que é uma mistura misteriosa de letras, números e caracteres especiais. A melhor estratégia agora é usar frases longas como senhas. Eu gostaria de fazer uma observação sobre os gerenciadores de senhas. Embora valha a pena usar esses programas, ainda é melhor usar senhas, que são frases que os usuários lembram e podem inserir por conta própria.


Aqui está o que o usuário @corymcdonald diz :



Onde eu trabalho, todos recebem hardware de autenticação multifator. Cada um possui 2 dispositivos YubiKey. Além disso, cada equipe usa o gerenciador de senhas 1Password e cada equipe tem seu próprio armazenamento de senhas. Quando um funcionário sai da empresa, a equipe de suporte alterna as senhas em todos os cofres aos quais o funcionário tinha acesso. Pessoalmente, por exemplo, cometi um erro imperdoável ao fazer upload de chaves para acessar a AWS no GitHub. É recomendado que você verifique suas coisas usando git-secrets antes de fazer commit . Isso evitará que o que parece ser informação classificada seja compartilhada.


Hackers usam Google



Agora que temos uma compreensão básica dos idiotas, podemos falar sobre o uso de consultas de pesquisa específicas no Google. Aqui você pode encontrar coisas incríveis com a ajuda deles. O Google é um poderoso mecanismo de busca que permite a você construir consultas, descrevendo strings que devem ou não estar presentes nos dados que você está procurando. O Google, entre outras coisas, permite que você pesquise arquivos com certas extensões, pode pesquisar por domínios especificados, por URL. Dê uma olhada na seguinte string de pesquisa:



"MySQL_ROOT_PASSWORD:" "docker-compose" ext:yml


Essa string é projetada para pesquisar arquivos com a extensão yml, além disso, esses devem ser arquivos docker-composenos quais os desenvolvedores costumam armazenar senhas. Senhas não particularmente exclusivas. Tente fazer uma pesquisa no Google para esta string. Você ficará surpreso com o que encontrará.



Outras sequências de pesquisa interessantes podem ser a procura de chaves RSA ou credenciais AWS. Aqui está outro exemplo:



"-----BEGIN RSA PRIVATE KEY-----" ext:key


Aqui, possibilidades infinitas se abrem diante de nós. A qualidade da pesquisa depende apenas do nível de criatividade do pesquisador e de quão bem ele está familiarizado com os vários sistemas. Aqui está uma grande lista de Google Dorks se você quiser experimentar.



Os hackers examinam os sistemas em que estão interessados



Quando um pesquisador de segurança (ou um hacker motivado) está muito interessado em um determinado sistema, ele começa a estudar o sistema em profundidade. Ele consegue conhecê-la de perto. Ele está interessado em terminais de API, convenções de nomenclatura para entidades, recursos de interação de partes internas de sistemas, acesso a diferentes versões do sistema se diferentes versões dele forem usadas simultaneamente.



Uma abordagem não muito boa para proteger APIs é complicar os caminhos de acesso, ocultando-os usando algo como um gerador de caracteres aleatórios. Este não é um substituto para mecanismos de segurança reais. Os pesquisadores de segurança estão tentando encontrar caminhos de acesso não seguros para sistemas, endpoints de API, por exemplo, usando ferramentas para busca "difusa" de vulnerabilidades. Essas ferramentas usam listas de palavras, criam caminhos a partir delas e testam esses caminhos analisando as respostas que recebem ao tentar acessá-las. Esse scanner não encontrará um ponto final, o caminho para o qual é representado por um conjunto de caracteres completamente aleatório. Mas essas ferramentas são ótimas para identificar padrões e encontrar terminais que os proprietários do sistema esqueceram ou nunca souberam.



Lembre-se de que "segurança através da obscuridade" não é a melhor maneira de proteger os sistemas (embora você não deva ignorá-la completamente).



É aqui que os idiotas do GitHub, sobre os quais falamos acima, vêm em auxílio dos invasores. Saber quais regras são usadas ao construir caminhos para os terminais do sistema (por exemplo, algo assim api.mydomain.com/v1/payments/...) pode ser de grande ajuda para um hacker. Pesquisar o repositório GitHub da empresa (e os repositórios de seus funcionários) por strings relacionadas à API geralmente encontrará caminhos que incluem caracteres aleatórios.



Mas "strings aleatórias", no entanto, têm seu lugar nos sistemas. Seu uso é sempre melhor do que usar sequências de identificadores de recursos, strings como userse nos caminhos para a API orders.



Aqui está o incrível repositório SecLists, que contém muitas strings usadas ao nomear entidades. Ele é usado por quase todos na indústria de proteção de dados. Freqüentemente, esses materiais são modificados para um sistema específico. Outra ferramenta que pode ser usada para encontrar caminhos "criptografados" é o FFuf , um programa de lógica fuzzy extremamente rápido escrito em Go.



Resultado



Os problemas de segurança costumam ser esquecidos nas partidas. Programadores e gerentes geralmente priorizam a velocidade de desenvolvimento e a frequência de lançamentos de produtos, sacrificando a qualidade e a segurança. Aqui vemos a inclusão de informações secretas no código que chega aos repositórios, o uso das mesmas chaves em diferentes locais do sistema, o uso de chaves de acesso onde você pode usar outra coisa. Às vezes pode parecer que algo assim permite que você agilize o trabalho no projeto, mas, com o tempo, pode levar a consequências muito ruins.



Neste post, tentei mostrar como strings que parecem estar protegidas por serem armazenadas em um repositório privado podem facilmente se tornar públicas. O mesmo vale para um clone de repositório, feito por um funcionário bem-intencionado e não destinado a curiosos, mas que se tornou público. No entanto, você pode construir uma base para operação segura usando uma ferramenta de compartilhamento de senha segura, usando um repositório centralizado de segredos, configurando políticas de segurança de senha e autenticação multifator. Isso permitirá, sem ignorar a segurança, não diminuir a velocidade de trabalho no projeto.



Quando se trata de proteção de informações, a ideia de que a velocidade é o mais importante não funciona muito bem aqui.



Obter conhecimento de como os hackers trabalham geralmente é um primeiro passo muito bom para entender o que é segurança da informação. Este é o primeiro passo para proteger os sistemas. Ao proteger sistemas, considere os métodos acima para penetrá-los e o fato de que os hackers usam um conjunto bastante limitado de tais métodos. Recomenda-se considerar do ponto de vista da segurança absolutamente tudo que de uma forma ou de outra esteja relacionado a um determinado sistema, independentemente de se tratar de mecanismos externos ou internos.



A segurança do sistema às vezes pode ser percebida como não muito importante, mas demorada e agitada. Mas fique tranquilo, as etapas simples que você executa para proteger seus sistemas podem evitar muitos problemas.



Como você protege seus sistemas?










All Articles