Github Security
O que é o Github
(De aqui) Em um nível alto, o GitHub é um site e um serviço baseado em nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código, bem como rastrear e controlar as alterações em seu código.
Informações Básicas
pageBasic Github InformationReconhecimento Externo
Os repositórios do Github podem ser configurados como públicos, privados e internos.
Privado significa que apenas pessoas da organização poderão acessá-los
Interno significa que apenas pessoas da empresa (uma empresa pode ter várias organizações) poderão acessá-lo
Público significa que toda a internet poderá acessá-lo.
Caso você saiba o usuário, repositório ou organização que deseja atacar, você pode usar dorks do github para encontrar informações sensíveis ou procurar por vazamentos de informações sensíveis em cada repositório.
Dorks do Github
O Github permite pesquisar algo especificando como escopo um usuário, um repositório ou uma organização. Portanto, com uma lista de strings que vão aparecer próximas a informações sensíveis, você pode facilmente procurar por informações sensíveis potenciais em seu alvo.
Ferramentas (cada ferramenta contém sua lista de dorks):
Vazamentos do Github
Por favor, note que os dorks do github também são destinados a procurar vazamentos usando opções de pesquisa do github. Esta seção é dedicada a ferramentas que irão baixar cada repositório e procurar por informações sensíveis neles (até mesmo verificando certa profundidade de commits).
Ferramentas (cada ferramenta contém sua lista de regexes):
Ao procurar vazamentos em um repositório e executar algo como git log -p, não se esqueça de que pode haver outras ramificações com outros commits contendo segredos!
Forks Externos
É possível comprometer repositórios abusando de pull requests. Para saber se um repositório é vulnerável, você precisa principalmente ler as configurações yaml do Github Actions. Mais informações sobre isso abaixo.
Reforço da Organização
Privilégios de Membros
Existem alguns privilégios padrão que podem ser atribuídos aos membros da organização. Estes podem ser controlados a partir da página https://github.com/organizations/<org_name>/settings/member_privileges ou da API de Organizações.
Permissões base: Os membros terão permissão Nenhuma/Leitura/Escrita/Administração sobre os repositórios da organização. Recomenda-se Nenhuma ou Leitura.
Fork de repositório: Se não for necessário, é melhor não permitir que os membros façam fork dos repositórios da organização.
Criação de páginas: Se não for necessário, é melhor não permitir que os membros publiquem páginas dos repositórios da organização. Se necessário, você pode permitir a criação de páginas públicas ou privadas.
Solicitações de acesso a integrações: Com isso habilitado, colaboradores externos poderão solicitar acesso para aplicativos GitHub ou OAuth acessarem esta organização e seus recursos. Geralmente é necessário, mas se não for, é melhor desabilitar.
Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar
Alteração de visibilidade do repositório: Se habilitado, membros com permissões de administração para o repositório poderão alterar sua visibilidade. Se desabilitado, apenas os proprietários da organização podem alterar as visibilidades dos repositórios. Se você não quer que as pessoas tornem as coisas públicas, certifique-se de que isso está desabilitado.
Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar
Exclusão e transferência de repositórios: Se habilitado, membros com permissões de administração para o repositório poderão excluir ou transferir repositórios públicos e privados.
Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar
Permitir que membros criem equipes: Se habilitado, qualquer membro da organização poderá criar novas equipes. Se desabilitado, apenas os proprietários da organização podem criar novas equipes. É melhor ter isso desabilitado.
Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar
Mais coisas podem ser configuradas nesta página, mas as anteriores são as mais relacionadas à segurança.
Configurações de Ações
Várias configurações relacionadas à segurança podem ser configuradas para ações a partir da página https://github.com/organizations/<org_name>/settings/actions.
Observe que todas essas configurações também podem ser definidas em cada repositório independentemente
Políticas de ações do Github: Permite indicar quais repositórios podem executar fluxos de trabalho e quais fluxos de trabalho devem ser permitidos. É recomendado especificar quais repositórios devem ser permitidos e não permitir que todas as ações sejam executadas.
Fluxos de trabalho de pull request de fork de colaboradores externos: É recomendado exigir aprovação para todos os colaboradores externos.
Não encontrei uma API com essa informação, compartilhe se você encontrar
Executar fluxos de trabalho de pull requests de fork: É altamente desencorajado executar fluxos de trabalho de pull requests pois os mantenedores da origem do fork terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
Não encontrei uma API com essa informação, compartilhe se você encontrar
Permissões de fluxo de trabalho: É altamente recomendado dar apenas permissões de leitura de repositório. É desencorajado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN fornecido para a execução de fluxos de trabalho.
Integrações
Me avise se você souber o endpoint da API para acessar essas informações!
Política de acesso de aplicativos de terceiros: É recomendado restringir o acesso a cada aplicativo e permitir apenas os necessários (após revisão).
Aplicativos do GitHub instalados: É recomendado permitir apenas os necessários (após revisão).
Recon & Ataques abusando de credenciais
Para este cenário, vamos supor que você obteve algum acesso a uma conta do github.
Com Credenciais de Usuário
Se de alguma forma você já possui credenciais de um usuário dentro de uma organização, você pode simplesmente fazer login e verificar quais funções de empresa e organização você possui, se você é um membro comum, verificar quais permissões os membros comuns têm, em quais grupos você está, quais permissões você possui sobre quais repositórios e como os repositórios estão protegidos.
Observe que a autenticação de dois fatores (2FA) pode ser usada, então você só poderá acessar essas informações se também passar por essa verificação.
Observe que se você conseguir roubar o cookie user_session (atualmente configurado com SameSite: Lax) você pode se passar completamente pelo usuário sem precisar de credenciais ou 2FA.
Verifique a seção abaixo sobre burlas de proteção de branches caso seja útil.
Com Chave SSH do Usuário
O Github permite que usuários configurem chaves SSH que serão usadas como método de autenticação para implantar código em seu nome (sem aplicação de 2FA).
Com essa chave, você pode fazer alterações nos repositórios onde o usuário tem alguns privilégios, no entanto, você não pode usá-la para acessar a API do github para enumerar o ambiente. No entanto, você pode enumerar configurações locais para obter informações sobre os repositórios e usuários aos quais você tem acesso:
Se o usuário configurou seu nome de usuário como seu nome de usuário do github, você pode acessar as chaves públicas que ele definiu em sua conta em https://github.com/<github_username>.keys, você pode verificar isso para confirmar se a chave privada que você encontrou pode ser usada.
Chaves SSH também podem ser definidas em repositórios como chaves de implantação. Qualquer pessoa com acesso a essa chave poderá lançar projetos a partir de um repositório. Geralmente, em um servidor com diferentes chaves de implantação, o arquivo local ~/.ssh/config fornecerá informações sobre qual chave está relacionada.
Chaves GPG
Como explicado aqui às vezes é necessário assinar os commits ou você pode ser descoberto.
Verifique localmente se o usuário atual possui alguma chave com:
Com Token de Usuário
Para uma introdução sobre Tokens de Usuário, confira as informações básicas.
Um token de usuário pode ser usado em vez de uma senha para Git sobre HTTPS, ou pode ser usado para autenticar na API usando Autenticação Básica. Dependendo dos privilégios associados a ele, você pode ser capaz de realizar diferentes ações.
Um token de usuário se parece com isso: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Com Aplicativo Oauth
Para uma introdução sobre Aplicativos Github Oauth, confira as informações básicas.
Um atacante pode criar um Aplicativo Oauth malicioso para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
Estes são os escopos que um aplicativo Oauth pode solicitar. Sempre verifique os escopos solicitados antes de aceitá-los.
Além disso, como explicado nas informações básicas, organizações podem conceder/negar acesso a aplicativos de terceiros a informações/repos/ações relacionadas à organização.
Com Aplicativo Github
Para uma introdução sobre Aplicativos Github, confira as informações básicas.
Um atacante pode criar um Aplicativo Github malicioso para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
Além disso, como explicado nas informações básicas, organizações podem conceder/negar acesso a aplicativos de terceiros a informações/repos/ações relacionadas à organização.
Comprometimento e Abuso da Ação Github
Existem várias técnicas para comprometer e abusar de uma Ação Github, verifique-as aqui:
pageAbusing Github ActionsBypass de Proteção de Branch
Exigir um número de aprovações: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você só tem acesso à conta de onde criou o PR, não pode aceitar seu próprio PR. No entanto, se tiver acesso a um ambiente de Ação Github dentro do repositório, usando o GITHUB_TOKEN você pode ser capaz de aprovar seu PR e obter 1 aprovação dessa forma.
Observação para isso e para a restrição de Proprietários de Código que geralmente um usuário não poderá aprovar seus próprios PRs, mas se puder, pode abusar para aceitar seus PRs.
Ignorar aprovações quando novos commits são enviados: Se isso não estiver configurado, você pode enviar código legítimo, aguardar até que alguém aprove e inserir código malicioso e mesclá-lo no branch protegido.
Exigir revisões dos Proprietários de Código: Se isso estiver ativado e você for um Proprietário de Código, você poderia fazer uma Ação Github criar seu PR e então aprová-lo você mesmo.
Quando um arquivo CODEOWNER está mal configurado o Github não reclama, mas não o utiliza. Portanto, se estiver mal configurado, sua proteção de Proprietários de Código não será aplicada.
Permitir que atores especificados ignorem os requisitos de pull request: Se você for um desses atores, pode ignorar as proteções de pull request.
Incluir administradores: Se isso não estiver configurado e você for administrador do repositório, pode ignorar essas proteções de branch.
Sequestro de PR: Você pode ser capaz de modificar o PR de outra pessoa adicionando código malicioso, aprovando o PR resultante e mesclando tudo.
Removendo Proteções de Branch: Se você for um administrador do repositório, pode desativar as proteções, mesclar seu PR e reativar as proteções.
Burlando proteções de push: Se um repositório permite apenas certos usuários enviar push (mesclar código) em branches (a proteção de branch pode estar protegendo todos os branches especificando o caractere curinga
*).Se você tem acesso de escrita sobre o repositório, mas não pode enviar código devido à proteção de branch, ainda pode criar um novo branch e dentro dele criar uma ação github que é acionada quando o código é enviado. Como a proteção de branch não protegerá o branch até que seja criado, este primeiro envio de código para o branch irá executar a ação github.
Burlando Proteções de Ambientes
Para uma introdução sobre Ambiente Github, confira as informações básicas.
Caso um ambiente possa ser acessado de todos os branches, ele não está protegido e você pode acessar facilmente os segredos dentro do ambiente. Note que você pode encontrar repositórios onde todos os branches estão protegidos (especificando seus nomes ou usando *), nesse cenário, encontre um branch onde você possa enviar código e você pode extrair os segredos criando uma nova ação github (ou modificando uma).
Observe que você pode encontrar o caso extremo onde todos os branches estão protegidos (via curinga *) é especificado quem pode enviar código para os branches (você pode especificar isso na proteção de branch) e seu usuário não é permitido. Ainda assim, você pode executar uma ação github personalizada porque pode criar um branch e usar o gatilho de envio sobre si mesmo. A proteção de branch permite o envio para um novo branch, então a ação github será acionada.
Note que após a criação do branch a proteção do branch será aplicada ao novo branch e você não poderá modificá-lo, mas nesse momento você já terá extraído os segredos.
Persistência
Gerar token de usuário
Roubar tokens do Github dos segredos
Exclusão dos resultados e branches do fluxo de trabalho
Dar mais permissões a toda a organização
Criar webhooks para exfiltrar informações
Convidar colaboradores externos
Remover webhooks usados pelo SIEM
Criar/modificar Ação do Github com uma porta dos fundos
Encontrar Ação do Github vulnerável para injeção de comando via modificação de valor secreto
Commits de Impostores - Porta dos fundos via commits no repositório
No Github é possível criar um PR para um repositório a partir de um fork. Mesmo que o PR não seja aceito, um id de commit dentro do repositório original será criado para a versão fork do código. Portanto, um atacante poderia fixar o uso de um commit específico de um repositório aparentemente legítimo que não foi criado pelo proprietário do repositório.
Como este:
Para mais informações, consulte https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Última actualización