Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
(De aqui) Em um nível alto, GitHub é um site e serviço baseado em nuvem que ajuda desenvolvedores a armazenar e gerenciar seu código, além de rastrear e controlar alterações em seu código.
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ê conheça o usuário, repositório ou organização que deseja atacar, você pode usar github dorks para encontrar informações sensíveis ou pesquisar por vazamentos de informações sensíveis em cada repositório.
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 pesquisar por informações sensíveis potenciais em seu alvo.
Ferramentas (cada ferramenta contém sua lista de dorks):
Por favor, note que os dorks do github também são destinados a pesquisar vazamentos usando opções de pesquisa do github. Esta seção é dedicada a aquelas ferramentas que irão baixar cada repositório e procurar informações sensíveis neles (até verificando certa profundidade de commits).
Ferramentas (cada ferramenta contém sua lista de regexes):
Quando você procura por vazamentos em um repositório e executa algo como git log -p, não se esqueça de que pode haver outras branches com outros commits contendo segredos!
É 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 das Ações do Github. Mais informações sobre isso abaixo.
Mesmo que deletados ou internos, pode ser possível obter dados sensíveis de forks de repositórios do github. Confira aqui:
Accessible Deleted Data in GithubExistem 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 básicas: Os membros terão a permissão Nenhuma/Leitura/escrita/Admin sobre os repositórios da organização. O recomendado é Nenhuma ou Leitura.
Forking de repositórios: 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 à integração: Com isso habilitado, colaboradores externos poderão solicitar acesso a aplicativos do GitHub ou OAuth para acessar 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
Mudança de visibilidade do repositório: Se habilitado, membros com permissões admin para o repositório poderão mudar sua visibilidade. Se desabilitado, apenas os proprietários da organização podem mudar as visibilidades dos repositórios. Se você não quiser que as pessoas tornem as coisas públicas, certifique-se de que isso esteja 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 admin 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.
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.
Note que todas essas configurações também podem ser definidas em cada repositório de forma independente
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 consegui encontrar uma API com essa informação, compartilhe se você encontrar
Executar fluxos de trabalho de pull requests de fork: É altamente desaconselhado executar fluxos de trabalho de pull requests pois os mantenedores do fork de origem terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
Não consegui encontrar 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. É desaconselhado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN dado aos fluxos de trabalho em execução.
Deixe-me saber se você conhece o endpoint da API para acessar essa informação!
Política de acesso a aplicativos de terceiros: É recomendado restringir o acesso a todos os aplicativos e permitir apenas os necessários (após revisá-los).
Aplicativos do GitHub instalados: É recomendado permitir apenas os necessários (após revisá-los).
Para este cenário, vamos supor que você obteve algum acesso a uma conta do github.
Se de alguma forma você já tem credenciais de um usuário dentro de uma organização, você pode apenas fazer login e verificar quais papéis de empresa e organização você tem, se você é um membro comum, verifique quais permissões os membros comuns têm, em quais grupos você está, quais permissões você tem sobre quais repositórios e como os repositórios estão protegidos.
Note que 2FA pode ser usado, então você só poderá acessar essas informações se também conseguir passar por essa verificação.
Note que se você conseguir roubar o cookie user_session (atualmente configurado com SameSite: Lax), você pode impersonar completamente o usuário sem precisar de credenciais ou 2FA.
Verifique a seção abaixo sobre bypasses de proteção de branch caso seja útil.
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 (nenhuma 2FA é aplicada).
Com essa chave, você pode realizar alterações em 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 o usuário ao qual 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 configurou 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 configuradas em repositórios como chaves de implantação. Qualquer pessoa com acesso a essa chave poderá iniciar projetos de um repositório. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local ~/.ssh/config fornecerá informações sobre a chave relacionada.
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:
Para uma introdução sobre Tokens de Usuário, verifique 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 via 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
Para uma introdução sobre Aplicativos Oauth do Github, verifique as informações básicas.
Um atacante pode criar um Aplicativo Oauth malicioso para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
Esses são os escopos que um aplicativo Oauth pode solicitar. Um deve sempre verificar os escopos solicitados antes de aceitá-los.
Além disso, como explicado nas informações básicas, as organizações podem conceder/negá-los acesso a aplicativos de terceiros a informações/repos/ações relacionadas à organização.
Para uma introdução sobre Aplicativos do Github, verifique as informações básicas.
Um atacante pode criar um Aplicativo Github malicioso para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
Além disso, como explicado nas informações básicas, as organizações podem conceder/negá-los acesso a aplicativos de terceiros a informações/repos/ações relacionadas à organização.
Existem várias técnicas para comprometer e abusar de uma Ação do Github, verifique-as aqui:
Abusing Github ActionsExigir um número de aprovações: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você tiver apenas a conta de onde criou o PR, não poderá aceitar seu próprio PR. No entanto, se você tiver acesso a um ambiente de Ação do Github dentro do repositório, usando o GITHUB_TOKEN, você pode ser capaz de aprovar seu PR e obter 1 aprovação dessa forma.
Nota 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 você puder, pode abusar disso para aceitar seus PRs.
Rejeitar aprovações quando novos commits são enviados: Se isso não estiver configurado, você pode enviar código legítimo, esperar até que alguém o aprove, e colocar código malicioso e mesclá-lo na branch protegida.
Exigir revisões de Proprietários de Código: Se isso estiver ativado e você for um Proprietário de Código, poderá fazer uma Ação do 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, a proteção de Proprietários de Código não é aplicada.
Permitir que atores especificados contornem os requisitos de pull request: Se você for um desses atores, pode contornar as proteções de pull request.
Incluir administradores: Se isso não estiver configurado e você for administrador do repositório, pode contornar 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 você mesmo 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.
Contornando proteções de push: Se um repositório somente permite que certos usuários enviem push (mesclem código) em branches (a proteção de branch pode estar protegendo todas as branches especificando o curinga *).
Se você tiver acesso de escrita sobre o repositório, mas não for permitido enviar código por causa da proteção de branch, ainda pode criar uma nova branch e dentro dela criar uma ação do github que é acionada quando o código é enviado. Como a proteção de branch não protegerá a branch até que ela seja criada, esse primeiro push de código para a branch executará a ação do github.
Para uma introdução sobre Ambiente do Github, verifique as informações básicas.
Caso um ambiente possa ser acessado de todas as branches, ele não está protegido e você pode facilmente acessar os segredos dentro do ambiente. Note que você pode encontrar repositórios onde todas as branches estão protegidas (especificando seus nomes ou usando *); nesse cenário, encontre uma branch onde você possa enviar código e você pode exfiltrar os segredos criando uma nova ação do github (ou modificando uma).
Note que você pode encontrar o caso extremo onde todas as branches estão protegidas (via curinga *), é especificado quem pode enviar código para as branches (você pode especificar isso na proteção de branch) e seu usuário não é permitido. Você ainda pode executar uma ação do github personalizada porque pode criar uma branch e usar o gatilho de push sobre ela mesma. A proteção de branch permite o push para uma nova branch, então a ação do 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.
Gerar token de usuário
Roubar tokens do github de segredos
Deleção de resultados e branches de workflow
Dar mais permissões a toda a org
Criar webhooks para exfiltrar informações
Convidar colaboradores externos
Remover webhooks usados pelo SIEM
Criar/modificar Github Action com uma porta dos fundos
Encontrar Github Action vulnerável a injeção de comando via modificação de valor de segredo
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 commit id 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
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
